From jonathan.gibbons at oracle.com Fri Aug 1 16:32:58 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 01 Aug 2014 09:32:58 -0700 Subject: Spec mailing lists In-Reply-To: <53DAC42A.4050205@oracle.com> References: <53DAC42A.4050205@oracle.com> Message-ID: <53DBC13A.2090601@oracle.com> Alex, Sounds good. Go for it! -- Jon On 07/31/2014 03:33 PM, Alex Buckley wrote: > Jon, > > Readers of The Java Language Specification and The JVM Specification > can presently send feedback about errors, omissions, and ambiguities > in each spec to jls-comments_ww at oracle.com and > jvms-comments_ww at oracle.com. > > While this is a useful alternative to filing spec bugs at > bugs.java.com, it is still rather unsatisfactory because the addresses > go to private mailboxes. This makes it difficult for engineers to > discuss the feedback, and there is no public archive. > > I would like to request that the Compiler Group sponsors a mailing list: > > jls-jvms-spec-comments at openjdk.java.net > > where anyone can send feedback about either spec, and where Oracle > engineers who maintain the specs can discuss the best course of > action. Some particulars: > > 1. Anyone can post to the list without subscribing. All posts will be > held for moderation. An on-topic post might, say, claim that a rule in > the JLS performs an incomplete case analysis, or note a problem with > the files at http://docs.oracle.com/javase/specs/. An off-topic post, > such as a proposal for a new Java language feature, would be discarded. > > 2. The initial subscribers will be myself and Dan Smith. Where we use > the list to discuss a piece of feedback, we will cc the original poster. > > 3. The list will be licensed under comment-and-evaluation terms, and > publicly archived at http://mail.openjdk.java.net/mailman/listinfo. > > 4. The list is preferred to various JSR lists that were used to > specify Java SE 8 and are still occasionally used to raise spec issues > (eventually they will be disabled) : > > lambda-spec-{experts,observers,comments} > type-annotations-spec-{experts,observers,comments} > enhanced-metadata-spec-discuss > > Alex From dl at cs.oswego.edu Sat Aug 2 11:51:03 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 02 Aug 2014 07:51:03 -0400 Subject: Spec mailing lists In-Reply-To: <53DAC42A.4050205@oracle.com> References: <53DAC42A.4050205@oracle.com> Message-ID: <53DCD0A7.2080809@cs.oswego.edu> On 07/31/2014 06:33 PM, Alex Buckley wrote: > Jon, > > Readers of The Java Language Specification and The JVM Specification can > presently send feedback about errors, omissions, and ambiguities in each spec to > jls-comments_ww at oracle.com and jvms-comments_ww at oracle.com. > > While this is a useful alternative to filing spec bugs at bugs.java.com, it is > still rather unsatisfactory because the addresses go to private mailboxes. This > makes it difficult for engineers to discuss the feedback, and there is no public > archive. > > I would like to request that the Compiler Group sponsors a mailing list: > > jls-jvms-spec-comments at openjdk.java.net > > where anyone can send feedback about either spec, and where Oracle engineers who > maintain the specs can discuss the best course of action. Some particulars: This all sounds good, although it would be nice to also regularize a "transition plan" for efforts (for example, the upcoming memory model updates; JDK8 lambdas) that result in spec updates. Probably nothing special beyond saying that upon integration of specs, follow-ups go here? -Doug > > 1. Anyone can post to the list without subscribing. All posts will be held for > moderation. An on-topic post might, say, claim that a rule in the JLS performs > an incomplete case analysis, or note a problem with the files at > http://docs.oracle.com/javase/specs/. An off-topic post, such as a proposal for > a new Java language feature, would be discarded. > > 2. The initial subscribers will be myself and Dan Smith. Where we use the list > to discuss a piece of feedback, we will cc the original poster. > > 3. The list will be licensed under comment-and-evaluation terms, and publicly > archived at http://mail.openjdk.java.net/mailman/listinfo. > > 4. The list is preferred to various JSR lists that were used to specify Java SE > 8 and are still occasionally used to raise spec issues (eventually they will be > disabled) : > > lambda-spec-{experts,observers,comments} > type-annotations-spec-{experts,observers,comments} > enhanced-metadata-spec-discuss > > Alex > From timeroot.alex at gmail.com Sun Aug 3 16:52:08 2014 From: timeroot.alex at gmail.com (Alex Meiburg) Date: Sun, 3 Aug 2014 09:52:08 -0700 Subject: Duplicate compilation attempt when code is too large Message-ID: Hi, This is my first time posting to this list, and I'm not sure of the right protocol -- I've got the following patch to submit. When jsr/ret were in use, if a method ran over the 64k code limit, it would try compilation again with more aggressive space optimization. Since jsr/ret aren't used any more, this just means that it takes twice as long to report the error to the user. There's also some (unused) code in dump() that was printing to sysout where it should have been printing to syserr. I have the patch attached, how/where do I submit it? Please excuse my ignorance, I couldn't find the answer. Thanks! -- Alexander Meiburg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2564.patch Type: application/octet-stream Size: 2028 bytes Desc: not available URL: From alex.buckley at oracle.com Mon Aug 4 19:49:09 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 04 Aug 2014 12:49:09 -0700 Subject: Spec mailing lists In-Reply-To: <53DCD0A7.2080809@cs.oswego.edu> References: <53DAC42A.4050205@oracle.com> <53DCD0A7.2080809@cs.oswego.edu> Message-ID: <53DFE3B5.4090603@oracle.com> On 8/2/2014 4:51 AM, Doug Lea wrote: > This all sounds good, although it would be nice to also regularize > a "transition plan" for efforts (for example, the upcoming memory model > updates; JDK8 lambdas) that result in spec updates. Probably nothing > special beyond saying that upon integration of specs, follow-ups > go here? Not necessarily. The Maintenance Lead (ML) for a JSR is the official contact for bugs in that JSR's spec. Just because a JSR's spec is integrated into the text of the JLS or JVMS doesn't mean that the ML's responsibilities diminish. In 2025, substantive feedback about the JMM9 spec developed in 2015 should be sent to the ML, not jls-jvms-spec-comments. To the extent that people send substantive feedback to jls-jvms-spec-comments anyway, the owner of that alias should not hesitate to bounce mails to the correct ML. Alex From jeremymanson at google.com Wed Aug 6 06:40:50 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 5 Aug 2014 23:40:50 -0700 Subject: Spec mailing lists In-Reply-To: <53DFE3B5.4090603@oracle.com> References: <53DAC42A.4050205@oracle.com> <53DCD0A7.2080809@cs.oswego.edu> <53DFE3B5.4090603@oracle.com> Message-ID: Alex, Although we discussed this in person, I was a little unclear about the single-point-of-failureness of it. What happens when the ML dies? Or even goes on vacation? Are they really the sole authority? Jeremy On Mon, Aug 4, 2014 at 12:49 PM, Alex Buckley wrote: > On 8/2/2014 4:51 AM, Doug Lea wrote: > >> This all sounds good, although it would be nice to also regularize >> a "transition plan" for efforts (for example, the upcoming memory model >> updates; JDK8 lambdas) that result in spec updates. Probably nothing >> special beyond saying that upon integration of specs, follow-ups >> go here? >> > > Not necessarily. The Maintenance Lead (ML) for a JSR is the official > contact for bugs in that JSR's spec. Just because a JSR's spec is > integrated into the text of the JLS or JVMS doesn't mean that the ML's > responsibilities diminish. In 2025, substantive feedback about the JMM9 > spec developed in 2015 should be sent to the ML, not > jls-jvms-spec-comments. To the extent that people send substantive feedback > to jls-jvms-spec-comments anyway, the owner of that alias should not > hesitate to bounce mails to the correct ML. > > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed Aug 6 18:22:26 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 06 Aug 2014 11:22:26 -0700 Subject: Spec mailing lists In-Reply-To: References: <53DAC42A.4050205@oracle.com> <53DCD0A7.2080809@cs.oswego.edu> <53DFE3B5.4090603@oracle.com> Message-ID: <53E27262.4080402@oracle.com> https://jcp.org/en/procedures/jcp2#5.1.1 Bear in mind that a majority of JSRs are led by companies, not individuals, so there is usually less single-point-of-failureness that one might imagine. In any case, these are all issues best addressed to the JCP Program Management Office. Alex On 8/5/2014 11:40 PM, Jeremy Manson wrote: > Alex, > > Although we discussed this in person, I was a little unclear about the > single-point-of-failureness of it. What happens when the ML dies? Or > even goes on vacation? Are they really the sole authority? > > Jeremy > > > On Mon, Aug 4, 2014 at 12:49 PM, Alex Buckley > wrote: > > On 8/2/2014 4:51 AM, Doug Lea wrote: > > This all sounds good, although it would be nice to also regularize > a "transition plan" for efforts (for example, the upcoming > memory model > updates; JDK8 lambdas) that result in spec updates. Probably nothing > special beyond saying that upon integration of specs, follow-ups > go here? > > > Not necessarily. The Maintenance Lead (ML) for a JSR is the official > contact for bugs in that JSR's spec. Just because a JSR's spec is > integrated into the text of the JLS or JVMS doesn't mean that the > ML's responsibilities diminish. In 2025, substantive feedback about > the JMM9 spec developed in 2015 should be sent to the ML, not > jls-jvms-spec-comments. To the extent that people send substantive > feedback to jls-jvms-spec-comments anyway, the owner of that alias > should not hesitate to bounce mails to the correct ML. > > Alex > > From oehrstroem at gmail.com Wed Aug 6 19:59:21 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 6 Aug 2014 21:59:21 +0200 Subject: RFR 8054461: Add @file support to sjavac Message-ID: The command line for building the jdk using sjavac is near the Windows/Cygwin limits. Even though the OpenJDK is being cleaned up and the command line is getting shorter, there are other projects that could need long command lines due to their irregular source organization. Javac already supports @files. Please review the addition of @file support to sjavac. http://cr.openjdk.java.net/~ohrstrom/webrev-8054461-atfile/ https://bugs.openjdk.java.net/browse/JDK-8054461 //Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Wed Aug 6 21:22:36 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 6 Aug 2014 23:22:36 +0200 Subject: RFR 8054465: Add --permit-unidentified-artifact=bar.txt support to sjavac Message-ID: The --permit-unidentified-artifacts option is too broad for many use cases. White-listing is more safe for many use cases, thus --permit-unidentified-artifact=bar.txt will allow bar.txt to remain within the destination dir and be ignored by sjavac. http://cr.openjdk.java.net/~ohrstrom/webrev-8054465-permit/ https://bugs.openjdk.java.net/browse/JDK-8054465 //Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Wed Aug 6 21:22:37 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 6 Aug 2014 23:22:37 +0200 Subject: RFR 8054465: Add --permit-unidentified-artifact=bar.txt support to sjavac Message-ID: The --permit-unidentified-artifacts option is too broad for many use cases. White-listing is more safe for many use cases, thus --permit-unidentified-artifact=bar.txt will allow bar.txt to remain within the destination dir and be ignored by sjavac. http://cr.openjdk.java.net/~ohrstrom/webrev-8054465-permit/ https://bugs.openjdk.java.net/browse/JDK-8054465 //Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Wed Aug 6 22:48:41 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Thu, 7 Aug 2014 00:48:41 +0200 Subject: RFR 8054474: Add --state-dir=bar to sjavac Message-ID: Currently sjavac defaults to store the sjavac_state file in the destination dir along the generated classes, this can be inconvenient in some build systems, because you have to avoid the state file when creating a jar archive. It is convenient to be able to relocate javac_state to a state dir. This directory will also hold a default portfile javac_server and the log files for the server, if the server conf is not supplied. The state dir defaults to the destination dir. http://cr.openjdk.java.net/~ohrstrom/webrev-8054474-statedir/ https://bugs.openjdk.java.net/browse/JDK-8054474 //Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Aug 7 01:30:14 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 06 Aug 2014 18:30:14 -0700 Subject: RFR 8054474: Add --state-dir=bar to sjavac In-Reply-To: References: Message-ID: <53E2D6A6.7060106@oracle.com> On 08/06/2014 03:48 PM, Fredrik ?hrstr?m wrote: > Currently sjavac defaults to store the sjavac_state file in the > destination dir along the generated classes, > this can be inconvenient in some build systems, because you have to > avoid the state file when creating a jar archive. It is convenient to > be able to relocate javac_state to a state dir. This directory will > also hold a default portfile javac_server and the log files for the > server, if the server conf is not supplied. > > The state dir defaults to the destination dir. > > http://cr.openjdk.java.net/~ohrstrom/webrev-8054474-statedir/ > > > https://bugs.openjdk.java.net/browse/JDK-8054474 > > //Fredrik Fredrik, JavacState.java 140 javacStateFilename = stateDir.getPath()+File.separator+"javac_state"; 141 javacState = new File(javacStateFilename); Try not to use "string addition to compute filenames. In this case it is better to write javacState = new File(stateDIr, "javac_state"); I know Andreas is not a "R"eviewer, but as he is also working on the sjavac code, I would like him to comment on these changes as well. -- Jon From jonathan.gibbons at oracle.com Thu Aug 7 01:32:56 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 06 Aug 2014 18:32:56 -0700 Subject: RFR 8054461: Add @file support to sjavac In-Reply-To: References: Message-ID: <53E2D748.8090908@oracle.com> On 08/06/2014 12:59 PM, Fredrik ?hrstr?m wrote: > The command line for building the jdk using sjavac is near the > Windows/Cygwin limits. Even though the OpenJDK is being cleaned up and > the command line is getting shorter, there are other projects that > could need long command lines due to their irregular source > organization. Javac already supports @files. > > Please review the addition of @file support to sjavac. > > http://cr.openjdk.java.net/~ohrstrom/webrev-8054461-atfile/ > > > https://bugs.openjdk.java.net/browse/JDK-8054461 > > //Fredrik > > OptionHelper.java 118 try { 119 args = CommandLine.parse(args); // Detect @file and load it as a command line. 120 } catch (java.io.IOException e) { 121 Log.warn("Problem reading @file: "+e.getMessage()); 122 return; 123 } If you can't read the @-file, that should be an error, not a warning. -- Jon From blackdrag at gmx.org Thu Aug 7 12:50:43 2014 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 07 Aug 2014 14:50:43 +0200 Subject: class lookup in javac Message-ID: <53E37623.4060309@gmx.org> Hi, I am trying to understand javac internals a bit more and I am currently trying to find out where exactly javac finds that it doesn't know a class. I am also trying to identify where javac looks for a precompiled class, and how that class is represented. Can I get some pointers from you guys? bye Jochen From maurizio.cimadamore at oracle.com Thu Aug 7 17:52:58 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 07 Aug 2014 18:52:58 +0100 Subject: class lookup in javac In-Reply-To: <53E37623.4060309@gmx.org> References: <53E37623.4060309@gmx.org> Message-ID: <53E3BCFA.2040508@oracle.com> Hi Jochen, I would say that the root of all magic lies in Resolve.loadClass - i.e. that method is called whenever a class needs to be resolved given its qualified name. This triggers a lookup using ClassFinder (which is a new addition in JDK 9 compiler - if you are using older codebase you might find analogous routines under ClassReader). ClassFinder is responsible for resolving a qualified name into: *) a source file (i.e. if the file being compiled references another file that is part of same compilation) *) a class file (i.e. if the file being compiled references a class in the classpath) *) both a class and a source file (if both the above case apply) In the last case, ClassFinder will decide as to whether the source or the class file should be used by preferring the 'freshest' file (see ClassFinder.includeClassFile). After ClassFinder has established where the bits should be coming from, javac will create a new ClassSymbol corresponding to the 'shell' of the newly found class. Whenever javac needs to access to members of this class, it will use a completer to do so - initially this completer will point to ClassFinder.complete() itself, which will then route completion to either JavaCompiler (source completion) or ClassReader (classfile completion). I hope this helps. Maurizio On 07/08/14 13:50, Jochen Theodorou wrote: > Hi, > > I am trying to understand javac internals a bit more and I am > currently trying to find out where exactly javac finds that it doesn't > know a class. I am also trying to identify where javac looks for a > precompiled class, and how that class is represented. > > Can I get some pointers from you guys? > > bye Jochen From alex.buckley at oracle.com Thu Aug 7 23:08:37 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 07 Aug 2014 16:08:37 -0700 Subject: Spec mailing lists In-Reply-To: <53DAC42A.4050205@oracle.com> References: <53DAC42A.4050205@oracle.com> Message-ID: <53E406F5.1050401@oracle.com> The jls-jvms-spec-comments list has been created. It's a little unfortunate that the printed JLS8 and JVMS8 books advertise jls-comments_ww and jvms-comments_ww. Still, I believe most readers view the specs online, so I will update the HTML and PDF versions later this year to advertise jls-jvms-spec-comments instead. At that time I will disable the old aliases. Alex On 7/31/2014 3:33 PM, Alex Buckley wrote: > Jon, > > Readers of The Java Language Specification and The JVM Specification can > presently send feedback about errors, omissions, and ambiguities in each > spec to jls-comments_ww at oracle.com and jvms-comments_ww at oracle.com. > > While this is a useful alternative to filing spec bugs at bugs.java.com, > it is still rather unsatisfactory because the addresses go to private > mailboxes. This makes it difficult for engineers to discuss the > feedback, and there is no public archive. > > I would like to request that the Compiler Group sponsors a mailing list: > > jls-jvms-spec-comments at openjdk.java.net > > where anyone can send feedback about either spec, and where Oracle > engineers who maintain the specs can discuss the best course of action. > Some particulars: > > 1. Anyone can post to the list without subscribing. All posts will be > held for moderation. An on-topic post might, say, claim that a rule in > the JLS performs an incomplete case analysis, or note a problem with the > files at http://docs.oracle.com/javase/specs/. An off-topic post, such > as a proposal for a new Java language feature, would be discarded. > > 2. The initial subscribers will be myself and Dan Smith. Where we use > the list to discuss a piece of feedback, we will cc the original poster. > > 3. The list will be licensed under comment-and-evaluation terms, and > publicly archived at http://mail.openjdk.java.net/mailman/listinfo. > > 4. The list is preferred to various JSR lists that were used to specify > Java SE 8 and are still occasionally used to raise spec issues > (eventually they will be disabled) : > > lambda-spec-{experts,observers,comments} > type-annotations-spec-{experts,observers,comments} > enhanced-metadata-spec-discuss > > Alex From oehrstroem at gmail.com Fri Aug 8 07:43:55 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 8 Aug 2014 09:43:55 +0200 Subject: RFR 8054474: Add --state-dir=bar to sjavac In-Reply-To: <53E2D6A6.7060106@oracle.com> References: <53E2D6A6.7060106@oracle.com> Message-ID: See update: http://cr.openjdk.java.net/~ohrstrom/webrev-8054474-statedir-v2/ 2014-08-07 3:30 GMT+02:00 Jonathan Gibbons : > > On 08/06/2014 03:48 PM, Fredrik ?hrstr?m wrote: > >> Currently sjavac defaults to store the sjavac_state file in the >> destination dir along the generated classes, >> this can be inconvenient in some build systems, because you have to avoid >> the state file when creating a jar archive. It is convenient to be able to >> relocate javac_state to a state dir. This directory will also hold a >> default portfile javac_server and the log files for the server, if the >> server conf is not supplied. >> >> The state dir defaults to the destination dir. >> >> http://cr.openjdk.java.net/~ohrstrom/webrev-8054474-statedir/ < >> http://cr.openjdk.java.net/%7Eohrstrom/webrev-8054474-statedir/> >> >> https://bugs.openjdk.java.net/browse/JDK-8054474 >> >> //Fredrik >> > > Fredrik, > > JavacState.java > > 140 javacStateFilename = stateDir.getPath()+File. > separator+"javac_state"; > 141 javacState = new File(javacStateFilename); > > Try not to use "string addition to compute filenames. In this case it is > better to write > > javacState = new File(stateDIr, "javac_state"); > > I know Andreas is not a "R"eviewer, but as he is also working on the > sjavac code, > I would like him to comment on these changes as well. > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Fri Aug 8 07:44:23 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 8 Aug 2014 09:44:23 +0200 Subject: RFR 8054461: Add @file support to sjavac In-Reply-To: <53E2D748.8090908@oracle.com> References: <53E2D748.8090908@oracle.com> Message-ID: See update: http://cr.openjdk.java.net/~ohrstrom/webrev-8054461-atfile-v2/ 2014-08-07 3:32 GMT+02:00 Jonathan Gibbons : > > On 08/06/2014 12:59 PM, Fredrik ?hrstr?m wrote: > >> The command line for building the jdk using sjavac is near the >> Windows/Cygwin limits. Even though the OpenJDK is being cleaned up and the >> command line is getting shorter, there are other projects that could need >> long command lines due to their irregular source organization. Javac >> already supports @files. >> >> Please review the addition of @file support to sjavac. >> >> http://cr.openjdk.java.net/~ohrstrom/webrev-8054461-atfile/ < >> http://cr.openjdk.java.net/%7Eohrstrom/webrev-8054461-atfile/> >> >> https://bugs.openjdk.java.net/browse/JDK-8054461 >> >> //Fredrik >> >> >> > OptionHelper.java > > 118 try { > 119 args = CommandLine.parse(args); // Detect @file and load > it as a command line. > 120 } catch (java.io.IOException e) { > 121 Log.warn("Problem reading @file: "+e.getMessage()); > 122 return; > 123 } > > If you can't read the @-file, that should be an error, not a warning. > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blackdrag at gmx.org Fri Aug 8 12:43:36 2014 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 08 Aug 2014 14:43:36 +0200 Subject: class lookup in javac In-Reply-To: <53E3BCFA.2040508@oracle.com> References: <53E37623.4060309@gmx.org> <53E3BCFA.2040508@oracle.com> Message-ID: <53E4C5F8.1040504@gmx.org> sorry, looks like my last reply did go to you personally.. Anyway.. thanks for the help, I am starting to feel more at home in javac source code now. I successfully used javac to compile a class that extends another class, which exists only programatically. If I wanted to get all the trees of the currently to be compiled sources... or I should maybe say all compilation units... is there a way to do that? And one question for the compile states... does the compiler try to complete the compilation for a compile unit first, or does the compiler let all compilation units progress through all states at the same time? Like "for all compileUnits do process" then "for all compileUnits do attr" and so on. I am aware that this is simplified, since they can't all be in sync like that all the time, but I am interested in the general approach here. bye Jochen Am 07.08.2014 19:52, schrieb Maurizio Cimadamore: > Hi Jochen, > I would say that the root of all magic lies in Resolve.loadClass - i.e. > that method is called whenever a class needs to be resolved given its > qualified name. This triggers a lookup using ClassFinder (which is a new > addition in JDK 9 compiler - if you are using older codebase you might > find analogous routines under ClassReader). ClassFinder is responsible > for resolving a qualified name into: > > *) a source file (i.e. if the file being compiled references another > file that is part of same compilation) > *) a class file (i.e. if the file being compiled references a class in > the classpath) > *) both a class and a source file (if both the above case apply) > > In the last case, ClassFinder will decide as to whether the source or > the class file should be used by preferring the 'freshest' file (see > ClassFinder.includeClassFile). > > After ClassFinder has established where the bits should be coming from, > javac will create a new ClassSymbol corresponding to the 'shell' of the > newly found class. Whenever javac needs to access to members of this > class, it will use a completer to do so - initially this completer will > point to ClassFinder.complete() itself, which will then route completion > to either JavaCompiler (source completion) or ClassReader (classfile > completion). > > I hope this helps. > > Maurizio > > On 07/08/14 13:50, Jochen Theodorou wrote: >> Hi, >> >> I am trying to understand javac internals a bit more and I am >> currently trying to find out where exactly javac finds that it doesn't >> know a class. I am also trying to identify where javac looks for a >> precompiled class, and how that class is represented. >> >> Can I get some pointers from you guys? >> >> bye Jochen > -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From andreas.lundblad at oracle.com Fri Aug 8 15:51:02 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Fri, 8 Aug 2014 17:51:02 +0200 Subject: RFR 8054465: Add --permit-unidentified-artifact=bar.txt support to sjavac In-Reply-To: References: Message-ID: <20140808155101.GS12710@e6430> On Wed, Aug 06, 2014 at 11:22:36PM +0200, Fredrik ?hrstr?m wrote: > The --permit-unidentified-artifacts option is too broad for many use cases. > > White-listing is more safe for many use cases, thus > --permit-unidentified-artifact=bar.txt > will allow bar.txt to remain within the destination dir and be ignored by > sjavac. > > http://cr.openjdk.java.net/~ohrstrom/webrev-8054465-permit/ > > https://bugs.openjdk.java.net/browse/JDK-8054465 > > //Fredrik I suggest you add a test that tests the semantics of the option as well (and not just the option decoding). Other than that it looks good. -- Andreas From andreas.lundblad at oracle.com Fri Aug 8 16:05:42 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Fri, 8 Aug 2014 18:05:42 +0200 Subject: RFR 8054474: Add --state-dir=bar to sjavac In-Reply-To: References: <53E2D6A6.7060106@oracle.com> Message-ID: <20140808160542.GT12710@e6430> On Fri, Aug 08, 2014 at 09:43:55AM +0200, Fredrik ?hrstr?m wrote: > See update: > http://cr.openjdk.java.net/~ohrstrom/webrev-8054474-statedir-v2/ This looks strange: + String idOpt = Util.extractStringOption("id", javacService.serverSettings()); final String id = idOpt; Why two variables? Perhaps the following variables could have more descriptive names. + String s = options.getServerConf(); + String se = (s!=null)? s : ""; + String i = Util.extractStringOption("id", se); Regarding settings = (se.equals("")) ? "id="+id+",portfile="+portfile : se; Do we have to bundle up the settings in a *String*? I'd prefea more typesafe datastructure. -- Andreas > > > 2014-08-07 3:30 GMT+02:00 Jonathan Gibbons : > > > > > On 08/06/2014 03:48 PM, Fredrik ?hrstr?m wrote: > > > >> Currently sjavac defaults to store the sjavac_state file in the > >> destination dir along the generated classes, > >> this can be inconvenient in some build systems, because you have to avoid > >> the state file when creating a jar archive. It is convenient to be able to > >> relocate javac_state to a state dir. This directory will also hold a > >> default portfile javac_server and the log files for the server, if the > >> server conf is not supplied. > >> > >> The state dir defaults to the destination dir. > >> > >> http://cr.openjdk.java.net/~ohrstrom/webrev-8054474-statedir/ < > >> http://cr.openjdk.java.net/%7Eohrstrom/webrev-8054474-statedir/> > >> > >> https://bugs.openjdk.java.net/browse/JDK-8054474 > >> > >> //Fredrik > >> > > > > Fredrik, > > > > JavacState.java > > > > 140 javacStateFilename = stateDir.getPath()+File. > > separator+"javac_state"; > > 141 javacState = new File(javacStateFilename); > > > > Try not to use "string addition to compute filenames. In this case it is > > better to write > > > > javacState = new File(stateDIr, "javac_state"); > > > > I know Andreas is not a "R"eviewer, but as he is also working on the > > sjavac code, > > I would like him to comment on these changes as well. > > > > -- Jon > > From andreas.lundblad at oracle.com Fri Aug 8 16:11:15 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Fri, 8 Aug 2014 18:11:15 +0200 Subject: RFR 8054461: Add @file support to sjavac In-Reply-To: References: <53E2D748.8090908@oracle.com> Message-ID: <20140808161114.GU12710@e6430> On Fri, Aug 08, 2014 at 09:44:23AM +0200, Fredrik ?hrstr?m wrote: > See update: > http://cr.openjdk.java.net/~ohrstrom/webrev-8054461-atfile-v2/ > I don't really like the idea of Sjavac.java: * @summary Test all aspects of sjavac. Can't we try to have one test per feature / bug? Code looks good. -- Andreas From jonathan.gibbons at oracle.com Fri Aug 8 18:47:29 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 08 Aug 2014 11:47:29 -0700 Subject: class lookup in javac In-Reply-To: <53E4C5F8.1040504@gmx.org> References: <53E37623.4060309@gmx.org> <53E3BCFA.2040508@oracle.com> <53E4C5F8.1040504@gmx.org> Message-ID: <53E51B41.20606@oracle.com> On 08/08/2014 05:43 AM, Jochen Theodorou wrote: > sorry, looks like my last reply did go to you personally.. Anyway.. > thanks for the help, I am starting to feel more at home in javac > source code now. > > I successfully used javac to compile a class that extends another > class, which exists only programatically. > > If I wanted to get all the trees of the currently to be compiled > sources... or I should maybe say all compilation units... is there a > way to do that? Use com.sun.source.util.JavacTask.parse() > > And one question for the compile states... does the compiler try to > complete the compilation for a compile unit first, or does the > compiler let all compilation units progress through all states at the > same time? Like "for all compileUnits do process" then "for all > compileUnits do attr" and so on. I am aware that this is simplified, > since they can't all be in sync like that all the time, but I am > interested in the general approach here. It is not possible to compile mutually referential files one file at a time. -- Jon > > bye Jochen > > Am 07.08.2014 19:52, schrieb Maurizio Cimadamore: >> Hi Jochen, >> I would say that the root of all magic lies in Resolve.loadClass - i.e. >> that method is called whenever a class needs to be resolved given its >> qualified name. This triggers a lookup using ClassFinder (which is a new >> addition in JDK 9 compiler - if you are using older codebase you might >> find analogous routines under ClassReader). ClassFinder is responsible >> for resolving a qualified name into: >> >> *) a source file (i.e. if the file being compiled references another >> file that is part of same compilation) >> *) a class file (i.e. if the file being compiled references a class in >> the classpath) >> *) both a class and a source file (if both the above case apply) >> >> In the last case, ClassFinder will decide as to whether the source or >> the class file should be used by preferring the 'freshest' file (see >> ClassFinder.includeClassFile). >> >> After ClassFinder has established where the bits should be coming from, >> javac will create a new ClassSymbol corresponding to the 'shell' of the >> newly found class. Whenever javac needs to access to members of this >> class, it will use a completer to do so - initially this completer will >> point to ClassFinder.complete() itself, which will then route completion >> to either JavaCompiler (source completion) or ClassReader (classfile >> completion). >> >> I hope this helps. >> >> Maurizio >> >> On 07/08/14 13:50, Jochen Theodorou wrote: >>> Hi, >>> >>> I am trying to understand javac internals a bit more and I am >>> currently trying to find out where exactly javac finds that it doesn't >>> know a class. I am also trying to identify where javac looks for a >>> precompiled class, and how that class is represented. >>> >>> Can I get some pointers from you guys? >>> >>> bye Jochen >> > > From oehrstroem at gmail.com Fri Aug 8 18:51:32 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 8 Aug 2014 20:51:32 +0200 Subject: RFR 8054461: Add @file support to sjavac In-Reply-To: <20140808161114.GU12710@e6430> References: <53E2D748.8090908@oracle.com> <20140808161114.GU12710@e6430> Message-ID: I don't really like the idea of Sjavac.java: > > * @summary Test all aspects of sjavac. > > Can't we try to have one test per feature / bug? > Indeed, see https://bugs.openjdk.java.net/browse/JDK-8054689 :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Fri Aug 8 18:52:44 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 8 Aug 2014 20:52:44 +0200 Subject: class lookup in javac In-Reply-To: <53E51B41.20606@oracle.com> References: <53E37623.4060309@gmx.org> <53E3BCFA.2040508@oracle.com> <53E4C5F8.1040504@gmx.org> <53E51B41.20606@oracle.com> Message-ID: > It is not possible to compile mutually referential files one file at a time. Well, you can if you use -sourcepath -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Aug 8 18:53:08 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 08 Aug 2014 11:53:08 -0700 Subject: RFR 8054461: Add @file support to sjavac In-Reply-To: <20140808161114.GU12710@e6430> References: <53E2D748.8090908@oracle.com> <20140808161114.GU12710@e6430> Message-ID: <53E51C94.9010201@oracle.com> On 08/08/2014 09:11 AM, Andreas Lundblad wrote: > On Fri, Aug 08, 2014 at 09:44:23AM +0200, Fredrik ?hrstr?m wrote: >> See update: >> http://cr.openjdk.java.net/~ohrstrom/webrev-8054461-atfile-v2/ >> > I don't really like the idea of Sjavac.java: > > * @summary Test all aspects of sjavac. > > Can't we try to have one test per feature / bug? > > > Code looks good. > > -- Andreas Note that the need for the overhead of the test wrapper classes has gone away, which makes it easier to have a test per feature/bug. I'm OK with multiple test cases within a test (it's a style issue that can go either way) but I would note that these days we are focussing on verifying that the tests for a feature do at least minimally execute the new or modified code for the feature. You can do this with the jcov support for checking the coverage of the new or modified code in a patch, and you can easily access this functionality from recent releases of jtreg. -- Jon From jonathan.gibbons at oracle.com Fri Aug 8 18:56:40 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 08 Aug 2014 11:56:40 -0700 Subject: class lookup in javac In-Reply-To: References: <53E37623.4060309@gmx.org> <53E3BCFA.2040508@oracle.com> <53E4C5F8.1040504@gmx.org> <53E51B41.20606@oracle.com> Message-ID: <53E51D68.1070802@oracle.com> On 08/08/2014 11:52 AM, Fredrik ?hrstr?m wrote: > > It is not possible to compile mutually referential files one file at > a time. > > Well, you can if you use -sourcepath > > The original question was about how how compilation units proceed through the pipeline, and my answer stands. If you have mutually referential files, you cannot send one through the javac pipeline, and then another -- they will proceed together, each at their own pace, through some or all of the compilation pipeline. -- Jon From oehrstroem at gmail.com Fri Aug 8 19:07:28 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 8 Aug 2014 21:07:28 +0200 Subject: RFR 8054474: Add --state-dir=bar to sjavac In-Reply-To: <20140808160542.GT12710@e6430> References: <53E2D6A6.7060106@oracle.com> <20140808160542.GT12710@e6430> Message-ID: + String idOpt = Util.extractStringOption("id", javacService.serverSettings()); > final String id = idOpt; > Leftover from the old code. Now fixed. Perhaps the following variables could have more descriptive names. > > + String s = options.getServerConf(); > + String se = (s!=null)? s : ""; > + String i = Util.extractStringOption("id", se); > > Fixed. > Do we have to bundle up the settings in a *String*? I'd prefea more > typesafe datastructure. > > See https://bugs.openjdk.java.net/browse/JDK-8054690 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Fri Aug 8 20:39:51 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 8 Aug 2014 22:39:51 +0200 Subject: RFR 8054465: Add --permit-unidentified-artifact=bar.txt support to sjavac In-Reply-To: <20140808155101.GS12710@e6430> References: <20140808155101.GS12710@e6430> Message-ID: Added semantic test and renamed the option to --permit-artifact= 2014-08-08 17:51 GMT+02:00 Andreas Lundblad : > On Wed, Aug 06, 2014 at 11:22:36PM +0200, Fredrik ?hrstr?m wrote: > > The --permit-unidentified-artifacts option is too broad for many use > cases. > > > > White-listing is more safe for many use cases, thus > > --permit-unidentified-artifact=bar.txt > > will allow bar.txt to remain within the destination dir and be ignored by > > sjavac. > > > > http://cr.openjdk.java.net/~ohrstrom/webrev-8054465-permit/ > > > > https://bugs.openjdk.java.net/browse/JDK-8054465 > > > > //Fredrik > > I suggest you add a test that tests the semantics of the option as well > (and not just the option decoding). > > Other than that it looks good. > > -- Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Fri Aug 8 20:41:26 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 8 Aug 2014 22:41:26 +0200 Subject: RFR 8054465: Add --permit-unidentified-artifact=bar.txt support to sjavac In-Reply-To: References: <20140808155101.GS12710@e6430> Message-ID: Added semantic test and renamed the option to --permit-artifact= http://cr.openjdk.java.net/~ohrstrom/webrev-8054465-permit-v2/ 2014-08-08 22:39 GMT+02:00 Fredrik ?hrstr?m : > Added semantic test and renamed the option to --permit-artifact= > > > > > 2014-08-08 17:51 GMT+02:00 Andreas Lundblad : > > On Wed, Aug 06, 2014 at 11:22:36PM +0200, Fredrik ?hrstr?m wrote: >> > The --permit-unidentified-artifacts option is too broad for many use >> cases. >> > >> > White-listing is more safe for many use cases, thus >> > --permit-unidentified-artifact=bar.txt >> > will allow bar.txt to remain within the destination dir and be ignored >> by >> > sjavac. >> > >> > http://cr.openjdk.java.net/~ohrstrom/webrev-8054465-permit/ >> > >> > https://bugs.openjdk.java.net/browse/JDK-8054465 >> > >> > //Fredrik >> >> I suggest you add a test that tests the semantics of the option as well >> (and not just the option decoding). >> >> Other than that it looks good. >> >> -- Andreas >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Fri Aug 8 21:16:14 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 8 Aug 2014 23:16:14 +0200 Subject: RFR 8054715: Changing the source roots and/or their filters forces a full recompile. Message-ID: Changing the source roots and/or their filters forces a full recompile, since the source roots and the filters are included in the command line memory in the javac_state file. This is a bug, since all changes to the set of source files should be gracefully handled incrementally. SJavac should do an incremental compile both when: beta/B.java is deleted from the file system (this works) or when "-x beta" is added to the command line to exclude beta/B.java from compilation (this does not work). Simple fix, do not include the filters and the source roots in the memory line in the javac_state file. http://cr.openjdk.java.net/~ohrstrom/webrev-8054715-sources/ https://bugs.openjdk.java.net/browse/JDK-8054715 //Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Aug 8 21:29:24 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 08 Aug 2014 14:29:24 -0700 Subject: RFR 8054465: Add --permit-unidentified-artifact=bar.txt support to sjavac In-Reply-To: References: <20140808155101.GS12710@e6430> Message-ID: <53E54134.1010702@oracle.com> Approved -- Jon On 08/08/2014 01:41 PM, Fredrik ?hrstr?m wrote: > Added semantic test and renamed the option to --permit-artifact= > > http://cr.openjdk.java.net/~ohrstrom/webrev-8054465-permit-v2/ > > > > 2014-08-08 22:39 GMT+02:00 Fredrik ?hrstr?m >: > > Added semantic test and renamed the option to --permit-artifact= > > > > > 2014-08-08 17:51 GMT+02:00 Andreas Lundblad > >: > > On Wed, Aug 06, 2014 at 11:22:36PM +0200, Fredrik ?hrstr?m wrote: > > The --permit-unidentified-artifacts option is too broad for > many use cases. > > > > White-listing is more safe for many use cases, thus > > --permit-unidentified-artifact=bar.txt > > will allow bar.txt to remain within the destination dir and > be ignored by > > sjavac. > > > > http://cr.openjdk.java.net/~ohrstrom/webrev-8054465-permit/ > > > > > https://bugs.openjdk.java.net/browse/JDK-8054465 > > > > //Fredrik > > I suggest you add a test that tests the semantics of the > option as well (and not just the option decoding). > > Other than that it looks good. > > -- Andreas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Fri Aug 8 22:22:29 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Sat, 9 Aug 2014 00:22:29 +0200 Subject: RFR 8054717: SJavac should track changes in the public apis of classpath classes! Message-ID: Here is very useful feature addition to sjavac, in fact it is required for a modularized OpenJDK build (Jigsawified), where not all sources are sent to sjavac at the same time. sjavac should track the public apis of the classes in the classpath, that the previous compile has linked to. If the public api of the linked to classes has changed, then this should trigger a recompile of the appropriate sources. This is a very useful feature. Currently sjavac must be fed all sources that belong to the product in a single huge compile. The OpenJDK is already at the limit of what fits in a reasonable (of today) sized Java heap. Other products are significantly larger and therefore cannot make use of the incremental compile in sjavac. With this feature, it is possible to compile the product as separate jar files, as long as the build dependencies for the jar files are a directed acyclic graph, then each succesive compile will detect if there were any changes in the public apis of the dependency jar files. If the public apis of the dependencies were not changed, and there were no other source changes for that jar, it will not be recompiled! But if there were changes in the public apis of the dependencies, then only the appropriate parts of the jar will be recompiled! This is the first draft of this large patch. In particular the new file Compile.java is a misnamer, it does NOT compile, it is used to extract the public apis of the classes on the classpath. Somehowe Compile.java should perhaps be part of JavaService. It is important that this public api scanning does not require a javac server started though. http://cr.openjdk.java.net/~ohrstrom/webrev-8054717-classpathdep/ https://bugs.openjdk.java.net/browse/JDK-8054717 //Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at hibernate.org Mon Aug 11 10:22:11 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 11 Aug 2014 12:22:11 +0200 Subject: Accessing type annotations via annotation processor Message-ID: Hi, I'm looking for a way to obtain annotations given on type uses using a JSR 269 annotation processor. E.g. I'd like to obtain the @NotNull annotation from the following field declaration: ... private List<@NotNull String> values; Based on a post of Joe [1] I assumed this to be possible, but a discussion on this list now makes me believe this cannot be done as of Java 8. Is this true? If so, will this be the case in SE 9? On a tangent, Joe referenced a diff of the JavaDocs of two versions of the JSR 269 API, containing nicely colored mark-up highlighting the changes. What's the tool used for creating this diff? Thanks, --Gunnar [1] https://blogs.oracle.com/darcy/entry/jsr_269_mr_for_java [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2014-May/008756.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Mon Aug 11 18:13:31 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 11 Aug 2014 11:13:31 -0700 Subject: Accessing type annotations via annotation processor In-Reply-To: References: Message-ID: <53E907CB.9030602@oracle.com> There are some known problems with retrieving type annotations on type parameter declarations, in both the Core Reflection API and the Language Model API. I believe type annotations on types used in member declarations work OK. If you have the VariableElement for 'values', you can get the TypeMirror for 'List<@NotNull String>', then visit it as a DeclaredType and call getTypeArguments() to get a TypeMirror for '@NotNull String'. TypeMirror is an AnnotatedConstruct so it can return the annotations on the use of 'String'. Alex On 8/11/2014 3:22 AM, Gunnar Morling wrote: > Hi, > > I'm looking for a way to obtain annotations given on type uses using a > JSR 269 annotation processor. > > E.g. I'd like to obtain the @NotNull annotation from the following field > declaration: > > ... > private List<@NotNull String> values; > > Based on a post of Joe [1] I assumed this to be possible, but a > discussion on this list now makes me believe this cannot be done as of > Java 8. Is this true? If so, will this be the case in SE 9? > > On a tangent, Joe referenced a diff of the JavaDocs of two versions of > the JSR 269 API, containing nicely colored mark-up highlighting the > changes. What's the tool used for creating this diff? > > Thanks, > > --Gunnar > > [1] https://blogs.oracle.com/darcy/entry/jsr_269_mr_for_java > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2014-May/008756.html > From joe.darcy at oracle.com Mon Aug 11 18:20:25 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 11 Aug 2014 11:20:25 -0700 Subject: Accessing type annotations via annotation processor In-Reply-To: References: Message-ID: <53E90969.90102@oracle.com> On 08/11/2014 03:22 AM, Gunnar Morling wrote: > Hi, > > I'm looking for a way to obtain annotations given on type uses using a > JSR 269 annotation processor. > > E.g. I'd like to obtain the @NotNull annotation from the following > field declaration: > > ... > private List<@NotNull String> values; > > Based on a post of Joe [1] I assumed this to be possible, but a > discussion on this list now makes me believe this cannot be done as of > Java 8. Is this true? If so, will this be the case in SE 9? > > On a tangent, Joe referenced a diff of the JavaDocs of two versions of > the JSR 269 API, containing nicely colored mark-up highlighting the > changes. What's the tool used for creating this diff? > > On the last point, I used a tool called "specdiff." This tool was developed by Sun and Oracle, but is not currently available externally. Cheers, -Joe From gunnar at hibernate.org Thu Aug 14 06:56:55 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 14 Aug 2014 08:56:55 +0200 Subject: Accessing type annotations via annotation processor In-Reply-To: <53E907CB.9030602@oracle.com> References: <53E907CB.9030602@oracle.com> Message-ID: Hi Alex, 2014-08-11 20:13 GMT+02:00 Alex Buckley : > There are some known problems with retrieving type annotations on type > parameter declarations, in both the Core Reflection API and the Language > Model API. I believe type annotations on types used in member declarations > work OK. If you have the VariableElement for 'values', you can get the > TypeMirror for 'List<@NotNull String>', then visit it as a DeclaredType and > call getTypeArguments() to get a TypeMirror for '@NotNull String'. > TypeMirror is an AnnotatedConstruct so it can return the annotations on the > use of 'String'. I tried what you suggested, but I only obtained a TypeMirror for 'List' from the VariableElement, thus the TypeMirror for the type argument represents 'String' rather than '@NotNull String'. Is there any example or test in OpenJDK which shows the retrieval of type annotations via the Language Model API? Another issue is that the process() method of the annotation processor is never invoked for the @NotNull annotation if it is only used as type annotation (the processor will be invoked though if @NotNull is e.g. used as a traditional field-level annotation). Is this an expected behavior? Thanks, --Gunnar Alex > > > On 8/11/2014 3:22 AM, Gunnar Morling wrote: > >> Hi, >> >> I'm looking for a way to obtain annotations given on type uses using a >> JSR 269 annotation processor. >> >> E.g. I'd like to obtain the @NotNull annotation from the following field >> declaration: >> >> ... >> private List<@NotNull String> values; >> >> Based on a post of Joe [1] I assumed this to be possible, but a >> discussion on this list now makes me believe this cannot be done as of >> Java 8. Is this true? If so, will this be the case in SE 9? >> >> On a tangent, Joe referenced a diff of the JavaDocs of two versions of >> the JSR 269 API, containing nicely colored mark-up highlighting the >> changes. What's the tool used for creating this diff? >> >> Thanks, >> >> --Gunnar >> >> [1] https://blogs.oracle.com/darcy/entry/jsr_269_mr_for_java >> [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2014- >> May/008756.html >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at hibernate.org Thu Aug 14 07:00:39 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 14 Aug 2014 09:00:39 +0200 Subject: Accessing type annotations via annotation processor In-Reply-To: <53E90969.90102@oracle.com> References: <53E90969.90102@oracle.com> Message-ID: 2014-08-11 20:20 GMT+02:00 Joe Darcy : > On 08/11/2014 03:22 AM, Gunnar Morling wrote: > >> Hi, >> >> I'm looking for a way to obtain annotations given on type uses using a >> JSR 269 annotation processor. >> >> E.g. I'd like to obtain the @NotNull annotation from the following field >> declaration: >> >> ... >> private List<@NotNull String> values; >> >> Based on a post of Joe [1] I assumed this to be possible, but a >> discussion on this list now makes me believe this cannot be done as of Java >> 8. Is this true? If so, will this be the case in SE 9? >> >> On a tangent, Joe referenced a diff of the JavaDocs of two versions of >> the JSR 269 API, containing nicely colored mark-up highlighting the >> changes. What's the tool used for creating this diff? >> >> >> > On the last point, I used a tool called "specdiff." This tool was > developed by Sun and Oracle, but is not currently available externally. > Ah, I see. Too bad that it's not available, this tool seems very useful also for other specs. It would be great to see it published at some point. Cheers, > > -Joe > Thanks, --Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Aug 14 17:25:29 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 14 Aug 2014 10:25:29 -0700 Subject: Accessing type annotations via annotation processor In-Reply-To: References: <53E907CB.9030602@oracle.com> Message-ID: <53ECF109.6020401@oracle.com> Hello, On 08/13/2014 11:56 PM, Gunnar Morling wrote: > Hi Alex, > > 2014-08-11 20:13 GMT+02:00 Alex Buckley >: > > There are some known problems with retrieving type annotations on > type parameter declarations, in both the Core Reflection API and > the Language Model API. I believe type annotations on types used > in member declarations work OK. If you have the VariableElement > for 'values', you can get the TypeMirror for 'List<@NotNull > String>', then visit it as a DeclaredType and call > getTypeArguments() to get a TypeMirror for '@NotNull String'. > TypeMirror is an AnnotatedConstruct so it can return the > annotations on the use of 'String'. > > > I tried what you suggested, but I only obtained a TypeMirror for > 'List' from the VariableElement, thus the TypeMirror for the > type argument represents 'String' rather than '@NotNull String'. Is > there any example or test in OpenJDK which shows the retrieval of type > annotations via the Language Model API? Since the AnnotatedConstruct interface is now implemented by both elements and type mirrors, is *should* work go call the annotation retrieval methods on a TypeMirror. > > Another issue is that the process() method of the annotation processor > is never invoked for the @NotNull annotation if it is only used as > type annotation (the processor will be invoked though if @NotNull is > e.g. used as a traditional field-level annotation). Is this an > expected behavior? From the revised discovery process documented in javax.annotation.processing.Processor: "Annotations on type uses, as opposed to annotations on elements, are ignored when computing whether or not an annotation type is present." HTH, -Joe > > Thanks, > > --Gunnar > > Alex > > > On 8/11/2014 3:22 AM, Gunnar Morling wrote: > > Hi, > > I'm looking for a way to obtain annotations given on type uses > using a > JSR 269 annotation processor. > > E.g. I'd like to obtain the @NotNull annotation from the > following field > declaration: > > ... > private List<@NotNull String> values; > > Based on a post of Joe [1] I assumed this to be possible, but a > discussion on this list now makes me believe this cannot be > done as of > Java 8. Is this true? If so, will this be the case in SE 9? > > On a tangent, Joe referenced a diff of the JavaDocs of two > versions of > the JSR 269 API, containing nicely colored mark-up > highlighting the > changes. What's the tool used for creating this diff? > > Thanks, > > --Gunnar > > [1] https://blogs.oracle.com/darcy/entry/jsr_269_mr_for_java > [2] > http://mail.openjdk.java.net/pipermail/compiler-dev/2014-May/008756.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.mccorkle at oracle.com Thu Aug 14 18:26:37 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 14 Aug 2014 14:26:37 -0400 Subject: Accessing type annotations via annotation processor In-Reply-To: <53E907CB.9030602@oracle.com> References: <53E907CB.9030602@oracle.com> Message-ID: <53ECFF5D.9090509@oracle.com> Type annotations on type arguments, arrays, and wildcard bounds are known to have issues in JDK8. Also, the language model only works for a small number of cases in JDK8. Type annotations on the base type of a declaration are the most reliable in JDK8, and the language model should work correctly. More complicated uses (anonymous classes, type arguments, arrays, wildcards, etc.) probably won't at this time. On 08/11/14 14:13, Alex Buckley wrote: > There are some known problems with retrieving type annotations on type > parameter declarations, in both the Core Reflection API and the Language > Model API. I believe type annotations on types used in member > declarations work OK. If you have the VariableElement for 'values', you > can get the TypeMirror for 'List<@NotNull String>', then visit it as a > DeclaredType and call getTypeArguments() to get a TypeMirror for > '@NotNull String'. TypeMirror is an AnnotatedConstruct so it can return > the annotations on the use of 'String'. > > Alex > > On 8/11/2014 3:22 AM, Gunnar Morling wrote: >> Hi, >> >> I'm looking for a way to obtain annotations given on type uses using a >> JSR 269 annotation processor. >> >> E.g. I'd like to obtain the @NotNull annotation from the following field >> declaration: >> >> ... >> private List<@NotNull String> values; >> >> Based on a post of Joe [1] I assumed this to be possible, but a >> discussion on this list now makes me believe this cannot be done as of >> Java 8. Is this true? If so, will this be the case in SE 9? >> >> On a tangent, Joe referenced a diff of the JavaDocs of two versions of >> the JSR 269 API, containing nicely colored mark-up highlighting the >> changes. What's the tool used for creating this diff? >> >> Thanks, >> >> --Gunnar >> >> [1] https://blogs.oracle.com/darcy/entry/jsr_269_mr_for_java >> [2] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2014-May/008756.html >> -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From eric.mccorkle at oracle.com Thu Aug 14 18:29:48 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 14 Aug 2014 14:29:48 -0400 Subject: Accessing type annotations via annotation processor In-Reply-To: References: <53E907CB.9030602@oracle.com> Message-ID: <53ED001C.3020003@oracle.com> On 08/14/14 02:56, Gunnar Morling wrote: > > I tried what you suggested, but I only obtained a TypeMirror for > 'List' from the VariableElement, thus the TypeMirror for the > type argument represents 'String' rather than '@NotNull String'. That is due to the known issues with type annotations. -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From gunnar at hibernate.org Fri Aug 15 10:53:30 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 15 Aug 2014 12:53:30 +0200 Subject: Accessing type annotations via annotation processor In-Reply-To: <53ECF109.6020401@oracle.com> References: <53E907CB.9030602@oracle.com> <53ECF109.6020401@oracle.com> Message-ID: Hi, 2014- 8-14 19:25 GMT+02:00 Joe Darcy : > Hello, > > > On 08/13/2014 11:56 PM, Gunnar Morling wrote: > > Hi Alex, > > 2014-08-11 20:13 GMT+02:00 Alex Buckley : > >> There are some known problems with retrieving type annotations on type >> parameter declarations, in both the Core Reflection API and the Language >> Model API. I believe type annotations on types used in member declarations >> work OK. If you have the VariableElement for 'values', you can get the >> TypeMirror for 'List<@NotNull String>', then visit it as a DeclaredType and >> call getTypeArguments() to get a TypeMirror for '@NotNull String'. >> TypeMirror is an AnnotatedConstruct so it can return the annotations on the >> use of 'String'. > > > I tried what you suggested, but I only obtained a TypeMirror for > 'List' from the VariableElement, thus the TypeMirror for the type > argument represents 'String' rather than '@NotNull String'. Is there any > example or test in OpenJDK which shows the retrieval of type annotations > via the Language Model API? > > > Since the AnnotatedConstruct interface is now implemented by both elements > and type mirrors, is *should* work go call the annotation retrieval methods > on a TypeMirror. > > > > Another issue is that the process() method of the annotation processor > is never invoked for the @NotNull annotation if it is only used as type > annotation (the processor will be invoked though if @NotNull is e.g. used > as a traditional field-level annotation). Is this an expected behavior? > > > From the revised discovery process documented in > javax.annotation.processing.Processor: > > "Annotations on type uses, as opposed to annotations on elements, are > ignored when computing whether or not an annotation type is present." > Ah, I see. Thanks for the pointer. Are there any plans to remove this restriction? Our annotation processor for Bean Validation aims at detecting constraint declaration errors such as "List<@Email Integer> email" (applying the @Email constraint to Integers does not make sense), but as it stands its not possible to implement such check for type annotations atm. > HTH, > > -Joe > Thanks, --Gunnar > > > > Thanks, > > --Gunnar > > Alex >> >> >> On 8/11/2014 3:22 AM, Gunnar Morling wrote: >> >>> Hi, >>> >>> I'm looking for a way to obtain annotations given on type uses using a >>> JSR 269 annotation processor. >>> >>> E.g. I'd like to obtain the @NotNull annotation from the following field >>> declaration: >>> >>> ... >>> private List<@NotNull String> values; >>> >>> Based on a post of Joe [1] I assumed this to be possible, but a >>> discussion on this list now makes me believe this cannot be done as of >>> Java 8. Is this true? If so, will this be the case in SE 9? >>> >>> On a tangent, Joe referenced a diff of the JavaDocs of two versions of >>> the JSR 269 API, containing nicely colored mark-up highlighting the >>> changes. What's the tool used for creating this diff? >>> >>> Thanks, >>> >>> --Gunnar >>> >>> [1] https://blogs.oracle.com/darcy/entry/jsr_269_mr_for_java >>> [2] >>> http://mail.openjdk.java.net/pipermail/compiler-dev/2014-May/008756.html >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at hibernate.org Fri Aug 15 10:55:49 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 15 Aug 2014 12:55:49 +0200 Subject: Accessing type annotations via annotation processor In-Reply-To: <53ED001C.3020003@oracle.com> References: <53E907CB.9030602@oracle.com> <53ED001C.3020003@oracle.com> Message-ID: 2014-08-14 20:29 GMT+02:00 Eric McCorkle : > On 08/14/14 02:56, Gunnar Morling wrote: > > > > I tried what you suggested, but I only obtained a TypeMirror for > > 'List' from the VariableElement, thus the TypeMirror for the > > type argument represents 'String' rather than '@NotNull String'. > > That is due to the known issues with type annotations. > Ok, I see. Many thanks for the clarification. Is there any known timeframe for fixing these issues? Possibly a later revision for JDK 8? --Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: From gassoumi.akrem.ensi at gmail.com Fri Aug 15 12:21:55 2014 From: gassoumi.akrem.ensi at gmail.com (Akrem Gassoumi) Date: Fri, 15 Aug 2014 13:21:55 +0100 Subject: java runtime error Message-ID: Hi there , I am starting with java learning and by testing the examples you mentionned in "jls8-diif.pdf" page 44 and instead of an output " -727379968 1000000000000 " here what i got instead , Exception in thread "main" java.lang.UnsupportedClassVersionError: Test0 : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:643) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) at java.net.URLClassLoader.access$000(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:212) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:323) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:268) Could not find the main class: Test0. Program will exit. ====So any help , i tried to google it but in vain still no solution PS: Test0 is the name of my class -- GasAkrem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Aug 15 18:04:46 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 15 Aug 2014 11:04:46 -0700 Subject: java runtime error In-Reply-To: References: Message-ID: <53EE4BBE.7000400@oracle.com> Akrem, This list is for the discussion of issues related to the implementation of the Java compiler, javac. -- Jon On 08/15/2014 05:21 AM, Akrem Gassoumi wrote: > > Hi there , > > I am starting with java learning and by testing the examples you > mentionned in "jls8-diif.pdf" page 44 and instead of an output " > -727379968 > 1000000000000 > " > > > here what i got instead , > > Exception in thread "main" java.lang.UnsupportedClassVersionError: > Test0 : Unsupported major.minor version 51.0 > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:643) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) > at java.net.URLClassLoader.access$000(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:212) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:205) > at java.lang.ClassLoader.loadClass(ClassLoader.java:323) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) > at java.lang.ClassLoader.loadClass(ClassLoader.java:268) > Could not find the main class: Test0. Program will exit. > > ====So any help , i tried to google it but in vain still no solution > PS: Test0 is the name of my class > > > -- > GasAkrem From timeroot.alex at gmail.com Mon Aug 18 17:49:59 2014 From: timeroot.alex at gmail.com (Alex Meiburg) Date: Mon, 18 Aug 2014 10:49:59 -0700 Subject: Duplicate compilation attempt when code is too large In-Reply-To: References: Message-ID: Sorry, I'm unsure what to do, given the lack of response -- should I ask for someone to file this as a bug report, so that this patch could be filed in response to it? It's a small fix, if someone could pull it, that would be nice. :) -- Alexander Meiburg ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Aug 18 19:45:23 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 18 Aug 2014 12:45:23 -0700 Subject: Duplicate compilation attempt when code is too large In-Reply-To: References: Message-ID: <53F257D3.3000007@oracle.com> On 08/18/2014 10:49 AM, Alex Meiburg wrote: > Sorry, I'm unsure what to do, given the lack of response -- should I > ask for someone to file this as a bug report, so that this patch could > be filed in response to it? It's a small fix, if someone could pull > it, that would be nice. :) > > -- Alexander Meiburg > ? Alex, For a general background on making contributions, see http://openjdk.java.net/contribute/ Also, while I accept that your two comments are both very small, the general rule is one fix per patch. -- Jon From jonathan.gibbons at oracle.com Mon Aug 18 19:54:10 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 18 Aug 2014 12:54:10 -0700 Subject: Duplicate compilation attempt when code is too large In-Reply-To: References: Message-ID: <53F259E2.9010307@oracle.com> On 08/03/2014 09:52 AM, Alex Meiburg wrote: > Hi, > > This is my first time posting to this list, and I'm not sure of the > right protocol -- I've got the following patch to submit. When jsr/ret > were in use, if a method ran over the 64k code limit, it would try > compilation again with more aggressive space optimization. Since > jsr/ret aren't used any more, this just means that it takes twice as > long to report the error to the user. > > There's also some (unused) code in dump() that was printing to sysout > where it should have been printing to syserr. > > I have the patch attached, how/where do I submit it? Please excuse my > ignorance, I couldn't find the answer. Thanks! > > -- Alexander Meiburg I looked at the suggestion for Gen. The code has been partially cleaned up in this area, such that the catch block is now dead code. So there isn't an "efficiency" argument to be made here, but I agree that cleaning up the dead code (and the dead exception which appears to no longer be thrown) would be a good idea. I looked at the suggestion for Code, and the inconsistent use of System.out and System.err. I think a good fix here would be to declare a single local variable to specify the stream to which all the printing in that method should be done. -- Jon From timeroot.alex at gmail.com Mon Aug 18 20:28:11 2014 From: timeroot.alex at gmail.com (Alex Meiburg) Date: Mon, 18 Aug 2014 13:28:11 -0700 Subject: Duplicate compilation attempt when code is too large In-Reply-To: <53F259E2.9010307@oracle.com> References: <53F259E2.9010307@oracle.com> Message-ID: Thanks. I was unsure if I should ask for a bug id if I'm just submitted a patch right off the bat, since there's not much to be "tracked". I split it up into two patches: I cut out the whole CodeSizeOverflow class in the former. In the latter there is now a second method available to which you can pass a PrintStream, and the earlier method defaults to syserr. -- Alexander Meiburg 2014-08-18 12:54 GMT-07:00 Jonathan Gibbons : > > On 08/03/2014 09:52 AM, Alex Meiburg wrote: > >> Hi, >> >> This is my first time posting to this list, and I'm not sure of the right >> protocol -- I've got the following patch to submit. When jsr/ret were in >> use, if a method ran over the 64k code limit, it would try compilation >> again with more aggressive space optimization. Since jsr/ret aren't used >> any more, this just means that it takes twice as long to report the error >> to the user. >> >> There's also some (unused) code in dump() that was printing to sysout >> where it should have been printing to syserr. >> >> I have the patch attached, how/where do I submit it? Please excuse my >> ignorance, I couldn't find the answer. Thanks! >> >> -- Alexander Meiburg >> > > I looked at the suggestion for Gen. The code has been partially cleaned > up in this area, such that the catch block is now dead code. So there isn't > an "efficiency" argument to be made here, but I agree that cleaning up the > dead code (and the dead exception which appears to no longer be thrown) > would be a good idea. > > I looked at the suggestion for Code, and the inconsistent use of > System.out and System.err. I think a good fix here would be to declare a > single local variable to specify the stream to which all the printing in > that method should be done. > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2565_gen_overflow.patch Type: application/octet-stream Size: 1745 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2566_code_dump.patch Type: application/octet-stream Size: 3182 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Mon Aug 18 20:34:47 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 18 Aug 2014 13:34:47 -0700 Subject: Duplicate compilation attempt when code is too large In-Reply-To: References: <53F259E2.9010307@oracle.com> Message-ID: <53F26367.2070407@oracle.com> If you anticipate making more contributions to OpenJDK, I would encourage you to sign the Oracle Contributor Agreement. We do need for folk to sign this before we can accept any non-trivial patches. http://openjdk.java.net/contribute/ -- Jon On 08/18/2014 01:28 PM, Alex Meiburg wrote: > Thanks. I was unsure if I should ask for a bug id if I'm just > submitted a patch right off the bat, since there's not much to be > "tracked". > > I split it up into two patches: I cut out the whole CodeSizeOverflow > class in the former. In the latter there is now a second method > available to which you can pass a PrintStream, and the earlier method > defaults to syserr. > > -- Alexander Meiburg > > > 2014-08-18 12:54 GMT-07:00 Jonathan Gibbons > >: > > > On 08/03/2014 09:52 AM, Alex Meiburg wrote: > > Hi, > > This is my first time posting to this list, and I'm not sure > of the right protocol -- I've got the following patch to > submit. When jsr/ret were in use, if a method ran over the 64k > code limit, it would try compilation again with more > aggressive space optimization. Since jsr/ret aren't used any > more, this just means that it takes twice as long to report > the error to the user. > > There's also some (unused) code in dump() that was printing to > sysout where it should have been printing to syserr. > > I have the patch attached, how/where do I submit it? Please > excuse my ignorance, I couldn't find the answer. Thanks! > > -- Alexander Meiburg > > > I looked at the suggestion for Gen. The code has been partially > cleaned up in this area, such that the catch block is now dead > code. So there isn't an "efficiency" argument to be made here, but > I agree that cleaning up the dead code (and the dead exception > which appears to no longer be thrown) would be a good idea. > > I looked at the suggestion for Code, and the inconsistent use of > System.out and System.err. I think a good fix here would be to > declare a single local variable to specify the stream to which all > the printing in that method should be done. > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Aug 19 00:40:13 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 18 Aug 2014 17:40:13 -0700 Subject: Accessing type annotations via annotation processor In-Reply-To: References: <53E907CB.9030602@oracle.com> <53ECF109.6020401@oracle.com> Message-ID: <53F29CED.7080600@oracle.com> Hello, On 08/15/2014 03:53 AM, Gunnar Morling wrote: > Hi, > > 2014- 8-14 19:25 GMT+02:00 Joe Darcy >: > > Hello, > > > On 08/13/2014 11:56 PM, Gunnar Morling wrote: >> Hi Alex, >> >> 2014-08-11 20:13 GMT+02:00 Alex Buckley > >: >> >> There are some known problems with retrieving type >> annotations on type parameter declarations, in both the Core >> Reflection API and the Language Model API. I believe type >> annotations on types used in member declarations work OK. If >> you have the VariableElement for 'values', you can get the >> TypeMirror for 'List<@NotNull String>', then visit it as a >> DeclaredType and call getTypeArguments() to get a TypeMirror >> for '@NotNull String'. TypeMirror is an AnnotatedConstruct so >> it can return the annotations on the use of 'String'. >> >> >> I tried what you suggested, but I only obtained a TypeMirror for >> 'List' from the VariableElement, thus the TypeMirror for >> the type argument represents 'String' rather than '@NotNull >> String'. Is there any example or test in OpenJDK which shows the >> retrieval of type annotations via the Language Model API? > > Since the AnnotatedConstruct interface is now implemented by both > elements and type mirrors, is *should* work go call the annotation > retrieval methods on a TypeMirror. > > >> >> Another issue is that the process() method of the annotation >> processor is never invoked for the @NotNull annotation if it is >> only used as type annotation (the processor will be invoked >> though if @NotNull is e.g. used as a traditional field-level >> annotation). Is this an expected behavior? > > From the revised discovery process documented in > javax.annotation.processing.Processor: > > "Annotations on type uses, as opposed to annotations on elements, > are ignored when computing whether or not an annotation type is > present." > > > Ah, I see. Thanks for the pointer. > > Are there any plans to remove this restriction? No; that was a conscious design decision. Type annotation are relatively uncommon and we thought it would be a poor trade-off to require much more extensive scanning of sources to look for annotations in those positions. > > Our annotation processor for Bean Validation aims at detecting > constraint declaration errors such as "List<@Email Integer> email" > (applying the @Email constraint to Integers does not make sense), but > as it stands its not possible to implement such check for type > annotations atm. To implement this functional, you could declare an annotation processor to process "*" and then do your own scans for the annotations of interest. HTH, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at hibernate.org Tue Aug 19 06:54:06 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 19 Aug 2014 08:54:06 +0200 Subject: Accessing type annotations via annotation processor In-Reply-To: <53F29CED.7080600@oracle.com> References: <53E907CB.9030602@oracle.com> <53ECF109.6020401@oracle.com> <53F29CED.7080600@oracle.com> Message-ID: Hi, 2014-08-19 2:40 GMT+02:00 Joe Darcy : > Hello, > > > On 08/15/2014 03:53 AM, Gunnar Morling wrote: > > Hi, > > 2014- 8-14 19:25 GMT+02:00 Joe Darcy : > >> Hello, >> >> >> On 08/13/2014 11:56 PM, Gunnar Morling wrote: >> >> Hi Alex, >> >> 2014-08-11 20:13 GMT+02:00 Alex Buckley : >> >>> There are some known problems with retrieving type annotations on type >>> parameter declarations, in both the Core Reflection API and the Language >>> Model API. I believe type annotations on types used in member declarations >>> work OK. If you have the VariableElement for 'values', you can get the >>> TypeMirror for 'List<@NotNull String>', then visit it as a DeclaredType and >>> call getTypeArguments() to get a TypeMirror for '@NotNull String'. >>> TypeMirror is an AnnotatedConstruct so it can return the annotations on the >>> use of 'String'. >> >> >> I tried what you suggested, but I only obtained a TypeMirror for >> 'List' from the VariableElement, thus the TypeMirror for the type >> argument represents 'String' rather than '@NotNull String'. Is there any >> example or test in OpenJDK which shows the retrieval of type annotations >> via the Language Model API? >> >> >> Since the AnnotatedConstruct interface is now implemented by both >> elements and type mirrors, is *should* work go call the annotation >> retrieval methods on a TypeMirror. >> >> >> >> Another issue is that the process() method of the annotation processor >> is never invoked for the @NotNull annotation if it is only used as type >> annotation (the processor will be invoked though if @NotNull is e.g. used >> as a traditional field-level annotation). Is this an expected behavior? >> >> >> From the revised discovery process documented in >> javax.annotation.processing.Processor: >> >> "Annotations on type uses, as opposed to annotations on elements, are >> ignored when computing whether or not an annotation type is present." >> > > Ah, I see. Thanks for the pointer. > > Are there any plans to remove this restriction? > > > No; that was a conscious design decision. Type annotation are relatively > uncommon and we thought it would be a poor trade-off to require much more > extensive scanning of sources to look for annotations in those positions. > I understand. At some point it might make sense to have some sort of switch which enables the discovery of type annotations (e.g. a processor could declare that it needs to handle type annotations). But what you describe below should work for me atm. > Our annotation processor for Bean Validation aims at detecting > constraint declaration errors such as "List<@Email Integer> email" > (applying the @Email constraint to Integers does not make sense), but as it > stands its not possible to implement such check for type annotations atm. > > > To implement this functional, you could declare an annotation processor to > process "*" and then do your own scans for the annotations of interest. > Ah, yes. I somehow assumed that an annotation processor would only ever be invoked if there is at least one annotation present; but when processing "*" I indeed see completely un-annotated root elements via RoundEnvironment #getRootElements(). > > HTH, > > -Joe > Many thanks for your help, --Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Tue Aug 19 06:58:41 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Tue, 19 Aug 2014 08:58:41 +0200 Subject: RFR 8054715: Changing the source roots and/or their filters forces a full recompile. In-Reply-To: References: Message-ID: <20140819065840.GD26119@e6430> On Fri, Aug 08, 2014 at 11:16:14PM +0200, Fredrik ?hrstr?m wrote: > Changing the source roots and/or their filters forces a full recompile, > since the source roots and the filters are included in the command line > memory in the javac_state file. > > This is a bug, since all changes to the set of source files should be > gracefully handled incrementally. > > SJavac should do an incremental compile both when: > beta/B.java is deleted from the file system (this works) > or when > "-x beta" is added to the command line to exclude beta/B.java from > compilation (this does not work). > > Simple fix, do not include the filters and the source roots in the memory > line in the javac_state file. So you say it works if beta/B.java is in fact deleted, but doesn't work if "-x beta" is added. Ideally "-x beta" should hide beta and the effect should be the same as if beta/B.java was removed from the file system, no? If we solve this by changing what we save in javac_state it feels like we're fixing the problem in the wrong place. If there's just no way to solve this at a better level of abstraction, then I would still argue that we shouldn't decide what options to save or not to save in javac_state based on these kind of corner cases. Save all options as is, and then, when deciding whether to do an incremental compile or not, we take the relevant options into account. -- Andreas From oehrstroem at gmail.com Tue Aug 19 08:50:34 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Tue, 19 Aug 2014 10:50:34 +0200 Subject: RFR 8054715: Changing the source roots and/or their filters forces a full recompile. In-Reply-To: <20140819065840.GD26119@e6430> References: <20140819065840.GD26119@e6430> Message-ID: The command line stored in javac_state is only used to detect if sjavac should recompile all sources from scratch. Options that do not affect the output should not be stored there. "-x" "-i" are such options. 2014-08-19 8:58 GMT+02:00 Andreas Lundblad : > On Fri, Aug 08, 2014 at 11:16:14PM +0200, Fredrik ?hrstr?m wrote: > > Changing the source roots and/or their filters forces a full recompile, > > since the source roots and the filters are included in the command line > > memory in the javac_state file. > > > > This is a bug, since all changes to the set of source files should be > > gracefully handled incrementally. > > > > SJavac should do an incremental compile both when: > > beta/B.java is deleted from the file system (this works) > > or when > > "-x beta" is added to the command line to exclude beta/B.java from > > compilation (this does not work). > > > > Simple fix, do not include the filters and the source roots in the memory > > line in the javac_state file. > > > So you say it works if beta/B.java is in fact deleted, but doesn't work if > "-x beta" is added. Ideally "-x beta" should hide beta and the effect > should be the same as if beta/B.java was removed from the file system, no? > If we solve this by changing what we save in javac_state it feels like > we're fixing the problem in the wrong place. > > If there's just no way to solve this at a better level of abstraction, > then I would still argue that we shouldn't decide what options to save or > not to save in javac_state based on these kind of corner cases. Save all > options as is, and then, when deciding whether to do an incremental compile > or not, we take the relevant options into account. > > -- Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Tue Aug 19 08:52:04 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Tue, 19 Aug 2014 10:52:04 +0200 Subject: RFR 8054715: Changing the source roots and/or their filters forces a full recompile. In-Reply-To: References: <20140819065840.GD26119@e6430> Message-ID: 2014-08-19 10:50 GMT+02:00 Fredrik ?hrstr?m : > The command line stored in javac_state is only used to detect if sjavac > should recompile all sources from scratch. Options that do not affect the > output should not be stored there. "-x" "-i" are such options. > Well, "-x" and "-i" affect the output, but in the same way as usual editing does, ie the incremental compile handles it well, therefore changes to "-x" and "-i" should not trigger a full recompile of all sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Thu Aug 21 08:34:26 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Thu, 21 Aug 2014 10:34:26 +0200 Subject: RFR 8054715: Changing the source roots and/or their filters forces a full recompile. In-Reply-To: References: <20140819065840.GD26119@e6430> Message-ID: <20140821083426.GH11257@e6430> On Tue, Aug 19, 2014 at 10:52:04AM +0200, Fredrik ?hrstr?m wrote: > 2014-08-19 10:50 GMT+02:00 Fredrik ?hrstr?m : > > > The command line stored in javac_state is only used to detect if sjavac > > should recompile all sources from scratch. Options that do not affect the > > output should not be stored there. "-x" "-i" are such options. > > > > Well, "-x" and "-i" affect the output, but in the same way as usual editing > does, ie the incremental compile handles it well, therefore changes to "-x" > and "-i" should not trigger a full recompile of all sources. Ok. I think have a clearer picture now. The change looks reasonable to me. In the long run I think we should be aiming for something closer to the semantics. That is, rather than recording the command line options we should record the actions that the options triggered. -- Andreas From erik.joelsson at oracle.com Thu Aug 21 08:42:31 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Aug 2014 10:42:31 +0200 Subject: RFR 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: References: Message-ID: <53F5B0F7.3070507@oracle.com> I can't comment on the code quality of this patch, but I do think this feature is important. I can't recommend people to try sjavac with a straight face at the moment as it will no longer guarantee a correct incremental build. The current behavior when I add a public field to java/lang/Object is that all of java.base is recompiled, then the rest of the modules are sent to sjavac (as make thinks they need to be recompiled) and sjavac does nothing with them. /Erik On 2014-08-09 00:22, Fredrik ?hrstr?m wrote: > Here is very useful feature addition to sjavac, in fact it is required > for a modularized OpenJDK build (Jigsawified), where not all sources > are sent to sjavac at the same time. > > sjavac should track the public apis of the classes in the classpath, > that the previous compile has linked to. If the public api of the > linked to classes has changed, then this should trigger a recompile of > the appropriate sources. > > This is a very useful feature. Currently sjavac must be fed all > sources that belong to the product in a single huge compile. The > OpenJDK is already at the limit of what fits in a reasonable (of > today) sized Java heap. Other products are significantly larger and > therefore cannot make use of the incremental compile in sjavac. > > With this feature, it is possible to compile the product as separate > jar files, as long as the build dependencies for the jar files are a > directed acyclic graph, then each succesive compile will detect if > there were any changes in the public apis of the dependency jar files. > If the public apis of the dependencies were not changed, and there > were no other source changes for that jar, it will not be recompiled! > But if there were changes in the public apis of the dependencies, then > only the appropriate parts of the jar will be recompiled! > > This is the first draft of this large patch. In particular the new > file Compile.java is a misnamer, it does NOT compile, it is used to > extract the public apis of the classes on the classpath. Somehowe > Compile.java should perhaps be part of JavaService. It is important > that this public api scanning does not require a javac server started > though. > > http://cr.openjdk.java.net/~ohrstrom/webrev-8054717-classpathdep/ > > > https://bugs.openjdk.java.net/browse/JDK-8054717 > > //Fredrik From erik.joelsson at oracle.com Thu Aug 21 14:58:19 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Aug 2014 16:58:19 +0200 Subject: RFR: JDK-8055767: Sjavac is leaking servers Message-ID: <53F6090B.9040308@oracle.com> Hello, Please review this simple fix to a rather annoying problem. Since JDK-8044131, Sjavac is never shutting down the server, at least not on Unix platforms. I have just killed a big bunch of stale servers in JPRT. Bug: https://bugs.openjdk.java.net/browse/JDK-8055767 Patch inline: diff -r 4d1ea4477956 src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java --- a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java @@ -310,7 +310,7 @@ @Override public void shutdown(String quitMsg) { - if (!keepAcceptingRequests.compareAndSet(false, true)) { + if (!keepAcceptingRequests.compareAndSet(true, false)) { // Already stopped, no need to shut down again return; } /Erik From jonathan.gibbons at oracle.com Thu Aug 21 22:05:55 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 21 Aug 2014 15:05:55 -0700 Subject: RFR 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: <53F5B0F7.3070507@oracle.com> References: <53F5B0F7.3070507@oracle.com> Message-ID: <53F66D43.2000702@oracle.com> Fredrik, Can you please explain the following some more: > It is important that this public api scanning does not require a javac > server started though. This is /not/ the direction we want to take sjavac. We want to change sjavac from its current client/server split to a (very) thin client, with most of the work happening in the server. In some version of an ideal world, the client would be so simple it could be written in C and not invoke a JVM at all. The client should just locate the server (starting it if necessary) and then dispatch its command line args to be processed in the server. Doing more and more work in a cold unshared JVM to avoid doing work in a hot shared JVM seems like a bad way to go. -- Jon On 08/21/2014 01:42 AM, Erik Joelsson wrote: > I can't comment on the code quality of this patch, but I do think this > feature is important. I can't recommend people to try sjavac with a > straight face at the moment as it will no longer guarantee a correct > incremental build. The current behavior when I add a public field to > java/lang/Object is that all of java.base is recompiled, then the rest > of the modules are sent to sjavac (as make thinks they need to be > recompiled) and sjavac does nothing with them. > > /Erik > > On 2014-08-09 00:22, Fredrik ?hrstr?m wrote: >> Here is very useful feature addition to sjavac, in fact it is >> required for a modularized OpenJDK build (Jigsawified), where not all >> sources are sent to sjavac at the same time. >> >> sjavac should track the public apis of the classes in the classpath, >> that the previous compile has linked to. If the public api of the >> linked to classes has changed, then this should trigger a recompile >> of the appropriate sources. >> >> This is a very useful feature. Currently sjavac must be fed all >> sources that belong to the product in a single huge compile. The >> OpenJDK is already at the limit of what fits in a reasonable (of >> today) sized Java heap. Other products are significantly larger and >> therefore cannot make use of the incremental compile in sjavac. >> >> With this feature, it is possible to compile the product as separate >> jar files, as long as the build dependencies for the jar files are a >> directed acyclic graph, then each succesive compile will detect if >> there were any changes in the public apis of the dependency jar >> files. If the public apis of the dependencies were not changed, and >> there were no other source changes for that jar, it will not be >> recompiled! But if there were changes in the public apis of the >> dependencies, then only the appropriate parts of the jar will be >> recompiled! >> >> This is the first draft of this large patch. In particular the new >> file Compile.java is a misnamer, it does NOT compile, it is used to >> extract the public apis of the classes on the classpath. Somehowe >> Compile.java should perhaps be part of JavaService. It is important >> that this public api scanning does not require a javac server started >> though. >> >> http://cr.openjdk.java.net/~ohrstrom/webrev-8054717-classpathdep/ >> >> >> https://bugs.openjdk.java.net/browse/JDK-8054717 >> >> //Fredrik > From andreas.lundblad at oracle.com Fri Aug 22 07:06:09 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Fri, 22 Aug 2014 09:06:09 +0200 Subject: RFR: JDK-8055767: Sjavac is leaking servers In-Reply-To: <53F6090B.9040308@oracle.com> References: <53F6090B.9040308@oracle.com> Message-ID: <20140822070608.GM11257@e6430> On Thu, Aug 21, 2014 at 04:58:19PM +0200, Erik Joelsson wrote: > Hello, > > Please review this simple fix to a rather annoying problem. Since > JDK-8044131, Sjavac is never shutting down the server, at least not > on Unix platforms. I have just killed a big bunch of stale servers > in JPRT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055767 > Patch inline: > > diff -r 4d1ea4477956 src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java > @@ -310,7 +310,7 @@ > > @Override > public void shutdown(String quitMsg) { > - if (!keepAcceptingRequests.compareAndSet(false, true)) { > + if (!keepAcceptingRequests.compareAndSet(true, false)) { > // Already stopped, no need to shut down again > return; > } > > /Erik Good catch Erik. Looks like an obvious mixup of arguments to me. (I'm not a Reviewer though.) -- Andreas From joel.franck at oracle.com Fri Aug 22 07:24:47 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 22 Aug 2014 09:24:47 +0200 Subject: RFR: JDK-8055767: Sjavac is leaking servers In-Reply-To: <53F6090B.9040308@oracle.com> References: <53F6090B.9040308@oracle.com> Message-ID: <37C3BA2A-CBB5-4E38-9D5B-2636FCC6CA70@oracle.com> Looks good, ship it cheers /Joel On 21 aug 2014, at 16:58, Erik Joelsson wrote: > Hello, > > Please review this simple fix to a rather annoying problem. Since JDK-8044131, Sjavac is never shutting down the server, at least not on Unix platforms. I have just killed a big bunch of stale servers in JPRT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055767 > Patch inline: > > diff -r 4d1ea4477956 src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java > @@ -310,7 +310,7 @@ > > @Override > public void shutdown(String quitMsg) { > - if (!keepAcceptingRequests.compareAndSet(false, true)) { > + if (!keepAcceptingRequests.compareAndSet(true, false)) { > // Already stopped, no need to shut down again > return; > } > > /Erik From oehrstroem at gmail.com Fri Aug 22 15:02:52 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 22 Aug 2014 17:02:52 +0200 Subject: RFR 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: <53F66D43.2000702@oracle.com> References: <53F5B0F7.3070507@oracle.com> <53F66D43.2000702@oracle.com> Message-ID: The path to a super thin client is quite long with a lot of interesting technical problems (I suppose that is why the royal we has not authorized RFR:8044131 since that does not reach the thin client in one go, but is a mere first step) however classpath dependency tracking is needed now. 2014-08-22 0:05 GMT+02:00 Jonathan Gibbons : > Fredrik, > > Can you please explain the following some more: > > It is important that this public api scanning does not require a javac >> server started though. >> > > This is /not/ the direction we want to take sjavac. We want to change > sjavac from its current client/server split to a (very) thin client, with > most of the work happening in the server. In some version of an ideal > world, the client would be so simple it could be written in C and not > invoke a JVM at all. The client should just locate the server (starting > it if necessary) and then dispatch its command line args to be processed in > the server. > > Doing more and more work in a cold unshared JVM to avoid doing work in a > hot shared JVM seems like a bad way to go. > > -- Jon > > > > > On 08/21/2014 01:42 AM, Erik Joelsson wrote: > >> I can't comment on the code quality of this patch, but I do think this >> feature is important. I can't recommend people to try sjavac with a >> straight face at the moment as it will no longer guarantee a correct >> incremental build. The current behavior when I add a public field to >> java/lang/Object is that all of java.base is recompiled, then the rest of >> the modules are sent to sjavac (as make thinks they need to be recompiled) >> and sjavac does nothing with them. >> >> /Erik >> >> On 2014-08-09 00:22, Fredrik ?hrstr?m wrote: >> >>> Here is very useful feature addition to sjavac, in fact it is required >>> for a modularized OpenJDK build (Jigsawified), where not all sources are >>> sent to sjavac at the same time. >>> >>> sjavac should track the public apis of the classes in the classpath, >>> that the previous compile has linked to. If the public api of the linked to >>> classes has changed, then this should trigger a recompile of the >>> appropriate sources. >>> >>> This is a very useful feature. Currently sjavac must be fed all sources >>> that belong to the product in a single huge compile. The OpenJDK is already >>> at the limit of what fits in a reasonable (of today) sized Java heap. Other >>> products are significantly larger and therefore cannot make use of the >>> incremental compile in sjavac. >>> >>> With this feature, it is possible to compile the product as separate jar >>> files, as long as the build dependencies for the jar files are a directed >>> acyclic graph, then each succesive compile will detect if there were any >>> changes in the public apis of the dependency jar files. If the public apis >>> of the dependencies were not changed, and there were no other source >>> changes for that jar, it will not be recompiled! But if there were changes >>> in the public apis of the dependencies, then only the appropriate parts of >>> the jar will be recompiled! >>> >>> This is the first draft of this large patch. In particular the new file >>> Compile.java is a misnamer, it does NOT compile, it is used to extract the >>> public apis of the classes on the classpath. Somehowe Compile.java should >>> perhaps be part of JavaService. It is important that this public api >>> scanning does not require a javac server started though. >>> >>> http://cr.openjdk.java.net/~ohrstrom/webrev-8054717-classpathdep/ < >>> http://cr.openjdk.java.net/%7Eohrstrom/webrev-8054717-classpathdep/> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8054717 >>> >>> //Fredrik >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.lagergren at oracle.com Fri Aug 22 17:12:48 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 22 Aug 2014 19:12:48 +0200 Subject: RFR: JDK-8055767: Sjavac is leaking servers In-Reply-To: <53F6090B.9040308@oracle.com> References: <53F6090B.9040308@oracle.com> Message-ID: <48BDDDC0-144F-4A1E-A62B-5C349AFA4435@oracle.com> +1 On 21 Aug 2014, at 16:58, Erik Joelsson wrote: > Hello, > > Please review this simple fix to a rather annoying problem. Since JDK-8044131, Sjavac is never shutting down the server, at least not on Unix platforms. I have just killed a big bunch of stale servers in JPRT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055767 > Patch inline: > > diff -r 4d1ea4477956 src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/server/SjavacServer.java > @@ -310,7 +310,7 @@ > > @Override > public void shutdown(String quitMsg) { > - if (!keepAcceptingRequests.compareAndSet(false, true)) { > + if (!keepAcceptingRequests.compareAndSet(true, false)) { > // Already stopped, no need to shut down again > return; > } > > /Erik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jonathan.gibbons at oracle.com Fri Aug 22 18:42:36 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Aug 2014 11:42:36 -0700 Subject: RFR 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: References: <53F5B0F7.3070507@oracle.com> <53F66D43.2000702@oracle.com> Message-ID: <53F78F1C.7090803@oracle.com> I think the path to a thin Java client is relatively quick and easy. Once you have located the server, you just have to change the protocol to send argv over the connection and accept stream output coming back. The bulk of the code that currently lives in the fat client can equally well exist and be executed in the server. The bug that Eric described in his message of 08/21/2014 01:42 AM sounds as much like a bug in the build as in sjavac. If a file in a module is modified, in the worst case, all dependent modules should be recompiled. Yes, that is suboptimal, but at least it would give correct class files. sjavac may provide the means to reduce the set of modules that need to be recompiled, but the build should be capable of behaving reasonably even without sjavac. -- Jon On 08/22/2014 08:02 AM, Fredrik ?hrstr?m wrote: > The path to a super thin client is quite long with a lot of > interesting technical problems (I suppose that is why the royal we has > not authorized RFR:8044131 since that does not reach the thin client > in one go, but is a mere first step) however classpath dependency > tracking is needed now. > > > > 2014-08-22 0:05 GMT+02:00 Jonathan Gibbons > >: > > Fredrik, > > Can you please explain the following some more: > > It is important that this public api scanning does not require > a javac server started though. > > > This is /not/ the direction we want to take sjavac. We want to > change sjavac from its current client/server split to a (very) > thin client, with most of the work happening in the server. In > some version of an ideal world, the client would be so simple it > could be written in C and not invoke a JVM at all. The client > should just locate the server (starting it if necessary) and then > dispatch its command line args to be processed in the server. > > Doing more and more work in a cold unshared JVM to avoid doing > work in a hot shared JVM seems like a bad way to go. > > -- Jon > > > > > On 08/21/2014 01:42 AM, Erik Joelsson wrote: > > I can't comment on the code quality of this patch, but I do > think this feature is important. I can't recommend people to > try sjavac with a straight face at the moment as it will no > longer guarantee a correct incremental build. The current > behavior when I add a public field to java/lang/Object is that > all of java.base is recompiled, then the rest of the modules > are sent to sjavac (as make thinks they need to be recompiled) > and sjavac does nothing with them. > > /Erik > > On 2014-08-09 00:22, Fredrik ?hrstr?m wrote: > > Here is very useful feature addition to sjavac, in fact it > is required for a modularized OpenJDK build (Jigsawified), > where not all sources are sent to sjavac at the same time. > > sjavac should track the public apis of the classes in the > classpath, that the previous compile has linked to. If the > public api of the linked to classes has changed, then this > should trigger a recompile of the appropriate sources. > > This is a very useful feature. Currently sjavac must be > fed all sources that belong to the product in a single > huge compile. The OpenJDK is already at the limit of what > fits in a reasonable (of today) sized Java heap. Other > products are significantly larger and therefore cannot > make use of the incremental compile in sjavac. > > With this feature, it is possible to compile the product > as separate jar files, as long as the build dependencies > for the jar files are a directed acyclic graph, then each > succesive compile will detect if there were any changes in > the public apis of the dependency jar files. If the public > apis of the dependencies were not changed, and there were > no other source changes for that jar, it will not be > recompiled! But if there were changes in the public apis > of the dependencies, then only the appropriate parts of > the jar will be recompiled! > > This is the first draft of this large patch. In particular > the new file Compile.java is a misnamer, it does NOT > compile, it is used to extract the public apis of the > classes on the classpath. Somehowe Compile.java should > perhaps be part of JavaService. It is important that this > public api scanning does not require a javac server > started though. > > http://cr.openjdk.java.net/~ohrstrom/webrev-8054717-classpathdep/ > > > > https://bugs.openjdk.java.net/browse/JDK-8054717 > > //Fredrik > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Aug 22 19:45:43 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Aug 2014 12:45:43 -0700 Subject: RFR 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: <53F78F1C.7090803@oracle.com> References: <53F5B0F7.3070507@oracle.com> <53F66D43.2000702@oracle.com> <53F78F1C.7090803@oracle.com> Message-ID: <53F79DE7.5030203@oracle.com> On 08/22/2014 11:42 AM, Jonathan Gibbons wrote: > On 08/22/2014 08:02 AM, Fredrik ?hrstr?m wrote: >> The path to a super thin client is quite long with a lot of >> interesting technical problems (I suppose that is why the royal we >> has not authorized RFR:8044131 since that does not reach the thin >> client in one go, but is a mere first step) however classpath >> dependency tracking is needed now. 8044131 was fixed in changeset 98a99928a76b $ hg log -k 8044131 -v | grep -v ^files: changeset: 2582:98a99928a76b user: alundblad date: Wed Aug 13 14:44:59 2014 +0200 description: 8048457: Sjavac should not use portfiles, sockets, etc if background=false 8044131: Restructure client / server protocol code Summary: Changes protocol code to use Object input/output streams. Avoids spawning server if background=false. Refactors idleness checks, pooling and port file monitoring. Reviewed-by: jjg, jfranck From jose.cornado at gmail.com Sun Aug 24 03:17:46 2014 From: jose.cornado at gmail.com (=?UTF-8?Q?Jos=C3=A9_Cornado?=) Date: Sat, 23 Aug 2014 21:17:46 -0600 Subject: Guidance on fork/join internal behavior Message-ID: Hello! I know that this is the wrong list but where can I find a document about how the JVM behaves when a big number of cpu cores are present. Thanks a lot in advance! -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Mon Aug 25 14:50:47 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Aug 2014 16:50:47 +0200 Subject: RFR: JDK-8055922: Work around sjavac limitation with public api tracking cross modules Message-ID: <53FB4D47.6010505@oracle.com> Hello, Please review this little workaround for a current shortcoming in Sjavac. See bug for more details. With this change, Sjavac will start acting correctly again and not miss any files that need to be recompiled. The approximation is course however, we should still fix https://bugs.openjdk.java.net/browse/JDK-8054717 to properly only recompile what is really necessary. Still, this workaround does add value compared to running without sjavac. With this change and JDK-8014510 (also on review) I'm starting to feel confident enough to make sjavac default for building jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-8055922 Webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.01/ /Erik From erik.joelsson at oracle.com Tue Aug 26 09:58:45 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Aug 2014 11:58:45 +0200 Subject: RFR: JDK-8055922: Work around sjavac limitation with public api tracking cross modules In-Reply-To: <53FB4D47.6010505@oracle.com> References: <53FB4D47.6010505@oracle.com> Message-ID: <53FC5A55.1000405@oracle.com> Updated webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.02/ Some of the demos failed to compile because the javac_state file did not contain any public api and this caused grep to exit with code 1, which failed the build. I made exit code 1 for this grep line not fail the build. /Erik On 2014-08-25 16:50, Erik Joelsson wrote: > Hello, > > Please review this little workaround for a current shortcoming in > Sjavac. See bug for more details. With this change, Sjavac will start > acting correctly again and not miss any files that need to be > recompiled. The approximation is course however, we should still fix > https://bugs.openjdk.java.net/browse/JDK-8054717 to properly only > recompile what is really necessary. Still, this workaround does add > value compared to running without sjavac. With this change and > JDK-8014510 (also on review) I'm starting to feel confident enough to > make sjavac default for building jdk9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055922 > Webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.01/ > > /Erik From magnus.ihse.bursie at oracle.com Tue Aug 26 10:06:11 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 26 Aug 2014 12:06:11 +0200 Subject: RFR: JDK-8055922: Work around sjavac limitation with public api tracking cross modules In-Reply-To: <53FC5A55.1000405@oracle.com> References: <53FB4D47.6010505@oracle.com> <53FC5A55.1000405@oracle.com> Message-ID: <53FC5C13.8070404@oracle.com> On 2014-08-26 11:58, Erik Joelsson wrote: > Updated webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.02/ > > Some of the demos failed to compile because the javac_state file did > not contain any public api and this caused grep to exit with code 1, > which failed the build. I made exit code 1 for this grep line not fail > the build. Looks good to me. /Magnus From oehrstroem at gmail.com Wed Aug 27 00:12:46 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 27 Aug 2014 02:12:46 +0200 Subject: RFR 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: <53F78F1C.7090803@oracle.com> References: <53F5B0F7.3070507@oracle.com> <53F66D43.2000702@oracle.com> <53F78F1C.7090803@oracle.com> Message-ID: It seems like the development speed for sjavac needs to be increased significantly, one JIRA bug, one 2 week review cycle, leads to one commit is much too slow. I belive it would be good to have a separate repository to do quicker development of sjavac, and test out all sorts of interesting stuff, after which a larger more polished review can be published here. I have now created such a high speed development repository and published my changes that I made over two late night hacks: https://bitbucket.org/jabberbeak/sjavac I believe that now when the OpenJDK sources are modularized, we should move sjavac to its own "module" perhaps jdk.sjavac. I also published a blog post on the contents of the high speed development repository, called "The Smart Javac Wrapper JDK8 Backport with Extras" and it can be found here: http://fredrikohrstrom.blogspot.se/ On Fri, Aug 22, 2014 at 8:42 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > I think the path to a thin Java client is relatively quick and easy. > > Once you have located the server, you just have to change the protocol to > send argv over the connection and accept stream output coming back. The > bulk of the code that currently lives in the fat client can equally well > exist and be executed in the server. > > The bug that Eric described in his message of 08/21/2014 01:42 AM sounds > as much like a bug in the build as in sjavac. If a file in a module is > modified, in the worst case, all dependent modules should be recompiled. > Yes, that is suboptimal, but at least it would give correct class files. > sjavac may provide the means to reduce the set of modules that need to be > recompiled, but the build should be capable of behaving reasonably even > without sjavac. > > -- Jon > > > > On 08/22/2014 08:02 AM, Fredrik ?hrstr?m wrote: > > The path to a super thin client is quite long with a lot of interesting > technical problems (I suppose that is why the royal we has not authorized > RFR:8044131 since that does not reach the thin client in one go, but is a > mere first step) however classpath dependency tracking is needed now. > > > > 2014-08-22 0:05 GMT+02:00 Jonathan Gibbons : > >> Fredrik, >> >> Can you please explain the following some more: >> >> It is important that this public api scanning does not require a javac >>> server started though. >>> >> >> This is /not/ the direction we want to take sjavac. We want to change >> sjavac from its current client/server split to a (very) thin client, with >> most of the work happening in the server. In some version of an ideal >> world, the client would be so simple it could be written in C and not >> invoke a JVM at all. The client should just locate the server (starting >> it if necessary) and then dispatch its command line args to be processed in >> the server. >> >> Doing more and more work in a cold unshared JVM to avoid doing work in a >> hot shared JVM seems like a bad way to go. >> >> -- Jon >> >> >> >> >> On 08/21/2014 01:42 AM, Erik Joelsson wrote: >> >>> I can't comment on the code quality of this patch, but I do think this >>> feature is important. I can't recommend people to try sjavac with a >>> straight face at the moment as it will no longer guarantee a correct >>> incremental build. The current behavior when I add a public field to >>> java/lang/Object is that all of java.base is recompiled, then the rest of >>> the modules are sent to sjavac (as make thinks they need to be recompiled) >>> and sjavac does nothing with them. >>> >>> /Erik >>> >>> On 2014-08-09 00:22, Fredrik ?hrstr?m wrote: >>> >>>> Here is very useful feature addition to sjavac, in fact it is required >>>> for a modularized OpenJDK build (Jigsawified), where not all sources are >>>> sent to sjavac at the same time. >>>> >>>> sjavac should track the public apis of the classes in the classpath, >>>> that the previous compile has linked to. If the public api of the linked to >>>> classes has changed, then this should trigger a recompile of the >>>> appropriate sources. >>>> >>>> This is a very useful feature. Currently sjavac must be fed all sources >>>> that belong to the product in a single huge compile. The OpenJDK is already >>>> at the limit of what fits in a reasonable (of today) sized Java heap. Other >>>> products are significantly larger and therefore cannot make use of the >>>> incremental compile in sjavac. >>>> >>>> With this feature, it is possible to compile the product as separate >>>> jar files, as long as the build dependencies for the jar files are a >>>> directed acyclic graph, then each succesive compile will detect if there >>>> were any changes in the public apis of the dependency jar files. If the >>>> public apis of the dependencies were not changed, and there were no other >>>> source changes for that jar, it will not be recompiled! But if there were >>>> changes in the public apis of the dependencies, then only the appropriate >>>> parts of the jar will be recompiled! >>>> >>>> This is the first draft of this large patch. In particular the new file >>>> Compile.java is a misnamer, it does NOT compile, it is used to extract the >>>> public apis of the classes on the classpath. Somehowe Compile.java should >>>> perhaps be part of JavaService. It is important that this public api >>>> scanning does not require a javac server started though. >>>> >>>> http://cr.openjdk.java.net/~ohrstrom/webrev-8054717-classpathdep/ < >>>> http://cr.openjdk.java.net/%7Eohrstrom/webrev-8054717-classpathdep/> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8054717 >>>> >>>> //Fredrik >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.franck at oracle.com Wed Aug 27 09:34:27 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 27 Aug 2014 11:34:27 +0200 Subject: RFR: JDK-8055922: Work around sjavac limitation with public api tracking cross modules In-Reply-To: <53FC5A55.1000405@oracle.com> References: <53FB4D47.6010505@oracle.com> <53FC5A55.1000405@oracle.com> Message-ID: Can?t really comment on the makefile changes but I think this workaround is good for now. Thumbs up cheers /Joel On 26 aug 2014, at 11:58, Erik Joelsson wrote: > Updated webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.02/ > > Some of the demos failed to compile because the javac_state file did not contain any public api and this caused grep to exit with code 1, which failed the build. I made exit code 1 for this grep line not fail the build. > > /Erik > > On 2014-08-25 16:50, Erik Joelsson wrote: >> Hello, >> >> Please review this little workaround for a current shortcoming in Sjavac. See bug for more details. With this change, Sjavac will start acting correctly again and not miss any files that need to be recompiled. The approximation is course however, we should still fix https://bugs.openjdk.java.net/browse/JDK-8054717 to properly only recompile what is really necessary. Still, this workaround does add value compared to running without sjavac. With this change and JDK-8014510 (also on review) I'm starting to feel confident enough to make sjavac default for building jdk9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055922 >> Webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.01/ >> >> /Erik > From andreas.lundblad at oracle.com Thu Aug 28 14:50:49 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Thu, 28 Aug 2014 16:50:49 +0200 Subject: RFR: 8056252, Incremental build fails on Windows Message-ID: <20140828145048.GF14449@e6430> Hi compiler-dev, Please review this patch which addresses part of JDK-8056252. - Description: Sjavac incorrectly translates directory names to packages by .replace('/', '.'). This in inappropriate on Windows which uses '\' as path separator. No test added in this patch, as the SJavac.java test fails before the patch is applied and passes after. - Links to bug report: https://bugs.openjdk.java.net/browse/JDK-8056252 Patch inlined below (kudos to Erik Joelsson for figuring this out!): diff -r a75064469e3f src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java --- a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java Wed Aug 27 11:41:03 2014 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java Thu Aug 28 16:48:39 2014 +0200 @@ -313,7 +313,7 @@ int sp = fn.lastIndexOf(File.separatorChar); String pkg = ""; if (sp != -1) { - pkg = fn.substring(0,sp).replace('/','.'); + pkg = fn.substring(0,sp).replace(File.separatorChar,'.'); } // Is this a module-info.java file? if (fn.endsWith("module-info.java")) { -- Andreas From joel.franck at oracle.com Fri Aug 29 11:09:10 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 29 Aug 2014 13:09:10 +0200 Subject: RFR: 8056252, Incremental build fails on Windows In-Reply-To: <20140828145048.GF14449@e6430> References: <20140828145048.GF14449@e6430> Message-ID: Looks good cheers /Joel On 28 aug 2014, at 16:50, Andreas Lundblad wrote: > Hi compiler-dev, > > Please review this patch which addresses part of JDK-8056252. > > - Description: > Sjavac incorrectly translates directory names to packages by .replace('/', '.'). This in inappropriate on Windows which uses '\' as path separator. > > No test added in this patch, as the SJavac.java test fails before the patch is applied and passes after. > > - Links to bug report: > https://bugs.openjdk.java.net/browse/JDK-8056252 > > > Patch inlined below (kudos to Erik Joelsson for figuring this out!): > > diff -r a75064469e3f src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java Wed Aug 27 11:41:03 2014 +0100 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Source.java Thu Aug 28 16:48:39 2014 +0200 > @@ -313,7 +313,7 @@ > int sp = fn.lastIndexOf(File.separatorChar); > String pkg = ""; > if (sp != -1) { > - pkg = fn.substring(0,sp).replace('/','.'); > + pkg = fn.substring(0,sp).replace(File.separatorChar,'.'); > } > // Is this a module-info.java file? > if (fn.endsWith("module-info.java")) { > > > > -- Andreas From Ulf.Zibis at CoSoCo.de Fri Aug 29 20:53:50 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 29 Aug 2014 22:53:50 +0200 Subject: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters In-Reply-To: References: <53E7FA44.9050207@oracle.com> <476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com> <53E8CCD6.2090503@CoSoCo.de> <53FDA7C1.6060303@CoSoCo.de> <902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com> <53FF7244.2030804@CoSoCo.de> Message-ID: <5400E85E.9030005@CoSoCo.de> Hi compiler people, is there some chance that javac could be enhanced to optimize better as discussed in this thread? Than refactoring of up to now better readable code to ugly StringBuilder at append() code would be superfluous. I really like the String concatenation syntax, but unfortunately it often causes slower code and bigger footprint. Optimally javac would optimize mixed use of StringBuilder, StringJoiner, concatenation, toString(), append(String), append(Collection) etc. to a single StringBuilder instance, so that the resulting code, JITed or not, will have better performance. Additionally javac could guess a reasonable initial capacity from the given source code. Am 29.08.2014 um 10:01 schrieb Wang Weijun: > So it's not that the optimization fails but there is no optimization on them yet. > > I do see the .append("x") case will be easy to deal with, but it looks like historically javac has not been a place to do many optimizations. It mostly converts the java source to byte codes in a 1-to-1 mapping and let VM do whatever it wants (to optimize). When you talked about compiling multiple concatenation into using a single StringBuilder, it's more like choosing the correct implementation rather than an optimization. > > I don't expect to see big change on this in the near future, so shall we go on with the current enhancement? > > Thanks > Max > > On Aug 29, 2014, at 2:17, Ulf Zibis wrote: > >> I mean: >> It does not output byte code that only uses a single char array to compose the entire String in question. >> With "optimization fails", I also mean, there is used an additional "StringComposer" e.g. another StringBuilder or a StringJoiner in addition to the 1st StringBuilder. >> >> -Ulf >> >> Am 27.08.2014 um 14:02 schrieb Pavel Rappo: >>> Could you please explain what you mean by "javac optimization fails" here? >>> >>> -Pavel >>> >>> On 27 Aug 2014, at 10:41, Ulf Zibis wrote: >>> >>>> 4.) Now we see, that javac optimization fails again if StringBuilder, concatenation, toString(), append(String), append(Collection) etc. and StringJoiner use is mixed. > From vitalyd at gmail.com Fri Aug 29 22:10:03 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 29 Aug 2014 18:10:03 -0400 Subject: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters In-Reply-To: <5400E85E.9030005@CoSoCo.de> References: <53E7FA44.9050207@oracle.com> <476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com> <53E8CCD6.2090503@CoSoCo.de> <53FDA7C1.6060303@CoSoCo.de> <902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com> <53FF7244.2030804@CoSoCo.de> <5400E85E.9030005@CoSoCo.de> Message-ID: It's probably best to teach the JIT to handle more of these cases. The reason is I don't think the longer compile time will be worth it considering that, on a large codebase, there will inevitably be lots of places where these patterns appear but have no dominance at runtime (either because they're not called or called just a few times). Additionally, these patterns are unlikely to appear in hot code paths; no matter what type of concat/string building (practical) optimizations you do, that type of code will kill performance. Assuming that's true, what's the value add given the costs? Sent from my phone On Aug 29, 2014 4:54 PM, "Ulf Zibis" wrote: > Hi compiler people, > > is there some chance that javac could be enhanced to optimize better as > discussed in this thread? Than refactoring of up to now better readable > code to ugly StringBuilder at append() code would be superfluous. > I really like the String concatenation syntax, but unfortunately it often > causes slower code and bigger footprint. > Optimally javac would optimize mixed use of StringBuilder, StringJoiner, > concatenation, toString(), append(String), append(Collection) etc. to a > single StringBuilder instance, so that the resulting code, JITed or not, > will have better performance. > Additionally javac could guess a reasonable initial capacity from the > given source code. > > > Am 29.08.2014 um 10:01 schrieb Wang Weijun: > >> So it's not that the optimization fails but there is no optimization on >> them yet. >> >> I do see the .append("x") case will be easy to deal with, but it looks >> like historically javac has not been a place to do many optimizations. It >> mostly converts the java source to byte codes in a 1-to-1 mapping and let >> VM do whatever it wants (to optimize). When you talked about compiling >> multiple concatenation into using a single StringBuilder, it's more like >> choosing the correct implementation rather than an optimization. >> >> I don't expect to see big change on this in the near future, so shall we >> go on with the current enhancement? >> >> Thanks >> Max >> >> On Aug 29, 2014, at 2:17, Ulf Zibis wrote: >> >> I mean: >>> It does not output byte code that only uses a single char array to >>> compose the entire String in question. >>> With "optimization fails", I also mean, there is used an additional >>> "StringComposer" e.g. another StringBuilder or a StringJoiner in addition >>> to the 1st StringBuilder. >>> >>> -Ulf >>> >>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo: >>> >>>> Could you please explain what you mean by "javac optimization fails" >>>> here? >>>> >>>> -Pavel >>>> >>>> On 27 Aug 2014, at 10:41, Ulf Zibis wrote: >>>> >>>> 4.) Now we see, that javac optimization fails again if StringBuilder, >>>>> concatenation, toString(), append(String), append(Collection) etc. and >>>>> StringJoiner use is mixed. >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Sat Aug 30 08:36:48 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 30 Aug 2014 12:36:48 +0400 Subject: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters In-Reply-To: <5400E85E.9030005@CoSoCo.de> References: <53E7FA44.9050207@oracle.com> <476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com> <53E8CCD6.2090503@CoSoCo.de> <53FDA7C1.6060303@CoSoCo.de> <902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com> <53FF7244.2030804@CoSoCo.de> <5400E85E.9030005@CoSoCo.de> Message-ID: <54018D20.7060806@oracle.com> It may be worth to compare the performance of alternative implementations with -XX:+OptimizeStringConcat option turned on. Sincerely yours, Ivan On 30.08.2014 0:53, Ulf Zibis wrote: > Hi compiler people, > > is there some chance that javac could be enhanced to optimize better > as discussed in this thread? Than refactoring of up to now better > readable code to ugly StringBuilder at append() code would be superfluous. > I really like the String concatenation syntax, but unfortunately it > often causes slower code and bigger footprint. > Optimally javac would optimize mixed use of StringBuilder, > StringJoiner, concatenation, toString(), append(String), > append(Collection) etc. to a single StringBuilder instance, so that > the resulting code, JITed or not, will have better performance. > Additionally javac could guess a reasonable initial capacity from the > given source code. > > > Am 29.08.2014 um 10:01 schrieb Wang Weijun: >> So it's not that the optimization fails but there is no optimization >> on them yet. >> >> I do see the .append("x") case will be easy to deal with, but it >> looks like historically javac has not been a place to do many >> optimizations. It mostly converts the java source to byte codes in a >> 1-to-1 mapping and let VM do whatever it wants (to optimize). When >> you talked about compiling multiple concatenation into using a single >> StringBuilder, it's more like choosing the correct implementation >> rather than an optimization. >> >> I don't expect to see big change on this in the near future, so shall >> we go on with the current enhancement? >> >> Thanks >> Max >> >> On Aug 29, 2014, at 2:17, Ulf Zibis wrote: >> >>> I mean: >>> It does not output byte code that only uses a single char array to >>> compose the entire String in question. >>> With "optimization fails", I also mean, there is used an additional >>> "StringComposer" e.g. another StringBuilder or a StringJoiner in >>> addition to the 1st StringBuilder. >>> >>> -Ulf >>> >>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo: >>>> Could you please explain what you mean by "javac optimization >>>> fails" here? >>>> >>>> -Pavel >>>> >>>> On 27 Aug 2014, at 10:41, Ulf Zibis wrote: >>>> >>>>> 4.) Now we see, that javac optimization fails again if >>>>> StringBuilder, concatenation, toString(), append(String), >>>>> append(Collection) etc. and StringJoiner use is mixed. >> > > >