From vicente.romero at oracle.com Sat Mar 1 13:02:28 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Sat, 01 Mar 2014 21:02:28 +0000 Subject: Review Request - 2 : JDK-8031670: remove unneeded -source option from javadoc tests In-Reply-To: <530F6416.2080004@oracle.com> References: <530EF0B0.6050700@oracle.com> <530F6416.2080004@oracle.com> Message-ID: <53124AE4.1070102@oracle.com> On 27/02/14 16:13, Neil Toda wrote: > This is a Review Request resubmission with reviewer-based changes. > > Original Description: > > A small set of javadoc tests contain the -source parameter. In > most cases, the parameter is > not required for the test. In several cases, the -source > parameter is being explicitly tested, > but relies on a JDK version that will be removed from JDK9. > > This changeset removes unnecessary -source specification when not > needed, or changes the > test/source-version requested to one that will work in JDK9 > > > The revised changeset-webrev can be found here: > > http://cr.openjdk.java.net/~darcy/neiltoda/8031670.1/ Hi, The change is OK for me, there is a typo in a test note of test: test/tools/javadoc/sourceOption/SourceOption.java "With JDK9, _this this_ test has been transformed into a NEGATIVE test." You don't need another review round for this. Thanks, Vicente. > > > Changes from first submittal: > > * in ./test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java > * correct spelling error : amy -> may > * remove comment on test from jtreg tag block > * to validate -source option operation > * reinstate ./sourceOption test > * in ./test/tools/javadoc/sourceOption/SourceOption.java > * changed to a negative test to make sure javac lambda construct > is not in 1.7 > * add information about updating test periodically > * add a fixVersion bug [ set to 1.10 for current targeted feature ] > * added ./test/tools/javadoc/sourceOption/p/LambdaConstructTest.java > * valid for 1.8, but not for 1.7. "-source 1.7" is checked with > this code. > * added ./test/tools/javadoc/sourceOption2/SourceOption2.java > * This test is a positive test to make sure that the lambda > construct provided for ./sourceOption is valid for 8. > * This test is actually examining > ./sourceOption/p/LambdaConstructTest.java > > Thanks > > -neil > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140301/b57873f6/attachment.html From joe.darcy at oracle.com Sat Mar 1 14:06:12 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 01 Mar 2014 14:06:12 -0800 Subject: Review Request - 2 : JDK-8031670: remove unneeded -source option from javadoc tests In-Reply-To: <530F6416.2080004@oracle.com> References: <530EF0B0.6050700@oracle.com> <530F6416.2080004@oracle.com> Message-ID: <531259D4.3090405@oracle.com> Hi Neil, Typically with negative tests, we do a golden file check on the non-localized output to verify the right error is reported in the right location. However, for testing the supported-ness of the source value, that isn't really necessary. Instead of adding SourceOption2.java as a separate file, please sightly restructure SourceOption to allow it to take a source option as an argument. In other words, the jtreg tags could be like 29 * @run main/fail SourceOption 7 30 * @run main SourceOption latest as long the main method translated from 7/latest to a source argument for the string array that gets passed in. Look at javax.lang.model.SourceVersion to compute latest, or if you want to keep things simpler, just support 29 * @run main/fail SourceOption 7 30 * @run main SourceOption 9 and pass the source argument down. Otherwise, the changes look fine to go back. Thanks, -Joe On 02/27/2014 08:13 AM, Neil Toda wrote: > This is a Review Request resubmission with reviewer-based changes. > > Original Description: > > A small set of javadoc tests contain the -source parameter. In > most cases, the parameter is > not required for the test. In several cases, the -source > parameter is being explicitly tested, > but relies on a JDK version that will be removed from JDK9. > > This changeset removes unnecessary -source specification when not > needed, or changes the > test/source-version requested to one that will work in JDK9 > > > The revised changeset-webrev can be found here: > > http://cr.openjdk.java.net/~darcy/neiltoda/8031670.1/ > > > Changes from first submittal: > > * in ./test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java > * correct spelling error : amy -> may > * remove comment on test from jtreg tag block > * to validate -source option operation > * reinstate ./sourceOption test > * in ./test/tools/javadoc/sourceOption/SourceOption.java > * changed to a negative test to make sure javac lambda construct > is not in 1.7 > * add information about updating test periodically > * add a fixVersion bug [ set to 1.10 for current targeted feature ] > * added ./test/tools/javadoc/sourceOption/p/LambdaConstructTest.java > * valid for 1.8, but not for 1.7. "-source 1.7" is checked with > this code. > * added ./test/tools/javadoc/sourceOption2/SourceOption2.java > * This test is a positive test to make sure that the lambda > construct provided for ./sourceOption is valid for 8. > * This test is actually examining > ./sourceOption/p/LambdaConstructTest.java > > Thanks > > -neil > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140301/0736d9f4/attachment.html From archie at dellroad.org Sun Mar 2 09:28:13 2014 From: archie at dellroad.org (Archie Cobbs) Date: Sun, 2 Mar 2014 11:28:13 -0600 Subject: JLS tweaks Message-ID: Hi folks, I'm new to this list so here's a quick introduction... I have worked on various open source projects for a long time, have used Java extensively in my day job since the late 90's, and have contributed to a few JVM implementations over the years (kaffe, harmony, Classpath libs), and even wrote my own experimental JVM at one point (jcvm). Over the years I've accumulated a list of unnecessary restrictions in the JLS that crop up over and over again to annoy me. I'd like to propose JLS changes that address these restrictions. This mailing list seems the right place to get feedback and any recommendations on how to proceed with JEPs if the ideas are deemed generally useful. I won't attempt to give a lot of motivation for these examples other than to say that in my "day job" the goal is clear and maintainable software, and these problems crop up repeatedly to make that job harder. More generally, I hope you agree that whether or not a particular issue affects someone, when you can remove that restriction and it doesn't cost you anything in terms of semantic clarity or backward compatibility, then it seems like it should be a worthwhile thing to do. In such cases, the only factor in the "cost" equation is how hard it would be to implement these changes in the compiler, and I'd like your input on that. All of these changes are fully backward-compatible with existing source semantics. *Idea #1: Allow final index variable in Iterable loops* This change would allow the index variable of an Iterable loop to be decared final. The compiler would disallow assignments to the variable within the loop in that case. for (final Person p : this.getPeople()) { // compiler allows this p.setUpdated(true); p = p.getParent(); // compiler error } *Idea #2: Allow non-this code prior to super()/this() call in constructors* The JLS requires that constructors invoke super()/this() as the first *statement*, whereas the JVM only requires constructors invoke super()/this() prior to any operations on this other than assigning instance fields. So there is a "gap" between what the JVM allows and what the JLS allows, with the JLS being more restrictive than necessary. For example, one would like to be able to do this: import java.util.*; public class IntersectionSet extends HashSet { private final boolean wasEmpty; public IntersectionSet(Set set1, Set set2) { final HashSet temp = new HashSet(); for (E e : set1) { if (set2.contains(e)) temp.add(e); } this.wasEmpty = temp.isEmpty(); super(temp); } } but instead you have to do this: import java.util.*; public class IntersectionSet extends HashSet { private final boolean wasEmpty; public IntersectionSet(Set set1, Set set2) { super(IntersectionSet.intersect(set1, set2)); this.wasEmpty = IntersectionSet.intersect(set1, set2).isEmpty(); // ugh, redundant calculation! } // This method only exists because of JLS restriction that "super()" must be first statement private static Set intersect(Set set1, Set set2) { final HashSet temp = new HashSet(); for (E e : set1) { if (set2.contains(e)) temp.add(e); } return temp; } } *Idea #3: Allow generic type declarations wherever normal type declarations are allowed* Generic type variable declarations are currently only allowed at the class level and the method level. This proposal would allow them to be declared everywhere a normal type can be declared. For example, imagine we have this type: import java.util.*; public abstract class StringEncoder { private final Class type; protected StringEncoder(Class type) { this.type = type; } public Class getType() { return this.type; } public abstract String toString(T obj); } The following code doesn't work due to the unbound generic type: public static void showEncodings(Collection> encoders, Object obj) { for (StringEncoder encoder : encoders) System.out.println(encoder.toString(encoder.getType().cast(obj))); // error: no suitable method found for toString(Object) } So instead you have to do this: public static void showEncodings(Collection> encoders, Object obj) { for (StringEncoder encoder : encoders) show(encoder, obj); } // This method only exists so we can bind generic type private static void show(StringEncoder encoder, Object obj) { System.out.println(encoder.toString(encoder.getType().cast(obj))); } This proposal would allow you do this: public static void showEncodings(Collection> encoders, Object obj) { for ( StringEncoder encoder : encoders) System.out.println(encoder.toString(encoder.getType().cast(obj))); } More generally, any variable declaration in a method could also declare a generic type variable. *Idea #4: Teach compiler that an exception means the last assignment statement was not executed* The JLS/compiler seems to think that exceptions can occur after the last statement of a try {} block has executed. For example: import java.util.Date; public class Foo { public Date example1(boolean setTimestamp) { final Date var; if (setTimestamp) var = new Date(); else var = null; // no error here return var; } public Date example2() { final Date var; try { var = new Date(); } catch (NullPointerException e) { var = null; // error: variable var might already have been assigned } return var; } } Of course the JVM may choose to randomly throw an exception at any time, but it seems the compiler can safely avoid giving an error when the conflicting assignment is the last statement of the try {} block; after all, the JVM doesn't really care in this case. *Idea #5: Allow enum types to have generic type parameters* An example of doing this: public enum Primitive implements Comparator { BOOLEAN { @Override public Boolean getDefaultValue() { return false; } @Override public int compare(Boolean value1, Boolean value2) { return Boolean.compare(value1, value2); } }, BYTE { @Override public Byte getDefaultValue() { return (byte)0; } @Override public int compare(Byte value1, Byte value2) { return Byte.compare(value1, value2); } }, ... etc ...; public abstract T getDefaultValue(); } Some of these obviously would take more compiler work than others. However, I want to make sure to keep separate feedback based on practical concerns (e.g., "too hard to implement") vs. more fundamental language issues that I may be missing. Thanks for your time & feedback. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140302/07c461f0/attachment-0001.html From neil.toda at oracle.com Mon Mar 3 09:11:48 2014 From: neil.toda at oracle.com (Neil Toda) Date: Mon, 03 Mar 2014 09:11:48 -0800 Subject: Fwd: Re: Review Request - 2 : JDK-8031670: remove unneeded -source option from javadoc tests In-Reply-To: <5314B70A.3070205@oracle.com> References: <5314B70A.3070205@oracle.com> Message-ID: <5314B7D4.8050904@oracle.com> -------- Original Message -------- Subject: Re: Review Request - 2 : JDK-8031670: remove unneeded -source option from javadoc tests Date: Mon, 03 Mar 2014 09:08:26 -0800 From: Neil Toda Organization: Oracle Corporation To: Vicente-Arturo Romero-Zaldivar I'll fix that. Thanks Vicente. -neil On 3/1/2014 1:02 PM, Vicente-Arturo Romero-Zaldivar wrote: > On 27/02/14 16:13, Neil Toda wrote: >> This is a Review Request resubmission with reviewer-based changes. >> >> Original Description: >> >> A small set of javadoc tests contain the -source parameter. In >> most cases, the parameter is >> not required for the test. In several cases, the -source >> parameter is being explicitly tested, >> but relies on a JDK version that will be removed from JDK9. >> >> This changeset removes unnecessary -source specification when not >> needed, or changes the >> test/source-version requested to one that will work in JDK9 >> >> >> The revised changeset-webrev can be found here: >> >> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.1/ > > Hi, > > The change is OK for me, there is a typo in a test note of test: > test/tools/javadoc/sourceOption/SourceOption.java > > "With JDK9, _this this_ test has been transformed into a NEGATIVE test." > > You don't need another review round for this. > > Thanks, > Vicente. > >> >> >> Changes from first submittal: >> >> * in ./test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java >> * correct spelling error : amy -> may >> * remove comment on test from jtreg tag block >> * to validate -source option operation >> * reinstate ./sourceOption test >> * in ./test/tools/javadoc/sourceOption/SourceOption.java >> * changed to a negative test to make sure javac lambda >> construct is not in 1.7 >> * add information about updating test periodically >> * add a fixVersion bug [ set to 1.10 for current targeted feature ] >> * added ./test/tools/javadoc/sourceOption/p/LambdaConstructTest.java >> * valid for 1.8, but not for 1.7. "-source 1.7" is checked with >> this code. >> * added ./test/tools/javadoc/sourceOption2/SourceOption2.java >> * This test is a positive test to make sure that the lambda >> construct provided for ./sourceOption is valid for 8. >> * This test is actually examining >> ./sourceOption/p/LambdaConstructTest.java >> >> Thanks >> >> -neil >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140303/2dd0d3a8/attachment.html From neil.toda at oracle.com Mon Mar 3 09:13:12 2014 From: neil.toda at oracle.com (Neil Toda) Date: Mon, 03 Mar 2014 09:13:12 -0800 Subject: Review Request - 2 : JDK-8031670: remove unneeded -source option from javadoc tests In-Reply-To: <531259D4.3090405@oracle.com> References: <530EF0B0.6050700@oracle.com> <530F6416.2080004@oracle.com> <531259D4.3090405@oracle.com> Message-ID: <5314B828.1040408@oracle.com> Thanks Joe Cleaner. I'll do that. -neil On 3/1/2014 2:06 PM, Joe Darcy wrote: > Hi Neil, > > Typically with negative tests, we do a golden file check on the > non-localized output to verify the right error is reported in the > right location. However, for testing the supported-ness of the source > value, that isn't really necessary. > > Instead of adding SourceOption2.java as a separate file, please > sightly restructure SourceOption to allow it to take a source option > as an argument. > > In other words, the jtreg tags could be like > > 29 * @run main/fail SourceOption 7 > 30 * @run main SourceOption latest > > as long the main method translated from 7/latest to a source argument > for the string array that gets passed in. > > Look at javax.lang.model.SourceVersion to compute latest, or if you > want to keep things simpler, just support > > > 29 * @run main/fail SourceOption 7 > 30 * @run main SourceOption 9 > > and pass the source argument down. > > Otherwise, the changes look fine to go back. > > Thanks, > > -Joe > > On 02/27/2014 08:13 AM, Neil Toda wrote: >> This is a Review Request resubmission with reviewer-based changes. >> >> Original Description: >> >> A small set of javadoc tests contain the -source parameter. In >> most cases, the parameter is >> not required for the test. In several cases, the -source >> parameter is being explicitly tested, >> but relies on a JDK version that will be removed from JDK9. >> >> This changeset removes unnecessary -source specification when not >> needed, or changes the >> test/source-version requested to one that will work in JDK9 >> >> >> The revised changeset-webrev can be found here: >> >> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.1/ >> >> >> Changes from first submittal: >> >> * in ./test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java >> * correct spelling error : amy -> may >> * remove comment on test from jtreg tag block >> * to validate -source option operation >> * reinstate ./sourceOption test >> * in ./test/tools/javadoc/sourceOption/SourceOption.java >> * changed to a negative test to make sure javac lambda >> construct is not in 1.7 >> * add information about updating test periodically >> * add a fixVersion bug [ set to 1.10 for current targeted feature ] >> * added ./test/tools/javadoc/sourceOption/p/LambdaConstructTest.java >> * valid for 1.8, but not for 1.7. "-source 1.7" is checked with >> this code. >> * added ./test/tools/javadoc/sourceOption2/SourceOption2.java >> * This test is a positive test to make sure that the lambda >> construct provided for ./sourceOption is valid for 8. >> * This test is actually examining >> ./sourceOption/p/LambdaConstructTest.java >> >> Thanks >> >> -neil >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140303/ccfca858/attachment.html From brian.goetz at oracle.com Mon Mar 3 09:45:14 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 03 Mar 2014 12:45:14 -0500 Subject: JLS tweaks In-Reply-To: References: Message-ID: <5314BFAA.7040606@oracle.com> So, none of these are really "tweaks". And of these, only #1 is actually small. Some very quick comments. > *Idea #1: Allow final index variable in Iterable loops* OK, this is a pretty tiny change. Low cost, low risk -- but also low reward. > *Idea #2: Allow non-this code prior to super()/this() call in > constructors* This is well-traveled ground; this request has come up, and been shot down, many times. If anything, the language spec is already too loose here, allowing too many unsafe operations (e.g., calling virtual methods from constructors, allowing constructor to publish 'this', etc) and this would make this problem dramatically worse. Worse, of the cases where people claim they need this feature, they tend to be wrong most of the time, both underestimating the safety costs and overestimating the need. In your example, you can accomplish what you want both safely and without redundant computation with a combination of a public factory and a private constructor. Weakening the language safety is not the answer. > *Idea #3: Allow generic type declarations wherever normal type > declarations are allowed* Obviously "wherever normal type declarations" is broader than you mean. What you're looking for is the ability to "uncapture" a captured variable, giving it a name. As you've pointed out, generic methods already provide you the ability to do that, and what you're asking for is do to that 'inline' in a block of code. My recommendation is to try and take this to the next step (a more detailed analysis); I think you'll find you'll run into complexity at multiple levels. > *Idea #4: Teach compiler that an exception means the last assignment > statement was not executed* > I'm kind of sympathetic here. Specifying "unless the last statement is..." is kind of messy, increasing the cost. > *Idea #5: Allow enum types to have generic type parameters* Another frequent suggestion. I agree it would have been better if it were done this way initially, and the cost would have been low. The cost of doing this now in a binary-compatible way would be higher. > Some of these obviously would take more compiler work than others. > However, I want to make sure to keep separate feedback based on > practical concerns (e.g., "too hard to implement") vs. more > fundamental language issues that I may be missing. So, summary: 1, 4: practical, but probably low return on investment 2: bad idea 3: bigger than you think 5: desirable, but compatibility risks lurk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140303/26a74516/attachment-0001.html From david.lloyd at redhat.com Mon Mar 3 10:55:53 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 03 Mar 2014 12:55:53 -0600 Subject: JLS tweaks In-Reply-To: <5314BFAA.7040606@oracle.com> References: <5314BFAA.7040606@oracle.com> Message-ID: <5314D039.8010305@redhat.com> On 03/03/2014 11:45 AM, Brian Goetz wrote: > So, none of these are really "tweaks". And of these, only #1 is > actually small. Some very quick comments. > >> *Idea #1: Allow final index variable in Iterable loops* > OK, this is a pretty tiny change. Low cost, low risk -- but also low > reward. AFAICT this is already allowed and works as described. >> *Idea #2: Allow non-this code prior to super()/this() call in >> constructors* > This is well-traveled ground; this request has come up, and been shot > down, many times. If anything, the language spec is already too loose > here, allowing too many unsafe operations (e.g., calling virtual methods > from constructors, allowing constructor to publish 'this', etc) and this > would make this problem dramatically worse. It's interesting that in core-libs-dev (iirc) we were discussing the exact opposite idea, in the context of serialization improvement the possibility of creating a new class or mode of constructor which explicitly is locked to the current class (i.e. no this/super allowed at all). -- - DML From archie at dellroad.org Mon Mar 3 12:55:39 2014 From: archie at dellroad.org (Archie Cobbs) Date: Mon, 3 Mar 2014 14:55:39 -0600 Subject: JLS tweaks In-Reply-To: <5314BFAA.7040606@oracle.com> References: <5314BFAA.7040606@oracle.com> Message-ID: Brian, Thanks for your comments. On Mon, Mar 3, 2014 at 11:45 AM, Brian Goetz wrote: > *Idea #2: Allow non-this code prior to super()/this() call in constructors* > > This is well-traveled ground; this request has come up, and been shot > down, many times. If anything, the language spec is already too loose > here, allowing too many unsafe operations (e.g., calling virtual methods > from constructors, allowing constructor to publish 'this', etc) and this > would make this problem dramatically worse. > I would like to better understand what you're saying here. I am certainly not interested in changes that would weaken language safety, so I must be misunderstanding something. When you refer to calling virtual methods and publishing 'this', do you mean prior to superclass constructor invocation? If so how is that possible currently? Because the JVM spec seems to disallowit.. I'm referring to the sentence "Before that method invokes another instance initialization method of myClass or its direct superclass on this, the only operation the method can perform on this is assigning fields declared within myClass." I take this to mean that for example that you couldn't pass 'this' as a parameter, assign it to a field, invoke a method on it, or do anything else that would allow its uninitialized escape. Or, if you meant calling virtual methods and publishing 'this' after super()/this(), then how does this proposal have any relation to those problems? They are on the "other side" of super()/this() line, so to speak, and this proposal would not make them any more permitted than they already are. It seems like the JVM spec gets it right - i.e., you can do (mostly) whatever you want prior to super()/this() as long as it doesn't try to make use of an uninitialized 'this', and no uninitialized 'this' can escape. It seems reasonable to want the JLS to more closely mirror this sensible stance. I must be missing something... *Idea #3: Allow generic type declarations wherever normal type declarations > are allowed* > Obviously "wherever normal type declarations" is broader than you mean. > What you're looking for is the ability to "uncapture" a captured variable, > giving it a name. As you've pointed out, generic methods already provide > you the ability to do that, and what you're asking for is do to that > 'inline' in a block of code. My recommendation is to try and take this to > the next step (a more detailed analysis); I think you'll find you'll run > into complexity at multiple levels. > I may not be smart enough to actually reach those multiple levels of complexity... :) Can you give me an example? In case it wasn't already clear... the original simplistic thought was that at any variable declaration where the declared type is generic, you could have the option of piggybacking onto that a generic type variable declaration. So any: final List x = ... could be changed to: final List x = ... and the T would be declared as a bound type variable with the same scope as 'x'. *Idea #5: Allow enum types to have generic type parameters* > Another frequent suggestion. I agree it would have been better if it were > done this way initially, and the cost would have been low. The cost of > doing this now in a binary-compatible way would be higher. > Ah, I didn't realize there was a binary compatibility problem here. What specifically is the problem? Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140303/b1001e59/attachment.html From forax at univ-mlv.fr Tue Mar 4 00:38:48 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 04 Mar 2014 09:38:48 +0100 Subject: JLS tweaks In-Reply-To: References: <5314BFAA.7040606@oracle.com> Message-ID: <53159118.7000802@univ-mlv.fr> Hi Archie, On 03/03/2014 09:55 PM, Archie Cobbs wrote: > Brian, > > Thanks for your comments. > > On Mon, Mar 3, 2014 at 11:45 AM, Brian Goetz > wrote: > > *Idea #2: Allow non-this code prior to super()/this() call in > constructors* > This is well-traveled ground; this request has come up, and been > shot down, many times. If anything, the language spec is already > too loose here, allowing too many unsafe operations (e.g., calling > virtual methods from constructors, allowing constructor to publish > 'this', etc) and this would make this problem dramatically worse. > > > I would like to better understand what you're saying here. I am > certainly not interested in changes that would weaken language safety, > so I must be misunderstanding something. > > When you refer to calling virtual methods and publishing 'this', do > you mean prior to superclass constructor invocation? If so how is that > possible currently? Because the JVM spec seems to disallow > > it.. I'm referring to the sentence "Before that method invokes > another instance initialization method of |myClass| or its direct > superclass on |this|, the only operation the method can perform on > |this| is assigning fields declared within |myClass|." I take this to > mean that for example that you couldn't pass 'this' as a parameter, > assign it to a field, invoke a method on it, or do anything else that > would allow its uninitialized escape. > > Or, if you meant calling virtual methods and publishing 'this' after > super()/this(), then how does this proposal have any relation to those > problems? They are on the "other side" of super()/this() line, so to > speak, and this proposal would not make them any more permitted than > they already are. > > It seems like the JVM spec gets it right - i.e., you can do (mostly) > whatever you want prior to super()/this() as long as it doesn't try to > make use of an uninitialized 'this', and no uninitialized 'this' can > escape. It seems reasonable to want the JLS to more closely mirror > this sensible stance. > > I must be missing something... The rules of Java the language are less permissive than the rules of the JVM regarding uninitialized instance, that's true. But at least, the Java rules is simple to understand to anyone. Adding complexity here will not worth it and as Brian mention, you can still call a static method inside this() or super(). > > *Idea #3: Allow generic type declarations wherever normal type > declarations are allowed* > Obviously "wherever normal type declarations" is broader than you > mean. What you're looking for is the ability to "uncapture" a > captured variable, giving it a name. As you've pointed out, > generic methods already provide you the ability to do that, and > what you're asking for is do to that 'inline' in a block of code. > My recommendation is to try and take this to the next step (a more > detailed analysis); I think you'll find you'll run into complexity > at multiple levels. > > > I may not be smart enough to actually reach those multiple levels of > complexity... :) Can you give me an example? > > In case it wasn't already clear... the original simplistic thought was > that at any variable declaration where the declared type is generic, > you could have the option of piggybacking onto that a generic type > variable declaration. > > So any: > > final List x = ... > > could be changed to: > > final List x = ... > > and the T would be declared as a bound type variable with the same > scope as 'x'. What you want is know as 'existential type', wildcards [1] are already a reduced form of existential types, and as far as I know, nobody tries to unify the two concept in a sound framework. > > *Idea #5: Allow enum types to have generic type parameters* > Another frequent suggestion. I agree it would have been better if > it were done this way initially, and the cost would have been > low. The cost of doing this now in a binary-compatible way would > be higher. > > > Ah, I didn't realize there was a binary compatibility problem here. > What specifically is the problem? There is another problem. You don't want an enum in your example. You want some properties of an enum but not others. An enum in Java is not only a type of a serie of values, it's a serie of values with a name, a unique number, a common type and a way to get an array of all these values (with Foo.values()). In your example, you don't want a common type and if an enum type is a generic type values() will return array of wildcard making values() (and valueOf) useless from the typing point of view. It seems you want only one part of the enum and not the other, so an enum is the wrong language construction for your problem. BTW, having the method values() also disable an enum to inherit from another one. > > Thanks, > -Archie > > -- > Archie L. Cobbs cheers, R?mi [1] http://www.sato.kuis.kyoto-u.ac.jp/~igarashi/papers/variance.html From Sergey.Bylokhov at oracle.com Tue Mar 4 07:53:33 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 04 Mar 2014 19:53:33 +0400 Subject: Question about foreach-over-array desugaring. Message-ID: <5315F6FD.9010100@oracle.com> Hello. I became interested in a question of the foreach-over-array conversion to the old version of for. According to specification foreach should be transformed to JLS 14.14.2: T[] #a = Expression; L1: L2: ... Lm: for (int #i = 0; #i < #a.length; #i++) { VariableModifiersopt TargetType Identifier = #a[#i]; Statement } And javac generates exactly the same code. But we generate this assignment "T[] #a = Expression;" even in case of an Expression is a reference to the local array, is it correct? This is obvious when a nested loops are used: T[] #a = Expression; ........ for (int #i = 0; #i < #a.length; #i++) { VariableModifiersopt TargetType Identifier = #a[#i]; // first assignment T[] #a1 = Identifier; //second assignment ........... for (int #i1 = 0; #i1 < #a1.length; #i1++) { VariableModifiersopt TargetType Identifier = #a1[#i1]; ............ } } This behavior is by design, or nobody paid any attention to it? Sure, I know that javac usually left all optimizations to the runtime, but it is simply curious and interesting. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140304/fbb0c758/attachment.html From cushon at google.com Wed Mar 5 13:49:25 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 5 Mar 2014 13:49:25 -0800 Subject: javac8 annotation processors don't visit parameter annotations Message-ID: There appears to be a javac8 bug that prevents annotation processors from visiting annotations on parameters. When repeated annotations were implemented [1][2] the annotation scanners in JavacProcessingEnvironment and JavacRoundEnvironment were modified and the following override was added: @Override public Set visitExecutable(ExecutableElement e, Set p) { // Type parameters are not considered to be enclosed by an executable scan(e.getTypeParameters(), p); return scan(e.getEnclosedElements(), p); } MethodSymbols don't have any enclosed elements, but they do have parameters (which currently aren't being visited). I think that line was meant to match the base implementation in ElementScanner: return scan(e.getParameters(), p); [1] https://bugs.openjdk.java.net/browse/JDK-7162089 [2] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/1908e86ee49a -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140305/a39514f5/attachment.html From cushon at google.com Wed Mar 5 14:06:58 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 5 Mar 2014 14:06:58 -0800 Subject: javac8 annotation processors don't visit parameter annotations In-Reply-To: References: Message-ID: Here's the (trivial) patch, with a test case that demonstrates the problem. On Wed, Mar 5, 2014 at 1:49 PM, Liam Miller-Cushon wrote: > There appears to be a javac8 bug that prevents annotation processors from > visiting annotations on parameters. When repeated annotations were > implemented [1][2] the annotation scanners in JavacProcessingEnvironment > and JavacRoundEnvironment were modified and the following override was > added: > > @Override > public Set visitExecutable(ExecutableElement e, > Set p) { > // Type parameters are not considered to be enclosed by an executable > scan(e.getTypeParameters(), p); > return scan(e.getEnclosedElements(), p); > } > > MethodSymbols don't have any enclosed elements, but they do have > parameters (which currently aren't being visited). I think that line was > meant to match the base implementation in ElementScanner: > > return scan(e.getParameters(), p); > > > [1] https://bugs.openjdk.java.net/browse/JDK-7162089 > [2] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/1908e86ee49a > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140305/497bd0c7/attachment.html -------------- next part -------------- # HG changeset patch # User cushon # Date 1394056943 28800 # Node ID ee6cd27af37336f07958ef4463d8827a7b9fe88a # Parent 927c17e4f6d158e70f43e41dd98f64b8a9e70aeb Visit parameter annotations during annotation procressing. diff -r 927c17e4f6d1 -r ee6cd27af373 src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java --- a/src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Mon Feb 24 13:06:07 2014 -0800 +++ b/src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Wed Mar 05 14:02:23 2014 -0800 @@ -768,7 +768,7 @@ public Set visitExecutable(ExecutableElement e, Set p) { // Type parameters are not considered to be enclosed by an executable scan(e.getTypeParameters(), p); - return scan(e.getEnclosedElements(), p); + return scan(e.getParameters(), p); } void addAnnotations(Element e, Set p) { diff -r 927c17e4f6d1 -r ee6cd27af373 src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java --- a/src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java Mon Feb 24 13:06:07 2014 -0800 +++ b/src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java Wed Mar 05 14:02:23 2014 -0800 @@ -144,7 +144,7 @@ public Set visitExecutable(ExecutableElement e, TypeElement p) { // Type parameters are not considered to be enclosed by an executable scan(e.getTypeParameters(), p); - return scan(e.getEnclosedElements(), p); + return scan(e.getParameters(), p); } @Override diff -r 927c17e4f6d1 -r ee6cd27af373 test/tools/javac/processing/environment/round/Anno.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/tools/javac/processing/environment/round/Anno.java Wed Mar 05 14:02:23 2014 -0800 @@ -0,0 +1,28 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import java.lang.annotation.*; +import static java.lang.annotation.RetentionPolicy.*; + + at Retention(RUNTIME) +public @interface Anno {} diff -r 927c17e4f6d1 -r ee6cd27af373 test/tools/javac/processing/environment/round/ParameterAnnotations.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/tools/javac/processing/environment/round/ParameterAnnotations.java Wed Mar 05 14:02:23 2014 -0800 @@ -0,0 +1,33 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/** + * Class to hold annotations for ElementsAnnotatedWithTest. + */ + + at AnnotatedElementInfo(annotationName="Anno", + expectedSize=1, + names={"annotatedParameter"}) +public class ParameterAnnotations { + private void foo(@Anno Object annotatedParameter) {} +} diff -r 927c17e4f6d1 -r ee6cd27af373 test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java --- a/test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java Mon Feb 24 13:06:07 2014 -0800 +++ b/test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java Wed Mar 05 14:02:23 2014 -0800 @@ -31,12 +31,14 @@ * @compile TestElementsAnnotatedWith.java * @compile InheritedAnnotation.java * @compile TpAnno.java + * @compile Anno.java * @compile -processor TestElementsAnnotatedWith -proc:only SurfaceAnnotations.java * @compile -processor TestElementsAnnotatedWith -proc:only BuriedAnnotations.java * @compile -processor TestElementsAnnotatedWith -proc:only Part1.java Part2.java * @compile -processor TestElementsAnnotatedWith -proc:only C2.java * @compile -processor TestElementsAnnotatedWith -proc:only Foo.java * @compile -processor TestElementsAnnotatedWith -proc:only TypeParameterAnnotations.java + * @compile -processor TestElementsAnnotatedWith -proc:only ParameterAnnotations.java * @compile/fail/ref=ErroneousAnnotations.out -processor TestElementsAnnotatedWith -proc:only -XDrawDiagnostics ErroneousAnnotations.java * @compile Foo.java * @compile/process -processor TestElementsAnnotatedWith -proc:only Foo From alex.buckley at oracle.com Wed Mar 5 14:08:40 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 05 Mar 2014 14:08:40 -0800 Subject: javac8 annotation processors don't visit parameter annotations In-Reply-To: References: Message-ID: <5317A068.1080106@oracle.com> Just to note that you're speaking about declaration annotations on a formal parameter. Type annotations on the type of a formal parameter are ignored during round processing. Alex On 3/5/2014 1:49 PM, Liam Miller-Cushon wrote: > There appears to be a javac8 bug that prevents annotation processors > from visiting annotations on parameters. When repeated annotations were > implemented [1][2] the annotation scanners in JavacProcessingEnvironment > and JavacRoundEnvironment were modified and the following override was > added: > > @Override > public Set visitExecutable(ExecutableElement e, > Set p) { > // Type parameters are not considered to be enclosed by an executable > scan(e.getTypeParameters(), p); > return scan(e.getEnclosedElements(), p); > } > > MethodSymbols don't have any enclosed elements, but they do have > parameters (which currently aren't being visited). I think that line was > meant to match the base implementation in ElementScanner: > > return scan(e.getParameters(), p); > > > [1] https://bugs.openjdk.java.net/browse/JDK-7162089 > [2] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/1908e86ee49a From joe.darcy at oracle.com Wed Mar 5 18:25:37 2014 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 05 Mar 2014 18:25:37 -0800 Subject: javac8 annotation processors don't visit parameter annotations In-Reply-To: References: Message-ID: <5317DCA1.5050508@oracle.com> Hello, Oops! Yes, the visitExecutable implementation in a scanner should traverse the parameters of the executable, as done in the ElementScanner superclass. Thanks for catching this Liam and sending in a patch, -Joe On 3/5/2014 1:49 PM, Liam Miller-Cushon wrote: > There appears to be a javac8 bug that prevents annotation processors > from visiting annotations on parameters. When repeated annotations > were implemented [1][2] the annotation scanners in > JavacProcessingEnvironment and JavacRoundEnvironment were modified and > the following override was added: > > @Override > public Set visitExecutable(ExecutableElement e, > Set p) { > // Type parameters are not considered to be enclosed by an executable > scan(e.getTypeParameters(), p); > return scan(e.getEnclosedElements(), p); > } > > MethodSymbols don't have any enclosed elements, but they do have > parameters (which currently aren't being visited). I think that line > was meant to match the base implementation in ElementScanner: > > return scan(e.getParameters(), p); > > > [1] https://bugs.openjdk.java.net/browse/JDK-7162089 > [2] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/1908e86ee49a From forax at univ-mlv.fr Thu Mar 6 03:29:49 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 06 Mar 2014 12:29:49 +0100 Subject: Lambda and multi-catch Message-ID: <53185C2D.4090907@univ-mlv.fr> A colleague of mine have find a hairy bug, here is a simple code to reproduce it. import java.io.IOException; public class FunWithMultiCatch { public static void main(String[] args) { Runnable r = () -> { try { Object o = null; o.getClass(); throw new IOException(); } catch(IOException | IllegalArgumentException e) { System.out.println("KO !"); } catch(RuntimeException e) { System.out.println("OK !"); } }; r.run(); } } It prints 'KO !' :( The problem can be reproduced for any multi-catch inside a lambda, the exception table is clearly wrong, the IOException and IAE are merged to their common supertype (java.lang.Exception). private static void lambda$main$0(); Code: 0: aconst_null ... 14: athrow 15: astore_0 16: getstatic #8 // Field java/lang/System.out:Ljava/io/PrintStream; 19: ldc #9 // String OK ! 21: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 24: goto 36 27: astore_0 28: getstatic #8 // Field java/lang/System.out:Ljava/io/PrintStream; 31: ldc #12 // String KO ! 33: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 36: return Exception table: from to target type 0 15 15 Class java/lang/Exception <------------ Oops 0 15 27 Class java/lang/RuntimeException The current workaround is to not use a multi-catch in a lambda. It seems that some version of Eclipse had the same issue but it's fixed with the one I use (from 21 feb). cheers, R?mi From david.lloyd at redhat.com Thu Mar 6 04:46:41 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 06 Mar 2014 06:46:41 -0600 Subject: Lambda and multi-catch In-Reply-To: <53185C2D.4090907@univ-mlv.fr> References: <53185C2D.4090907@univ-mlv.fr> Message-ID: <53186E31.5080608@redhat.com> On 03/06/2014 05:29 AM, Remi Forax wrote: > A colleague of mine have find a hairy bug, > here is a simple code to reproduce it. > > import java.io.IOException; > > public class FunWithMultiCatch { > public static void main(String[] args) { > Runnable r = () -> { > try { > Object o = null; > o.getClass(); > throw new IOException(); > } catch(IOException | IllegalArgumentException e) { > System.out.println("KO !"); > } catch(RuntimeException e) { > System.out.println("OK !"); > } > }; > r.run(); > } > } > > It prints 'KO !' :( > The problem can be reproduced for any multi-catch inside a lambda, > the exception table is clearly wrong, the IOException and IAE are merged > to their common supertype (java.lang.Exception). > > private static void lambda$main$0(); > Code: > 0: aconst_null > ... > 14: athrow > 15: astore_0 > 16: getstatic #8 // Field > java/lang/System.out:Ljava/io/PrintStream; > 19: ldc #9 // String OK ! > 21: invokevirtual #10 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 24: goto 36 > 27: astore_0 > 28: getstatic #8 // Field > java/lang/System.out:Ljava/io/PrintStream; > 31: ldc #12 // String KO ! > 33: invokevirtual #10 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 36: return > Exception table: > from to target type > 0 15 15 Class > java/lang/Exception <------------ Oops > 0 15 27 Class java/lang/RuntimeException > > The current workaround is to not use a multi-catch in a lambda. > > It seems that some version of Eclipse had the same issue but it's fixed > with the one I use (from 21 feb). I've noticed that the Oracle JDK 7 also uses the common supertype instead of two catch clauses, which caused trouble for my seven2six bytecode translator when a new exception common supertype was introduced in the hierarchy in JDK 7 (but it could cause trouble in other, normal cases of upgrade as well). I figured this was some form of optimization. But doesn't it make more sense to rely on the JVM to optimize this case? A paranoid fellow might interpret it as a deliberate move to make binary compatibility even more difficult than it is today. Or is it a mistake that the JDK ever did this? -- - DML From neil.toda at oracle.com Thu Mar 6 11:44:36 2014 From: neil.toda at oracle.com (Neil Toda) Date: Thu, 06 Mar 2014 11:44:36 -0800 Subject: Review Request - 3 minor cleanup : JDK-8031670: remove unneeded -source option from javadoc tests In-Reply-To: <5317B2E6.1090207@oracle.com> References: <5317B2E6.1090207@oracle.com> Message-ID: <5318D024.7050301@oracle.com> A final webrev changing ./sourceOption test to include both the positive and negative test. The negative test shows that the lambda feature is not supported in 1.7. The positive test shows that the supplied file correctly uses lambda in 1.9. Thanks. http://cr.openjdk.java.net/~darcy/neiltoda/8031670.2/ From david.holmes at oracle.com Thu Mar 6 21:15:30 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Mar 2014 15:15:30 +1000 Subject: Lambda and multi-catch In-Reply-To: <53185C2D.4090907@univ-mlv.fr> References: <53185C2D.4090907@univ-mlv.fr> Message-ID: <531955F2.1010602@oracle.com> On 6/03/2014 9:29 PM, Remi Forax wrote: > A colleague of mine have find a hairy bug, > here is a simple code to reproduce it. > > import java.io.IOException; > > public class FunWithMultiCatch { > public static void main(String[] args) { > Runnable r = () -> { > try { > Object o = null; > o.getClass(); > throw new IOException(); > } catch(IOException | IllegalArgumentException e) { > System.out.println("KO !"); > } catch(RuntimeException e) { > System.out.println("OK !"); > } > }; > r.run(); > } > } > > It prints 'KO !' :( What am I missing? We throw IOException and have a catch block for IOException so I would expect it to print "KO !". I'm more surprised that a non-lambda version prints "OK !" > The problem can be reproduced for any multi-catch inside a lambda, > the exception table is clearly wrong, the IOException and IAE are merged > to their common supertype (java.lang.Exception). That would definitely seem wrong, but more of an issue with catching RuntimeExceptions in the first block that should be handled by the second catch block. eg change it to throw IllegalStateException() instead: if (false) throw new IOException(); throw new IllegalStateException(); -> "KO !" !!!WT! David ----- > private static void lambda$main$0(); > Code: > 0: aconst_null > ... > 14: athrow > 15: astore_0 > 16: getstatic #8 // Field > java/lang/System.out:Ljava/io/PrintStream; > 19: ldc #9 // String OK ! > 21: invokevirtual #10 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 24: goto 36 > 27: astore_0 > 28: getstatic #8 // Field > java/lang/System.out:Ljava/io/PrintStream; > 31: ldc #12 // String KO ! > 33: invokevirtual #10 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 36: return > Exception table: > from to target type > 0 15 15 Class > java/lang/Exception <------------ Oops > 0 15 27 Class java/lang/RuntimeException > > The current workaround is to not use a multi-catch in a lambda. > > It seems that some version of Eclipse had the same issue but it's fixed > with the one I use (from 21 feb). > > cheers, > R?mi > > From david.holmes at oracle.com Thu Mar 6 22:15:38 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Mar 2014 16:15:38 +1000 Subject: Lambda and multi-catch In-Reply-To: References: <53185C2D.4090907@univ-mlv.fr> <531955F2.1010602@oracle.com> Message-ID: <5319640A.7060507@oracle.com> On 7/03/2014 3:53 PM, Sam Pullara wrote: > It is throwing an NPE when he dereferences the null o ? I thought the > same thing the first time I looked at it. Ughhh. That was unnecessarily obscure. So the issue is that use of Exception is catching exceptions it should not. Thanks Sam. David > Sam > > > > On Thu, Mar 6, 2014 at 9:15 PM, David Holmes > wrote: > > On 6/03/2014 9:29 PM, Remi Forax wrote: > > A colleague of mine have find a hairy bug, > > here is a simple code to reproduce it. > > > > import java.io.IOException; > > > > public class FunWithMultiCatch { > > public static void main(String[] args) { > > Runnable r = () -> { > > try { > > Object o = null; > > o.getClass(); > > throw new IOException(); > > } catch(IOException | IllegalArgumentException e) { > > System.out.println("KO !"); > > } catch(RuntimeException e) { > > System.out.println("OK !"); > > } > > }; > > r.run(); > > } > > } > > > > It prints 'KO !' :( > > What am I missing? We throw IOException and have a catch block for > IOException so I would expect it to print "KO !". > > I'm more surprised that a non-lambda version prints "OK !" > > > The problem can be reproduced for any multi-catch inside a lambda, > > the exception table is clearly wrong, the IOException and IAE are > merged > > to their common supertype (java.lang.Exception). > > That would definitely seem wrong, but more of an issue with catching > RuntimeExceptions in the first block that should be handled by the > second catch block. eg change it to throw IllegalStateException() > instead: > > if (false) throw new IOException(); > throw new IllegalStateException(); > > -> "KO !" !!!WT! > > David > ----- > > > private static void lambda$main$0(); > > Code: > > 0: aconst_null > > ... > > 14: athrow > > 15: astore_0 > > 16: getstatic #8 // Field > > java/lang/System.out:Ljava/io/PrintStream; > > 19: ldc #9 // String OK ! > > 21: invokevirtual #10 // Method > > java/io/PrintStream.println:(Ljava/lang/String;)V > > 24: goto 36 > > 27: astore_0 > > 28: getstatic #8 // Field > > java/lang/System.out:Ljava/io/PrintStream; > > 31: ldc #12 // String KO ! > > 33: invokevirtual #10 // Method > > java/io/PrintStream.println:(Ljava/lang/String;)V > > 36: return > > Exception table: > > from to target type > > 0 15 15 Class > > java/lang/Exception <------------ Oops > > 0 15 27 Class java/lang/RuntimeException > > > > The current workaround is to not use a multi-catch in a lambda. > > > > It seems that some version of Eclipse had the same issue but it's > fixed > > with the one I use (from 21 feb). > > > > cheers, > > R?mi > > > > > > From joe.darcy at oracle.com Thu Mar 6 23:40:58 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 06 Mar 2014 23:40:58 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 Message-ID: <5319780A.5070002@oracle.com> Hello, Please review the webrev of changes for JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 http://cr.openjdk.java.net/~darcy/8036842.0/ The langtools regression tests suite still passes with these changes in place. Thanks, -Joe From ivan.gerasimov at oracle.com Fri Mar 7 00:27:12 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 07 Mar 2014 12:27:12 +0400 Subject: RFR [8034044] Message-ID: <531982E0.1050307@oracle.com> Hello! JLS states that an anonymous class cannot be static [1]. However, in OpenJDK implementation Class#getModifiers(), when called for the anonymous class, returns the STATIC bit set. Would you please help review the proposed fix, which removes STATIC from the anonymous class's modifier? An exception to this is an enum constant's body. It's not clear, whether they should be treated in the same way as anonymous classes, so I left them as they are now. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034044 WEBREV: http://cr.openjdk.java.net/~igerasim/8034044/0/webrev/ I ran tests from langtools/test/tools/javac/ with jtreg. No failures were caused by this fix. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.9.5 Sincerely yours, Ivan From ivan.gerasimov at oracle.com Fri Mar 7 00:29:18 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 07 Mar 2014 12:29:18 +0400 Subject: RFR [8034044] Class.getModifiers() returns "static" for anonymous classes In-Reply-To: <531982E0.1050307@oracle.com> References: <531982E0.1050307@oracle.com> Message-ID: <5319835E.4090007@oracle.com> Resent with the correct Subject line ------------------------------- Hello! JLS states that an anonymous class cannot be static [1]. However, in OpenJDK implementation Class#getModifiers(), when called for the anonymous class, returns the STATIC bit set. Would you please help review the proposed fix, which removes STATIC from the anonymous class's modifier? An exception to this is an enum constant's body. It's not clear, whether they should be treated in the same way as anonymous classes, so I left them as they are now. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034044 WEBREV: http://cr.openjdk.java.net/~igerasim/8034044/0/webrev/ I ran tests from langtools/test/tools/javac/ with jtreg. No failures were caused by this fix. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.9.5 Sincerely yours, Ivan From sonali.goel at oracle.com Fri Mar 7 02:06:50 2014 From: sonali.goel at oracle.com (Sonali Goel) Date: Fri, 07 Mar 2014 02:06:50 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 In-Reply-To: <5319780A.5070002@oracle.com> References: <5319780A.5070002@oracle.com> Message-ID: <53199A3A.4090903@oracle.com> Hello, The changes look fine. A couple of questions/comments: - test/tools/javac/meth/InvokeMH.java - Why did you remove -source 7 -target 7 from the code? - test/tools/javac/api/T6265137.java - Why is -source 9 needed? - test/tools/javac/ClassLit.java - trivial comment - no need to add @compile line Thanks, Sonali On 3/6/2014 11:40 PM, Joe Darcy wrote: > Hello, > > Please review the webrev of changes for > > JDK-8036842: Remove unneeded/obsolete -source/-target options in > javac tests, part 2 > http://cr.openjdk.java.net/~darcy/8036842.0/ > > The langtools regression tests suite still passes with these changes > in place. > > Thanks, > > -Joe From jonathan.gibbons at oracle.com Fri Mar 7 07:58:37 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 07 Mar 2014 07:58:37 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 In-Reply-To: <5319780A.5070002@oracle.com> References: <5319780A.5070002@oracle.com> Message-ID: <5319ECAD.7030804@oracle.com> On 03/06/2014 11:40 PM, Joe Darcy wrote: > Hello, > > Please review the webrev of changes for > > JDK-8036842: Remove unneeded/obsolete -source/-target options in > javac tests, part 2 > http://cr.openjdk.java.net/~darcy/8036842.0/ > > The langtools regression tests suite still passes with these changes > in place. > > Thanks, > > -Joe Joe, I think the tests for 6464451 should be deleted as no longer interesting. ClassLit.java: T6266772.java: you can remove the @compile/@run main and use the default action of the test T6265137.java do you need any -target ClassVersionChecker.java The set of jdk versions should auto adapt to the current specification version The comment of line 50 is out of date. T6384542.java The first @compile is redundant EnumAsIdentifier.java,.out The test is redundant (equivalent to T6384542.java) -- Jon From jonathan.gibbons at oracle.com Fri Mar 7 08:32:14 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 07 Mar 2014 08:32:14 -0800 Subject: RFR [8034044] Class.getModifiers() returns "static" for anonymous classes In-Reply-To: <5319835E.4090007@oracle.com> References: <531982E0.1050307@oracle.com> <5319835E.4090007@oracle.com> Message-ID: <5319F48E.4000902@oracle.com> I would remove the comment in Attr 2132-2138. In general, javac lives in the present. There's no need to document an erroneous past in the comments. That's what the Mercurial changelog and bug system are for ;-) -- Jon On 03/07/2014 12:29 AM, Ivan Gerasimov wrote: > Resent with the correct Subject line > ------------------------------- > > Hello! > > JLS states that an anonymous class cannot be static [1]. > However, in OpenJDK implementation Class#getModifiers(), when called > for the anonymous class, returns the STATIC bit set. > Would you please help review the proposed fix, which removes STATIC > from the anonymous class's modifier? > > An exception to this is an enum constant's body. > It's not clear, whether they should be treated in the same way as > anonymous classes, so I left them as they are now. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034044 > WEBREV: http://cr.openjdk.java.net/~igerasim/8034044/0/webrev/ > > I ran tests from langtools/test/tools/javac/ with jtreg. > No failures were caused by this fix. > > > [1] > http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.9.5 > > Sincerely yours, > Ivan > From joe.darcy at oracle.com Fri Mar 7 09:25:53 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 07 Mar 2014 09:25:53 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 In-Reply-To: <5319ECAD.7030804@oracle.com> References: <5319780A.5070002@oracle.com> <5319ECAD.7030804@oracle.com> Message-ID: <531A0121.4070602@oracle.com> Hi Jon, On 03/07/2014 07:58 AM, Jonathan Gibbons wrote: > On 03/06/2014 11:40 PM, Joe Darcy wrote: >> Hello, >> >> Please review the webrev of changes for >> >> JDK-8036842: Remove unneeded/obsolete -source/-target options in >> javac tests, part 2 >> http://cr.openjdk.java.net/~darcy/8036842.0/ >> >> The langtools regression tests suite still passes with these changes >> in place. >> >> Thanks, >> >> -Joe > > Joe, > > I think the tests for 6464451 should be deleted as no longer interesting. Removed. > > ClassLit.java: > T6266772.java: > you can remove the @compile/@run main and use the default action of > the test Done. > > T6265137.java > do you need any -target The bug being tested seemed to be "if you use -target, you get a crash" so I left the use of -target in. > > ClassVersionChecker.java > The set of jdk versions should auto adapt to the current specification > version > The comment of line 50 is out of date. I changed the comment to say: " * 1. If both empty, version num is for the current release" Sonali, as the author of this test, please file an RFE to address Jon's comment to make the test adapt to the JDK's version. > > T6384542.java > The first @compile is redundant Do you mean a different file? T6384542.java has been deleted. > > EnumAsIdentifier.java,.out > The test is redundant (equivalent to T6384542.java) > > Keeping one of the files is probably sufficient :-) Thanks, -Joe From joe.darcy at oracle.com Fri Mar 7 09:34:48 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 07 Mar 2014 09:34:48 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 In-Reply-To: <53199A3A.4090903@oracle.com> References: <5319780A.5070002@oracle.com> <53199A3A.4090903@oracle.com> Message-ID: <531A0338.5090805@oracle.com> Hi Sonali, On 03/07/2014 02:06 AM, Sonali Goel wrote: > Hello, > > The changes look fine. A couple of questions/comments: > - test/tools/javac/meth/InvokeMH.java - Why did you remove -source 7 > -target 7 from the code? Because it wasn't needed :-) For source code in the JDK regression tests, we should accept the default source / target levels unless there is a need to specify a different one. The canonical uses case for us is specifying an earlier source version for a negative test. Since the features in question work in source/target 7 and higher, these don't need to be specified in JDK 9. > - test/tools/javac/api/T6265137.java - Why is -source 9 needed? This test was for a bug where setting target using the API interface caused an exception so I left in setting a target. > - test/tools/javac/ClassLit.java - trivial comment - no need to add > @compile line Removed. Thanks, -Joe > > Thanks, > Sonali > > On 3/6/2014 11:40 PM, Joe Darcy wrote: >> Hello, >> >> Please review the webrev of changes for >> >> JDK-8036842: Remove unneeded/obsolete -source/-target options in >> javac tests, part 2 >> http://cr.openjdk.java.net/~darcy/8036842.0/ >> >> The langtools regression tests suite still passes with these changes >> in place. >> >> Thanks, >> >> -Joe > From eric.mccorkle at oracle.com Fri Mar 7 09:35:56 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 07 Mar 2014 12:35:56 -0500 Subject: Type Annotations clarification Message-ID: <531A037C.4090306@oracle.com> Hello, I need clarification for a specific case: class Outer { class Inner {} } And a type use of: @A Outer.Inner @B [] @C [] The type path for @A is clearly [ARRAY, ARRAY, INNER_TYPE] However, should the type path for @B and @C contain an INNER_TYPE as well? -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 303 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140307/2a9dda94/eric_mccorkle.vcf From wdietl at gmail.com Fri Mar 7 09:50:25 2014 From: wdietl at gmail.com (Werner Dietl) Date: Fri, 7 Mar 2014 12:50:25 -0500 Subject: Type Annotations clarification In-Reply-To: <531A037C.4090306@oracle.com> References: <531A037C.4090306@oracle.com> Message-ID: Hi Eric, it would help make the discussions concrete, if you sent complete programs that each of us can test. I've extended your example to: === import java.lang.annotation.*; class Outer { class Inner {} } class Use { @A Outer. @B Inner @C [] @D [] f; } @Target(ElementType.TYPE_USE) @interface A { }; @Target(ElementType.TYPE_USE) @interface B { }; @Target(ElementType.TYPE_USE) @interface C { }; @Target(ElementType.TYPE_USE) @interface D { }; === I get the following type annotations for field f, where #10 is C, #11 is D, #12 is B, and #13 is A: RuntimeInvisibleTypeAnnotations: 0: #10(): FIELD 1: #11(): FIELD, location=[ARRAY] 2: #12(): FIELD, location=[ARRAY, ARRAY, INNER_TYPE] 3: #13(): FIELD, location=[ARRAY, ARRAY] This seems correct to me: - @A is on Outer, so no INNER_TYPE is required. It is on the component type of a two-dimensional array, so two ARRAY are correct. - @B is on Inner, so it additionally takes one INNER_TYPE. - @C is on the outermost-array type, so no location is called for. - @D is on the second array dimension, so one ARRAY location is needed. Note that the array component type is "Outer.Inner". The array types are not nested and do not need an INNER_TYPE. Why do you say that @A should have an INNER_TYPE? cu, WMD. On Fri, Mar 7, 2014 at 12:35 PM, Eric McCorkle wrote: > Hello, > > I need clarification for a specific case: > > class Outer { > class Inner {} > } > > And a type use of: > > @A Outer.Inner @B [] @C [] > > The type path for @A is clearly [ARRAY, ARRAY, INNER_TYPE] > > However, should the type path for @B and @C contain an INNER_TYPE as well? -- http://www.google.com/profiles/wdietl From joe.darcy at oracle.com Fri Mar 7 09:58:20 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 07 Mar 2014 09:58:20 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 In-Reply-To: <531A0121.4070602@oracle.com> References: <5319780A.5070002@oracle.com> <5319ECAD.7030804@oracle.com> <531A0121.4070602@oracle.com> Message-ID: <531A08BC.6040007@oracle.com> PS Revised webrev at http://cr.openjdk.java.net/~darcy/8036842.1/ -Joe On 03/07/2014 09:25 AM, Joe Darcy wrote: > Hi Jon, > > On 03/07/2014 07:58 AM, Jonathan Gibbons wrote: >> On 03/06/2014 11:40 PM, Joe Darcy wrote: >>> Hello, >>> >>> Please review the webrev of changes for >>> >>> JDK-8036842: Remove unneeded/obsolete -source/-target options in >>> javac tests, part 2 >>> http://cr.openjdk.java.net/~darcy/8036842.0/ >>> >>> The langtools regression tests suite still passes with these changes >>> in place. >>> >>> Thanks, >>> >>> -Joe >> >> Joe, >> >> I think the tests for 6464451 should be deleted as no longer >> interesting. > > Removed. > >> >> ClassLit.java: >> T6266772.java: >> you can remove the @compile/@run main and use the default action of >> the test > > Done. > >> >> T6265137.java >> do you need any -target > > The bug being tested seemed to be "if you use -target, you get a > crash" so I left the use of -target in. > >> >> ClassVersionChecker.java >> The set of jdk versions should auto adapt to the current >> specification version >> The comment of line 50 is out of date. > > I changed the comment to say: " * 1. If both empty, version num is for > the current release" > > Sonali, as the author of this test, please file an RFE to address > Jon's comment to make the test adapt to the JDK's version. > >> >> T6384542.java >> The first @compile is redundant > > Do you mean a different file? T6384542.java has been deleted. > >> >> EnumAsIdentifier.java,.out >> The test is redundant (equivalent to T6384542.java) >> >> > > Keeping one of the files is probably sufficient :-) > > Thanks, > > -Joe > From alex.buckley at oracle.com Fri Mar 7 10:10:08 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 07 Mar 2014 10:10:08 -0800 Subject: RFR [8034044] Class.getModifiers() returns "static" for anonymous classes In-Reply-To: <5319835E.4090007@oracle.com> References: <531982E0.1050307@oracle.com> <5319835E.4090007@oracle.com> Message-ID: <531A0B80.3070804@oracle.com> On 3/7/2014 12:29 AM, Ivan Gerasimov wrote: > JLS states that an anonymous class cannot be static [1]. > However, in OpenJDK implementation Class#getModifiers(), when called for > the anonymous class, returns the STATIC bit set. > Would you please help review the proposed fix, which removes STATIC from > the anonymous class's modifier? > > An exception to this is an enum constant's body. > It's not clear, whether they should be treated in the same way as > anonymous classes, so I left them as they are now. JLS 8.9.1: The optional class body of an enum constant implicitly defines an anonymous class declaration (?15.9.5) that extends the immediately enclosing enum type. So the class generated for an enum constant's body should not be ACC_STATIC. Alex From ivan.gerasimov at oracle.com Fri Mar 7 10:39:45 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 07 Mar 2014 22:39:45 +0400 Subject: RFR [8034044] Class.getModifiers() returns "static" for anonymous classes In-Reply-To: <531A0B80.3070804@oracle.com> References: <531982E0.1050307@oracle.com> <5319835E.4090007@oracle.com> <531A0B80.3070804@oracle.com> Message-ID: <531A1271.6080607@oracle.com> Thank you Alex! On 07.03.2014 22:10, Alex Buckley wrote: > On 3/7/2014 12:29 AM, Ivan Gerasimov wrote: >> JLS states that an anonymous class cannot be static [1]. >> However, in OpenJDK implementation Class#getModifiers(), when called for >> the anonymous class, returns the STATIC bit set. >> Would you please help review the proposed fix, which removes STATIC from >> the anonymous class's modifier? >> >> An exception to this is an enum constant's body. >> It's not clear, whether they should be treated in the same way as >> anonymous classes, so I left them as they are now. > > JLS 8.9.1: The optional class body of an enum constant implicitly > defines an anonymous class declaration (?15.9.5) that extends the > immediately enclosing enum type. > > So the class generated for an enum constant's body should not be > ACC_STATIC. > Ok, I'll remove STATIC from the enum bodies too. Sincerely yours, Ivan > Alex > From ivan.gerasimov at oracle.com Fri Mar 7 10:40:37 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 07 Mar 2014 22:40:37 +0400 Subject: RFR [8034044] Class.getModifiers() returns "static" for anonymous classes In-Reply-To: <5319F48E.4000902@oracle.com> References: <531982E0.1050307@oracle.com> <5319835E.4090007@oracle.com> <5319F48E.4000902@oracle.com> Message-ID: <531A12A5.8010402@oracle.com> On 07.03.2014 20:32, Jonathan Gibbons wrote: > I would remove the comment in Attr 2132-2138. > > In general, javac lives in the present. There's no need to document > an erroneous past in the comments. That's what the Mercurial changelog > and bug system are for ;-) > Yes, I agree. I'll remove that comment. Sincerely yours, Ivan > -- Jon > > On 03/07/2014 12:29 AM, Ivan Gerasimov wrote: >> Resent with the correct Subject line >> ------------------------------- >> >> Hello! >> >> JLS states that an anonymous class cannot be static [1]. >> However, in OpenJDK implementation Class#getModifiers(), when called >> for the anonymous class, returns the STATIC bit set. >> Would you please help review the proposed fix, which removes STATIC >> from the anonymous class's modifier? >> >> An exception to this is an enum constant's body. >> It's not clear, whether they should be treated in the same way as >> anonymous classes, so I left them as they are now. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8034044 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8034044/0/webrev/ >> >> I ran tests from langtools/test/tools/javac/ with jtreg. >> No failures were caused by this fix. >> >> >> [1] >> http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.9.5 >> >> Sincerely yours, >> Ivan >> > > > From vicente.romero at oracle.com Fri Mar 7 12:34:43 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 07 Mar 2014 20:34:43 +0000 Subject: Lambda and multi-catch In-Reply-To: References: <53185C2D.4090907@univ-mlv.fr> <531955F2.1010602@oracle.com> <5319640A.7060507@oracle.com> Message-ID: <531A2D63.2040204@oracle.com> Hi Remi, Thanks for the bug report, I have filed: https://bugs.openjdk.java.net/browse/JDK-8036942 to track it, Vicente From sonali.goel at oracle.com Fri Mar 7 12:48:20 2014 From: sonali.goel at oracle.com (Sonali Goel) Date: Fri, 07 Mar 2014 12:48:20 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 In-Reply-To: <531A0121.4070602@oracle.com> References: <5319780A.5070002@oracle.com> <5319ECAD.7030804@oracle.com> <531A0121.4070602@oracle.com> Message-ID: <531A3094.7090201@oracle.com> Hi Joe, On 3/7/2014 9:25 AM, Joe Darcy wrote: > Hi Jon, > > On 03/07/2014 07:58 AM, Jonathan Gibbons wrote: >> On 03/06/2014 11:40 PM, Joe Darcy wrote: >>> Hello, >>> >>> Please review the webrev of changes for >>> >>> JDK-8036842: Remove unneeded/obsolete -source/-target options in >>> javac tests, part 2 >>> http://cr.openjdk.java.net/~darcy/8036842.0/ >>> >>> The langtools regression tests suite still passes with these changes >>> in place. >>> >>> Thanks, >>> >>> -Joe >> >> Joe, >> >> I think the tests for 6464451 should be deleted as no longer >> interesting. > > Removed. > >> >> ClassLit.java: >> T6266772.java: >> you can remove the @compile/@run main and use the default action of >> the test > > Done. > >> >> T6265137.java >> do you need any -target > > The bug being tested seemed to be "if you use -target, you get a > crash" so I left the use of -target in. > >> >> ClassVersionChecker.java >> The set of jdk versions should auto adapt to the current >> specification version >> The comment of line 50 is out of date. > > I changed the comment to say: " * 1. If both empty, version num is for > the current release" > > Sonali, as the author of this test, please file an RFE to address > Jon's comment to make the test adapt to the JDK's version. JDK-8036946 filed. > >> >> T6384542.java >> The first @compile is redundant > > Do you mean a different file? T6384542.java has been deleted. I think Jon is referring to test/tools/javac/enum/6384542/T6384542a.java. They both test the use of enum keyword as an identifier. Thanks, Sonali > >> >> EnumAsIdentifier.java,.out >> The test is redundant (equivalent to T6384542.java) >> >> > > Keeping one of the files is probably sufficient :-) > > Thanks, > > -Joe > From jonathan.gibbons at oracle.com Fri Mar 7 12:56:38 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 07 Mar 2014 12:56:38 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 In-Reply-To: <531A3094.7090201@oracle.com> References: <5319780A.5070002@oracle.com> <5319ECAD.7030804@oracle.com> <531A0121.4070602@oracle.com> <531A3094.7090201@oracle.com> Message-ID: <531A3286.3090809@oracle.com> On 03/07/2014 12:48 PM, Sonali Goel wrote: >>> >> >> Do you mean a different file? T6384542.java has been deleted. > I think Jon is referring to test/tools/javac/enum/6384542/T6384542a.java. > They both test the use of enum keyword as an identifier. > > Thanks, > Sonali Yes. In these two lines, the first one seems redundant: 6 * @compile/fail T6384542a.java 7 * @compile/fail/ref=T6384542a_5.out -Xlint:-options -XDrawDiagnostics T6384542a.java -- Jon From jonathan.gibbons at oracle.com Fri Mar 7 13:13:48 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 07 Mar 2014 13:13:48 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 In-Reply-To: <531A08BC.6040007@oracle.com> References: <5319780A.5070002@oracle.com> <5319ECAD.7030804@oracle.com> <531A0121.4070602@oracle.com> <531A08BC.6040007@oracle.com> Message-ID: <531A368C.30802@oracle.com> Joe, If you remove the numerically named duplicate test for "enum as identifier", I approve the changes. -- Jon On 03/07/2014 09:58 AM, Joe Darcy wrote: > PS Revised webrev at > > http://cr.openjdk.java.net/~darcy/8036842.1/ > > -Joe > > On 03/07/2014 09:25 AM, Joe Darcy wrote: >> Hi Jon, >> >> On 03/07/2014 07:58 AM, Jonathan Gibbons wrote: >>> On 03/06/2014 11:40 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> Please review the webrev of changes for >>>> >>>> JDK-8036842: Remove unneeded/obsolete -source/-target options >>>> in javac tests, part 2 >>>> http://cr.openjdk.java.net/~darcy/8036842.0/ >>>> >>>> The langtools regression tests suite still passes with these >>>> changes in place. >>>> >>>> Thanks, >>>> >>>> -Joe >>> >>> Joe, >>> >>> I think the tests for 6464451 should be deleted as no longer >>> interesting. >> >> Removed. >> >>> >>> ClassLit.java: >>> T6266772.java: >>> you can remove the @compile/@run main and use the default action of >>> the test >> >> Done. >> >>> >>> T6265137.java >>> do you need any -target >> >> The bug being tested seemed to be "if you use -target, you get a >> crash" so I left the use of -target in. >> >>> >>> ClassVersionChecker.java >>> The set of jdk versions should auto adapt to the current >>> specification version >>> The comment of line 50 is out of date. >> >> I changed the comment to say: " * 1. If both empty, version num is >> for the current release" >> >> Sonali, as the author of this test, please file an RFE to address >> Jon's comment to make the test adapt to the JDK's version. >> >>> >>> T6384542.java >>> The first @compile is redundant >> >> Do you mean a different file? T6384542.java has been deleted. >> >>> >>> EnumAsIdentifier.java,.out >>> The test is redundant (equivalent to T6384542.java) >>> >>> >> >> Keeping one of the files is probably sufficient :-) >> >> Thanks, >> >> -Joe >> > From joe.darcy at oracle.com Fri Mar 7 13:29:40 2014 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 07 Mar 2014 13:29:40 -0800 Subject: JDK 9 RFR of JDK-8036842: Remove unneeded/obsolete -source/-target options in javac tests, part 2 In-Reply-To: <531A368C.30802@oracle.com> References: <5319780A.5070002@oracle.com> <5319ECAD.7030804@oracle.com> <531A0121.4070602@oracle.com> <531A08BC.6040007@oracle.com> <531A368C.30802@oracle.com> Message-ID: <531A3A44.9050708@oracle.com> Jon, Will do; thanks, -Joe On 3/7/2014 1:13 PM, Jonathan Gibbons wrote: > Joe, > > If you remove the numerically named duplicate test for "enum as > identifier", I approve the changes. > > -- Jon > > On 03/07/2014 09:58 AM, Joe Darcy wrote: >> PS Revised webrev at >> >> http://cr.openjdk.java.net/~darcy/8036842.1/ >> >> -Joe >> >> On 03/07/2014 09:25 AM, Joe Darcy wrote: >>> Hi Jon, >>> >>> On 03/07/2014 07:58 AM, Jonathan Gibbons wrote: >>>> On 03/06/2014 11:40 PM, Joe Darcy wrote: >>>>> Hello, >>>>> >>>>> Please review the webrev of changes for >>>>> >>>>> JDK-8036842: Remove unneeded/obsolete -source/-target options >>>>> in javac tests, part 2 >>>>> http://cr.openjdk.java.net/~darcy/8036842.0/ >>>>> >>>>> The langtools regression tests suite still passes with these >>>>> changes in place. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>> >>>> Joe, >>>> >>>> I think the tests for 6464451 should be deleted as no longer >>>> interesting. >>> >>> Removed. >>> >>>> >>>> ClassLit.java: >>>> T6266772.java: >>>> you can remove the @compile/@run main and use the default action of >>>> the test >>> >>> Done. >>> >>>> >>>> T6265137.java >>>> do you need any -target >>> >>> The bug being tested seemed to be "if you use -target, you get a >>> crash" so I left the use of -target in. >>> >>>> >>>> ClassVersionChecker.java >>>> The set of jdk versions should auto adapt to the current >>>> specification version >>>> The comment of line 50 is out of date. >>> >>> I changed the comment to say: " * 1. If both empty, version num is >>> for the current release" >>> >>> Sonali, as the author of this test, please file an RFE to address >>> Jon's comment to make the test adapt to the JDK's version. >>> >>>> >>>> T6384542.java >>>> The first @compile is redundant >>> >>> Do you mean a different file? T6384542.java has been deleted. >>> >>>> >>>> EnumAsIdentifier.java,.out >>>> The test is redundant (equivalent to T6384542.java) >>>> >>>> >>> >>> Keeping one of the files is probably sufficient :-) >>> >>> Thanks, >>> >>> -Joe >>> >> > From vicente.romero at oracle.com Fri Mar 7 14:06:55 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 07 Mar 2014 22:06:55 +0000 Subject: Review Request - 3 minor cleanup : JDK-8031670: remove unneeded -source option from javadoc tests In-Reply-To: <5318D024.7050301@oracle.com> References: <5317B2E6.1090207@oracle.com> <5318D024.7050301@oracle.com> Message-ID: <531A42FF.2040308@oracle.com> Hi Neil, I'm OK with the last version of the patch. Vicente On 06/03/14 19:44, Neil Toda wrote: > > A final webrev changing ./sourceOption test to include both the > positive and > negative test. The negative test shows that the lambda feature is not > supported > in 1.7. The positive test shows that the supplied file correctly uses > lambda in 1.9. > > Thanks. > > http://cr.openjdk.java.net/~darcy/neiltoda/8031670.2/ > > > From neil.toda at oracle.com Sat Mar 8 01:05:39 2014 From: neil.toda at oracle.com (Neil Toda) Date: Fri, 07 Mar 2014 17:05:39 -0800 Subject: Review Request - 3 minor cleanup : JDK-8031670: remove unneeded -source option from javadoc tests In-Reply-To: <531A42FF.2040308@oracle.com> References: <5317B2E6.1090207@oracle.com> <5318D024.7050301@oracle.com> <531A42FF.2040308@oracle.com> Message-ID: <531A6CE3.2090509@oracle.com> Thank you Vicente. -neil On 3/7/2014 2:06 PM, Vicente-Arturo Romero-Zaldivar wrote: > Hi Neil, > > I'm OK with the last version of the patch. > > Vicente > > On 06/03/14 19:44, Neil Toda wrote: >> >> A final webrev changing ./sourceOption test to include both the >> positive and >> negative test. The negative test shows that the lambda feature is >> not supported >> in 1.7. The positive test shows that the supplied file correctly >> uses lambda in 1.9. >> >> Thanks. >> >> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.2/ >> >> >> > From kumar.x.srinivasan at oracle.com Fri Mar 7 22:34:31 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 07 Mar 2014 14:34:31 -0800 Subject: Review Request - 3 minor cleanup : JDK-8031670: remove unneeded -source option from javadoc tests In-Reply-To: <5318D024.7050301@oracle.com> References: <5317B2E6.1090207@oracle.com> <5318D024.7050301@oracle.com> Message-ID: <531A4977.8050108@oracle.com> Hi Neil, Looks good to me. Kumar On 3/6/2014 11:44 AM, Neil Toda wrote: > > A final webrev changing ./sourceOption test to include both the > positive and > negative test. The negative test shows that the lambda feature is not > supported > in 1.7. The positive test shows that the supplied file correctly uses > lambda in 1.9. > > Thanks. > > http://cr.openjdk.java.net/~darcy/neiltoda/8031670.2/ > > > From joe.darcy at oracle.com Sat Mar 8 00:41:21 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 07 Mar 2014 16:41:21 -0800 Subject: JDK 9 RFR for documenting JSR 269 readObject methods Message-ID: <531A6731.6060509@oracle.com> Hello, Please review the small patch below with adds some javadoc to the readObject methods's of two JSR 269 exception types. Thanks, -Joe diff -r f675ddb8bd67 src/share/classes/javax/lang/model/type/MirroredTypeException.java --- a/src/share/classes/javax/lang/model/type/MirroredTypeException.java Fri Mar 07 13:30:23 2014 -0800 +++ b/src/share/classes/javax/lang/model/type/MirroredTypeException.java Fri Mar 07 16:33:06 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -70,6 +70,10 @@ /** * Explicitly set all transient fields. + * @param s the serial stream + * @throws ClassNotFoundException for a missing class during + * deserialization + * @throws IOException for an IO problem during deserialization */ private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException { diff -r f675ddb8bd67 src/share/classes/javax/lang/model/type/MirroredTypesException.java --- a/src/share/classes/javax/lang/model/type/MirroredTypesException.java Fri Mar 07 13:30:23 2014 -0800 +++ b/src/share/classes/javax/lang/model/type/MirroredTypesException.java Fri Mar 07 16:33:06 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -85,6 +85,10 @@ /** * Explicitly set all transient fields. + * @param s the serial stream + * @throws ClassNotFoundException for a missing class during + * deserialization + * @throws IOException for an IO problem during deserialization */ private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException { From neil.toda at oracle.com Sat Mar 8 01:05:06 2014 From: neil.toda at oracle.com (Neil Toda) Date: Fri, 07 Mar 2014 17:05:06 -0800 Subject: Review Request - 3 minor cleanup : JDK-8031670: remove unneeded -source option from javadoc tests In-Reply-To: <531A4977.8050108@oracle.com> References: <5317B2E6.1090207@oracle.com> <5318D024.7050301@oracle.com> <531A4977.8050108@oracle.com> Message-ID: <531A6CC2.1030304@oracle.com> Thanks Kumar On 3/7/2014 2:34 PM, Kumar Srinivasan wrote: > Hi Neil, > > Looks good to me. > > Kumar > > On 3/6/2014 11:44 AM, Neil Toda wrote: >> >> A final webrev changing ./sourceOption test to include both the >> positive and >> negative test. The negative test shows that the lambda feature is >> not supported >> in 1.7. The positive test shows that the supplied file correctly >> uses lambda in 1.9. >> >> Thanks. >> >> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.2/ >> >> >> > From ivan.gerasimov at oracle.com Mon Mar 10 17:14:10 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 10 Mar 2014 21:14:10 +0400 Subject: RFR [8034044] Class.getModifiers() returns "static" for anonymous classes In-Reply-To: <531A1271.6080607@oracle.com> References: <531982E0.1050307@oracle.com> <5319835E.4090007@oracle.com> <531A0B80.3070804@oracle.com> <531A1271.6080607@oracle.com> Message-ID: <531DF2E2.5030706@oracle.com> I removed the STATIC bit from the modifiers of the enum body. Jtreg test is updated accordingly. No new jtreg/jck test failures. Would you please help review the updated webrev? http://cr.openjdk.java.net/~igerasim/8034044/1/webrev/ Sincerely yours, Ivan On 07.03.2014 22:39, Ivan Gerasimov wrote: > Thank you Alex! > > On 07.03.2014 22:10, Alex Buckley wrote: >> On 3/7/2014 12:29 AM, Ivan Gerasimov wrote: >>> JLS states that an anonymous class cannot be static [1]. >>> However, in OpenJDK implementation Class#getModifiers(), when called >>> for >>> the anonymous class, returns the STATIC bit set. >>> Would you please help review the proposed fix, which removes STATIC >>> from >>> the anonymous class's modifier? >>> >>> An exception to this is an enum constant's body. >>> It's not clear, whether they should be treated in the same way as >>> anonymous classes, so I left them as they are now. >> >> JLS 8.9.1: The optional class body of an enum constant implicitly >> defines an anonymous class declaration (?15.9.5) that extends the >> immediately enclosing enum type. >> >> So the class generated for an enum constant's body should not be >> ACC_STATIC. >> > > Ok, I'll remove STATIC from the enum bodies too. > > Sincerely yours, > Ivan > >> Alex >> > > > > From boaznahum at gmail.com Tue Mar 11 15:27:44 2014 From: boaznahum at gmail.com (Boaz Nahum) Date: Tue, 11 Mar 2014 17:27:44 +0200 Subject: Change in behavior of javax.tools.JavaCompiler in JDK 8 running with -proc:only ? Message-ID: Hi I hope some can give me hint how anlyse our probelms with JDK 8. We use some code like this to do annotation processing (for generating code): JavaCompiler.CompilationTask task = javaCompiler.getTask(null, fileManager, diagnostics, optionsAsList, null, compilationUnits); BuildingBlockParamProcessor processor = new BuildingBlockParamProcessor(); List processors = new ArrayList(); processors.add(processor); task.setProcessors(processors); if(!task.call()){ .... } The code we try to process won't be compile in regular environment - a lot of stuff is missing from classpath. But that is OK, we use '-proc:only' and we *thought* that this what allows us to ignore the errors. When we moved to JDK 8, the exact code fails, javax.tools.JavaCompiler.CompilationTask#call returns false. *My question, is a possibilty that '-proc:only' is ignored in JDK 8 ?* *Or maybe there is by-design change regarding annotation processing that we need to be aware of ?* I want to mention that if the early EAP of JDK 8 , this code run without any problems. (Moving to annotation processing during compilation is big effort for us) Any tip/hint will be appreciatively accepted Thanks Boaz -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie at dellroad.org Tue Mar 11 18:09:04 2014 From: archie at dellroad.org (Archie Cobbs) Date: Tue, 11 Mar 2014 13:09:04 -0500 Subject: JLS tweaks In-Reply-To: <53159118.7000802@univ-mlv.fr> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> Message-ID: On Tue, Mar 4, 2014 at 2:38 AM, Remi Forax wrote: > > It seems like the JVM spec gets it right - i.e., you can do (mostly) >> whatever you want prior to super()/this() as long as it doesn't try to make >> use of an uninitialized 'this', and no uninitialized 'this' can escape. It >> seems reasonable to want the JLS to more closely mirror this sensible >> stance. >> >> I must be missing something... >> > > The rules of Java the language are less permissive than the rules of the > JVM regarding uninitialized instance, that's true. > But at least, the Java rules is simple to understand to anyone. Adding > complexity here will not worth it and as Brian mention, > you can still call a static method inside this() or super(). > I don't see how any complexity would be added (that is, for the programmer). What's being added is flexibility. If someone wants to continue to make super()/this() the first line of every constructor, they can happily continue do so. This proposal is like the change in Java8 allowing variables used in anonymous inner classes to no longer be required to be 'final'. Both changes are simply relaxing an unnecessary source code restriction. I'd even argue this proposal has much more unambiguous semantics than that change does. And those semantics are not anything new really. Think of the restrictions that apply to a final field: you must set it exactly once, and you must set it before you use it. This proposal would have the same restriction on 'this': you must initialize it exactly once, and you must initialize it before you use it. By the way, your suggested workaround is missing something: the only workaround (as Brian mentioned) is not not use a constructor at all, replacing it with a static factory method. Otherwise there's no way to avoid e.g. redundant calculation without changing from constructor-based creation to factory-method-based creation. In any case, I don't see how the existence of an imperfect workaround makes the proposal any less correct (at least in theory). > *Idea #5: Allow enum types to have generic type parameters* >> >> Another frequent suggestion. I agree it would have been better if >> it were done this way initially, and the cost would have been >> low. The cost of doing this now in a binary-compatible way would >> be higher. >> >> >> Ah, I didn't realize there was a binary compatibility problem here. What >> specifically is the problem? >> > > > There is another problem. You don't want an enum in your example. > You want some properties of an enum but not others. An enum in Java is not > only a type of a serie of values, > it's a serie of values with a name, a unique number, a common type and a > way to get an array of all these values (with Foo.values()). > > In your example, you don't want a common type and if an enum type is a > generic type values() will return array of wildcard making values() (and > valueOf) useless from the typing point of view. It seems you want only one > part of the enum and not the other, so an enum is the wrong language > construction for your problem. > Not sure what you mean by "You don't want an enum in your example" and I don't really understand your counter-argument. Why do you say I don't want a common type? What part of an enum are you saying I don't really want? Of course values() will return array of Primitive. That's not useless, and certainly no more useless than array of Primitive (non-generic) which is all you get with the current enum. Also, nobody has yet explained what the binary compatibility problem is. That certainly doesn't mean there isn't one, but I just don't see it yet. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie at dellroad.org Tue Mar 11 18:10:03 2014 From: archie at dellroad.org (Archie Cobbs) Date: Tue, 11 Mar 2014 13:10:03 -0500 Subject: JLS tweaks In-Reply-To: References: <5314BFAA.7040606@oracle.com> Message-ID: Just a friendly reminder... still waiting on input regarding the questions below (which were in response to Brian's earlier email). Thanks, -Archie On Mon, Mar 3, 2014 at 2:55 PM, Archie Cobbs wrote: > Brian, > > Thanks for your comments. > > > On Mon, Mar 3, 2014 at 11:45 AM, Brian Goetz wrote: > >> *Idea #2: Allow non-this code prior to super()/this() call in >> constructors* >> >> This is well-traveled ground; this request has come up, and been shot >> down, many times. If anything, the language spec is already too loose >> here, allowing too many unsafe operations (e.g., calling virtual methods >> from constructors, allowing constructor to publish 'this', etc) and this >> would make this problem dramatically worse. >> > > I would like to better understand what you're saying here. I am certainly > not interested in changes that would weaken language safety, so I must be > misunderstanding something. > > When you refer to calling virtual methods and publishing 'this', do you > mean prior to superclass constructor invocation? If so how is that possible > currently? Because the JVM spec seems to disallowit.. I'm referring to the sentence "Before that method invokes another > instance initialization method of myClass or its direct superclass on this, > the only operation the method can perform on this is assigning fields > declared within myClass." I take this to mean that for example that you > couldn't pass 'this' as a parameter, assign it to a field, invoke a method > on it, or do anything else that would allow its uninitialized escape. > > Or, if you meant calling virtual methods and publishing 'this' after > super()/this(), then how does this proposal have any relation to those > problems? They are on the "other side" of super()/this() line, so to speak, > and this proposal would not make them any more permitted than they already > are. > > It seems like the JVM spec gets it right - i.e., you can do (mostly) > whatever you want prior to super()/this() as long as it doesn't try to make > use of an uninitialized 'this', and no uninitialized 'this' can escape. It > seems reasonable to want the JLS to more closely mirror this sensible > stance. > > I must be missing something... > > *Idea #3: Allow generic type declarations wherever normal type >> declarations are allowed* >> Obviously "wherever normal type declarations" is broader than you mean. >> What you're looking for is the ability to "uncapture" a captured variable, >> giving it a name. As you've pointed out, generic methods already provide >> you the ability to do that, and what you're asking for is do to that >> 'inline' in a block of code. My recommendation is to try and take this to >> the next step (a more detailed analysis); I think you'll find you'll run >> into complexity at multiple levels. >> > > I may not be smart enough to actually reach those multiple levels of > complexity... :) Can you give me an example? > > In case it wasn't already clear... the original simplistic thought was > that at any variable declaration where the declared type is generic, you > could have the option of piggybacking onto that a generic type variable > declaration. > > So any: > > final List x = ... > > could be changed to: > > final List x = ... > > and the T would be declared as a bound type variable with the same scope > as 'x'. > > *Idea #5: Allow enum types to have generic type parameters* >> Another frequent suggestion. I agree it would have been better if it >> were done this way initially, and the cost would have been low. The cost >> of doing this now in a binary-compatible way would be higher. >> > > Ah, I didn't realize there was a binary compatibility problem here. What > specifically is the problem? > > Thanks, > -Archie > > -- > Archie L. Cobbs > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Mar 11 18:24:35 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Mar 2014 11:24:35 -0700 Subject: Change in behavior of javax.tools.JavaCompiler in JDK 8 running with -proc:only ? In-Reply-To: References: Message-ID: <531F54E3.1050801@oracle.com> Boaz, In JDK 8, javac is more aggressive about reporting errors (and stopping the compilation) if the errors cannot be fixed by running annotation processors. This should not be an issue if you are using anno processors for generating code. What sort of errors are you seeing in your compilation? -- Jon On 03/11/2014 08:27 AM, Boaz Nahum wrote: > Hi > > I hope some can give me hint how anlyse our probelms with JDK 8. > > We use some code like this to do annotation processing (for generating > code): > > JavaCompiler.CompilationTask task = > javaCompiler.getTask(null, fileManager, diagnostics, > optionsAsList, null, compilationUnits); > > BuildingBlockParamProcessor processor = new > BuildingBlockParamProcessor(); > List processors = new ArrayList(); > processors.add(processor); > task.setProcessors(processors); > if(!task.call()){ .... } > > The code we try to process won't be compile in regular environment - a > lot of stuff is missing from classpath. > But that is OK, we use '-proc:only' and we *thought* that this what > allows us to ignore the errors. > > > When we moved to JDK 8, the exact code fails, > javax.tools.JavaCompiler.CompilationTask#call returns false. > > *My question, is a possibilty that '-proc:only' is ignored in JDK 8 ? > * > *Or maybe there is by-design change regarding annotation processing > that we need to be aware of ? > * > I want to mention that if the early EAP of JDK 8 , this code run > without any problems. > > (Moving to annotation processing during compilation is big effort for us) > > Any tip/hint will be appreciatively accepted > > Thanks > Boaz > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Mar 11 20:56:24 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Mar 2014 13:56:24 -0700 Subject: JDK 9 RFR for documenting JSR 269 readObject methods In-Reply-To: <531A6731.6060509@oracle.com> References: <531A6731.6060509@oracle.com> Message-ID: <531F7878.8060603@oracle.com> Looks good to me. -- Jon On 03/07/2014 04:41 PM, Joe Darcy wrote: > Hello, > > Please review the small patch below with adds some javadoc to the > readObject methods's of two JSR 269 exception types. > > Thanks, > > -Joe > > diff -r f675ddb8bd67 > src/share/classes/javax/lang/model/type/MirroredTypeException.java > --- > a/src/share/classes/javax/lang/model/type/MirroredTypeException.java > Fri Mar 07 13:30:23 2014 -0800 > +++ > b/src/share/classes/javax/lang/model/type/MirroredTypeException.java > Fri Mar 07 16:33:06 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -70,6 +70,10 @@ > > /** > * Explicitly set all transient fields. > + * @param s the serial stream > + * @throws ClassNotFoundException for a missing class during > + * deserialization > + * @throws IOException for an IO problem during deserialization > */ > private void readObject(ObjectInputStream s) > throws IOException, ClassNotFoundException { > diff -r f675ddb8bd67 > src/share/classes/javax/lang/model/type/MirroredTypesException.java > --- > a/src/share/classes/javax/lang/model/type/MirroredTypesException.java > Fri Mar 07 13:30:23 2014 -0800 > +++ > b/src/share/classes/javax/lang/model/type/MirroredTypesException.java > Fri Mar 07 16:33:06 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -85,6 +85,10 @@ > > /** > * Explicitly set all transient fields. > + * @param s the serial stream > + * @throws ClassNotFoundException for a missing class during > + * deserialization > + * @throws IOException for an IO problem during deserialization > */ > private void readObject(ObjectInputStream s) > throws IOException, ClassNotFoundException { > From weijun.wang at oracle.com Wed Mar 12 07:45:33 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 12 Mar 2014 15:45:33 +0800 Subject: Is there a way to provide a default toString() to an interface? Message-ID: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> Hi All I have an interface that wraps an integer, like this interface Wrapper { int getX(); } Why cannot I add a default toString method default String toString() { return "This is " + getX(); } The error is error: default method toString in interface DSAPublicKey overrides a member of java.lang.Object default String toString() { Is there any other way to do it? I do not want to rename it to getString() and let all child classes call it in their toString(). Thanks Max P.S. security-dev@ guys, I want to move toString() back to {DSA|RSA|EC}PublicKey so that we get the same strings for SunPKCS11 and SunJCE. From john.r.rose at oracle.com Wed Mar 12 08:02:05 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 12 Mar 2014 01:02:05 -0700 Subject: Is there a way to provide a default toString() to an interface? In-Reply-To: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> References: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> Message-ID: <3BD338FF-EE7A-47A4-9885-3D1C5613202D@oracle.com> On Mar 12, 2014, at 12:45 AM, Wang Weijun wrote: > I do not want to rename it to getString() and let all child classes call it in their toString(). It is probably best to define a *static* method to hold the default implementation, so that the only candidate for overriding is toString itself. See MethodHandleInfo and InfoFromMemberName (in java.lang.invoke) for one example of this pattern. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From boaznahum at gmail.com Wed Mar 12 10:00:50 2014 From: boaznahum at gmail.com (Boaz Nahum) Date: Wed, 12 Mar 2014 12:00:50 +0200 Subject: Change in behavior of javax.tools.JavaCompiler in JDK 8 running with -proc:only ? In-Reply-To: <531F54E3.1050801@oracle.com> References: <531F54E3.1050801@oracle.com> Message-ID: Thank you so much for your reply. The simplest file that fails to compile is like this: package wf.auto_testing_jsystem_tiny_test.tint_test; import amat.jsystem.bbs_params.annotation.BuildingBlock; import amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext; public class TinyTest { /** * A dummy comment */ @BuildingBlock public static void loadBatchFromFile(BuildingBlockContext context, String batchPath) throws Exception { } } one of the error messages is: * ....\TinyTest.java:4: error: package amat.jsystem.bbs_utils.infrastructure does not exist* * import amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext;* ^ As I mentioned in my question, it is expected error, because we don't supply all the necessary compilation dependencies(we can't) . My question -again-, is That in JDK 7, it works perfect: The errors above are reported only via javax.tools.DiagnosticListener#report (not printed to the console) javax.tools.JavaCompiler.CompilationTask#*call returns true*. In JDK 8, Same errors are reported both via javax.tools.DiagnosticListener#report and are printed to the console, javax.tools.JavaCompiler.CompilationTask#*call returns false*. *In JDK 7*, If I omit '-proc:only', then I get the exact behavior *as JDK 8*, that why I'm wondering, *maybe JDK 8 somehow ignore '-proc:only'* Thank again Boaz On Tue, Mar 11, 2014 at 8:24 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Boaz, > > In JDK 8, javac is more aggressive about reporting errors (and stopping > the compilation) if the errors cannot be fixed by running annotation > processors. This should not be an issue if you are using anno processors > for generating code. > > What sort of errors are you seeing in your compilation? > > -- Jon > > > On 03/11/2014 08:27 AM, Boaz Nahum wrote: > > Hi > > I hope some can give me hint how anlyse our probelms with JDK 8. > > We use some code like this to do annotation processing (for generating > code): > > JavaCompiler.CompilationTask task = > javaCompiler.getTask(null, fileManager, diagnostics, > optionsAsList, null, compilationUnits); > > BuildingBlockParamProcessor processor = new > BuildingBlockParamProcessor(); > List processors = new ArrayList(); > processors.add(processor); > task.setProcessors(processors); > if(!task.call()){ .... } > > The code we try to process won't be compile in regular environment - a > lot of stuff is missing from classpath. > But that is OK, we use '-proc:only' and we *thought* that this what > allows us to ignore the errors. > > > When we moved to JDK 8, the exact code fails, > javax.tools.JavaCompiler.CompilationTask#call returns false. > > > *My question, is a possibilty that '-proc:only' is ignored in JDK 8 ? * > > *Or maybe there is by-design change regarding annotation processing that > we need to be aware of ? * > I want to mention that if the early EAP of JDK 8 , this code run without > any problems. > > (Moving to annotation processing during compilation is big effort for us) > > Any tip/hint will be appreciatively accepted > > Thanks > Boaz > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boaznahum at gmail.com Wed Mar 12 10:18:47 2014 From: boaznahum at gmail.com (Boaz Nahum) Date: Wed, 12 Mar 2014 12:18:47 +0200 Subject: Change in behavior of javax.tools.JavaCompiler in JDK 8 running with -proc:only ? In-Reply-To: References: <531F54E3.1050801@oracle.com> Message-ID: My aplogozie, In JDK 8, > Same errors are reported both via javax.tools.DiagnosticListener#report > and are printed to the console, > > > This is not true, errors are not reported to the console. only via javax.tools.DiagnosticListener#report -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Mar 12 13:58:35 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 12 Mar 2014 14:58:35 +0100 Subject: Change in behavior of javax.tools.JavaCompiler in JDK 8 running with -proc:only ? In-Reply-To: References: <531F54E3.1050801@oracle.com> Message-ID: <5320680B.9010302@oracle.com> Hi Boaz, Do I understand it correctly that the only difference between JDK 7 and JDK 8 in your usecase is the return value from CompilationTask.call()? In particular, your annotation processor is run and the same errors are reported under both JDK 7 and JDK 8? The related difference (in a usecase similar to yours) between JDK 7 and JDK 8 that I was able to find is as follows. In JDK 7 javac "forgot" that it produced the errors, and acted as it they were not printed, and so returned the OK return code for -proc:only (and, as another consequence, printed the errors again for normal compilation). In JDK 8, javac properly keeps track of errors it produced, and consequently returns "EXIT_ERROR", which is then mapped to "false" return value of CompilationTask.call(). Jan On 03/12/2014 11:00 AM, Boaz Nahum wrote: > Thank you so much for your reply. > > The simplest file that fails to compile is like this: > > package wf.auto_testing_jsystem_tiny_test.tint_test; > > import amat.jsystem.bbs_params.annotation.BuildingBlock; > import amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext; > > public class TinyTest { > > /** > * A dummy comment > */ > @BuildingBlock > public static void loadBatchFromFile(BuildingBlockContext context, > String batchPath) throws Exception { > > } > } > > > one of the error messages is: > > * ....\TinyTest.java:4: error: package > amat.jsystem.bbs_utils.infrastructure does not exist > * > * import amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext; > * > ^ > > As I mentioned in my question, it is expected error, because we don't > supply all the necessary compilation dependencies(we can't) . > > My question -again-, is That in JDK 7, it works perfect: > The errors above are reported only via > javax.tools.DiagnosticListener#report (not printed to the console) > javax.tools.JavaCompiler.CompilationTask#*call returns true*. > > In JDK 8, > Same errors are reported both via javax.tools.DiagnosticListener#report > and are printed to the console, > javax.tools.JavaCompiler.CompilationTask#*call returns false*. > > *In JDK 7*, If I omit '-proc:only', then I get the exact behavior *as > JDK 8*, that why I'm wondering, *maybe JDK 8 somehow ignore '-proc:only'* > > Thank again > Boaz > > > > > On Tue, Mar 11, 2014 at 8:24 PM, Jonathan Gibbons > > wrote: > > Boaz, > > In JDK 8, javac is more aggressive about reporting errors (and > stopping the compilation) if the errors cannot be fixed by running > annotation processors. This should not be an issue if you are using > anno processors for generating code. > > What sort of errors are you seeing in your compilation? > > -- Jon > > > On 03/11/2014 08:27 AM, Boaz Nahum wrote: >> Hi >> >> I hope some can give me hint how anlyse our probelms with JDK 8. >> >> We use some code like this to do annotation processing (for >> generating code): >> >> JavaCompiler.CompilationTask task = >> javaCompiler.getTask(null, fileManager, >> diagnostics, optionsAsList, null, compilationUnits); >> >> BuildingBlockParamProcessor processor = new >> BuildingBlockParamProcessor(); >> List processors = new ArrayList(); >> processors.add(processor); >> task.setProcessors(processors); >> if(!task.call()){ .... } >> >> The code we try to process won't be compile in regular environment >> - a lot of stuff is missing from classpath. >> But that is OK, we use '-proc:only' and we *thought* that this >> what allows us to ignore the errors. >> >> >> When we moved to JDK 8, the exact code fails, >> javax.tools.JavaCompiler.CompilationTask#call returns false. >> >> *My question, is a possibilty that '-proc:only' is ignored in JDK 8 ? >> * >> *Or maybe there is by-design change regarding annotation >> processing that we need to be aware of ? >> * >> I want to mention that if the early EAP of JDK 8 , this code run >> without any problems. >> >> (Moving to annotation processing during compilation is big effort >> for us) >> >> Any tip/hint will be appreciatively accepted >> >> Thanks >> Boaz >> >> >> > > From brian.goetz at oracle.com Wed Mar 12 15:57:41 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 12 Mar 2014 11:57:41 -0400 Subject: Is there a way to provide a default toString() to an interface? In-Reply-To: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> References: <43ADCF7D-B761-4334-8280-88DF71684BB3@oracle.com> Message-ID: <532083F5.8060906@oracle.com> This is a common question. The short answer is "no". The short explanation of "why not", is that if there's a conflict between a superCLASS method and a superINTERFACE method, the class method wins. Since Object is a class, the toString (or hashCode, or equals) in Object will win over any default. (The error is there to call your attention to the fact that this is a method that cannot be inherited by any subtype; without the error, you'd be posting an even more annoyed message when you discovered (probably much later) that the implementation was not being inherited.) But of course you can ask "well, why is this the rule?" This rule wasn't chosen arbitrarily; alternate rulesets were investigated, some of which might have enabled this usage pattern. But they were dramatically more complicated, and had poorer compatibility characteristics, for very little incremental expressiveness. This current ruleset is simple and 100% compatible (any method inherited under 7 works exactly the same way under 8.) Looking at it from the other side, I understand why one would want to write a default method for equals/hashCode/toString, but in reality this is a pretty bad idea. The reason is that these methods are inextricably bound to an object's state. And the state lives in classes, not interfaces; the class should be the one providing these methods. If we allowed you to inherit these methods from an interface, it would still only work predictably for inheritance patterns that are strictly single-inheritance, such as if we wrote AbstractList as an interface (which we could, because it has no state). But in the general case, interfaces are not used that way, and the weirdness that would ensue because some library class three libraries and nine levels of inheritance up added an equals method and that was inherited by your application and subtly changed its behavior would be a nightmare. So, summarizing: - It would dramatically complicate inheritance rules to enable this, and - Its a bad idea anyway. Now, if you have a complicated toString() method you want to put in an interface, you can do this: interface Wrapper { default String wrapperAsString() { ... } } class X implements Wrapper { String toString() { return wrapperAsString(); } } But the class has to opt-into this being the toString implementation. Same with equals/hashCode. On 3/12/2014 3:45 AM, Wang Weijun wrote: > Hi All > > I have an interface that wraps an integer, like this > > interface Wrapper { > int getX(); > } > > Why cannot I add a default toString method > > default String toString() { > return "This is " + getX(); > } > > The error is > > error: default method toString in interface DSAPublicKey overrides a member of java.lang.Object > default String toString() { > > Is there any other way to do it? I do not want to rename it to getString() and let all child classes call it in their toString(). > > Thanks > Max > > P.S. security-dev@ guys, I want to move toString() back to {DSA|RSA|EC}PublicKey so that we get the same strings for SunPKCS11 and SunJCE. > From jonathan.gibbons at oracle.com Wed Mar 12 17:17:49 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Mar 2014 10:17:49 -0700 Subject: Change in behavior of javax.tools.JavaCompiler in JDK 8 running with -proc:only ? In-Reply-To: References: <531F54E3.1050801@oracle.com> Message-ID: <532096BD.1000803@oracle.com> This sounds like a possible bug, but I doubt it is related to -proc:only. In JDK 8 javac, diagnostics are classified as "recoverable" or not, depending on whether a diagnostic could conceivably go away if an annotation processor is run. It is possible that "package does not exist" is not being marked as a recoverable error. The other possibility is that the message is coming out of the last round of anno processing (before -proc:only) is kicking in. -- Jon On 03/12/2014 03:00 AM, Boaz Nahum wrote: > Thank you so much for your reply. > > The simplest file that fails to compile is like this: > > package wf.auto_testing_jsystem_tiny_test.tint_test; > > import amat.jsystem.bbs_params.annotation.BuildingBlock; > import amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext; > > public class TinyTest { > > /** > * A dummy comment > */ > @BuildingBlock > public static void loadBatchFromFile(BuildingBlockContext context, > String batchPath) throws Exception { > > } > } > > > one of the error messages is: > > * ....\TinyTest.java:4: error: package > amat.jsystem.bbs_utils.infrastructure does not exist > * > * import amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext; > * ^ > > As I mentioned in my question, it is expected error, because we don't > supply all the necessary compilation dependencies(we can't) . > > My question -again-, is That in JDK 7, it works perfect: > The errors above are reported only via > javax.tools.DiagnosticListener#report (not printed to the console) > javax.tools.JavaCompiler.CompilationTask#*call returns true*. > > In JDK 8, > Same errors are reported both via > javax.tools.DiagnosticListener#report and are printed to the console, > javax.tools.JavaCompiler.CompilationTask#*call returns false*. > > *In JDK 7*, If I omit '-proc:only', then I get the exact behavior *as > JDK 8*, that why I'm wondering, *maybe JDK 8 somehow ignore '-proc:only'* > > Thank again > Boaz > > > > > On Tue, Mar 11, 2014 at 8:24 PM, Jonathan Gibbons > > wrote: > > Boaz, > > In JDK 8, javac is more aggressive about reporting errors (and > stopping the compilation) if the errors cannot be fixed by running > annotation processors. This should not be an issue if you are > using anno processors for generating code. > > What sort of errors are you seeing in your compilation? > > -- Jon > > > On 03/11/2014 08:27 AM, Boaz Nahum wrote: >> Hi >> >> I hope some can give me hint how anlyse our probelms with JDK 8. >> >> We use some code like this to do annotation processing (for >> generating code): >> >> JavaCompiler.CompilationTask task = >> javaCompiler.getTask(null, fileManager, >> diagnostics, optionsAsList, null, compilationUnits); >> >> BuildingBlockParamProcessor processor = new >> BuildingBlockParamProcessor(); >> List processors = new ArrayList(); >> processors.add(processor); >> task.setProcessors(processors); >> if(!task.call()){ .... } >> >> The code we try to process won't be compile in regular >> environment - a lot of stuff is missing from classpath. >> But that is OK, we use '-proc:only' and we *thought* that this >> what allows us to ignore the errors. >> >> >> When we moved to JDK 8, the exact code fails, >> javax.tools.JavaCompiler.CompilationTask#call returns false. >> >> *My question, is a possibilty that '-proc:only' is ignored in JDK 8 ? >> * >> *Or maybe there is by-design change regarding annotation >> processing that we need to be aware of ? >> * >> I want to mention that if the early EAP of JDK 8 , this code run >> without any problems. >> >> (Moving to annotation processing during compilation is big effort >> for us) >> >> Any tip/hint will be appreciatively accepted >> >> Thanks >> Boaz >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boaznahum at gmail.com Wed Mar 12 19:13:05 2014 From: boaznahum at gmail.com (Boaz Nahum) Date: Wed, 12 Mar 2014 21:13:05 +0200 Subject: Change in behavior of javax.tools.JavaCompiler in JDK 8 running with -proc:only ? In-Reply-To: <532096BD.1000803@oracle.com> References: <531F54E3.1050801@oracle.com> <532096BD.1000803@oracle.com> Message-ID: I'm little confused- How should I continue, keep investigating and bring more info? Or take it as is ? Boaz On Mar 12, 2014 7:17 PM, "Jonathan Gibbons" wrote: > This sounds like a possible bug, but I doubt it is related to -proc:only. > > In JDK 8 javac, diagnostics are classified as "recoverable" or not, > depending on whether a diagnostic could conceivably go away if an > annotation processor is run. It is possible that "package does not exist" > is not being marked as a recoverable error. The other possibility is that > the message is coming out of the last round of anno processing (before > -proc:only) is kicking in. > > -- Jon > > > > > On 03/12/2014 03:00 AM, Boaz Nahum wrote: > > Thank you so much for your reply. > > The simplest file that fails to compile is like this: > > package wf.auto_testing_jsystem_tiny_test.tint_test; > > import amat.jsystem.bbs_params.annotation.BuildingBlock; > import amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext; > > public class TinyTest { > > /** > * A dummy comment > */ > @BuildingBlock > public static void loadBatchFromFile(BuildingBlockContext context, > String batchPath) throws Exception { > > } > } > > > one of the error messages is: > > > * ....\TinyTest.java:4: error: package > amat.jsystem.bbs_utils.infrastructure does not exist * > > * import amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext; * > ^ > > As I mentioned in my question, it is expected error, because we don't > supply all the necessary compilation dependencies(we can't) . > > My question -again-, is That in JDK 7, it works perfect: > The errors above are reported only via > javax.tools.DiagnosticListener#report (not printed to the console) > javax.tools.JavaCompiler.CompilationTask#*call returns true*. > > In JDK 8, > Same errors are reported both via javax.tools.DiagnosticListener#report > and are printed to the console, > javax.tools.JavaCompiler.CompilationTask#*call returns false*. > > *In JDK 7*, If I omit '-proc:only', then I get the exact behavior *as > JDK 8*, that why I'm wondering, *maybe JDK 8 somehow ignore '-proc:only'* > > Thank again > Boaz > > > > > On Tue, Mar 11, 2014 at 8:24 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> Boaz, >> >> In JDK 8, javac is more aggressive about reporting errors (and stopping >> the compilation) if the errors cannot be fixed by running annotation >> processors. This should not be an issue if you are using anno processors >> for generating code. >> >> What sort of errors are you seeing in your compilation? >> >> -- Jon >> >> >> On 03/11/2014 08:27 AM, Boaz Nahum wrote: >> >> Hi >> >> I hope some can give me hint how anlyse our probelms with JDK 8. >> >> We use some code like this to do annotation processing (for generating >> code): >> >> JavaCompiler.CompilationTask task = >> javaCompiler.getTask(null, fileManager, diagnostics, >> optionsAsList, null, compilationUnits); >> >> BuildingBlockParamProcessor processor = new >> BuildingBlockParamProcessor(); >> List processors = new ArrayList(); >> processors.add(processor); >> task.setProcessors(processors); >> if(!task.call()){ .... } >> >> The code we try to process won't be compile in regular environment - a >> lot of stuff is missing from classpath. >> But that is OK, we use '-proc:only' and we *thought* that this what >> allows us to ignore the errors. >> >> >> When we moved to JDK 8, the exact code fails, >> javax.tools.JavaCompiler.CompilationTask#call returns false. >> >> >> *My question, is a possibilty that '-proc:only' is ignored in JDK 8 ? * >> >> *Or maybe there is by-design change regarding annotation processing that >> we need to be aware of ? * >> I want to mention that if the early EAP of JDK 8 , this code run >> without any problems. >> >> (Moving to annotation processing during compilation is big effort for >> us) >> >> Any tip/hint will be appreciatively accepted >> >> Thanks >> Boaz >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Mar 12 19:25:00 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Mar 2014 12:25:00 -0700 Subject: Change in behavior of javax.tools.JavaCompiler in JDK 8 running with -proc:only ? In-Reply-To: References: <531F54E3.1050801@oracle.com> <532096BD.1000803@oracle.com> Message-ID: <5320B48C.3000803@oracle.com> I'll file a bug, so that this gets investigated further. Jan's comments about exit code handling are noteworthy. -- Jon On 03/12/2014 12:13 PM, Boaz Nahum wrote: > > I'm little confused- How should I continue, keep investigating and > bring more info? Or take it as is ? > > Boaz > > On Mar 12, 2014 7:17 PM, "Jonathan Gibbons" > > wrote: > > This sounds like a possible bug, but I doubt it is related to > -proc:only. > > In JDK 8 javac, diagnostics are classified as "recoverable" or > not, depending on whether a diagnostic could conceivably go away > if an annotation processor is run. It is possible that "package > does not exist" is not being marked as a recoverable error. The > other possibility is that the message is coming out of the last > round of anno processing (before -proc:only) is kicking in. > > -- Jon > > > > > On 03/12/2014 03:00 AM, Boaz Nahum wrote: >> Thank you so much for your reply. >> >> The simplest file that fails to compile is like this: >> >> package wf.auto_testing_jsystem_tiny_test.tint_test; >> >> import amat.jsystem.bbs_params.annotation.BuildingBlock; >> import amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext; >> >> public class TinyTest { >> >> /** >> * A dummy comment >> */ >> @BuildingBlock >> public static void loadBatchFromFile(BuildingBlockContext >> context, String batchPath) throws Exception { >> >> } >> } >> >> >> one of the error messages is: >> >> *....\TinyTest.java:4: error: package >> amat.jsystem.bbs_utils.infrastructure does not exist >> * >> * import >> amat.jsystem.bbs_utils.infrastructure.BuildingBlockContext; >> * ^ >> >> As I mentioned in my question, it is expected error, because we >> don't supply all the necessary compilation dependencies(we can't) . >> >> My question -again-, is That in JDK 7, it works perfect: >> The errors above are reported only via >> javax.tools.DiagnosticListener#report (not printed to the console) >> javax.tools.JavaCompiler.CompilationTask#*call returns true*. >> >> In JDK 8, >> Same errors are reported both via >> javax.tools.DiagnosticListener#report and are printed to the console, >> javax.tools.JavaCompiler.CompilationTask#*call returns false*. >> >> *In JDK 7*, If I omit '-proc:only', then I get the exact behavior >> *as JDK 8*, that why I'm wondering, *maybe JDK 8 somehow ignore >> '-proc:only'* >> >> Thank again >> Boaz >> >> >> >> >> On Tue, Mar 11, 2014 at 8:24 PM, Jonathan Gibbons >> > > wrote: >> >> Boaz, >> >> In JDK 8, javac is more aggressive about reporting errors >> (and stopping the compilation) if the errors cannot be fixed >> by running annotation processors. This should not be an issue >> if you are using anno processors for generating code. >> >> What sort of errors are you seeing in your compilation? >> >> -- Jon >> >> >> On 03/11/2014 08:27 AM, Boaz Nahum wrote: >>> Hi >>> >>> I hope some can give me hint how anlyse our probelms with JDK 8. >>> >>> We use some code like this to do annotation processing (for >>> generating code): >>> >>> JavaCompiler.CompilationTask task = >>> javaCompiler.getTask(null, fileManager, diagnostics, >>> optionsAsList, null, compilationUnits); >>> >>> BuildingBlockParamProcessor processor = new >>> BuildingBlockParamProcessor(); >>> List processors = new >>> ArrayList(); >>> processors.add(processor); >>> task.setProcessors(processors); >>> if(!task.call()){ .... } >>> >>> The code we try to process won't be compile in regular >>> environment - a lot of stuff is missing from classpath. >>> But that is OK, we use '-proc:only' and we *thought* that >>> this what allows us to ignore the errors. >>> >>> >>> When we moved to JDK 8, the exact code fails, >>> javax.tools.JavaCompiler.CompilationTask#call returns false. >>> >>> *My question, is a possibilty that '-proc:only' is ignored >>> in JDK 8 ? >>> * >>> *Or maybe there is by-design change regarding annotation >>> processing that we need to be aware of ? >>> * >>> I want to mention that if the early EAP of JDK 8 , this code >>> run without any problems. >>> >>> (Moving to annotation processing during compilation is big >>> effort for us) >>> >>> Any tip/hint will be appreciatively accepted >>> >>> Thanks >>> Boaz >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Thu Mar 13 10:08:17 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 13 Mar 2014 11:08:17 +0100 Subject: JLS tweaks In-Reply-To: References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> Message-ID: <53218391.2030205@gmail.com> On 03/11/2014 07:09 PM, Archie Cobbs wrote: > On Tue, Mar 4, 2014 at 2:38 AM, Remi Forax > wrote: > > > It seems like the JVM spec gets it right - i.e., you can do > (mostly) whatever you want prior to super()/this() as long as > it doesn't try to make use of an uninitialized 'this', and no > uninitialized 'this' can escape. It seems reasonable to want > the JLS to more closely mirror this sensible stance. > > I must be missing something... > > > The rules of Java the language are less permissive than the rules > of the JVM regarding uninitialized instance, that's true. > But at least, the Java rules is simple to understand to anyone. > Adding complexity here will not worth it and as Brian mention, > you can still call a static method inside this() or super(). > > > I don't see how any complexity would be added (that is, for the > programmer). What's being added is flexibility. If someone wants to > continue to make super()/this() the first line of every constructor, > they can happily continue do so. Hi Archie, Would you want this to be allowed too: public class C extends B { public C(boolean b) { if (b) { super("YES"); // we may now use this... this.method(); } else { // we may not use this before call to super super("NO"); // we may now use this... } } } What about the following: public class C extends B { public C() { try { super(); if (Math.random() > 0.5L) throw new RuntimeException(); } catch (RuntimeException e) { // can we use 'this' here? } // is 'this' fully initialized here? } } ...and similar cases? Just to illustrate this is not a simple problem. But there might be a solution that is similar to a feature already present in Java language. Namely: the final variables and definitive assignment rules. We could treat 'this' (explicit and implicit) as a final instance field that is definitely not assigned at the start of a constructor. Any call to super(...) or this(...) is only possible in parts of constructor flow where 'this' is definitely not assigned and has the effect of making 'this' definitely assigned after the call. 'this' should either be definitely assigned or definitely unassigned at all non-exceptional exit paths from the constructor or else there is a compile-time error. If it is definitely assigned, nothing is done, if it is definitely unassigned, a synthetic call to super() is generated as the first instruction in the constructor. So if we threat 'this' as a final instance field for which the assignment state is tracked by the compiler, every explicit or implicit use of 'this' should only be allowed in parts of constructor flow where it is definitely assigned. I don't see this as any more complex or unsafe as the rules for final fields. But I don't know if it is compatible with JVM rules. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Thu Mar 13 10:21:35 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 13 Mar 2014 11:21:35 +0100 Subject: JLS tweaks In-Reply-To: <53218391.2030205@gmail.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> Message-ID: <532186AF.4000909@gmail.com> On 03/13/2014 11:08 AM, Peter Levart wrote: > I don't see this as any more complex or unsafe as the rules for final > fields. But I don't know if it is compatible with JVM rules. Does JVM have any rules for final instance fields regarding their definitive assignment at all non-exceptional exit paths of the constructor? Regards, Peter From archie at dellroad.org Thu Mar 13 16:22:50 2014 From: archie at dellroad.org (Archie Cobbs) Date: Thu, 13 Mar 2014 11:22:50 -0500 Subject: JLS tweaks In-Reply-To: <53218391.2030205@gmail.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> Message-ID: On Thu, Mar 13, 2014 at 5:08 AM, Peter Levart wrote: > On 03/11/2014 07:09 PM, Archie Cobbs wrote: > > On Tue, Mar 4, 2014 at 2:38 AM, Remi Forax wrote: > >> >> It seems like the JVM spec gets it right - i.e., you can do (mostly) >>> whatever you want prior to super()/this() as long as it doesn't try to make >>> use of an uninitialized 'this', and no uninitialized 'this' can escape. It >>> seems reasonable to want the JLS to more closely mirror this sensible >>> stance. >>> >>> I must be missing something... >>> >> >> The rules of Java the language are less permissive than the rules of the >> JVM regarding uninitialized instance, that's true. >> But at least, the Java rules is simple to understand to anyone. Adding >> complexity here will not worth it and as Brian mention, >> you can still call a static method inside this() or super(). >> > > I don't see how any complexity would be added (that is, for the > programmer). What's being added is flexibility. If someone wants to > continue to make super()/this() the first line of every constructor, they > can happily continue do so. > > > Hi Archie, > > Would you want this to be allowed too: > > public class C extends B { > public C(boolean b) { > if (b) { > super("YES"); > // we may now use this... > this.method(); > } else { > // we may not use this before call to super > super("NO"); > // we may now use this... > } > } > } > Yes. Or, for example: public C(int x, int y) { if (y > 0) x = Math.min(x, y); super(x); } > What about the following: > > public class C extends B { > public C() { > try { > super(); > if (Math.random() > 0.5L) throw new RuntimeException(); > } catch (RuntimeException e) { > // can we use 'this' here? > } > // is 'this' fully initialized here? > } > } > No... because exactly once initialization cannot be proven. As you point out, the same compiler logic that verifies final field initialization ("initialize exactly once and don't use until intialized") could be re-used for 'this' initialization ("initialize exactly once and don't use until initialized"). In your try/catch example, if you replaced 'this' initialization with final field intialization, you would get a compiler error. So the same thing would happen in your example - the compiler would complain that in the catch block it could not verify 'this' was initialized (if you tried to use it). Moreover, even if the compiler did allow your example the JVM would reject it. The JVM spec requires the bytecode verifier to do data flow analysis to verify exactly once 'this' initialization. > Just to illustrate this is not a simple problem. But there might be a > solution that is similar to a feature already present in Java language. > Namely: the final variables and definitive assignment rules. We could treat > 'this' (explicit and implicit) as a final instance field that is definitely > not assigned at the start of a constructor. Any call to super(...) or > this(...) is only possible in parts of constructor flow where 'this' is > definitely not assigned and has the effect of making 'this' definitely > assigned after the call. 'this' should either be definitely assigned or > definitely unassigned at all non-exceptional exit paths from the > constructor or else there is a compile-time error. If it is definitely > assigned, nothing is done, if it is definitely unassigned, a synthetic call > to super() is generated as the first instruction in the constructor. > > So if we threat 'this' as a final instance field for which the assignment > state is tracked by the compiler, every explicit or implicit use of 'this' > should only be allowed in parts of constructor flow where it is definitely > assigned. > Exactly. The same compiler logic that already exists for final field intiailization can be re-used mostly as-is. > I don't see this as any more complex or unsafe as the rules for final > fields. But I don't know if it is compatible with JVM rules. > The JVM has exactly this same rule, so it's compatible. This change simply aligns what the compiler permits with what the JVM permits. So in summary: - There is no weakening of type safety with this change - Change is fully compatible with existing source code and current JVM spec - The same logic for checking final field initialization that already exists in the compiler can be re-used for 'this' initialization - This feature has been requested many times in the past (as Brian pointed out) This one really seems like a no-brainer to me (just my own opinion of course). -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Mar 13 20:20:27 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 13 Mar 2014 20:20:27 +0000 Subject: compilation fails with 'no enclosing instance' error In-Reply-To: <530FAE54.9010106@oracle.com> References: <52FC2BE5.9010903@oracle.com> <52FD62C5.7020006@oracle.com> <530F5A9D.9020900@oracle.com> <530F6AB1.1060608@oracle.com> <530F9B07.3030700@oracle.com> <530FAE54.9010106@oracle.com> Message-ID: <5322130B.7070004@oracle.com> Hi Liam, The bug you reported has already been fixed in version 9. Thanks again for the bug report, Vicente changeset: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bd152504a538 original bug report: https://bugs.openjdk.java.net/browse/JDK-8034924 backport v9: https://bugs.openjdk.java.net/browse/JDK-8035432 On 27/02/14 21:29, Vicente-Arturo Romero-Zaldivar wrote: > On 27/02/14 21:14, Liam Miller-Cushon wrote: >> Got it, thanks for taking the time to explain. > > np, and thanks to you. You was right that the problem was there which > made the search much easier. > > Vicente > >> >> >> On Thu, Feb 27, 2014 at 12:07 PM, Vicente-Arturo Romero-Zaldivar >> > wrote: >> >> On 27/02/14 17:23, Liam Miller-Cushon wrote: >>> >>> Well hiddenIn() is not used for methods only, also fields >>> are considered. >>> >>> >>> So hiddenIn() should search along the path from the class to the >>> member's owner, and at each step search the superinterfaces of >>> the current class? I think the only change from the current >>> implementation would be terminating the search after reaching >>> the owner. >>> >>> Thanks, >>> Liam >> Yes that's the idea of the patch I'm working on and that's why I >> suggested that this was the reason of the problem :) As a side >> effect we may have some performance improvement. >> >> Vicente >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie at dellroad.org Thu Mar 13 22:00:42 2014 From: archie at dellroad.org (Archie Cobbs) Date: Thu, 13 Mar 2014 17:00:42 -0500 Subject: JLS tweaks In-Reply-To: <532186AF.4000909@gmail.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> Message-ID: On Thu, Mar 13, 2014 at 5:21 AM, Peter Levart wrote: > On 03/13/2014 11:08 AM, Peter Levart wrote: > >> I don't see this as any more complex or unsafe as the rules for final >> fields. But I don't know if it is compatible with JVM rules. >> > > Does JVM have any rules for final instance fields regarding their > definitive assignment at all non-exceptional exit paths of the constructor? > My understanding is that the JVM doesn't care how many times you assign a final field in a constructor, it only cares that you don't try to assign it from within a non-constructor method. See also this stackoverflow discussion . Note also that the JVM spec specifically allows a constructor to assign final fields before invoking super()/this(). So if the proposal we are talking about were implemented, it should probably also allow this. So for example this would be legal: public class SetOfInts extends HashSet { private final int max; public SetOfInts(int max) { this.max = max; // the only thing you can do with 'this' here final Integer[] array = new Integer[max]; for (int i = 0; i < max; i++) array[i] = i; super(Arrays.asList(array)); } } -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Fri Mar 14 13:50:37 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 14 Mar 2014 08:50:37 -0500 Subject: JLS tweaks In-Reply-To: References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> Message-ID: <5323092D.7030101@redhat.com> On 03/13/2014 05:00 PM, Archie Cobbs wrote: > On Thu, Mar 13, 2014 at 5:21 AM, Peter Levart > wrote: > > On 03/13/2014 11:08 AM, Peter Levart wrote: > > I don't see this as any more complex or unsafe as the rules for > final fields. But I don't know if it is compatible with JVM rules. > > > Does JVM have any rules for final instance fields regarding their > definitive assignment at all non-exceptional exit paths of the > constructor? > > > My understanding is that the JVM doesn't care how many times you assign > a final field in a constructor, it only cares that you don't try to > assign it from within a non-constructor method. [...] > Note also that the JVM spec specifically allows a constructor to assign > final fields before invoking super()/this(). I think you're mistaken on both of these points... can you quote a section of the JLS that says this? -- - DML From jonathan.gibbons at oracle.com Fri Mar 14 14:56:10 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 14 Mar 2014 07:56:10 -0700 Subject: JLS tweaks In-Reply-To: <5323092D.7030101@redhat.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> Message-ID: <5323188A.3030001@oracle.com> May I remind folk that the compiler-dev mailing list is for discussions about javac itself. It is not a place for language design discussions, or for proposing changes to JLS. Language changes are done by JSRs, under the governance of the JCP. -- Jon http://mail.openjdk.java.net/mailman/listinfo/compiler-dev compiler-dev -- Technical discussion about the development of the Java compiler (javac) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Fri Mar 14 14:57:57 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 14 Mar 2014 10:57:57 -0400 Subject: JLS tweaks In-Reply-To: <5323092D.7030101@redhat.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> Message-ID: <532318F5.90700@oracle.com> Regardless, "the JVM allows it, so the language should allow it" is barking up the wrong tree. The JVM and language have deeply different requirements, constraints, goals, and programmer audiences (the programmer audience for the JVM is mostly compiler writers.) The JVM has this flexibility not because we believe its a good idea to not initialize final fields, but because offline compilation is a better place to enforce this guideline than runtime. This "improvement" was deemed a bad idea in 2006 and is still a bad idea: https://bugs.openjdk.java.net/browse/JDK-4093999 Just because a lot of other people had the same bad idea, doesn't mean its a good idea. As far as I can see, the only real argument raised in favor of this feature is "the language already allows partially-constructed instances to be exposed to arbitrary code, how much worse would it be if it exposed even-less-constructed objects?" But this argument is a pretty silly one (it basically says that unless one can enforce a safety goal 100%, the goal has no legitimacy.) As I've said before, I don't even like that instances methods can be called from constructors, since they may still expose an object that has not been completely constructed. For example: class A implements Listener { public A() { // Do A's initialization someEventSource.registerListener(this); // really bad idea } // called when event source sends us an event public void onEvent(Event e) { ... } } Now, this might seem harmless, right? A has already been initialized, right? Wrong. Suppose someone subclasses B, adds invariants, and overrides onEvent: class B extends A { private final Logger logger; public B() { super(); this.logger = new Logger(); } @Override public void onEvent(Event e) { logger.log("Event: " + e); // XXX super.onEvent(e); } } Now suppose that the event source sends a message really soon after registration. B.onEvent() could see logger == null at line XXX. Ooops! What went wrong? A exposed a partially constructed B from its constructor, because the B initialization had not yet run when A's constructor registered itself as a listener, even though it thought it was all done initializing. B had no idea that A was a time bomb waiting to blow up. All because A was allowed to expose 'this' before it was finished constructing. As I said, I'd be more in favor of tightening the rules, to disallow this-escapes like this, rather than broaden the conditions under which partially constucted 'this' references can escape. But we can't do that, so at least we shouldn't make the problem worse. This stuff is trickier than it looks. We should err on the side of making this stuff harder. On 3/14/2014 9:50 AM, David M. Lloyd wrote: > On 03/13/2014 05:00 PM, Archie Cobbs wrote: >> On Thu, Mar 13, 2014 at 5:21 AM, Peter Levart > > wrote: >> >> On 03/13/2014 11:08 AM, Peter Levart wrote: >> >> I don't see this as any more complex or unsafe as the rules for >> final fields. But I don't know if it is compatible with JVM >> rules. >> >> >> Does JVM have any rules for final instance fields regarding their >> definitive assignment at all non-exceptional exit paths of the >> constructor? >> >> >> My understanding is that the JVM doesn't care how many times you assign >> a final field in a constructor, it only cares that you don't try to >> assign it from within a non-constructor method. > [...] > >> Note also that the JVM spec specifically allows a constructor to assign >> final fields before invoking super()/this(). > > I think you're mistaken on both of these points... can you quote a > section of the JLS that says this? > From cushon at google.com Fri Mar 14 18:41:41 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 14 Mar 2014 11:41:41 -0700 Subject: compilation fails with 'no enclosing instance' error In-Reply-To: <5322130B.7070004@oracle.com> References: <52FC2BE5.9010903@oracle.com> <52FD62C5.7020006@oracle.com> <530F5A9D.9020900@oracle.com> <530F6AB1.1060608@oracle.com> <530F9B07.3030700@oracle.com> <530FAE54.9010106@oracle.com> <5322130B.7070004@oracle.com> Message-ID: Hi Vicente, That's great, thanks for the quick fix. Liam On Thu, Mar 13, 2014 at 1:20 PM, Vicente-Arturo Romero-Zaldivar < vicente.romero at oracle.com> wrote: > Hi Liam, > > The bug you reported has already been fixed in version 9. > > Thanks again for the bug report, > > Vicente > > changeset: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bd152504a538 > original bug report: https://bugs.openjdk.java.net/browse/JDK-8034924 > backport v9: https://bugs.openjdk.java.net/browse/JDK-8035432 > > > On 27/02/14 21:29, Vicente-Arturo Romero-Zaldivar wrote: > > On 27/02/14 21:14, Liam Miller-Cushon wrote: > > Got it, thanks for taking the time to explain. > > > np, and thanks to you. You was right that the problem was there which made > the search much easier. > > Vicente > > > > On Thu, Feb 27, 2014 at 12:07 PM, Vicente-Arturo Romero-Zaldivar < > vicente.romero at oracle.com> wrote: > >> On 27/02/14 17:23, Liam Miller-Cushon wrote: >> >> Well hiddenIn() is not used for methods only, also fields are >>> considered. >>> >> >> So hiddenIn() should search along the path from the class to the >> member's owner, and at each step search the superinterfaces of the current >> class? I think the only change from the current implementation would be >> terminating the search after reaching the owner. >> >> Thanks, >> Liam >> >> Yes that's the idea of the patch I'm working on and that's why I >> suggested that this was the reason of the problem :) As a side effect we >> may have some performance improvement. >> >> Vicente >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie at dellroad.org Fri Mar 14 22:09:50 2014 From: archie at dellroad.org (Archie Cobbs) Date: Fri, 14 Mar 2014 17:09:50 -0500 Subject: JLS tweaks In-Reply-To: <5323092D.7030101@redhat.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> Message-ID: On Fri, Mar 14, 2014 at 8:50 AM, David M. Lloyd wrote: > On 03/13/2014 05:00 PM, Archie Cobbs wrote: > >> On Thu, Mar 13, 2014 at 5:21 AM, Peter Levart > > wrote: >> >> On 03/13/2014 11:08 AM, Peter Levart wrote: >> >> I don't see this as any more complex or unsafe as the rules for >> final fields. But I don't know if it is compatible with JVM rules. >> >> >> Does JVM have any rules for final instance fields regarding their >> definitive assignment at all non-exceptional exit paths of the >> constructor? >> >> >> My understanding is that the JVM doesn't care how many times you assign >> a final field in a constructor, it only cares that you don't try to >> assign it from within a non-constructor method. >> > [...] > > > Note also that the JVM spec specifically allows a constructor to assign >> final fields before invoking super()/this(). >> > > I think you're mistaken on both of these points... can you quote a section > of the JLS that says this? > You said "JLS" ... not sure if that was just a typo not... I'm talking here about the JVM spec, not the JLS. I'm basing this on sect 4.10.2.4which says in part: The instance initialization method (?2.9) > for class myClass sees the new uninitialized object as its this argument > in local variable 0. Before that method invokes another instance > initialization method of myClass or its direct superclass on this, the > only operation the method can perform on this is assigning fields > declared within myClass. > That covers the second point (constructors can assign final fields prior to super()/this()). On the first point (final fields can be assigned more than once in a constructor) from what I can tell there is nothing in the JVM spec that explicitly prevents it. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie at dellroad.org Fri Mar 14 22:19:09 2014 From: archie at dellroad.org (Archie Cobbs) Date: Fri, 14 Mar 2014 17:19:09 -0500 Subject: JLS tweaks In-Reply-To: <5323188A.3030001@oracle.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> <5323188A.3030001@oracle.com> Message-ID: On Fri, Mar 14, 2014 at 9:56 AM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > May I remind folk that the compiler-dev mailing list is for discussions > about javac itself. It is not a place for language design discussions, or > for proposing changes to JLS. > > Language changes are done by JSRs, under the governance of the JCP. > Since I started this discussion ... my apologies if this is the wrong place. The reason I started here is because before the initial post I asked Joe Darcy where to start with proposals for language changes and he said use the JEP process... and according the JEP process documented in JEP 1: > Much of the work behind a successful JEP will, then, involve building > consensus for the proposal by convincing some Reviewers to review it and > some Group or Area Leads to endorse it. > > This process does not mandate any particular method for reaching that > goal. It is expected, however, that the typical new proposal will start as > an idea explored informally and shaken out within a specific Group, then > drafted as a JEP for further review and comment, then endorsed by that > Group's Lead and later the relevant Area Lead, and then submitted for > acceptance by the OpenJDK Lead. Discussions along the way will usually take > place in e-mail, but review meetings may be useful for particularly large > or contentious proposals. The results of any such meetings should be > reported to the JEP's discussion list for the record. > So this is the "start as an idea explored informally and shaken out within a specific Group" step. But JEP 1 also says: This process does not in any way supplant the Java Community Process. The > JCP remains the governing body for all standard Java SE APIs and related > interfaces. If a proposal accepted into this process intends to revise > existing standard interfaces, or to define new ones, then a parallel effort > to design, review, and approve those changes must be undertaken in the JCP, > either as part of a Maintenance Review of an existing JSR or in the context > of a new JSR. > So you're right there would also have to be a JSR as well. I have not gotten that far yet... and it doesn't seem appropriate to go there until the idea has been "sanity checked" by the folks who know the most about the JLS and would be impacted. I'm completely open to suggestions on how to proceed.. and hope other folks might also get interested in one or more of these ideas. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie at dellroad.org Fri Mar 14 23:34:15 2014 From: archie at dellroad.org (Archie Cobbs) Date: Fri, 14 Mar 2014 18:34:15 -0500 Subject: JLS tweaks In-Reply-To: <532318F5.90700@oracle.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> <532318F5.90700@oracle.com> Message-ID: Hi Brian, On Fri, Mar 14, 2014 at 9:57 AM, Brian Goetz wrote: > Regardless, "the JVM allows it, so the language should allow it" is > barking up the wrong tree. The JVM and language have deeply different > requirements, constraints, goals, and programmer audiences (the programmer > audience for the JVM is mostly compiler writers.) The JVM has this > flexibility not because we believe its a good idea to not initialize final > fields, but because offline compilation is a better place to enforce this > guideline than runtime. > I think the argument is more along the lines of: the JVM allows it, so if the JLS does not allow it there ought to be a good reason. A good reason would be e.g. "increases type safety". But that is not the case here. Nothing that bothers you about the existing semantics of how constructors work would be worsened by this change. If you don't agree, please give an example so I can better understand you. This "improvement" was deemed a bad idea in 2006 and is still a bad idea: > > https://bugs.openjdk.java.net/browse/JDK-4093999 > > That bug is interesting because the counter-arguments presented in the third comment (Alex Buckley 2006-11-21) can be completely countered by what we've already discussed here: (1) the analysis complexity is exactly the same as final fields, and the existing compiler code for that can be reused easily; (2) the counter-argument to "purely semantic" applies just as easily to final fields as it does to this proposal -- and look! we have the compiler doing "semantic checking" of final fields currently -- so why the double standard?? > Just because a lot of other people had the same bad idea, doesn't mean its > a good idea. > We agree on that principle.. but I don't agree that this is a bad idea. I think it's a good idea and it should have been in the language from the very start, as a parallel to what we have for final fields. It's fundamentally the same thing, just with 'this' instead of 'field'. Again, why should there be a double standard? As far as I can see, the only real argument raised in favor of this feature > is "the language already allows partially-constructed instances to be > exposed to arbitrary code, how much worse would it be if it exposed > even-less-constructed objects?" But this argument is a pretty silly one > (it basically says that unless one can enforce a safety goal 100%, the goal > has no legitimacy.) > I don't understand this and I'm not making that argument... can you please show an example of where this change would allow exposure of a less-constructed object than what the current JLS allows? This seems to be a key area of disagreement and I'd like to better understand what you're saying here. Please provide an example. As I've said before, I don't even like that instances methods can be called > from constructors, since they may still expose an object that has not been > completely constructed. For example: > > ... > > Now suppose that the event source sends a message really soon after > registration. B.onEvent() could see logger == null at line XXX. Ooops! > What went wrong? A exposed a partially constructed B from its > constructor, because the B initialization had not yet run when A's > constructor registered itself as a listener, even though it thought it was > all done initializing. B had no idea that A was a time bomb waiting to > blow up. All because A was allowed to expose 'this' before it was finished > constructing. > I actually agree with you here... the current rules may be too loose... and this exact think has led to obscure bugs in Java code that I've worked on over the years. Usually it involves the superclass constructor directly invoking an instance method that the subclass overrides, and the subclass override method uses instance fields that aren't initialized yet. Ha! What's ironic is that the proposal under discussion would allow you to address this problem: because the subclass could initialize it's final fields prior to invoking super(). See, this change makes things better rather than worse :) -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie at dellroad.org Sat Mar 15 23:01:02 2014 From: archie at dellroad.org (Archie Cobbs) Date: Sat, 15 Mar 2014 18:01:02 -0500 Subject: JLS tweaks In-Reply-To: <532318F5.90700@oracle.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> <532318F5.90700@oracle.com> Message-ID: Hi Brian, On Fri, Mar 14, 2014 at 9:57 AM, Brian Goetz wrote: > As far as I can see, the only real argument raised in favor of this > feature is "the language already allows partially-constructed instances to > be exposed to arbitrary code, how much worse would it be if it exposed > even-less-constructed objects?" This comment made me realize this discussion is getting sideways. There is one very simple and powerful argument in favor of this feature: it would make life better for Java programmers. They would not have to jump through ridiculous contortions to get their super() parameters in order all in one statement. They would not have to choose between redundantly calculating the same result vs. having to use factory methods instead of constructors. I have talked to several day-to-day programmers and every single one expressed displeasure with this "super() first" restriction... everything from "yeah that annoys me" to various unprintables. As a small objective data point, this stackoverflow question("why does this() and super() have to be the first statement in a constructor?") has been upvoted 153 times. These folks are not language theoreticians, but they are all intuitively smart enough understand that the current syntax-based rule is too restrictive. Constructors should be allowed more room to get their parameters in order prior to invoking super()/this(). It's obvious to anyone who writes Java code for a living. And FWIW, in my personal experience writing Java code over the past 15+ years, this is my number one annoyance with the JLS. I'm spending time pushing this because I believe in "stop complaining and do something about it". But trust me I'm representing lots of other folks too. Of course, JLS change decisions should made by reasoned analysis, not mob rule. But to say there's no argument in favor of this proposal is just being in denial. Moreover, there are many small JLS changes in Java 7 and Java 8 that had a much smaller benefit to the programmer than this one, yet were still approved. So I think the burden of proof here is on YOU any any other naysayers - to demonstrate even just one good argument why we should NOT remove this restriction. As soon as I hear one I'll drop it! But so far here is what I've heard you and others say: 1. We already rejected that idea. This is not, per se, relevant. However, if you can go back and retrieve a good reason against this idea, fine - let's hear it. Or are you saying that it's impossible previous decisions could be wrong? I don't think you're saying that... otherwise there would be no such thing as JSR process. Or, are you implying that it would be too embarrassing for members of the JLS team to been seen changing their minds on something. Well, I was under the impression we optimizing here based on objective, technical language criteria, not bureaucratic nonsense or saving face. And in any case, those earlier suggestions may have been slightly different from this one, e.g., in ways that actually would weaken type security. I'm certain that this one, however, does not, so let's stay focused on it. 2. This makes an already questionable type safety worse. Not true Now, I agree with you that the existing constructor type safety situation has some flaws. Trust me, I am personally a big fan of Java's strong type safety - it's why I use Java instead of python or whatever. However, you are wrong to let dissatisfaction with the current situation bleed over into this proposal. This proposal has absolutely no relation to, or negative effect on, the problems you have described - on the contrary, the very example you gave (constructor registering listener) can be fixed by allowing this change! This proposal does not weaken type safety one iota, in fact it makes it slightly better. I've asked for an example of how this change would make type safety worse but you have not provided one. That's because anyone can see with a moment's reflection that no such example exists... because the proposed change does not allow you to "do anything" with 'this' prior to initialization. Perhaps you had in mind a previous, slightly different version of this proposal at first. I'm sure you've seen many variants. Here's another way to look at it: any code that takes advantage of this relaxed restriction can be transformed into equivalent code legal under the current JLS, by "uninlining" all the code prior to super()/this() and moving it into every constructor call site, and adding additional constructor parameter(s). For example, this: public Foo(boolean b) { int x = b ? 4 : 5; super(x); } public void caller1() { new Foo(true); } public void caller2() { new Foo(false); } is equivalent to this: public Foo(boolean b, int x) { super(x); } public void caller1() { int x = true ? 4 : 5; new Foo(true, x); } public void caller2() { int x = false ? 4 : 5; x = new Foo(false, x); } Therefore it can't possibly be any less type safe than what we currently have. So this objection needs to be put to rest. Either provide an example of how this proposal makes the current situation any worse, or agree that one doesn't exist so we can move forward. 3. Too much additional compiler complexity This is easily debunked. The very same criteria and existing compiler code that implements the current 'final' assignment logic ("initialize exactly once, and only use after initialization") can be re-used to implement this feature. So in summary, we have at least one good reason to remove this restriction (people are demanding it), maybe two (allows an improvement in type safety when the superclass constructor invokes overridden method(s)), and zero reasons not to remove it. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From eaftan at google.com Mon Mar 17 23:37:52 2014 From: eaftan at google.com (Eddie Aftandilian) Date: Mon, 17 Mar 2014 16:37:52 -0700 Subject: Users encountering bug JDK-7101822 Message-ID: Hi, Over the past few months we've received several reports of instances of bug JDK-7101822. Can I ask what is the status of that bug? Do you plan to fix it in a javac 8 update, or in javac 9? Thanks, Eddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Mar 18 00:16:46 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 17 Mar 2014 17:16:46 -0700 Subject: Users encountering bug JDK-7101822 In-Reply-To: References: Message-ID: <5327906E.6060903@oracle.com> Eddie, We've definitely got stuff on the list to improve import handling for 9. -- Jon On 03/17/2014 04:37 PM, Eddie Aftandilian wrote: > Hi, > > Over the past few months we've received several reports of instances > of bug JDK-7101822. Can I ask what is the status of that bug? Do you > plan to fix it in a javac 8 update, or in javac 9? > > Thanks, > Eddie From jan.lahoda at oracle.com Tue Mar 18 19:59:38 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 18 Mar 2014 20:59:38 +0100 Subject: RFR: JDK-8035890 - jdk8 javac -source 7 compiles test case it should not Message-ID: <5328A5AA.6080703@oracle.com> Hello, I'd like to ask for a review of a patch for: https://bugs.openjdk.java.net/browse/JDK-8035890 (for JDK9 and backport to JDK8u) The patch is here: http://cr.openjdk.java.net/~jlahoda/8035890/webrev.01/ The bug is that, when -source 7 is used, javac does not in some cases properly report errors for Java 8 constructs related to type annotations. The fix covers two cases: First, consider this code: --- import java.lang.annotation.*; public class AnnotCopiedToAnonymous { private Object o1 = new @Annot Object(); private Object o2 = new @Annot Object() { }; } @Target(ElementType.TYPE_USE) @interface Annot { } --- The problem here is that JavacParser.creator parses the annotations as declaration annotations, which does not perform the source level check for source >= 8. The proposed patch changes the parser to parse the annotations as type annotations, which ensures the source level check is performed correctly (and also changes the tree kinds for the annotations to TYPE_ANNOTATION). An alternate solution would be to keep the current way of parsing these annotations, and add an explicit source level check, if that would be more appropriate. The second case is like this: --- public class AnnotAfterTypeParams { public @Decl int foo() { return 0; } } @interface Decl { } --- With -source 8, declaration annotations are accepted after method's type parameters, so reusing the same error as for type annotations did not seem appropriate, so I've added a new error when this situation is detected with -source 7. Any comments are very welcome. Thanks, Jan From andreas.lundblad at oracle.com Wed Mar 19 08:49:40 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 19 Mar 2014 09:49:40 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten Message-ID: <20140319084939.GA17590@e6430> Hi compiler-dev + build-dev, Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to sjavac (option handling) and dev/ + dev/jdk build files. Description: - Sjavac relied on passing around the main arg array to whatever part of the code that were potentially affected by command line options. The patch restructures the code so that all option are validated and parsed up front. - A recent commit in the JDK repository exposed another sjavac bug caused by having directory names that were not valid package identifiers. The patch changes sjavac to handle directories instead of packages... - ...which required modifying a couple of .gmk so that arguments are passed as directories (separated by "/") instead of packages (separated with ".") - Finally the patch adds a couple of unit tests which cover the new code. Link to webrevs: http://cr.openjdk.java.net/~alundblad/8035063/ - dev build (dev/make/common/JavaCompilation.gmk) - jdk build (dev/jdk/make/CompileJavaClasses.gmk) - langtools (the sjavac changes + tests) Links to bug reports: https://bugs.openjdk.java.net/browse/JDK-8035063 https://bugs.openjdk.java.net/browse/JDK-8037085 -- Andreas From erik.joelsson at oracle.com Wed Mar 19 09:03:33 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Mar 2014 10:03:33 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319084939.GA17590@e6430> References: <20140319084939.GA17590@e6430> Message-ID: <53295D65.7040707@oracle.com> Hello, The input from our makefiles changes from "-i some.package" to "-i some/package/*". IIRC the include flag works recursively for sub packages. Will the single * do the same? /Erik On 2014-03-19 09:49, Andreas Lundblad wrote: > Hi compiler-dev + build-dev, > > Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to sjavac (option handling) and dev/ + dev/jdk build files. > > > Description: > > - Sjavac relied on passing around the main arg array to whatever part of the code that were potentially affected by command line options. The patch restructures the code so that all option are validated and parsed up front. > > - A recent commit in the JDK repository exposed another sjavac bug caused by having directory names that were not valid package identifiers. The patch changes sjavac to handle directories instead of packages... > > - ...which required modifying a couple of .gmk so that arguments are passed as directories (separated by "/") instead of packages (separated with ".") > > - Finally the patch adds a couple of unit tests which cover the new code. > > > Link to webrevs: > http://cr.openjdk.java.net/~alundblad/8035063/ > - dev build (dev/make/common/JavaCompilation.gmk) > - jdk build (dev/jdk/make/CompileJavaClasses.gmk) > - langtools (the sjavac changes + tests) > > > Links to bug reports: > https://bugs.openjdk.java.net/browse/JDK-8035063 > https://bugs.openjdk.java.net/browse/JDK-8037085 > > -- Andreas From andreas.lundblad at oracle.com Wed Mar 19 10:17:58 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 19 Mar 2014 11:17:58 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <53295D65.7040707@oracle.com> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> Message-ID: <20140319101757.GA3230@e6430> On Wed, Mar 19, 2014 at 10:03:33AM +0100, Erik Joelsson wrote: > Hello, > > The input from our makefiles changes from "-i some.package" to "-i > some/package/*". IIRC the include flag works recursively for sub > packages. Will the single * do the same? > > /Erik That's strange. What used to be "-i some.package" should now be "-i some/package". The -i works recursively only if the pattern ends with a '*'. I did however log all patterns that were given as arguments to -i during a 'make clean images' and all those patterns ended with a '.*'. (Maby I missed some patterns somewhere?) Regardless, if something that used to be "some.package" and is now "some/package/*", I'd say it's a bug. -- Andreas From erik.joelsson at oracle.com Wed Mar 19 11:29:03 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Mar 2014 12:29:03 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319101757.GA3230@e6430> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> Message-ID: <53297F7F.7080002@oracle.com> Ah, I see now, it was "-i some.package.*" in the original code. Build part looks good to me now. /Erik On 2014-03-19 11:17, Andreas Lundblad wrote: > On Wed, Mar 19, 2014 at 10:03:33AM +0100, Erik Joelsson wrote: >> Hello, >> >> The input from our makefiles changes from "-i some.package" to "-i >> some/package/*". IIRC the include flag works recursively for sub >> packages. Will the single * do the same? >> >> /Erik > That's strange. What used to be "-i some.package" should now be "-i some/package". > > The -i works recursively only if the pattern ends with a '*'. > > I did however log all patterns that were given as arguments to -i during a 'make clean images' and all those patterns ended with a '.*'. (Maby I missed some patterns somewhere?) > > Regardless, if something that used to be "some.package" and is now "some/package/*", I'd say it's a bug. > > -- Andreas From oehrstroem at gmail.com Wed Mar 19 12:58:21 2014 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 19 Mar 2014 13:58:21 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <53297F7F.7080002@oracle.com> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> <53297F7F.7080002@oracle.com> Message-ID: The code by itself looks good. However I think that changing from . to / is a really bad idea. If someone committed a package directory that does not map correctly to the package name, then that is a major problem. You will not find that source through -sourcepath, which means that you just broke sjavac ability to compile using multiple threads. This is just as bad as when Nashorn tried to insert $ into java source file names! The horror, the horror. I.e. do not replace . with /. Fix the problem in the jdk. //Fredrik 2014-03-19 12:29 GMT+01:00 Erik Joelsson : > Ah, I see now, it was "-i some.package.*" in the original code. Build part > looks good to me now. > > /Erik > > > On 2014-03-19 11:17, Andreas Lundblad wrote: > >> On Wed, Mar 19, 2014 at 10:03:33AM +0100, Erik Joelsson wrote: >> >>> Hello, >>> >>> The input from our makefiles changes from "-i some.package" to "-i >>> some/package/*". IIRC the include flag works recursively for sub >>> packages. Will the single * do the same? >>> >>> /Erik >>> >> That's strange. What used to be "-i some.package" should now be "-i >> some/package". >> >> The -i works recursively only if the pattern ends with a '*'. >> >> I did however log all patterns that were given as arguments to -i during >> a 'make clean images' and all those patterns ended with a '.*'. (Maby I >> missed some patterns somewhere?) >> >> Regardless, if something that used to be "some.package" and is now >> "some/package/*", I'd say it's a bug. >> >> -- Andreas >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Wed Mar 19 13:32:09 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 19 Mar 2014 14:32:09 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> <53297F7F.7080002@oracle.com> Message-ID: <20140319133208.GC3230@e6430> On Wed, Mar 19, 2014 at 01:58:21PM +0100, Fredrik ?hrstr?m wrote: > The code by itself looks good. However I think that changing from . to / is > a really bad idea. > > If someone committed a package directory that does not map correctly to the > package name, then that is a major problem. You will not find that source > through -sourcepath, which means that you just broke sjavac ability to > compile using multiple threads. This is just as bad as when Nashorn tried > to insert $ into java source file names! The horror, the horror. > > I.e. do not replace . with /. Fix the problem in the jdk. In this case, the directory did not contain any source files, just a bunch of resources for documentation, such as .gif-files. (How could it contain source files? A package may not contain a '-'.) So unless I misunderstood you, there should therefore be no problem in this case. I would prefer to see -i and -x as filters on what directories (not packages) exists in the subsequent source root: This is more in line with other options (-if, -xf, -src, ...) which all talk about paths and more general since each package corresponds to a directory, but only some directories correspond to packages. - Andreas From magnus.ihse.bursie at oracle.com Wed Mar 19 13:57:13 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Mar 2014 14:57:13 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319084939.GA17590@e6430> References: <20140319084939.GA17590@e6430> Message-ID: <5329A239.5040204@oracle.com> On 2014-03-19 09:49, Andreas Lundblad wrote: > Hi compiler-dev + build-dev, > > Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to sjavac (option handling) and dev/ + dev/jdk build files. The build part looks good to me. /Magnus From erik.joelsson at oracle.com Wed Mar 19 13:58:51 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Mar 2014 14:58:51 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319133208.GC3230@e6430> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> <53297F7F.7080002@oracle.com> <20140319133208.GC3230@e6430> Message-ID: <5329A29B.90804@oracle.com> I should fill in that the background for this change is that there are a bunch of directories named "doc-files" in the classes source dir. They have been there a long time. These contain html and gif files (mainly) that shouldn't get copied into the output classes directory. In a recent cleanup of the copy mechanism, I changed the copy rules to by default include html and gif files and explicitly exclude those that shouldn't be included, rather than explicitly listing what should be copied. Because of this, we now have the following exclude rules: # These directories should not be copied at all EXCLUDES += \ com/sun/org/apache/xml/internal/security/resource/schema \ java/awt/doc-files \ java/lang/doc-files \ javax/swing/doc-files \ javax/swing/text/doc-files \ javax/swing/plaf/synth/doc-files \ javax/swing/undo/doc-files \ sun/awt/X11/doc-files \ sun/util/cldr/resources \ # When building with sjavac, these get translated to "-e java.awt.doc-files.*" which sjavac does not accept, because doc-files are not proper package names. Another possible fix would be to filter out non valid package names from the excludes sent to sjavac. /Erik On 2014-03-19 14:32, Andreas Lundblad wrote: > On Wed, Mar 19, 2014 at 01:58:21PM +0100, Fredrik ?hrstr?m wrote: >> The code by itself looks good. However I think that changing from . to / is >> a really bad idea. >> >> If someone committed a package directory that does not map correctly to the >> package name, then that is a major problem. You will not find that source >> through -sourcepath, which means that you just broke sjavac ability to >> compile using multiple threads. This is just as bad as when Nashorn tried >> to insert $ into java source file names! The horror, the horror. >> >> I.e. do not replace . with /. Fix the problem in the jdk. > In this case, the directory did not contain any source files, just a bunch of resources for documentation, such as .gif-files. (How could it contain source files? A package may not contain a '-'.) So unless I misunderstood you, there should therefore be no problem in this case. > > I would prefer to see -i and -x as filters on what directories (not packages) exists in the subsequent source root: This is more in line with other options (-if, -xf, -src, ...) which all talk about paths and more general since each package corresponds to a directory, but only some directories correspond to packages. > > - Andreas From jonathan.gibbons at oracle.com Wed Mar 19 16:19:42 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 19 Mar 2014 09:19:42 -0700 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <5329A29B.90804@oracle.com> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> <53297F7F.7080002@oracle.com> <20140319133208.GC3230@e6430> <5329A29B.90804@oracle.com> Message-ID: <5329C39E.5040109@oracle.com> I think sjavac should filter out all directories which could not correspond to package names. -- Jon On 03/19/2014 06:58 AM, Erik Joelsson wrote: > I should fill in that the background for this change is that there are > a bunch of directories named "doc-files" in the classes source dir. > They have been there a long time. These contain html and gif files > (mainly) that shouldn't get copied into the output classes directory. > > In a recent cleanup of the copy mechanism, I changed the copy rules to > by default include html and gif files and explicitly exclude those > that shouldn't be included, rather than explicitly listing what should > be copied. Because of this, we now have the following exclude rules: > > # These directories should not be copied at all > EXCLUDES += \ > com/sun/org/apache/xml/internal/security/resource/schema \ > java/awt/doc-files \ > java/lang/doc-files \ > javax/swing/doc-files \ > javax/swing/text/doc-files \ > javax/swing/plaf/synth/doc-files \ > javax/swing/undo/doc-files \ > sun/awt/X11/doc-files \ > sun/util/cldr/resources \ > # > > When building with sjavac, these get translated to "-e > java.awt.doc-files.*" which sjavac does not accept, because doc-files > are not proper package names. Another possible fix would be to filter > out non valid package names from the excludes sent to sjavac. > > /Erik > > On 2014-03-19 14:32, Andreas Lundblad wrote: >> On Wed, Mar 19, 2014 at 01:58:21PM +0100, Fredrik ?hrstr?m wrote: >>> The code by itself looks good. However I think that changing from . >>> to / is >>> a really bad idea. >>> >>> If someone committed a package directory that does not map correctly >>> to the >>> package name, then that is a major problem. You will not find that >>> source >>> through -sourcepath, which means that you just broke sjavac ability to >>> compile using multiple threads. This is just as bad as when Nashorn >>> tried >>> to insert $ into java source file names! The horror, the horror. >>> >>> I.e. do not replace . with /. Fix the problem in the jdk. >> In this case, the directory did not contain any source files, just a >> bunch of resources for documentation, such as .gif-files. (How could >> it contain source files? A package may not contain a '-'.) So unless >> I misunderstood you, there should therefore be no problem in this case. >> >> I would prefer to see -i and -x as filters on what directories (not >> packages) exists in the subsequent source root: This is more in line >> with other options (-if, -xf, -src, ...) which all talk about paths >> and more general since each package corresponds to a directory, but >> only some directories correspond to packages. >> >> - Andreas > From oehrstroem at gmail.com Thu Mar 20 09:00:55 2014 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Thu, 20 Mar 2014 10:00:55 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <5329C39E.5040109@oracle.com> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> <53297F7F.7080002@oracle.com> <20140319133208.GC3230@e6430> <5329A29B.90804@oracle.com> <5329C39E.5040109@oracle.com> Message-ID: Ok, Eriks explanation makes sense. There might also be situations where you want to exclude/include copying META-INF files and such, that reside in non-package directories. So, changing from . to / is ok. In particular since sjavac cleverly detects and reports an error, if a source file is in the wrong package directory. See JavaCompilerWithDeps.java at the end, so there is already protection against messing up the source tree. :-) //Fredrik 2014-03-19 17:19 GMT+01:00 Jonathan Gibbons : > I think sjavac should filter out all directories which could not > correspond to package names. > > -- Jon > > > On 03/19/2014 06:58 AM, Erik Joelsson wrote: > >> I should fill in that the background for this change is that there are a >> bunch of directories named "doc-files" in the classes source dir. They have >> been there a long time. These contain html and gif files (mainly) that >> shouldn't get copied into the output classes directory. >> >> In a recent cleanup of the copy mechanism, I changed the copy rules to by >> default include html and gif files and explicitly exclude those that >> shouldn't be included, rather than explicitly listing what should be >> copied. Because of this, we now have the following exclude rules: >> >> # These directories should not be copied at all >> EXCLUDES += \ >> com/sun/org/apache/xml/internal/security/resource/schema \ >> java/awt/doc-files \ >> java/lang/doc-files \ >> javax/swing/doc-files \ >> javax/swing/text/doc-files \ >> javax/swing/plaf/synth/doc-files \ >> javax/swing/undo/doc-files \ >> sun/awt/X11/doc-files \ >> sun/util/cldr/resources \ >> # >> >> When building with sjavac, these get translated to "-e >> java.awt.doc-files.*" which sjavac does not accept, because doc-files are >> not proper package names. Another possible fix would be to filter out non >> valid package names from the excludes sent to sjavac. >> >> /Erik >> >> On 2014-03-19 14:32, Andreas Lundblad wrote: >> >>> On Wed, Mar 19, 2014 at 01:58:21PM +0100, Fredrik ?hrstr?m wrote: >>> >>>> The code by itself looks good. However I think that changing from . to >>>> / is >>>> a really bad idea. >>>> >>>> If someone committed a package directory that does not map correctly to >>>> the >>>> package name, then that is a major problem. You will not find that >>>> source >>>> through -sourcepath, which means that you just broke sjavac ability to >>>> compile using multiple threads. This is just as bad as when Nashorn >>>> tried >>>> to insert $ into java source file names! The horror, the horror. >>>> >>>> I.e. do not replace . with /. Fix the problem in the jdk. >>>> >>> In this case, the directory did not contain any source files, just a >>> bunch of resources for documentation, such as .gif-files. (How could it >>> contain source files? A package may not contain a '-'.) So unless I >>> misunderstood you, there should therefore be no problem in this case. >>> >>> I would prefer to see -i and -x as filters on what directories (not >>> packages) exists in the subsequent source root: This is more in line with >>> other options (-if, -xf, -src, ...) which all talk about paths and more >>> general since each package corresponds to a directory, but only some >>> directories correspond to packages. >>> >>> - Andreas >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Thu Mar 20 09:01:08 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Thu, 20 Mar 2014 02:01:08 -0700 (PDT) Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten Message-ID: Do you mean it should filter out directories with, say dashes, automatically? My feeling is that that's a brittle approach. If someone renames a directory from something that doesn't happen to be a valid package identifier into something that happens to be a valid package identifier, it could break the build. (Despite there were no trace of the original package name in the build files.) Having to explicitly exclude all directories that shouldn't be part of the build (not just the ones that happen to have valid package names) seems more robust to me. -- Andreas ----- Original Message ----- From: jonathan.gibbons at oracle.com To: compiler-dev at openjdk.java.net Sent: Wednesday, March 19, 2014 5:20:10 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR: 8035063: Option handling in sjavac needs to be rewritten I think sjavac should filter out all directories which could not correspond to package names. -- Jon From ralucas at google.com Thu Mar 20 19:15:36 2014 From: ralucas at google.com (Raluca Sauciuc) Date: Thu, 20 Mar 2014 12:15:36 -0700 Subject: Optimizations around sources used only for linking Message-ID: Hi, I have a question about sjavac and its parallel compilation model. In JDK7, source files used only for linking, even with -implicit:none, are going though ATTR, FLOW, etc. just like the sources to be compiled. This can be very expensive and unnecessary (attribution and type checking can also require the resolution of other types, etc). Is sjavac taking advantage of any optimizations in this regard? If yes, any pointers to code or changesets would be great. Thank you, Raluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Mar 20 20:23:43 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Mar 2014 13:23:43 -0700 Subject: Optimizations around sources used only for linking In-Reply-To: References: Message-ID: <532B4E4F.5080005@oracle.com> Hi, See http://hg.openjdk.java.net/jdk9/dev/langtools/rev/37cf13ea5cf9 This change is in mainstream JDK 9 javac. -- Jon On 03/20/2014 12:15 PM, Raluca Sauciuc wrote: > Hi, > > I have a question about sjavac and its parallel compilation model. > > In JDK7, source files used only for linking, even with -implicit:none, > are going though ATTR, FLOW, etc. just like the sources to be > compiled. This can be very expensive and unnecessary (attribution and > type checking can also require the resolution of other types, etc). > > Is sjavac taking advantage of any optimizations in this regard? If > yes, any pointers to code or changesets would be great. > > Thank you, > Raluca From joel.franck at oracle.com Fri Mar 21 09:50:27 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 21 Mar 2014 10:50:27 +0100 Subject: javac8 annotation processors don't visit parameter annotations In-Reply-To: References: Message-ID: <20140321095027.GD3061@oracle.com> Hi Liam, Thanks! I filed https://bugs.openjdk.java.net/browse/JDK-8038080 I intend to submit your fix for 9 and 8u20. cheers /Joel On 2014-03-05, Liam Miller-Cushon wrote: > There appears to be a javac8 bug that prevents annotation processors from > visiting annotations on parameters. When repeated annotations were > implemented [1][2] the annotation scanners in JavacProcessingEnvironment > and JavacRoundEnvironment were modified and the following override was > added: > > @Override > public Set visitExecutable(ExecutableElement e, > Set p) { > // Type parameters are not considered to be enclosed by an executable > scan(e.getTypeParameters(), p); > return scan(e.getEnclosedElements(), p); > } > > MethodSymbols don't have any enclosed elements, but they do have parameters > (which currently aren't being visited). I think that line was meant to > match the base implementation in ElementScanner: > > return scan(e.getParameters(), p); > > > [1] https://bugs.openjdk.java.net/browse/JDK-7162089 > [2] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/1908e86ee49a From joel.franck at oracle.com Fri Mar 21 14:52:37 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 21 Mar 2014 15:52:37 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319084939.GA17590@e6430> References: <20140319084939.GA17590@e6430> Message-ID: <20140321145237.GE3061@oracle.com> Hi, On 2014-03-19, Andreas Lundblad wrote: > Hi compiler-dev + build-dev, > > Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to sjavac (option handling) and dev/ + dev/jdk build files. > > > Description: > > - Sjavac relied on passing around the main arg array to whatever part of the code that were potentially affected by command line options. The patch restructures the code so that all option are validated and parsed up front. > > - A recent commit in the JDK repository exposed another sjavac bug caused by having directory names that were not valid package identifiers. The patch changes sjavac to handle directories instead of packages... > > - ...which required modifying a couple of .gmk so that arguments are passed as directories (separated by "/") instead of packages (separated with ".") > > - Finally the patch adds a couple of unit tests which cover the new code. > > > Link to webrevs: > http://cr.openjdk.java.net/~alundblad/8035063/ > - dev build (dev/make/common/JavaCompilation.gmk) > - jdk build (dev/jdk/make/CompileJavaClasses.gmk) > - langtools (the sjavac changes + tests) > > > Links to bug reports: > https://bugs.openjdk.java.net/browse/JDK-8035063 > https://bugs.openjdk.java.net/browse/JDK-8037085 > I think this looks good. In the future, if we need the ability to exclude packages we can add it back (-xp or something like it), but we currently don't need it. cheers /Joel From cushon at google.com Fri Mar 21 16:51:40 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 21 Mar 2014 09:51:40 -0700 Subject: javac8 annotation processors don't visit parameter annotations In-Reply-To: <20140321095027.GD3061@oracle.com> References: <20140321095027.GD3061@oracle.com> Message-ID: Thanks Joel, that's great. Liam On Fri, Mar 21, 2014 at 2:50 AM, Joel Borggren-Franck < joel.franck at oracle.com> wrote: > Hi Liam, > > Thanks! > > I filed https://bugs.openjdk.java.net/browse/JDK-8038080 > > I intend to submit your fix for 9 and 8u20. > > cheers > /Joel > > On 2014-03-05, Liam Miller-Cushon wrote: > > There appears to be a javac8 bug that prevents annotation processors from > > visiting annotations on parameters. When repeated annotations were > > implemented [1][2] the annotation scanners in JavacProcessingEnvironment > > and JavacRoundEnvironment were modified and the following override was > > added: > > > > @Override > > public Set visitExecutable(ExecutableElement e, > > Set p) { > > // Type parameters are not considered to be enclosed by an executable > > scan(e.getTypeParameters(), p); > > return scan(e.getEnclosedElements(), p); > > } > > > > MethodSymbols don't have any enclosed elements, but they do have > parameters > > (which currently aren't being visited). I think that line was meant to > > match the base implementation in ElementScanner: > > > > return scan(e.getParameters(), p); > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-7162089 > > [2] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/1908e86ee49a > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boaznahum at gmail.com Sun Mar 23 12:29:43 2014 From: boaznahum at gmail.com (Boaz Nahum) Date: Sun, 23 Mar 2014 14:29:43 +0200 Subject: Compiler crash with -parameters - need help to open a bug Message-ID: When compiling our code with '-parameters' (1.8.0_20-ea and 1.8.0-b132), we got this exception: An exception has occurred in the compiler (1.8.0). Please file a bug at the Java Developer/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.ClassCastException: java.lang.String cannot be cast to com.sun.tools.javac.util.Name at com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) at com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) at com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) at com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) at com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) at com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) at com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) at com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) at com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) at com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) at com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) at com.sun.tools.javac.comp.Enter.complete(Enter.java:497) at com.sun.tools.javac.comp.Enter.main(Enter.java:475) at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) at com.sun.tools.javac.main.Main.compile(Main.java:523) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:56) at com.sun.tools.javac.Main.main(Main.java:42) Thanks Boaz In order to isolate the problematic code, I add -XDverboseCompilePolicy and -Xdiags:verbose, without luck. Why they are ignored ? Please note that an annotation processor is involved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From boaznahum at gmail.com Sun Mar 23 12:40:01 2014 From: boaznahum at gmail.com (Boaz Nahum) Date: Sun, 23 Mar 2014 14:40:01 +0200 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: References: Message-ID: Actaully '-XDverboseCompilePolicy and -Xdiags:verbose' are not ignored, it is just that the exception occurs too early. If I remove '-parameters' then they do the work .... On Sun, Mar 23, 2014 at 2:29 PM, Boaz Nahum wrote: > When compiling our code with '-parameters' (1.8.0_20-ea and 1.8.0-b132), > we got this exception: > > An exception has occurred in the compiler (1.8.0). Please file a bug at > the Java Developer/bugreport) after checking the Bug Parade for > duplicates. Include your program and the following diagnostic in your > report. Thank you. > java.lang.ClassCastException: java.lang.String cannot be cast to > com.sun.tools.javac.util.Name > at > com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) > at > com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) > at > com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) > at > com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) > at > com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) > at > com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) > at > com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) > at > com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) > at > com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) > at > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) > at > com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) > at com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) > at > com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) > at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) > at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) > at > com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) > at com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) > at com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) > at > com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) > at > com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) > at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) > at > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) > at > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) > at > com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) > at > com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) > at > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) > at > com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) > at > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) > at com.sun.tools.javac.comp.Enter.complete(Enter.java:497) > at com.sun.tools.javac.comp.Enter.main(Enter.java:475) > at > com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) > at > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:56) > at com.sun.tools.javac.Main.main(Main.java:42) > > > Thanks > Boaz > > > > In order to isolate the problematic code, I add -XDverboseCompilePolicy > and -Xdiags:verbose, without luck. > Why they are ignored ? > > Please note that an annotation processor is involved. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Sun Mar 23 19:18:30 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Sun, 23 Mar 2014 19:18:30 +0000 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: References: Message-ID: <532F3386.5070901@oracle.com> Hi Boaz, Do you have an isolated test case? Thanks, Vicente On 23/03/14 12:40, Boaz Nahum wrote: > Actaully '-XDverboseCompilePolicy and -Xdiags:verbose' are not > ignored, it is just that the exception occurs too early. If I remove > '-parameters' then they do the work .... > > > On Sun, Mar 23, 2014 at 2:29 PM, Boaz Nahum > wrote: > > When compiling our code with '-parameters' (1.8.0_20-ea and > 1.8.0-b132), we got this exception: > > An exception has occurred in the compiler (1.8.0). Please file a > bug at the Java Developer/bugreport) after checking the Bug > Parade for duplicates. Include your program and the following > diagnostic in your report. Thank you. > java.lang.ClassCastException: java.lang.String cannot be cast > to com.sun.tools.javac.util.Name > > at > com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) > at > com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) > at > com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) > at > com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) > at > com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) > at > com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) > at > com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) > at > com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) > at > com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) > at > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) > at > com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) > at > com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) > at > com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) > at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) > at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) > at > com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) > at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) > at com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) > at com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) > at > com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) > at > com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) > at > com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) > at > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) > at > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) > at > com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) > at > com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) > at > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) > at > com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) > at > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) > at com.sun.tools.javac.comp.Enter.complete(Enter.java:497) > at com.sun.tools.javac.comp.Enter.main(Enter.java:475) > at > com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) > at > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:56) > at com.sun.tools.javac.Main.main(Main.java:42) > > > Thanks > Boaz > > > > In order to isolate the problematic code, I add > -XDverboseCompilePolicy and -Xdiags:verbose, without luck. > Why they are ignored ? > > Please note that an annotation processor is involved. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boaznahum at gmail.com Mon Mar 24 07:10:44 2014 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 24 Mar 2014 09:10:44 +0200 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: <532F3386.5070901@oracle.com> References: <532F3386.5070901@oracle.com> Message-ID: That what I'm asking help for - to isolate the problematic source. But from what I learnt - it is combination of source and dependencies. The same source ***passed*** if it is complied with a dependency that wasn't compile with "-parameters". What I need is a flag (or a patch) that causes the compiler to emit verbose information Thanks Boaz On Mar 23, 2014 9:18 PM, "Vicente-Arturo Romero-Zaldivar" < vicente.romero at oracle.com> wrote: > Hi Boaz, > > Do you have an isolated test case? > > Thanks, > Vicente > > On 23/03/14 12:40, Boaz Nahum wrote: > > Actaully '-XDverboseCompilePolicy and -Xdiags:verbose' are not ignored, it > is just that the exception occurs too early. If I remove '-parameters' then > they do the work .... > > > On Sun, Mar 23, 2014 at 2:29 PM, Boaz Nahum wrote: > >> When compiling our code with '-parameters' (1.8.0_20-ea and >> 1.8.0-b132), we got this exception: >> >> An exception has occurred in the compiler (1.8.0). Please file a bug at >> the Java Developer/bugreport) after checking the Bug Parade for >> duplicates. Include your program and the following diagnostic in your >> report. Thank you. >> java.lang.ClassCastException: java.lang.String cannot be cast to >> com.sun.tools.javac.util.Name >> at >> com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) >> at >> com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) >> at >> com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) >> at >> com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) >> at >> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) >> at >> com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) >> at >> com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) >> at >> com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) >> at >> com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) >> at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >> at >> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >> at >> com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) >> at com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) >> at >> com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) >> at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) >> at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) >> at >> com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) >> at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) >> at com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) >> at com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) >> at >> com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) >> at >> com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) >> at >> com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) >> at >> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >> at >> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) >> at >> com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) >> at >> com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) >> at >> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >> at >> com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) >> at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >> at >> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >> at com.sun.tools.javac.comp.Enter.complete(Enter.java:497) >> at com.sun.tools.javac.comp.Enter.main(Enter.java:475) >> at >> com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) >> at >> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) >> at com.sun.tools.javac.main.Main.compile(Main.java:523) >> at com.sun.tools.javac.main.Main.compile(Main.java:381) >> at com.sun.tools.javac.main.Main.compile(Main.java:370) >> at com.sun.tools.javac.main.Main.compile(Main.java:361) >> at com.sun.tools.javac.Main.compile(Main.java:56) >> at com.sun.tools.javac.Main.main(Main.java:42) >> >> >> Thanks >> Boaz >> >> >> >> In order to isolate the problematic code, I add -XDverboseCompilePolicy >> and -Xdiags:verbose, without luck. >> Why they are ignored ? >> >> Please note that an annotation processor is involved. >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Mar 24 11:24:31 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Mon, 24 Mar 2014 11:24:31 +0000 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: References: <532F3386.5070901@oracle.com> Message-ID: <533015EF.8090703@oracle.com> Hi Boaz, OK it seems like we both need more information :) What version of javac is this? Can you get the last javac from http://hg.openjdk.java.net/jdk9/dev/langtools/ and try to reproduce the issue? Do you get any meaningful information after executing javac with plain "-verbose" option? Thanks, Vicente On 24/03/14 07:10, Boaz Nahum wrote: > > That what I'm asking help for - to isolate the problematic source. > But from what I learnt - it is combination of source and dependencies. > The same source ***passed*** if it is complied with a dependency that > wasn't compile with "-parameters". > What I need is a flag (or a patch) that causes the compiler to emit > verbose information > > Thanks > Boaz > > On Mar 23, 2014 9:18 PM, "Vicente-Arturo Romero-Zaldivar" > > wrote: > > Hi Boaz, > > Do you have an isolated test case? > > Thanks, > Vicente > > On 23/03/14 12:40, Boaz Nahum wrote: >> Actaully '-XDverboseCompilePolicy and -Xdiags:verbose' are not >> ignored, it is just that the exception occurs too early. If I >> remove '-parameters' then they do the work .... >> >> >> On Sun, Mar 23, 2014 at 2:29 PM, Boaz Nahum > > wrote: >> >> When compiling our code with '-parameters' (1.8.0_20-ea and >> 1.8.0-b132), we got this exception: >> >> An exception has occurred in the compiler (1.8.0). Please >> file a bug at the Java Developer/bugreport) after checking >> the Bug Parade for duplicates. Include your program and the >> following diagnostic in your report. Thank you. >> java.lang.ClassCastException: java.lang.String cannot be >> cast to com.sun.tools.javac.util.Name >> >> at >> com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) >> at >> com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) >> at >> com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) >> at >> com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) >> at >> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) >> at >> com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) >> at >> com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) >> at >> com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) >> at >> com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) >> at >> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >> at >> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >> at >> com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) >> at >> com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) >> at >> com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) >> at >> com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) >> at >> com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) >> at >> com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) >> at >> com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) >> at >> com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) >> at >> com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) >> at >> com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) >> at >> com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) >> at >> com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) >> at >> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >> at >> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) >> at >> com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) >> at >> com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) >> at >> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >> at >> com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) >> at >> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >> at >> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >> at >> com.sun.tools.javac.comp.Enter.complete(Enter.java:497) >> at com.sun.tools.javac.comp.Enter.main(Enter.java:475) >> at >> com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) >> at >> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) >> at com.sun.tools.javac.main.Main.compile(Main.java:523) >> at com.sun.tools.javac.main.Main.compile(Main.java:381) >> at com.sun.tools.javac.main.Main.compile(Main.java:370) >> at com.sun.tools.javac.main.Main.compile(Main.java:361) >> at com.sun.tools.javac.Main.compile(Main.java:56) >> at com.sun.tools.javac.Main.main(Main.java:42) >> >> >> Thanks >> Boaz >> >> >> >> In order to isolate the problematic code, I add >> -XDverboseCompilePolicy and -Xdiags:verbose, without luck. >> Why they are ignored ? >> >> Please note that an annotation processor is involved. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Mon Mar 24 11:39:08 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 24 Mar 2014 15:39:08 +0400 Subject: RFR [8034044] Class.getModifiers() returns "static" for anonymous classes In-Reply-To: <531DF2E2.5030706@oracle.com> References: <531982E0.1050307@oracle.com> <5319835E.4090007@oracle.com> <531A0B80.3070804@oracle.com> <531A1271.6080607@oracle.com> <531DF2E2.5030706@oracle.com> Message-ID: <5330195C.6020906@oracle.com> Hello everyone! It's a friendly reminder. Would somebody please help review the changes and share suggestions/approvals? http://cr.openjdk.java.net/~igerasim/8034044/1/webrev/ Thanks in advance, Ivan On 10.03.2014 21:14, Ivan Gerasimov wrote: > I removed the STATIC bit from the modifiers of the enum body. > Jtreg test is updated accordingly. > > No new jtreg/jck test failures. > > Would you please help review the updated webrev? > > http://cr.openjdk.java.net/~igerasim/8034044/1/webrev/ > > Sincerely yours, > Ivan > > On 07.03.2014 22:39, Ivan Gerasimov wrote: >> Thank you Alex! >> >> On 07.03.2014 22:10, Alex Buckley wrote: >>> On 3/7/2014 12:29 AM, Ivan Gerasimov wrote: >>>> JLS states that an anonymous class cannot be static [1]. >>>> However, in OpenJDK implementation Class#getModifiers(), when >>>> called for >>>> the anonymous class, returns the STATIC bit set. >>>> Would you please help review the proposed fix, which removes STATIC >>>> from >>>> the anonymous class's modifier? >>>> >>>> An exception to this is an enum constant's body. >>>> It's not clear, whether they should be treated in the same way as >>>> anonymous classes, so I left them as they are now. >>> >>> JLS 8.9.1: The optional class body of an enum constant implicitly >>> defines an anonymous class declaration (?15.9.5) that extends the >>> immediately enclosing enum type. >>> >>> So the class generated for an enum constant's body should not be >>> ACC_STATIC. >>> >> >> Ok, I'll remove STATIC from the enum bodies too. >> >> Sincerely yours, >> Ivan >> >>> Alex >>> >> >> >> >> > > > > From joel.franck at oracle.com Tue Mar 25 10:36:59 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 25 Mar 2014 11:36:59 +0100 Subject: RFR JDK9: 8038080: annotation processors don't visit declaration parameter annotations In-Reply-To: References: Message-ID: Hi, Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8038080 annotation processors don't visit declaration parameter annotations http://cr.openjdk.java.net/~jfranck/8038080/webrev.00/ When updating annotation processing for type annotations regular declaration annotations on parameters were left out of discovery. The fix is based on Liam?s patch but slightly different, I think using super in all 4 cases is better. I also added a test for the change in JavacProcessingEnvironment. Liam does this work for you? cheers /Joel From joel.franck at oracle.com Tue Mar 25 14:37:26 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 25 Mar 2014 15:37:26 +0100 Subject: RFR [8034044] Class.getModifiers() returns "static" for anonymous classes In-Reply-To: <5330195C.6020906@oracle.com> References: <531982E0.1050307@oracle.com> <5319835E.4090007@oracle.com> <531A0B80.3070804@oracle.com> <531A1271.6080607@oracle.com> <531DF2E2.5030706@oracle.com> <5330195C.6020906@oracle.com> Message-ID: Hi Ivan, I think this looks good. cheers /Joel On 24 Mar 2014, at 12:39, Ivan Gerasimov wrote: > Hello everyone! > > It's a friendly reminder. > Would somebody please help review the changes and share suggestions/approvals? > http://cr.openjdk.java.net/~igerasim/8034044/1/webrev/ > > Thanks in advance, > Ivan > > On 10.03.2014 21:14, Ivan Gerasimov wrote: >> I removed the STATIC bit from the modifiers of the enum body. >> Jtreg test is updated accordingly. >> >> No new jtreg/jck test failures. >> >> Would you please help review the updated webrev? >> >> http://cr.openjdk.java.net/~igerasim/8034044/1/webrev/ >> >> Sincerely yours, >> Ivan >> >> On 07.03.2014 22:39, Ivan Gerasimov wrote: >>> Thank you Alex! >>> >>> On 07.03.2014 22:10, Alex Buckley wrote: >>>> On 3/7/2014 12:29 AM, Ivan Gerasimov wrote: >>>>> JLS states that an anonymous class cannot be static [1]. >>>>> However, in OpenJDK implementation Class#getModifiers(), when called for >>>>> the anonymous class, returns the STATIC bit set. >>>>> Would you please help review the proposed fix, which removes STATIC from >>>>> the anonymous class's modifier? >>>>> >>>>> An exception to this is an enum constant's body. >>>>> It's not clear, whether they should be treated in the same way as >>>>> anonymous classes, so I left them as they are now. >>>> >>>> JLS 8.9.1: The optional class body of an enum constant implicitly defines an anonymous class declaration (?15.9.5) that extends the immediately enclosing enum type. >>>> >>>> So the class generated for an enum constant's body should not be ACC_STATIC. >>>> >>> >>> Ok, I'll remove STATIC from the enum bodies too. >>> >>> Sincerely yours, >>> Ivan >>> >>>> Alex >>>> >>> >>> >>> >>> >> >> >> >> > From boaznahum at gmail.com Tue Mar 25 16:03:08 2014 From: boaznahum at gmail.com (Boaz Nahum) Date: Tue, 25 Mar 2014 18:03:08 +0200 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: <53308D8B.8060705@oracle.com> References: <532F3386.5070901@oracle.com> <533015EF.8090703@oracle.com> <53303459.8000604@oracle.com> <53303707.7080909@oracle.com> <533038A4.9020503@oracle.com> <533088A8.5000803@oracle.com> <53308D8B.8060705@oracle.com> Message-ID: Hi. First, with your help, I managed to isolate some piece of code that reproduce similar crash ( By 'isolate' I mean 45 files that I can send you out of 80K). ('Similar' means 'Information:java: java.lang.ClassCastException: com.sun.tools.javac.jvm.ClassFile$NameAndType cannot be cast to com.sun.tools.javac.util.Name' ) But now the crash only with 1.8.0u20 but not with http://hg.openjdk.java.net/jdk8/tl/ On the other hand, in our huge project it happens also with http://hg.openjdk.java.net/jdk8/tl/ So I guess I didn't isolated it completely. Second. this crash happens only if 'annotation processor' is involved. So, I don't know if it worth the effort to send you the files (and short description how to build them) ? Thanks Boaz On Mon, Mar 24, 2014 at 9:54 PM, Vicente-Arturo Romero-Zaldivar < vicente.romero at oracle.com> wrote: > On 24/03/14 19:41, Boaz Nahum wrote: > > Of curse you can ( why not mention my name :) ? ) > > > :) just in case you didn't want but I have no problem with adding your > name and / or mail > > > Anyway, do you already know what the bug is ? Can you share the bug ID > with me ? > > > I haven't created it yet but I will send you the id once I have it. > > > I will try to isolate the code and send it to you. > > > Thanks, > Vicente > > > The > Boaz > On Mar 24, 2014 9:34 PM, "Vicente-Arturo Romero-Zaldivar" < > vicente.romero at oracle.com> wrote: > >> Thanks Boaz, >> >> I will add all this info in a bug report. Can I use this test case to >> write a mail, probably a blog in the future, about obtaining extra >> information from hard bugs? I won't mention your name. My idea is to write >> some info that may help other users to provide more information associated >> to a crash or bug. >> >> Thanks, >> Vicente >> >> On 24/03/14 17:31, Boaz Nahum wrote: >> >> Comment out >> //@NotNull >> //public static T createSingleton(final Class> DIGlobalCxPDD> dd) { >> // >> // return Singletons.createNonNull(dd, new Factory0Adapter() { >> // @Override >> // public T get() { >> // return createWithContext(dd, null, null); >> // } >> // }); >> //} >> >> --------------------------------------------------------------------- >> Brings a new exception: >> >> >> >> ********************* error in file >> F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob >> al/DIFW.class) >> ********************* while trying to read constant pool entry 72 >> >> #70 = Utf8 all >> #71 = Utf8 >> Ljava/util/List<+Lwf/core/util/factory/Factory<+TT;-TP;>;>; >> #72 = Utf8 Ljava/util/List; >> #73 = Utf8 get0 >> #74 = Utf8 >> (Ljava/lang/Class;)Lwf/core/util/factory/Factory0; >> >> Comment out: >> >> //List> all = >> DIFWImp.getAll(dd, context); >> >> //noinspection unchecked >> return null;//(List>)all; >> >> --------------------------------------------------------------------- >> >> Brings a new exception: >> >> ********************* while trying to read constant pool entry 162 >> >> #161 = Utf8 >> Ljava/lang/Class<+Lwf/core/util/factory/di/core/DIAbstractDD<-Ljava/lang/Void;+TT;-TP;>;>; >> #162 = Utf8 wf/core/util/packing/Params2 >> #163 = Class #162 // wf/core/util/packing/Params2 >> #164 = Utf8 >> (Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; >> #165 = NameAndType #34:#164 // >> create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; >> #166 = Methodref #163.#165 // >> wf/core/util/packing/Params2.create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; >> #167 = Utf8 >> Ljava/lang/Class<+Lwf/core/util/factory/di/factory/DIGlobalCxPDD;>;>; >> >> >> >> Thx >> Boaz >> >> >> >> >> >> >> >> >> >> >> On Mon, Mar 24, 2014 at 6:40 PM, Boaz Nahum wrote: >> >>> Thx >>> >>> ********************* error in file >>> F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob >>> al/DIFW.class) >>> ********************* while trying to read constant pool entry 64 >>> >>> Attachedfiles DIFW{.java, .class,$*.class} >>> >>> >>> >>> >>> >>> >>> On Mon, Mar 24, 2014 at 3:52 PM, Vicente-Arturo Romero-Zaldivar < >>> vicente.romero at oracle.com> wrote: >>> >>>> On 24/03/14 13:50, Boaz Nahum wrote: >>>> >>>> is repo http://hg.openjdk.java.net/jdk8/jdk8 is good enough, or maybe >>>> other >>>> >>>> >>>> Please use this one: http://hg.openjdk.java.net/jdk8/tl/ >>>> >>>> >>>> >>>> >>>> On Mon, Mar 24, 2014 at 3:45 PM, Vicente-Arturo Romero-Zaldivar < >>>> vicente.romero at oracle.com> wrote: >>>> >>>>> I usually do this with Linux, if you have Linux you can go to your >>>>> jdk repo, to the langtools folder and do: >>>>> >>>>> patch -p1 < /path/to/mypatch >>>>> >>>>> after that you can rebuild again the jdk and you will have the patched >>>>> javac. >>>>> >>>>> Vicente >>>>> >>>>> >>>>> On 24/03/14 13:41, Boaz Nahum wrote: >>>>> >>>>> Please send my link to instruction how to apply pathc (I know how to >>>>> compile JDK, never before applied a patch) >>>>> >>>>> >>>>> On Mon, Mar 24, 2014 at 3:34 PM, Vicente-Arturo Romero-Zaldivar < >>>>> vicente.romero at oracle.com> wrote: >>>>> >>>>>> Hi Boaz, >>>>>> >>>>>> Please try the attached patch and send me the obtained information >>>>>> along with the failing .class file. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> >>>>>> On 24/03/14 13:07, Boaz Nahum wrote: >>>>>> >>>>>> It happens both with 1.8.0_20-ea and 1.8.0-b132 >>>>>> >>>>>> The javac (with -verbose) output >>>>>> https://drive.google.com/file/d/0B4MyZ6FK5jswZVZWV0VMSnE3c0k/edit?usp=sharing >>>>>> >>>>>> I didn't tired with http://hg.openjdk.java.net/jdk9/dev/langtools/I need to re-setup by jdk build environment >>>>>> >>>>>> >>>>>> many thanks >>>>>> Boaz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Mar 24, 2014 at 1:24 PM, Vicente-Arturo Romero-Zaldivar < >>>>>> vicente.romero at oracle.com> wrote: >>>>>> >>>>>>> Hi Boaz, >>>>>>> >>>>>>> OK it seems like we both need more information :) >>>>>>> >>>>>>> What version of javac is this? Can you get the last javac from >>>>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/ and try to reproduce >>>>>>> the issue? Do you get any meaningful information after executing javac with >>>>>>> plain "-verbose" option? >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> >>>>>>> On 24/03/14 07:10, Boaz Nahum wrote: >>>>>>> >>>>>>> That what I'm asking help for - to isolate the problematic source. >>>>>>> But from what I learnt - it is combination of source and >>>>>>> dependencies. The same source ***passed*** if it is complied with a >>>>>>> dependency that wasn't compile with "-parameters". >>>>>>> What I need is a flag (or a patch) that causes the compiler to emit >>>>>>> verbose information >>>>>>> >>>>>>> Thanks >>>>>>> Boaz >>>>>>> On Mar 23, 2014 9:18 PM, "Vicente-Arturo Romero-Zaldivar" < >>>>>>> vicente.romero at oracle.com> wrote: >>>>>>> >>>>>>>> Hi Boaz, >>>>>>>> >>>>>>>> Do you have an isolated test case? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vicente >>>>>>>> >>>>>>>> On 23/03/14 12:40, Boaz Nahum wrote: >>>>>>>> >>>>>>>> Actaully '-XDverboseCompilePolicy and -Xdiags:verbose' are not >>>>>>>> ignored, it is just that the exception occurs too early. If I remove >>>>>>>> '-parameters' then they do the work .... >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Mar 23, 2014 at 2:29 PM, Boaz Nahum wrote: >>>>>>>> >>>>>>>>> When compiling our code with '-parameters' (1.8.0_20-ea and >>>>>>>>> 1.8.0-b132), we got this exception: >>>>>>>>> >>>>>>>>> An exception has occurred in the compiler (1.8.0). Please file a >>>>>>>>> bug at the Java Developer/bugreport) after checking the Bug Parade for >>>>>>>>> duplicates. Include your program and the following diagnostic in your >>>>>>>>> report. Thank you. >>>>>>>>> java.lang.ClassCastException: java.lang.String cannot be cast >>>>>>>>> to com.sun.tools.javac.util.Name >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) >>>>>>>>> at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) >>>>>>>>> at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) >>>>>>>>> at com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) >>>>>>>>> at com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >>>>>>>>> at com.sun.tools.javac.comp.Enter.complete(Enter.java:497) >>>>>>>>> at com.sun.tools.javac.comp.Enter.main(Enter.java:475) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) >>>>>>>>> at >>>>>>>>> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) >>>>>>>>> at com.sun.tools.javac.main.Main.compile(Main.java:523) >>>>>>>>> at com.sun.tools.javac.main.Main.compile(Main.java:381) >>>>>>>>> at com.sun.tools.javac.main.Main.compile(Main.java:370) >>>>>>>>> at com.sun.tools.javac.main.Main.compile(Main.java:361) >>>>>>>>> at com.sun.tools.javac.Main.compile(Main.java:56) >>>>>>>>> at com.sun.tools.javac.Main.main(Main.java:42) >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Boaz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> In order to isolate the problematic code, I add >>>>>>>>> -XDverboseCompilePolicy and -Xdiags:verbose, without luck. >>>>>>>>> Why they are ignored ? >>>>>>>>> >>>>>>>>> Please note that an annotation processor is involved. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Mar 25 16:14:58 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 25 Mar 2014 16:14:58 +0000 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: References: <532F3386.5070901@oracle.com> <533015EF.8090703@oracle.com> <53303459.8000604@oracle.com> <53303707.7080909@oracle.com> <533038A4.9020503@oracle.com> <533088A8.5000803@oracle.com> <53308D8B.8060705@oracle.com> Message-ID: <5331AB82.6040704@oracle.com> Hi Boaz, If the problem is reproducible with the big project only and you can share it, yes I think that you can send it or you can share a repo with the code and instructions to reproduce the issue. Once I have all this information I will create the bug report. Thanks for your help, Vicente On 25/03/14 16:03, Boaz Nahum wrote: > Hi. > > > First, with your help, I managed to isolate some piece of code that > reproduce similar crash ( By 'isolate' I mean 45 files that I can send > you out of 80K). > > ('Similar' means 'Information:java: java.lang.ClassCastException: > com.sun.tools.javac.jvm.ClassFile$NameAndType cannot be cast to > com.sun.tools.javac.util.Name ' ) > > > But now the crash only with 1.8.0u20 but not with > http://hg.openjdk.java.net/jdk8/tl/ > > On the other hand, in our huge project it happens also with > http://hg.openjdk.java.net/jdk8/tl/ > > So I guess I didn't isolated it completely. > > Second. this crash happens only if 'annotation processor' is involved. > > So, I don't know if it worth the effort to send you the files (and > short description how to build them) ? > > Thanks > Boaz > > > > On Mon, Mar 24, 2014 at 9:54 PM, Vicente-Arturo Romero-Zaldivar > > wrote: > > On 24/03/14 19:41, Boaz Nahum wrote: >> >> Of curse you can ( why not mention my name :) ? ) >> > > :) just in case you didn't want but I have no problem with adding > your name and / or mail > > >> Anyway, do you already know what the bug is ? Can you share the >> bug ID with me ? >> > > I haven't created it yet but I will send you the id once I have it. > > >> I will try to isolate the code and send it to you. >> > > Thanks, > Vicente > > >> The >> Boaz >> >> On Mar 24, 2014 9:34 PM, "Vicente-Arturo Romero-Zaldivar" >> > wrote: >> >> Thanks Boaz, >> >> I will add all this info in a bug report. Can I use this test >> case to write a mail, probably a blog in the future, about >> obtaining extra information from hard bugs? I won't mention >> your name. My idea is to write some info that may help other >> users to provide more information associated to a crash or bug. >> >> Thanks, >> Vicente >> >> On 24/03/14 17:31, Boaz Nahum wrote: >>> Comment out >>> //@NotNull >>> //public static T createSingleton(final Class>> extends DIGlobalCxPDD> dd) { >>> // >>> // return Singletons.createNonNull(dd, new >>> Factory0Adapter() { >>> // @Override >>> // public T get() { >>> // return createWithContext(dd, null, null); >>> // } >>> // }); >>> //} >>> >>> --------------------------------------------------------------------- >>> Brings a new exception: >>> >>> >>> >>> ********************* error in file >>> F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob >>> al/DIFW.class) >>> ********************* while trying to read constant pool >>> entry 72 >>> >>> #70 = Utf8 all >>> #71 = Utf8 >>> Ljava/util/List<+Lwf/core/util/factory/Factory<+TT;-TP;>;>; >>> #72 = Utf8 Ljava/util/List; >>> #73 = Utf8 get0 >>> #74 = Utf8 (Ljava/lang/Class;)Lwf/core/util/factory/Factory0; >>> >>> Comment out: >>> >>> //List> >>> all = DIFWImp.getAll(dd, context); >>> >>> //noinspection unchecked >>> return null;//(List>)all; >>> >>> --------------------------------------------------------------------- >>> >>> Brings a new exception: >>> >>> ********************* while trying to read constant pool >>> entry 162 >>> >>> #161 = Utf8 >>> Ljava/lang/Class<+Lwf/core/util/factory/di/core/DIAbstractDD<-Ljava/lang/Void;+TT;-TP;>;>; >>> #162 = Utf8 wf/core/util/packing/Params2 >>> #163 = Class #162 // wf/core/util/packing/Params2 >>> #164 = Utf8 >>> (Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; >>> #165 = NameAndType #34:#164 // >>> create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; >>> #166 = Methodref #163.#165 // >>> wf/core/util/packing/Params2.create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; >>> #167 = Utf8 >>> Ljava/lang/Class<+Lwf/core/util/factory/di/factory/DIGlobalCxPDD;>;>; >>> >>> >>> >>> Thx >>> Boaz >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Mar 24, 2014 at 6:40 PM, Boaz Nahum >>> > wrote: >>> >>> Thx >>> >>> ********************* error in file >>> F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob >>> al/DIFW.class) >>> ********************* while trying to read constant >>> pool entry 64 >>> >>> Attachedfiles DIFW{.java, .class,$*.class} >>> >>> >>> >>> >>> >>> >>> On Mon, Mar 24, 2014 at 3:52 PM, Vicente-Arturo >>> Romero-Zaldivar >> > wrote: >>> >>> On 24/03/14 13:50, Boaz Nahum wrote: >>>> is repo http://hg.openjdk.java.net/jdk8/jdk8 is >>>> good enough, or maybe other >>> >>> Please use this one: >>> http://hg.openjdk.java.net/jdk8/tl/ >>> >>> >>>> >>>> >>>> On Mon, Mar 24, 2014 at 3:45 PM, Vicente-Arturo >>>> Romero-Zaldivar >>> > wrote: >>>> >>>> I usually do this with Linux, if you have Linux >>>> you can go to your jdk repo, to the langtools >>>> folder and do: >>>> >>>> patch -p1 < /path/to/mypatch >>>> >>>> after that you can rebuild again the jdk and >>>> you will have the patched javac. >>>> >>>> Vicente >>>> >>>> >>>> On 24/03/14 13:41, Boaz Nahum wrote: >>>>> Please send my link to instruction how to >>>>> apply pathc (I know how to compile JDK, never >>>>> before applied a patch) >>>>> >>>>> >>>>> On Mon, Mar 24, 2014 at 3:34 PM, >>>>> Vicente-Arturo Romero-Zaldivar >>>>> >>>> > wrote: >>>>> >>>>> Hi Boaz, >>>>> >>>>> Please try the attached patch and send me >>>>> the obtained information along with the >>>>> failing .class file. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> >>>>> On 24/03/14 13:07, Boaz Nahum wrote: >>>>>> It happens both with 1.8.0_20-ea and >>>>>> 1.8.0-b132 >>>>>> >>>>>> The javac (with -verbose) output >>>>>> https://drive.google.com/file/d/0B4MyZ6FK5jswZVZWV0VMSnE3c0k/edit?usp=sharing >>>>>> >>>>>> I didn't tired with >>>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/ >>>>>> I need to re-setup by jdk build environment >>>>>> >>>>>> >>>>>> many thanks >>>>>> Boaz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Mar 24, 2014 at 1:24 PM, >>>>>> Vicente-Arturo Romero-Zaldivar >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi Boaz, >>>>>> >>>>>> OK it seems like we both need more >>>>>> information :) >>>>>> >>>>>> What version of javac is this? Can >>>>>> you get the last javac from >>>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/ >>>>>> and try to reproduce the issue? Do >>>>>> you get any meaningful information >>>>>> after executing javac with plain >>>>>> "-verbose" option? >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> >>>>>> On 24/03/14 07:10, Boaz Nahum wrote: >>>>>>> >>>>>>> That what I'm asking help for - to >>>>>>> isolate the problematic source. >>>>>>> But from what I learnt - it is >>>>>>> combination of source and >>>>>>> dependencies. The same source >>>>>>> ***passed*** if it is complied with >>>>>>> a dependency that wasn't compile >>>>>>> with "-parameters". >>>>>>> What I need is a flag (or a patch) >>>>>>> that causes the compiler to emit >>>>>>> verbose information >>>>>>> >>>>>>> Thanks >>>>>>> Boaz >>>>>>> >>>>>>> On Mar 23, 2014 9:18 PM, >>>>>>> "Vicente-Arturo Romero-Zaldivar" >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi Boaz, >>>>>>> >>>>>>> Do you have an isolated test case? >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> On 23/03/14 12:40, Boaz Nahum wrote: >>>>>>>> Actaully >>>>>>>> '-XDverboseCompilePolicy and >>>>>>>> -Xdiags:verbose' are not >>>>>>>> ignored, it is just that the >>>>>>>> exception occurs too early. If >>>>>>>> I remove '-parameters' then >>>>>>>> they do the work .... >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Mar 23, 2014 at 2:29 >>>>>>>> PM, Boaz Nahum >>>>>>>> >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> When compiling our code >>>>>>>> with '-parameters' >>>>>>>> (1.8.0_20-ea and >>>>>>>> 1.8.0-b132), we got this >>>>>>>> exception: >>>>>>>> >>>>>>>> An exception has occurred >>>>>>>> in the compiler (1.8.0). >>>>>>>> Please file a bug at the >>>>>>>> Java Developer/bugreport) >>>>>>>> after checking the Bug >>>>>>>> Parade for duplicates. >>>>>>>> Include your program and >>>>>>>> the following diagnostic in >>>>>>>> your report. Thank you. >>>>>>>> java.lang.ClassCastException: >>>>>>>> java.lang.String cannot be >>>>>>>> cast to >>>>>>>> com.sun.tools.javac.util.Name >>>>>>>> >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) >>>>>>>> at >>>>>>>> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >>>>>>>> at >>>>>>>> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) >>>>>>>> at >>>>>>>> com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) >>>>>>>> at >>>>>>>> com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) >>>>>>>> at >>>>>>>> com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) >>>>>>>> at >>>>>>>> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >>>>>>>> at >>>>>>>> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Enter.complete(Enter.java:497) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Enter.main(Enter.java:475) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:523) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:381) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:370) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:361) >>>>>>>> at >>>>>>>> com.sun.tools.javac.Main.compile(Main.java:56) >>>>>>>> at >>>>>>>> com.sun.tools.javac.Main.main(Main.java:42) >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Boaz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In order to isolate the >>>>>>>> problematic code, I add >>>>>>>> -XDverboseCompilePolicy and >>>>>>>> -Xdiags:verbose, without luck. >>>>>>>> Why they are ignored ? >>>>>>>> >>>>>>>> Please note that an >>>>>>>> annotation processor is >>>>>>>> involved. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Mar 25 16:51:15 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 25 Mar 2014 16:51:15 +0000 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: <5331AB82.6040704@oracle.com> References: <532F3386.5070901@oracle.com> <533015EF.8090703@oracle.com> <53303459.8000604@oracle.com> <53303707.7080909@oracle.com> <533038A4.9020503@oracle.com> <533088A8.5000803@oracle.com> <53308D8B.8060705@oracle.com> <5331AB82.6040704@oracle.com> Message-ID: <5331B403.3010205@oracle.com> Hi Boaz, I have created bug entry: https://bugs.openjdk.java.net/browse/JDK-8038334. Thanks, Vicente On 25/03/14 16:14, Vicente-Arturo Romero-Zaldivar wrote: > Hi Boaz, > > If the problem is reproducible with the big project only and you can > share it, yes I think that you can send it or you can share a repo > with the code and instructions to reproduce the issue. Once I have all > this information I will create the bug report. > > Thanks for your help, > Vicente > > On 25/03/14 16:03, Boaz Nahum wrote: >> Hi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Mar 25 16:56:28 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 25 Mar 2014 09:56:28 -0700 Subject: RFR JDK9: 8038080: annotation processors don't visit declaration parameter annotations In-Reply-To: References: Message-ID: Looks good to me. Thanks Joel. On Tue, Mar 25, 2014 at 3:36 AM, Joel Borggr?n-Franck < joel.franck at oracle.com> wrote: > Hi, > > Please review this fix for > https://bugs.openjdk.java.net/browse/JDK-8038080 annotation processors > don't visit declaration parameter annotations > > http://cr.openjdk.java.net/~jfranck/8038080/webrev.00/ > > When updating annotation processing for type annotations regular > declaration annotations on parameters were left out of discovery. > > The fix is based on Liam?s patch but slightly different, I think using > super in all 4 cases is better. I also added a test for the change in > JavacProcessingEnvironment. > > Liam does this work for you? > > cheers > /Joel -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Mar 25 18:27:17 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 25 Mar 2014 11:27:17 -0700 Subject: RFR JDK9: 8038080: annotation processors don't visit declaration parameter annotations In-Reply-To: References: Message-ID: <5331CA85.6020704@oracle.com> Looks good Joel; this one would be good to get back ported into an early 8 update too. Thanks, -Joe On 03/25/2014 03:36 AM, Joel Borggr?n-Franck wrote: > Hi, > > Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8038080 annotation processors don't visit declaration parameter annotations > > http://cr.openjdk.java.net/~jfranck/8038080/webrev.00/ > > When updating annotation processing for type annotations regular declaration annotations on parameters were left out of discovery. > > The fix is based on Liam?s patch but slightly different, I think using super in all 4 cases is better. I also added a test for the change in JavacProcessingEnvironment. > > Liam does this work for you? > > cheers > /Joel From cushon at google.com Tue Mar 25 21:04:02 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 25 Mar 2014 14:04:02 -0700 Subject: javac8 with jdk7 Message-ID: Hi, I'm curious if there's any interest in reducing javac's dependence on the specific JDK version it's running on. Currently javac8 works with jdk7 only if it's on the jvm's bootclasspath, because of some changes to the javax classes that are also in rt.jar. (Specifically: the addition of StandardLocation.NATIVE_HEADER_OUTPUT and SourceVersion.RELEASE_8.) Being able to run javacN on at least jdkN-1 would be convenient when working with code that invokes javac programmatically, since configuring the bootclasspath complicates deployment. Any thoughts on whether this would be worthwhile? Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Mar 25 22:02:19 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Mar 2014 15:02:19 -0700 Subject: javac8 with jdk7 In-Reply-To: References: Message-ID: <5331FCEB.8080101@oracle.com> On 03/25/2014 02:04 PM, Liam Miller-Cushon wrote: > > Hi, > > > I'm curious if there's any interest in reducing javac's dependence on > the specific JDK version it's running on. Currently javac8 works with > jdk7 only if it's on the jvm's bootclasspath, because of some changes > to the javax classes that are also in rt.jar. (Specifically: the > addition of StandardLocation.NATIVE_HEADER_OUTPUT and > SourceVersion.RELEASE_8.) > > > Being able to run javacN on at least jdkN-1 would be convenient when > working with code that invokes javac programmatically, since > configuring the bootclasspath complicates deployment. > > > Any thoughts on whether this would be worthwhile? > > > Thanks, > > Liam Liam, Because of the way we bootstrap the JDK build, it is a requirement that javac N must be able to run on JRE N-1. I can't quite untangle your second sentence (beginning "Currently...) so it would help if you could explain your perceived issues a bit more. Your issues about configuring the bootclasspath may hint at your issues. Any time you want to compile against a different version of the libraries other than those native to the underlying JVM, you have to set the bootclasspath, at least for now. There are ideas about a new -platform option which would supercede -source, -target and -bootclasspath. But that would only allow you to compile for earlier versions (i.e. just like the -source and -target options today). But I suspect you are wanting to compile for future versions. e.g. you are suggesting that it should be possible to run a variant of javac 8 on JDK 7, such that the variant has bound within it a copy of the JRE 8 libraries that are normally found on the JRE 8 bootclasspath. Technically, that could certainly be done; I'm not sure it is generally worthwhile, though. If the only issue is that "configuring the bootclasspath complicates deployment" then the solution should be as simple as a modified bundle, with the extra libraries added, and a wrapper script for javac that sets the bootclasspath for you, before calling the desired version of javac. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Tue Mar 25 22:35:26 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 25 Mar 2014 15:35:26 -0700 Subject: javac8 with jdk7 In-Reply-To: <5331FCEB.8080101@oracle.com> References: <5331FCEB.8080101@oracle.com> Message-ID: Often software is structured above the level of a process invocation. Imagine a jre7 with an api that included a parameter where to find a javac implementation, that would get loaded via a URLClassLoader. You could even run multiple javac versions in the same java process at the same time in separate classloaders. Because javac is "just" another java application. Almost. Another way of looking at it is that the -Xbootclasspath/p: hack is deeply non-modular. But I can understand if you're maintaining the -Xbootclasspath/p: hack just to bootstrap-build the jdk itself. On Tue, Mar 25, 2014 at 3:02 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > On 03/25/2014 02:04 PM, Liam Miller-Cushon wrote: > > Hi, > > I'm curious if there's any interest in reducing javac's dependence on > the specific JDK version it's running on. Currently javac8 works with jdk7 > only if it's on the jvm's bootclasspath, because of some changes to the > javax classes that are also in rt.jar. (Specifically: the addition of > StandardLocation.NATIVE_HEADER_OUTPUT and SourceVersion.RELEASE_8.) > > Being able to run javacN on at least jdkN-1 would be convenient when > working with code that invokes javac programmatically, since configuring > the bootclasspath complicates deployment. > > Any thoughts on whether this would be worthwhile? > > Thanks, > Liam > > > Liam, > > Because of the way we bootstrap the JDK build, it is a requirement that > javac N must be able to run on JRE N-1. > > I can't quite untangle your second sentence (beginning "Currently...) so > it would help if you could explain your perceived issues a bit more. > > Your issues about configuring the bootclasspath may hint at your issues. > Any time you want to compile against a different version of the libraries > other than those native to the underlying JVM, you have to set the > bootclasspath, at least for now. There are ideas about a new -platform > option which would supercede -source, -target and -bootclasspath. But that > would only allow you to compile for earlier versions (i.e. just like the > -source and -target options today). > > But I suspect you are wanting to compile for future versions. e.g. you > are suggesting that it should be possible to run a variant of javac 8 on > JDK 7, such that the variant has bound within it a copy of the JRE 8 > libraries that are normally found on the JRE 8 bootclasspath. Technically, > that could certainly be done; I'm not sure it is generally worthwhile, > though. If the only issue is that "configuring the bootclasspath > complicates deployment" then the solution should be as simple as a modified > bundle, with the extra libraries added, and a wrapper script for javac that > sets the bootclasspath for you, before calling the desired version of javac. > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Mar 25 22:51:06 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Mar 2014 15:51:06 -0700 Subject: javac8 with jdk7 In-Reply-To: References: <5331FCEB.8080101@oracle.com> Message-ID: <5332085A.1050206@oracle.com> Well, you've jumped all the way to -Xbootclasspath/p:. You jumped over -bootclasspath alias -Xbootclasspath which are more likely candidates for what it seems you are trying to do. If you want to set the platform libraries for your compilation, -bootclasspath is the way to go. And, in case it is not obvious, note that -bootclasspath, -Xbootclasspath and its variants are all options to javac itself, and not to the underlying JVM. -- Jon On 03/25/2014 03:35 PM, Martin Buchholz wrote: > Often software is structured above the level of a process invocation. > Imagine a jre7 with an api that included a parameter where to find a > javac implementation, that would get loaded via a URLClassLoader. You > could even run multiple javac versions in the same java process at the > same time in separate classloaders. Because javac is "just" another > java application. Almost. Another way of looking at it is that the > -Xbootclasspath/p: hack is deeply non-modular. But I can understand > if you're maintaining the -Xbootclasspath/p: hack just to > bootstrap-build the jdk itself. > > > On Tue, Mar 25, 2014 at 3:02 PM, Jonathan Gibbons > > wrote: > > On 03/25/2014 02:04 PM, Liam Miller-Cushon wrote: >> >> Hi, >> >> >> I'm curious if there's any interest in reducing javac's >> dependence on the specific JDK version it's running on. Currently >> javac8 works with jdk7 only if it's on the jvm's bootclasspath, >> because of some changes to the javax classes that are also in >> rt.jar. (Specifically: the addition of >> StandardLocation.NATIVE_HEADER_OUTPUT and SourceVersion.RELEASE_8.) >> >> >> Being able to run javacN on at least jdkN-1 would be convenient >> when working with code that invokes javac programmatically, since >> configuring the bootclasspath complicates deployment. >> >> >> Any thoughts on whether this would be worthwhile? >> >> >> Thanks, >> >> Liam > > Liam, > > Because of the way we bootstrap the JDK build, it is a requirement > that javac N must be able to run on JRE N-1. > > I can't quite untangle your second sentence (beginning > "Currently...) so it would help if you could explain your > perceived issues a bit more. > > Your issues about configuring the bootclasspath may hint at your > issues. Any time you want to compile against a different version > of the libraries other than those native to the underlying JVM, > you have to set the bootclasspath, at least for now. There are > ideas about a new -platform option which would supercede -source, > -target and -bootclasspath. But that would only allow you to > compile for earlier versions (i.e. just like the -source and > -target options today). > > But I suspect you are wanting to compile for future versions. > e.g. you are suggesting that it should be possible to run a > variant of javac 8 on JDK 7, such that the variant has bound > within it a copy of the JRE 8 libraries that are normally found on > the JRE 8 bootclasspath. Technically, that could certainly be > done; I'm not sure it is generally worthwhile, though. If the > only issue is that "configuring the bootclasspath complicates > deployment" then the solution should be as simple as a modified > bundle, with the extra libraries added, and a wrapper script for > javac that sets the bootclasspath for you, before calling the > desired version of javac. > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.mccorkle at oracle.com Tue Mar 25 22:59:27 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 25 Mar 2014 18:59:27 -0400 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: References: <532F3386.5070901@oracle.com> <533015EF.8090703@oracle.com> <53303459.8000604@oracle.com> <53303707.7080909@oracle.com> <533038A4.9020503@oracle.com> <533088A8.5000803@oracle.com> <53308D8B.8060705@oracle.com> Message-ID: <53320A4F.4050305@oracle.com> Coming in a bit late here, see replies inline. On 03/25/14 12:03, Boaz Nahum wrote: > Hi. > > > First, with your help, I managed to isolate some piece of code that > reproduce similar crash ( By 'isolate' I mean 45 files that I can send > you out of 80K). > > ('Similar' means 'Information:java: java.lang.ClassCastException: > com.sun.tools.javac.jvm.ClassFile$NameAndType cannot be cast to > com.sun.tools.javac.util.Name ' ) My intuition, based on what I've seen earlier in the thread, is that there's a problem with javac reading method parameter data back out of a class file. That is why you are seeing it only on source that depends on something compiled with -parameters. The problem isn't with the source you're compiling; it's with the class files that get read. > > But now the crash only with 1.8.0u20 but not with > http://hg.openjdk.java.net/jdk8/tl/ That is strange. I'm not aware that parameter reflection has been changed in 8u20 yet. > On the other hand, in our huge project it happens also with > http://hg.openjdk.java.net/jdk8/tl/ > > So I guess I didn't isolated it completely. > > Second. this crash happens only if 'annotation processor' is involved. That is helpful, though I'm not sure what it means offhand. > So, I don't know if it worth the effort to send you the files (and short > description how to build them) ? > > Thanks > Boaz > > > > On Mon, Mar 24, 2014 at 9:54 PM, Vicente-Arturo Romero-Zaldivar > > wrote: > > On 24/03/14 19:41, Boaz Nahum wrote: >> >> Of curse you can ( why not mention my name :) ? ) >> > > :) just in case you didn't want but I have no problem with adding > your name and / or mail > > >> Anyway, do you already know what the bug is ? Can you share the >> bug ID with me ? >> > > I haven't created it yet but I will send you the id once I have it. > > >> I will try to isolate the code and send it to you. >> > > Thanks, > Vicente > > >> The >> Boaz >> >> On Mar 24, 2014 9:34 PM, "Vicente-Arturo Romero-Zaldivar" >> > wrote: >> >> Thanks Boaz, >> >> I will add all this info in a bug report. Can I use this test >> case to write a mail, probably a blog in the future, about >> obtaining extra information from hard bugs? I won't mention >> your name. My idea is to write some info that may help other >> users to provide more information associated to a crash or bug. >> >> Thanks, >> Vicente >> >> On 24/03/14 17:31, Boaz Nahum wrote: >>> Comment out >>> //@NotNull >>> //public static T createSingleton(final Class>> extends DIGlobalCxPDD> dd) { >>> // >>> // return Singletons.createNonNull(dd, new >>> Factory0Adapter() { >>> // @Override >>> // public T get() { >>> // return createWithContext(dd, null, null); >>> // } >>> // }); >>> //} >>> >>> --------------------------------------------------------------------- >>> Brings a new exception: >>> >>> >>> >>> ********************* error in file >>> F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob >>> al/DIFW.class) >>> ********************* while trying to read constant pool entry 72 >>> >>> #70 = Utf8 all >>> #71 = Utf8 >>> Ljava/util/List<+Lwf/core/util/factory/Factory<+TT;-TP;>;>; >>> #72 = Utf8 Ljava/util/List; >>> #73 = Utf8 get0 >>> #74 = Utf8 >>> (Ljava/lang/Class;)Lwf/core/util/factory/Factory0; >>> >>> Comment out: >>> >>> //List> all >>> = DIFWImp.getAll(dd, context); >>> >>> //noinspection unchecked >>> return null;//(List>)all; >>> >>> --------------------------------------------------------------------- >>> >>> Brings a new exception: >>> >>> ********************* while trying to read constant pool >>> entry 162 >>> >>> #161 = Utf8 >>> Ljava/lang/Class<+Lwf/core/util/factory/di/core/DIAbstractDD<-Ljava/lang/Void;+TT;-TP;>;>; >>> #162 = Utf8 wf/core/util/packing/Params2 >>> #163 = Class #162 // >>> wf/core/util/packing/Params2 >>> #164 = Utf8 >>> (Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; >>> #165 = NameAndType #34:#164 // >>> create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; >>> #166 = Methodref #163.#165 // >>> wf/core/util/packing/Params2.create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; >>> #167 = Utf8 >>> Ljava/lang/Class<+Lwf/core/util/factory/di/factory/DIGlobalCxPDD;>;>; >>> >>> >>> >>> Thx >>> Boaz >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Mar 24, 2014 at 6:40 PM, Boaz Nahum >>> > wrote: >>> >>> Thx >>> >>> ********************* error in file >>> F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob >>> al/DIFW.class) >>> ********************* while trying to read constant >>> pool entry 64 >>> >>> Attachedfiles DIFW{.java, .class,$*.class} >>> >>> >>> >>> >>> >>> >>> On Mon, Mar 24, 2014 at 3:52 PM, Vicente-Arturo >>> Romero-Zaldivar >> > wrote: >>> >>> On 24/03/14 13:50, Boaz Nahum wrote: >>>> is repo http://hg.openjdk.java.net/jdk8/jdk8 is good >>>> enough, or maybe other >>> >>> Please use this one: http://hg.openjdk.java.net/jdk8/tl/ >>> >>> >>>> >>>> >>>> On Mon, Mar 24, 2014 at 3:45 PM, Vicente-Arturo >>>> Romero-Zaldivar >>> > wrote: >>>> >>>> I usually do this with Linux, if you have Linux >>>> you can go to your jdk repo, to the langtools >>>> folder and do: >>>> >>>> patch -p1 < /path/to/mypatch >>>> >>>> after that you can rebuild again the jdk and you >>>> will have the patched javac. >>>> >>>> Vicente >>>> >>>> >>>> On 24/03/14 13:41, Boaz Nahum wrote: >>>>> Please send my link to instruction how to apply >>>>> pathc (I know how to compile JDK, never before >>>>> applied a patch) >>>>> >>>>> >>>>> On Mon, Mar 24, 2014 at 3:34 PM, Vicente-Arturo >>>>> Romero-Zaldivar >>>> > wrote: >>>>> >>>>> Hi Boaz, >>>>> >>>>> Please try the attached patch and send me >>>>> the obtained information along with the >>>>> failing .class file. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> >>>>> On 24/03/14 13:07, Boaz Nahum wrote: >>>>>> It happens both with 1.8.0_20-ea and >>>>>> 1.8.0-b132 >>>>>> >>>>>> The javac (with -verbose) output >>>>>> https://drive.google.com/file/d/0B4MyZ6FK5jswZVZWV0VMSnE3c0k/edit?usp=sharing >>>>>> >>>>>> I didn't tired with >>>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/ >>>>>> I need to re-setup by jdk build environment >>>>>> >>>>>> >>>>>> many thanks >>>>>> Boaz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Mar 24, 2014 at 1:24 PM, >>>>>> Vicente-Arturo Romero-Zaldivar >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi Boaz, >>>>>> >>>>>> OK it seems like we both need more >>>>>> information :) >>>>>> >>>>>> What version of javac is this? Can you >>>>>> get the last javac from >>>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/ >>>>>> and try to reproduce the issue? Do you >>>>>> get any meaningful information after >>>>>> executing javac with plain "-verbose" >>>>>> option? >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> >>>>>> On 24/03/14 07:10, Boaz Nahum wrote: >>>>>>> >>>>>>> That what I'm asking help for - to >>>>>>> isolate the problematic source. >>>>>>> But from what I learnt - it is >>>>>>> combination of source and >>>>>>> dependencies. The same source >>>>>>> ***passed*** if it is complied with a >>>>>>> dependency that wasn't compile with >>>>>>> "-parameters". >>>>>>> What I need is a flag (or a patch) >>>>>>> that causes the compiler to emit >>>>>>> verbose information >>>>>>> >>>>>>> Thanks >>>>>>> Boaz >>>>>>> >>>>>>> On Mar 23, 2014 9:18 PM, >>>>>>> "Vicente-Arturo Romero-Zaldivar" >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi Boaz, >>>>>>> >>>>>>> Do you have an isolated test case? >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> On 23/03/14 12:40, Boaz Nahum wrote: >>>>>>>> Actaully >>>>>>>> '-XDverboseCompilePolicy and >>>>>>>> -Xdiags:verbose' are not >>>>>>>> ignored, it is just that the >>>>>>>> exception occurs too early. If I >>>>>>>> remove '-parameters' then they >>>>>>>> do the work .... >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Mar 23, 2014 at 2:29 PM, >>>>>>>> Boaz Nahum >>>>>>> > wrote: >>>>>>>> >>>>>>>> When compiling our code with >>>>>>>> '-parameters' (1.8.0_20-ea >>>>>>>> and 1.8.0-b132), we got >>>>>>>> this exception: >>>>>>>> >>>>>>>> An exception has occurred in >>>>>>>> the compiler (1.8.0). Please >>>>>>>> file a bug at the Java >>>>>>>> Developer/bugreport) after >>>>>>>> checking the Bug Parade for >>>>>>>> duplicates. Include your >>>>>>>> program and the following >>>>>>>> diagnostic in your report. >>>>>>>> Thank you. >>>>>>>> >>>>>>>> java.lang.ClassCastException: java.lang.String >>>>>>>> cannot be cast to >>>>>>>> com.sun.tools.javac.util.Name >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) >>>>>>>> at >>>>>>>> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >>>>>>>> at >>>>>>>> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >>>>>>>> at >>>>>>>> com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) >>>>>>>> at >>>>>>>> com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) >>>>>>>> at >>>>>>>> com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) >>>>>>>> at >>>>>>>> com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) >>>>>>>> at >>>>>>>> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) >>>>>>>> at >>>>>>>> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Enter.complete(Enter.java:497) >>>>>>>> at >>>>>>>> com.sun.tools.javac.comp.Enter.main(Enter.java:475) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:523) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:381) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:370) >>>>>>>> at >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:361) >>>>>>>> at >>>>>>>> com.sun.tools.javac.Main.compile(Main.java:56) >>>>>>>> at >>>>>>>> com.sun.tools.javac.Main.main(Main.java:42) >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Boaz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In order to isolate the >>>>>>>> problematic code, I add >>>>>>>> -XDverboseCompilePolicy and >>>>>>>> -Xdiags:verbose, without luck. >>>>>>>> Why they are ignored ? >>>>>>>> >>>>>>>> Please note that an >>>>>>>> annotation processor is >>>>>>>> involved. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 303 bytes Desc: not available URL: From cushon at google.com Tue Mar 25 23:10:01 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 25 Mar 2014 16:10:01 -0700 Subject: javac8 with jdk7 In-Reply-To: <5332085A.1050206@oracle.com> References: <5331FCEB.8080101@oracle.com> <5332085A.1050206@oracle.com> Message-ID: Hi Jon, I was interested in running javac 8 on the JRE 7 to compile java 7 code. In that case my understanding is that you do need to set the JVM's bootclasspath, since javac itself depends on classes from the latest JRE. A more concrete question is whether it's desirable for javac to depend on the latest versions of platform libraries when there are alternatives. For example: - the filemanager implementation could use the FileManager.Location interface instead of depending on specific StandardLocation values - Source.toSourceVersion(...) could return only the SourceVersion values that are present in the current platform, instead of requiring that the latest version is available Liam On Tue, Mar 25, 2014 at 3:51 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Well, you've jumped all the way to -Xbootclasspath/p:. You jumped over > -bootclasspath alias -Xbootclasspath which are more likely candidates for > what it seems you are trying to do. > > If you want to set the platform libraries for your compilation, > -bootclasspath is the way to go. And, in case it is not obvious, note > that -bootclasspath, -Xbootclasspath and its variants are all options to > javac itself, and not to the underlying JVM. > > -- Jon > > > On 03/25/2014 03:35 PM, Martin Buchholz wrote: > > Often software is structured above the level of a process invocation. > Imagine a jre7 with an api that included a parameter where to find a javac > implementation, that would get loaded via a URLClassLoader. You could even > run multiple javac versions in the same java process at the same time in > separate classloaders. Because javac is "just" another java application. > Almost. Another way of looking at it is that the -Xbootclasspath/p: hack > is deeply non-modular. But I can understand if you're maintaining > the -Xbootclasspath/p: hack just to bootstrap-build the jdk itself. > > > On Tue, Mar 25, 2014 at 3:02 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> On 03/25/2014 02:04 PM, Liam Miller-Cushon wrote: >> >> Hi, >> >> I'm curious if there's any interest in reducing javac's dependence on >> the specific JDK version it's running on. Currently javac8 works with jdk7 >> only if it's on the jvm's bootclasspath, because of some changes to the >> javax classes that are also in rt.jar. (Specifically: the addition of >> StandardLocation.NATIVE_HEADER_OUTPUT and SourceVersion.RELEASE_8.) >> >> Being able to run javacN on at least jdkN-1 would be convenient when >> working with code that invokes javac programmatically, since configuring >> the bootclasspath complicates deployment. >> >> Any thoughts on whether this would be worthwhile? >> >> Thanks, >> Liam >> >> >> Liam, >> >> Because of the way we bootstrap the JDK build, it is a requirement that >> javac N must be able to run on JRE N-1. >> >> I can't quite untangle your second sentence (beginning "Currently...) so >> it would help if you could explain your perceived issues a bit more. >> >> Your issues about configuring the bootclasspath may hint at your >> issues. Any time you want to compile against a different version of the >> libraries other than those native to the underlying JVM, you have to set >> the bootclasspath, at least for now. There are ideas about a new >> -platform option which would supercede -source, -target and -bootclasspath. >> But that would only allow you to compile for earlier versions (i.e. just >> like the -source and -target options today). >> >> But I suspect you are wanting to compile for future versions. e.g. you >> are suggesting that it should be possible to run a variant of javac 8 on >> JDK 7, such that the variant has bound within it a copy of the JRE 8 >> libraries that are normally found on the JRE 8 bootclasspath. Technically, >> that could certainly be done; I'm not sure it is generally worthwhile, >> though. If the only issue is that "configuring the bootclasspath >> complicates deployment" then the solution should be as simple as a modified >> bundle, with the extra libraries added, and a wrapper script for javac that >> sets the bootclasspath for you, before calling the desired version of javac. >> >> -- Jon >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Mar 26 00:08:18 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Mar 2014 17:08:18 -0700 Subject: javac8 with jdk7 In-Reply-To: References: <5331FCEB.8080101@oracle.com> <5332085A.1050206@oracle.com> Message-ID: <53321A72.2090900@oracle.com> On 03/25/2014 04:10 PM, Liam Miller-Cushon wrote: > Hi Jon, > > I was interested in running javac 8 on the JRE 7 to compile java 7 > code. In that case my understanding is that you do need to set the > JVM's bootclasspath, since javac itself depends on classes from the > latest JRE. > > A more concrete question is whether it's desirable for javac to depend > on the latest versions of platform libraries when there are > alternatives. For example: > - the filemanager implementation could use the FileManager.Location > interface instead of depending on specific StandardLocation values > - Source.toSourceVersion(...) could return only the SourceVersion > values that are present in the current platform, instead of requiring > that the latest version is available > > Liam OK, I think I finally see the issue that you may be addressing. I think you're saying that javac 8 depends on some enum constants in the JDK 8 rt.jar. To be specific, it depends on javax.tools.StandardLocation.NATIVE_HEADER_OUTPUT and javax.lang.model.SourceVersion.RELEASE_8. So yes, at some level, this is a bug. For what it's worth, we don't see this problem when bootstrapping JDK because the classes in question are part of the "interim" version of javac used for the bootstrap, and yes, I guess we do use -Xbootclasspath/p: to override the classes in the bootstrap JDK, so now I maybe understand Martin's comment as well. With respect to your suggestions, yes I can see that it would be technically feasible to dynamically determine is SourceVersion.RELEASE_8 was defined and to avoid trying to return it. But NATIVE_HEADER_OUTPUT is a bigger problem. We *do* expect JDK 8 clients to use the StandardLocation values, and so javac must support them. But we could simply disable the native header feature entirely if we're running on top of JDK 7, meaning we would dynamically determine if NATIVE_HEADER_OUTPUT was defined and deal with it if it was not. -- Jon From martinrb at google.com Wed Mar 26 00:36:03 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 25 Mar 2014 17:36:03 -0700 Subject: javac8 with jdk7 In-Reply-To: <53321A72.2090900@oracle.com> References: <5331FCEB.8080101@oracle.com> <5332085A.1050206@oracle.com> <53321A72.2090900@oracle.com> Message-ID: I think we understand each other now. And it seems you would be willing to accept a change that would allow jdk8 to work within a jre7 as a normal application with possibly degraded functionality - e.g. when acting as a "better javac7" On Tue, Mar 25, 2014 at 5:08 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > On 03/25/2014 04:10 PM, Liam Miller-Cushon wrote: > >> Hi Jon, >> >> I was interested in running javac 8 on the JRE 7 to compile java 7 code. >> In that case my understanding is that you do need to set the JVM's >> bootclasspath, since javac itself depends on classes from the latest JRE. >> >> A more concrete question is whether it's desirable for javac to depend on >> the latest versions of platform libraries when there are alternatives. For >> example: >> - the filemanager implementation could use the FileManager.Location >> interface instead of depending on specific StandardLocation values >> - Source.toSourceVersion(...) could return only the SourceVersion values >> that are present in the current platform, instead of requiring that the >> latest version is available >> >> Liam >> > > OK, I think I finally see the issue that you may be addressing. > > I think you're saying that javac 8 depends on some enum constants in the > JDK 8 rt.jar. To be specific, it depends on javax.tools.StandardLocation.NATIVE_HEADER_OUTPUT > and javax.lang.model.SourceVersion.RELEASE_8. > > So yes, at some level, this is a bug. For what it's worth, we don't see > this problem when bootstrapping JDK because the classes in question are > part of the "interim" version of javac used for the bootstrap, and yes, I > guess we do use -Xbootclasspath/p: to override the classes in the bootstrap > JDK, so now I maybe understand Martin's comment as well. > > With respect to your suggestions, yes I can see that it would be > technically feasible to dynamically determine is SourceVersion.RELEASE_8 > was defined and to avoid trying to return it. But NATIVE_HEADER_OUTPUT is a > bigger problem. We *do* expect JDK 8 clients to use the StandardLocation > values, and so javac must support them. But we could simply disable the > native header feature entirely if we're running on top of JDK 7, meaning we > would dynamically determine if NATIVE_HEADER_OUTPUT was defined and deal > with it if it was not. > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Mar 26 01:07:56 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Mar 2014 18:07:56 -0700 Subject: javac8 with jdk7 In-Reply-To: References: <5331FCEB.8080101@oracle.com> <5332085A.1050206@oracle.com> <53321A72.2090900@oracle.com> Message-ID: <5332286C.1060500@oracle.com> Well, it has always been the intent to be able to run javac N on JRE N-1, albeit currently with some inelegancies. If we can do that in a cleaner way, without disturbing the code too much, then that's probably a good idea. -- Jon On 03/25/2014 05:36 PM, Martin Buchholz wrote: > I think we understand each other now. And it seems you would be > willing to accept a change that would allow jdk8 to work within a jre7 > as a normal application with possibly degraded functionality - e.g. > when acting as a "better javac7" > > > On Tue, Mar 25, 2014 at 5:08 PM, Jonathan Gibbons > > wrote: > > On 03/25/2014 04:10 PM, Liam Miller-Cushon wrote: > > Hi Jon, > > I was interested in running javac 8 on the JRE 7 to compile > java 7 code. In that case my understanding is that you do need > to set the JVM's bootclasspath, since javac itself depends on > classes from the latest JRE. > > A more concrete question is whether it's desirable for javac > to depend on the latest versions of platform libraries when > there are alternatives. For example: > - the filemanager implementation could use the > FileManager.Location interface instead of depending on > specific StandardLocation values > - Source.toSourceVersion(...) could return only the > SourceVersion values that are present in the current platform, > instead of requiring that the latest version is available > > Liam > > > OK, I think I finally see the issue that you may be addressing. > > I think you're saying that javac 8 depends on some enum constants > in the JDK 8 rt.jar. To be specific, it depends on > javax.tools.StandardLocation.NATIVE_HEADER_OUTPUT and > javax.lang.model.SourceVersion.RELEASE_8. > > So yes, at some level, this is a bug. For what it's worth, we > don't see this problem when bootstrapping JDK because the classes > in question are part of the "interim" version of javac used for > the bootstrap, and yes, I guess we do use -Xbootclasspath/p: to > override the classes in the bootstrap JDK, so now I maybe > understand Martin's comment as well. > > With respect to your suggestions, yes I can see that it would be > technically feasible to dynamically determine is > SourceVersion.RELEASE_8 was defined and to avoid trying to return > it. But NATIVE_HEADER_OUTPUT is a bigger problem. We *do* expect > JDK 8 clients to use the StandardLocation values, and so javac > must support them. But we could simply disable the native header > feature entirely if we're running on top of JDK 7, meaning we > would dynamically determine if NATIVE_HEADER_OUTPUT was defined > and deal with it if it was not. > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Mar 26 01:45:11 2014 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 25 Mar 2014 18:45:11 -0700 Subject: javac8 with jdk7 In-Reply-To: <53321A72.2090900@oracle.com> References: <5331FCEB.8080101@oracle.com> <5332085A.1050206@oracle.com> <53321A72.2090900@oracle.com> Message-ID: <53323127.5000104@oracle.com> Hello, On 3/25/2014 5:08 PM, Jonathan Gibbons wrote: > On 03/25/2014 04:10 PM, Liam Miller-Cushon wrote: >> Hi Jon, >> >> I was interested in running javac 8 on the JRE 7 to compile java 7 >> code. In that case my understanding is that you do need to set the >> JVM's bootclasspath, since javac itself depends on classes from the >> latest JRE. >> >> A more concrete question is whether it's desirable for javac to >> depend on the latest versions of platform libraries when there are >> alternatives. For example: >> - the filemanager implementation could use the FileManager.Location >> interface instead of depending on specific StandardLocation values >> - Source.toSourceVersion(...) could return only the SourceVersion >> values that are present in the current platform, instead of requiring >> that the latest version is available >> >> Liam > > OK, I think I finally see the issue that you may be addressing. > > I think you're saying that javac 8 depends on some enum constants in > the JDK 8 rt.jar. To be specific, it depends on > javax.tools.StandardLocation.NATIVE_HEADER_OUTPUT and > javax.lang.model.SourceVersion.RELEASE_8. For the purposes of running a Java compiler for JDK version N on top of JDK version (N-1), JSRs 199 and 269, which define the javax.tools, javax.anotation.processing, and javax.lang.model.* APIs, are usable stand alone as well as being bundled as part of the JDK. In other words, the right way to run a Java SE 8 compiler on top of a JDK 7 is to have a jar file with the 199 and 269 APIs and pop that into the right path to override the system-provided versions of those APIs. > > So yes, at some level, this is a bug. For what it's worth, we don't > see this problem when bootstrapping JDK because the classes in > question are part of the "interim" version of javac used for the > bootstrap, and yes, I guess we do use -Xbootclasspath/p: to override > the classes in the bootstrap JDK, so now I maybe understand Martin's > comment as well. > > With respect to your suggestions, yes I can see that it would be > technically feasible to dynamically determine is > SourceVersion.RELEASE_8 was defined and to avoid trying to return it. > But NATIVE_HEADER_OUTPUT is a bigger problem. We *do* expect JDK 8 > clients to use the StandardLocation values, and so javac must support > them. But we could simply disable the native header feature entirely > if we're running on top of JDK 7, meaning we would dynamically > determine if NATIVE_HEADER_OUTPUT was defined and deal with it if it > was not. > > -- Jon I generally don't think it is a problem for javac in JDK N to directly reference new-in-JDK-N javac-related APIs. On the contrary, to the limited extent I do javac development, I would prefer if language and platform features could be used sooner and more directly in javac than they are now. -Joe From jonathan.gibbons at oracle.com Wed Mar 26 02:01:41 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Mar 2014 19:01:41 -0700 Subject: javac8 with jdk7 In-Reply-To: <53323127.5000104@oracle.com> References: <5331FCEB.8080101@oracle.com> <5332085A.1050206@oracle.com> <53321A72.2090900@oracle.com> <53323127.5000104@oracle.com> Message-ID: <53323505.2050905@oracle.com> On 03/25/2014 06:45 PM, Joseph Darcy wrote: > Hello, > > On 3/25/2014 5:08 PM, Jonathan Gibbons wrote: >> On 03/25/2014 04:10 PM, Liam Miller-Cushon wrote: >>> Hi Jon, >>> >>> I was interested in running javac 8 on the JRE 7 to compile java 7 >>> code. In that case my understanding is that you do need to set the >>> JVM's bootclasspath, since javac itself depends on classes from the >>> latest JRE. >>> >>> A more concrete question is whether it's desirable for javac to >>> depend on the latest versions of platform libraries when there are >>> alternatives. For example: >>> - the filemanager implementation could use the FileManager.Location >>> interface instead of depending on specific StandardLocation values >>> - Source.toSourceVersion(...) could return only the SourceVersion >>> values that are present in the current platform, instead of >>> requiring that the latest version is available >>> >>> Liam >> >> OK, I think I finally see the issue that you may be addressing. >> >> I think you're saying that javac 8 depends on some enum constants in >> the JDK 8 rt.jar. To be specific, it depends on >> javax.tools.StandardLocation.NATIVE_HEADER_OUTPUT and >> javax.lang.model.SourceVersion.RELEASE_8. > > For the purposes of running a Java compiler for JDK version N on top > of JDK version (N-1), JSRs 199 and 269, which define the javax.tools, > javax.anotation.processing, and javax.lang.model.* APIs, are usable > stand alone as well as being bundled as part of the JDK. > > In other words, the right way to run a Java SE 8 compiler on top of a > JDK 7 is to have a jar file with the 199 and 269 APIs and pop that > into the right path to override the system-provided versions of those > APIs. I agree, if you want a Java SE 8 compiler. But the underlying question is, do we want to support javac 8 as an implementation of the 7-version of the 199 and 269 APIs? > >> >> So yes, at some level, this is a bug. For what it's worth, we don't >> see this problem when bootstrapping JDK because the classes in >> question are part of the "interim" version of javac used for the >> bootstrap, and yes, I guess we do use -Xbootclasspath/p: to override >> the classes in the bootstrap JDK, so now I maybe understand Martin's >> comment as well. >> >> With respect to your suggestions, yes I can see that it would be >> technically feasible to dynamically determine is >> SourceVersion.RELEASE_8 was defined and to avoid trying to return it. >> But NATIVE_HEADER_OUTPUT is a bigger problem. We *do* expect JDK 8 >> clients to use the StandardLocation values, and so javac must support >> them. But we could simply disable the native header feature entirely >> if we're running on top of JDK 7, meaning we would dynamically >> determine if NATIVE_HEADER_OUTPUT was defined and deal with it if it >> was not. >> >> -- Jon > > I generally don't think it is a problem for javac in JDK N to directly > reference new-in-JDK-N javac-related APIs. On the contrary, to the > limited extent I do javac development, I would prefer if language and > platform features could be used sooner and more directly in javac than > they are now. > I agree that being able to use new language features sooner is an admirable goal. But there will always be competing pragmatic goals, not least the bootstrapping requirement. So we should always be open to using new features less if it satisfies more of the overall set of goals for the product. > -Joe From jeremymanson at google.com Wed Mar 26 06:54:31 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 25 Mar 2014 23:54:31 -0700 Subject: javac8 with jdk7 In-Reply-To: <53323505.2050905@oracle.com> References: <5331FCEB.8080101@oracle.com> <5332085A.1050206@oracle.com> <53321A72.2090900@oracle.com> <53323127.5000104@oracle.com> <53323505.2050905@oracle.com> Message-ID: It seems to me that javac should either be officially Java N-1 compliant or officially not. Since Java N-1 compliance is a requirement for bootstrapping (which is SOP for most compiler implementations), it makes a certain amount of sense to have it be officially Java N-1 compliant, treat violations of that property as bugs, and welcome appropriate patches. Having it be mostly Java N-1 compliant, but not really, because there are some classes that need to sneak onto the bootclasspath, is just confusing. (Yes, I understand that people like us are the only ones this is ever likely to bite, and that there aren't many people like us.) (You may argue that we should just use whatever JDK came with the javac. However, from a selfish standpoint, we'd like to use a relatively close to head javac, and we don't *really* want to use a relatively close to head rest-of-the-JDK, because it is much harder to make sure that a bleeding edge JVM works than it is to make sure that a bleeding edge javac works. Case in point, 8036100.) Jeremy On Tue, Mar 25, 2014 at 7:01 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > On 03/25/2014 06:45 PM, Joseph Darcy wrote: > >> Hello, >> >> On 3/25/2014 5:08 PM, Jonathan Gibbons wrote: >> >>> On 03/25/2014 04:10 PM, Liam Miller-Cushon wrote: >>> >>>> Hi Jon, >>>> >>>> I was interested in running javac 8 on the JRE 7 to compile java 7 >>>> code. In that case my understanding is that you do need to set the JVM's >>>> bootclasspath, since javac itself depends on classes from the latest JRE. >>>> >>>> A more concrete question is whether it's desirable for javac to depend >>>> on the latest versions of platform libraries when there are alternatives. >>>> For example: >>>> - the filemanager implementation could use the FileManager.Location >>>> interface instead of depending on specific StandardLocation values >>>> - Source.toSourceVersion(...) could return only the SourceVersion >>>> values that are present in the current platform, instead of requiring that >>>> the latest version is available >>>> >>>> Liam >>>> >>> >>> OK, I think I finally see the issue that you may be addressing. >>> >>> I think you're saying that javac 8 depends on some enum constants in the >>> JDK 8 rt.jar. To be specific, it depends on javax.tools.StandardLocation.NATIVE_HEADER_OUTPUT >>> and javax.lang.model.SourceVersion.RELEASE_8. >>> >> >> For the purposes of running a Java compiler for JDK version N on top of >> JDK version (N-1), JSRs 199 and 269, which define the javax.tools, >> javax.anotation.processing, and javax.lang.model.* APIs, are usable stand >> alone as well as being bundled as part of the JDK. >> >> In other words, the right way to run a Java SE 8 compiler on top of a JDK >> 7 is to have a jar file with the 199 and 269 APIs and pop that into the >> right path to override the system-provided versions of those APIs. >> > > > I agree, if you want a Java SE 8 compiler. But the underlying question > is, do we want to support javac 8 as an implementation of the 7-version of > the 199 and 269 APIs? > > > >> >>> So yes, at some level, this is a bug. For what it's worth, we don't see >>> this problem when bootstrapping JDK because the classes in question are >>> part of the "interim" version of javac used for the bootstrap, and yes, I >>> guess we do use -Xbootclasspath/p: to override the classes in the bootstrap >>> JDK, so now I maybe understand Martin's comment as well. >>> >>> With respect to your suggestions, yes I can see that it would be >>> technically feasible to dynamically determine is SourceVersion.RELEASE_8 >>> was defined and to avoid trying to return it. But NATIVE_HEADER_OUTPUT is a >>> bigger problem. We *do* expect JDK 8 clients to use the StandardLocation >>> values, and so javac must support them. But we could simply disable the >>> native header feature entirely if we're running on top of JDK 7, meaning we >>> would dynamically determine if NATIVE_HEADER_OUTPUT was defined and deal >>> with it if it was not. >>> >>> -- Jon >>> >> >> I generally don't think it is a problem for javac in JDK N to directly >> reference new-in-JDK-N javac-related APIs. On the contrary, to the limited >> extent I do javac development, I would prefer if language and platform >> features could be used sooner and more directly in javac than they are now. >> >> > I agree that being able to use new language features sooner is an > admirable goal. But there will always be competing pragmatic goals, not > least the bootstrapping requirement. So we should always be open to using > new features less if it satisfies more of the overall set of goals for the > product. > > -Joe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.franck at oracle.com Wed Mar 26 08:34:36 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 26 Mar 2014 09:34:36 +0100 Subject: javac8 with jdk7 In-Reply-To: References: <5331FCEB.8080101@oracle.com> <5332085A.1050206@oracle.com> <53321A72.2090900@oracle.com> <53323127.5000104@oracle.com> <53323505.2050905@oracle.com> Message-ID: Hi, On 26 mar 2014, at 07:54, Jeremy Manson wrote: > It seems to me that javac should either be officially Java N-1 compliant or officially not. Since Java N-1 compliance is a requirement for bootstrapping (which is SOP for most compiler implementations), it makes a certain amount of sense to have it be officially Java N-1 compliant, treat violations of that property as bugs, and welcome appropriate patches. > > Having it be mostly Java N-1 compliant, but not really, because there are some classes that need to sneak onto the bootclasspath, is just confusing. > Well there is build time compliant and run time compliant, if the cost is too high I don't see a problem with being 100% build time compliant but not at all run time compliant. But I agree with what I think Jon is saying, having javac run with JRE n-1 in a degraded state would be a nice contribution if the patches aren't too intrusive. cheers /Joel From jan.lahoda at oracle.com Wed Mar 26 10:30:16 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 26 Mar 2014 11:30:16 +0100 Subject: javac8 with jdk7 In-Reply-To: References: <5331FCEB.8080101@oracle.com> <5332085A.1050206@oracle.com> <53321A72.2090900@oracle.com> <53323127.5000104@oracle.com> <53323505.2050905@oracle.com> Message-ID: <5332AC38.8080704@oracle.com> On 03/26/2014 07:54 AM, Jeremy Manson wrote: > It seems to me that javac should either be officially Java N-1 compliant > or officially not. Since Java N-1 compliance is a requirement for > bootstrapping (which is SOP for most compiler implementations), it makes > a certain amount of sense to have it be officially Java N-1 compliant, > treat violations of that property as bugs, and welcome appropriate patches. > > Having it be mostly Java N-1 compliant, but not really, because there > are some classes that need to sneak onto the bootclasspath, is just > confusing. As a note, there are enhancements to the javax.lang.model.** APIs in 8, notably TypeKind.INTERSECTION, Modifier.DEFAULT and related changes, that may need to be included in the consideration as well. > > (Yes, I understand that people like us are the only ones this is ever > likely to bite, and that there aren't many people like us.) FWIW, at runtime, NetBeans is solving a similar problem using classloader magic. But the NetBeans usecase is somewhat different, as NetBeans wants to see a specific version of the model. Jan > > (You may argue that we should just use whatever JDK came with the javac. > However, from a selfish standpoint, we'd like to use a relatively > close to head javac, and we don't *really* want to use a relatively > close to head rest-of-the-JDK, because it is much harder to make sure > that a bleeding edge JVM works than it is to make sure that a bleeding > edge javac works. Case in point, 8036100.) > > Jeremy > > > On Tue, Mar 25, 2014 at 7:01 PM, Jonathan Gibbons > > wrote: > > On 03/25/2014 06:45 PM, Joseph Darcy wrote: > > Hello, > > On 3/25/2014 5:08 PM, Jonathan Gibbons wrote: > > On 03/25/2014 04:10 PM, Liam Miller-Cushon wrote: > > Hi Jon, > > I was interested in running javac 8 on the JRE 7 to > compile java 7 code. In that case my understanding is > that you do need to set the JVM's bootclasspath, since > javac itself depends on classes from the latest JRE. > > A more concrete question is whether it's desirable for > javac to depend on the latest versions of platform > libraries when there are alternatives. For example: > - the filemanager implementation could use the > FileManager.Location interface instead of depending on > specific StandardLocation values > - Source.toSourceVersion(...) could return only the > SourceVersion values that are present in the current > platform, instead of requiring that the latest version > is available > > Liam > > > OK, I think I finally see the issue that you may be addressing. > > I think you're saying that javac 8 depends on some enum > constants in the JDK 8 rt.jar. To be specific, it depends on > javax.tools.StandardLocation.__NATIVE_HEADER_OUTPUT and > javax.lang.model.__SourceVersion.RELEASE_8. > > > For the purposes of running a Java compiler for JDK version N on > top of JDK version (N-1), JSRs 199 and 269, which define the > javax.tools, javax.anotation.processing, and javax.lang.model.* > APIs, are usable stand alone as well as being bundled as part of > the JDK. > > In other words, the right way to run a Java SE 8 compiler on top > of a JDK 7 is to have a jar file with the 199 and 269 APIs and > pop that into the right path to override the system-provided > versions of those APIs. > > > > I agree, if you want a Java SE 8 compiler. But the underlying > question is, do we want to support javac 8 as an implementation of > the 7-version of the 199 and 269 APIs? > > > > > So yes, at some level, this is a bug. For what it's worth, > we don't see this problem when bootstrapping JDK because the > classes in question are part of the "interim" version of > javac used for the bootstrap, and yes, I guess we do use > -Xbootclasspath/p: to override the classes in the bootstrap > JDK, so now I maybe understand Martin's comment as well. > > With respect to your suggestions, yes I can see that it > would be technically feasible to dynamically determine is > SourceVersion.RELEASE_8 was defined and to avoid trying to > return it. But NATIVE_HEADER_OUTPUT is a bigger problem. We > *do* expect JDK 8 clients to use the StandardLocation > values, and so javac must support them. But we could simply > disable the native header feature entirely if we're running > on top of JDK 7, meaning we would dynamically determine if > NATIVE_HEADER_OUTPUT was defined and deal with it if it was not. > > -- Jon > > > I generally don't think it is a problem for javac in JDK N to > directly reference new-in-JDK-N javac-related APIs. On the > contrary, to the limited extent I do javac development, I would > prefer if language and platform features could be used sooner > and more directly in javac than they are now. > > > I agree that being able to use new language features sooner is an > admirable goal. But there will always be competing pragmatic goals, > not least the bootstrapping requirement. So we should always be open > to using new features less if it satisfies more of the overall set > of goals for the product. > > -Joe > > > From boaznahum at gmail.com Thu Mar 27 12:01:23 2014 From: boaznahum at gmail.com (Boaz Nahum) Date: Thu, 27 Mar 2014 14:01:23 +0200 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: <53320A4F.4050305@oracle.com> References: <532F3386.5070901@oracle.com> <533015EF.8090703@oracle.com> <53303459.8000604@oracle.com> <53303707.7080909@oracle.com> <533038A4.9020503@oracle.com> <533088A8.5000803@oracle.com> <53308D8B.8060705@oracle.com> <53320A4F.4050305@oracle.com> Message-ID: Hi. Please accept my apologies. I was in process of send you the isolate project the re-produce the bug, I wrote an ANT file, but when I try to compile it I was unable to reproduce the bug. So after long investigation I found that the problem is not in javac but with "jetbrains @NotNull" byte instrumentation - which produce the wrong .class http://youtrack.jetbrains.com/issue/IDEA-123001 Please accept my apologies for wasting everyone time. Boaz On Wed, Mar 26, 2014 at 12:59 AM, Eric McCorkle wrote: > Coming in a bit late here, see replies inline. > > On 03/25/14 12:03, Boaz Nahum wrote: > > Hi. > > > > > > First, with your help, I managed to isolate some piece of code that > > reproduce similar crash ( By 'isolate' I mean 45 files that I can send > > you out of 80K). > > > > ('Similar' means 'Information:java: java.lang.ClassCastException: > > com.sun.tools.javac.jvm.ClassFile$NameAndType cannot be cast to > > com.sun.tools.javac.util.Name ' ) > > My intuition, based on what I've seen earlier in the thread, is that > there's a problem with javac reading method parameter data back out of a > class file. That is why you are seeing it only on source that depends > on something compiled with -parameters. The problem isn't with the > source you're compiling; it's with the class files that get read. > > > > > But now the crash only with 1.8.0u20 but not with > > http://hg.openjdk.java.net/jdk8/tl/ > > That is strange. I'm not aware that parameter reflection has been > changed in 8u20 yet. > > > On the other hand, in our huge project it happens also with > > http://hg.openjdk.java.net/jdk8/tl/ > > > > So I guess I didn't isolated it completely. > > > > Second. this crash happens only if 'annotation processor' is involved. > > That is helpful, though I'm not sure what it means offhand. > > > So, I don't know if it worth the effort to send you the files (and short > > description how to build them) ? > > > > Thanks > > Boaz > > > > > > > > On Mon, Mar 24, 2014 at 9:54 PM, Vicente-Arturo Romero-Zaldivar > > > wrote: > > > > On 24/03/14 19:41, Boaz Nahum wrote: > >> > >> Of curse you can ( why not mention my name :) ? ) > >> > > > > :) just in case you didn't want but I have no problem with adding > > your name and / or mail > > > > > >> Anyway, do you already know what the bug is ? Can you share the > >> bug ID with me ? > >> > > > > I haven't created it yet but I will send you the id once I have it. > > > > > >> I will try to isolate the code and send it to you. > >> > > > > Thanks, > > Vicente > > > > > >> The > >> Boaz > >> > >> On Mar 24, 2014 9:34 PM, "Vicente-Arturo Romero-Zaldivar" > >> > > wrote: > >> > >> Thanks Boaz, > >> > >> I will add all this info in a bug report. Can I use this test > >> case to write a mail, probably a blog in the future, about > >> obtaining extra information from hard bugs? I won't mention > >> your name. My idea is to write some info that may help other > >> users to provide more information associated to a crash or bug. > >> > >> Thanks, > >> Vicente > >> > >> On 24/03/14 17:31, Boaz Nahum wrote: > >>> Comment out > >>> //@NotNull > >>> //public static T createSingleton(final Class >>> extends DIGlobalCxPDD> dd) { > >>> // > >>> // return Singletons.createNonNull(dd, new > >>> Factory0Adapter() { > >>> // @Override > >>> // public T get() { > >>> // return createWithContext(dd, null, null); > >>> // } > >>> // }); > >>> //} > >>> > >>> > --------------------------------------------------------------------- > >>> Brings a new exception: > >>> > >>> > >>> > >>> ********************* error in file > >>> > F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob > >>> al/DIFW.class) > >>> ********************* while trying to read constant pool entry > 72 > >>> > >>> #70 = Utf8 all > >>> #71 = Utf8 > >>> Ljava/util/List<+Lwf/core/util/factory/Factory<+TT;-TP;>;>; > >>> #72 = Utf8 Ljava/util/List; > >>> #73 = Utf8 get0 > >>> #74 = Utf8 > >>> (Ljava/lang/Class;)Lwf/core/util/factory/Factory0; > >>> > >>> Comment out: > >>> > >>> //List> all > >>> = DIFWImp.getAll(dd, context); > >>> > >>> //noinspection unchecked > >>> return null;//(List>)all; > >>> > >>> > --------------------------------------------------------------------- > >>> > >>> Brings a new exception: > >>> > >>> ********************* while trying to read constant pool > >>> entry 162 > >>> > >>> #161 = Utf8 > >>> > Ljava/lang/Class<+Lwf/core/util/factory/di/core/DIAbstractDD<-Ljava/lang/Void;+TT;-TP;>;>; > >>> #162 = Utf8 wf/core/util/packing/Params2 > >>> #163 = Class #162 // > >>> wf/core/util/packing/Params2 > >>> #164 = Utf8 > >>> > (Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; > >>> #165 = NameAndType #34:#164 // > >>> > create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; > >>> #166 = Methodref #163.#165 // > >>> > wf/core/util/packing/Params2.create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; > >>> #167 = Utf8 > >>> > Ljava/lang/Class<+Lwf/core/util/factory/di/factory/DIGlobalCxPDD;>;>; > >>> > >>> > >>> > >>> Thx > >>> Boaz > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Mon, Mar 24, 2014 at 6:40 PM, Boaz Nahum > >>> > wrote: > >>> > >>> Thx > >>> > >>> ********************* error in file > >>> > F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob > >>> al/DIFW.class) > >>> ********************* while trying to read constant > >>> pool entry 64 > >>> > >>> Attachedfiles DIFW{.java, .class,$*.class} > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Mon, Mar 24, 2014 at 3:52 PM, Vicente-Arturo > >>> Romero-Zaldivar >>> > wrote: > >>> > >>> On 24/03/14 13:50, Boaz Nahum wrote: > >>>> is repo http://hg.openjdk.java.net/jdk8/jdk8 is good > >>>> enough, or maybe other > >>> > >>> Please use this one: > http://hg.openjdk.java.net/jdk8/tl/ > >>> > >>> > >>>> > >>>> > >>>> On Mon, Mar 24, 2014 at 3:45 PM, Vicente-Arturo > >>>> Romero-Zaldivar >>>> > wrote: > >>>> > >>>> I usually do this with Linux, if you have Linux > >>>> you can go to your jdk repo, to the langtools > >>>> folder and do: > >>>> > >>>> patch -p1 < /path/to/mypatch > >>>> > >>>> after that you can rebuild again the jdk and you > >>>> will have the patched javac. > >>>> > >>>> Vicente > >>>> > >>>> > >>>> On 24/03/14 13:41, Boaz Nahum wrote: > >>>>> Please send my link to instruction how to apply > >>>>> pathc (I know how to compile JDK, never before > >>>>> applied a patch) > >>>>> > >>>>> > >>>>> On Mon, Mar 24, 2014 at 3:34 PM, Vicente-Arturo > >>>>> Romero-Zaldivar >>>>> > wrote: > >>>>> > >>>>> Hi Boaz, > >>>>> > >>>>> Please try the attached patch and send me > >>>>> the obtained information along with the > >>>>> failing .class file. > >>>>> > >>>>> Thanks, > >>>>> Vicente > >>>>> > >>>>> > >>>>> On 24/03/14 13:07, Boaz Nahum wrote: > >>>>>> It happens both with 1.8.0_20-ea and > >>>>>> 1.8.0-b132 > >>>>>> > >>>>>> The javac (with -verbose) output > >>>>>> > https://drive.google.com/file/d/0B4MyZ6FK5jswZVZWV0VMSnE3c0k/edit?usp=sharing > >>>>>> > >>>>>> I didn't tired with > >>>>>> > http://hg.openjdk.java.net/jdk9/dev/langtools/ > >>>>>> I need to re-setup by jdk build environment > >>>>>> > >>>>>> > >>>>>> many thanks > >>>>>> Boaz > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Mar 24, 2014 at 1:24 PM, > >>>>>> Vicente-Arturo Romero-Zaldivar > >>>>>> >>>>>> > wrote: > >>>>>> > >>>>>> Hi Boaz, > >>>>>> > >>>>>> OK it seems like we both need more > >>>>>> information :) > >>>>>> > >>>>>> What version of javac is this? Can you > >>>>>> get the last javac from > >>>>>> > http://hg.openjdk.java.net/jdk9/dev/langtools/ > >>>>>> and try to reproduce the issue? Do you > >>>>>> get any meaningful information after > >>>>>> executing javac with plain "-verbose" > >>>>>> option? > >>>>>> > >>>>>> Thanks, > >>>>>> Vicente > >>>>>> > >>>>>> > >>>>>> On 24/03/14 07:10, Boaz Nahum wrote: > >>>>>>> > >>>>>>> That what I'm asking help for - to > >>>>>>> isolate the problematic source. > >>>>>>> But from what I learnt - it is > >>>>>>> combination of source and > >>>>>>> dependencies. The same source > >>>>>>> ***passed*** if it is complied with a > >>>>>>> dependency that wasn't compile with > >>>>>>> "-parameters". > >>>>>>> What I need is a flag (or a patch) > >>>>>>> that causes the compiler to emit > >>>>>>> verbose information > >>>>>>> > >>>>>>> Thanks > >>>>>>> Boaz > >>>>>>> > >>>>>>> On Mar 23, 2014 9:18 PM, > >>>>>>> "Vicente-Arturo Romero-Zaldivar" > >>>>>>> >>>>>>> > > >>>>>>> wrote: > >>>>>>> > >>>>>>> Hi Boaz, > >>>>>>> > >>>>>>> Do you have an isolated test case? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Vicente > >>>>>>> > >>>>>>> On 23/03/14 12:40, Boaz Nahum > wrote: > >>>>>>>> Actaully > >>>>>>>> '-XDverboseCompilePolicy and > >>>>>>>> -Xdiags:verbose' are not > >>>>>>>> ignored, it is just that the > >>>>>>>> exception occurs too early. If I > >>>>>>>> remove '-parameters' then they > >>>>>>>> do the work .... > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sun, Mar 23, 2014 at 2:29 PM, > >>>>>>>> Boaz Nahum >>>>>>>> > > wrote: > >>>>>>>> > >>>>>>>> When compiling our code with > >>>>>>>> '-parameters' (1.8.0_20-ea > >>>>>>>> and 1.8.0-b132), we got > >>>>>>>> this exception: > >>>>>>>> > >>>>>>>> An exception has occurred in > >>>>>>>> the compiler (1.8.0). Please > >>>>>>>> file a bug at the Java > >>>>>>>> Developer/bugreport) after > >>>>>>>> checking the Bug Parade for > >>>>>>>> duplicates. Include your > >>>>>>>> program and the following > >>>>>>>> diagnostic in your report. > >>>>>>>> Thank you. > >>>>>>>> > >>>>>>>> java.lang.ClassCastException: > java.lang.String > >>>>>>>> cannot be cast to > >>>>>>>> com.sun.tools.javac.util.Name< > http://com.sun.tools.javac.util.Name> > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Enter.complete(Enter.java:497) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Enter.main(Enter.java:475) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.main.Main.compile(Main.java:523) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.main.Main.compile(Main.java:381) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.main.Main.compile(Main.java:370) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.main.Main.compile(Main.java:361) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.Main.compile(Main.java:56) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.Main.main(Main.java:42) > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Boaz > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> In order to isolate the > >>>>>>>> problematic code, I add > >>>>>>>> -XDverboseCompilePolicy and > >>>>>>>> -Xdiags:verbose, without luck. > >>>>>>>> Why they are ignored ? > >>>>>>>> > >>>>>>>> Please note that an > >>>>>>>> annotation processor is > >>>>>>>> involved. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Mar 27 13:49:11 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 27 Mar 2014 13:49:11 +0000 Subject: Compiler crash with -parameters - need help to open a bug In-Reply-To: References: <532F3386.5070901@oracle.com> <533015EF.8090703@oracle.com> <53303459.8000604@oracle.com> <53303707.7080909@oracle.com> <533038A4.9020503@oracle.com> <533088A8.5000803@oracle.com> <53308D8B.8060705@oracle.com> <53320A4F.4050305@oracle.com> Message-ID: <53342C57.4000600@oracle.com> Hi Boaz, Don't worry this is part of the process. Thanks for the update and for your interest. I will close the bug. Please let us know if you find any other issue. Thanks, Vicente On 27/03/14 12:01, Boaz Nahum wrote: > Hi. > > Please accept my apologies. > > I was in process of send you the isolate project the re-produce the > bug, I wrote an ANT file, but when I try to compile it I was unable to > reproduce the bug. > So after long investigation I found that the problem is not in javac > but with "jetbrains @NotNull" byte instrumentation - which produce the > wrong .class > http://youtrack.jetbrains.com/issue/IDEA-123001 > > > Please accept my apologies for wasting everyone time. > > Boaz > > > > > On Wed, Mar 26, 2014 at 12:59 AM, Eric McCorkle > > wrote: > > Coming in a bit late here, see replies inline. > > On 03/25/14 12:03, Boaz Nahum wrote: > > Hi. > > > > > > First, with your help, I managed to isolate some piece of code that > > reproduce similar crash ( By 'isolate' I mean 45 files that I > can send > > you out of 80K). > > > > ('Similar' means 'Information:java: java.lang.ClassCastException: > > com.sun.tools.javac.jvm.ClassFile$NameAndType cannot be cast to > > com.sun.tools.javac.util.Name > > ' ) > > My intuition, based on what I've seen earlier in the thread, is that > there's a problem with javac reading method parameter data back > out of a > class file. That is why you are seeing it only on source that depends > on something compiled with -parameters. The problem isn't with the > source you're compiling; it's with the class files that get read. > > > > > But now the crash only with 1.8.0u20 but not with > > http://hg.openjdk.java.net/jdk8/tl/ > > That is strange. I'm not aware that parameter reflection has been > changed in 8u20 yet. > > > On the other hand, in our huge project it happens also with > > http://hg.openjdk.java.net/jdk8/tl/ > > > > So I guess I didn't isolated it completely. > > > > Second. this crash happens only if 'annotation processor' is > involved. > > That is helpful, though I'm not sure what it means offhand. > > > So, I don't know if it worth the effort to send you the files > (and short > > description how to build them) ? > > > > Thanks > > Boaz > > > > > > > > On Mon, Mar 24, 2014 at 9:54 PM, Vicente-Arturo Romero-Zaldivar > > > >> wrote: > > > > On 24/03/14 19:41, Boaz Nahum wrote: > >> > >> Of curse you can ( why not mention my name :) ? ) > >> > > > > :) just in case you didn't want but I have no problem with > adding > > your name and / or mail > > > > > >> Anyway, do you already know what the bug is ? Can you share the > >> bug ID with me ? > >> > > > > I haven't created it yet but I will send you the id once I > have it. > > > > > >> I will try to isolate the code and send it to you. > >> > > > > Thanks, > > Vicente > > > > > >> The > >> Boaz > >> > >> On Mar 24, 2014 9:34 PM, "Vicente-Arturo Romero-Zaldivar" > >> > >> wrote: > >> > >> Thanks Boaz, > >> > >> I will add all this info in a bug report. Can I use > this test > >> case to write a mail, probably a blog in the future, about > >> obtaining extra information from hard bugs? I won't mention > >> your name. My idea is to write some info that may help > other > >> users to provide more information associated to a crash > or bug. > >> > >> Thanks, > >> Vicente > >> > >> On 24/03/14 17:31, Boaz Nahum wrote: > >>> Comment out > >>> //@NotNull > >>> //public static T createSingleton(final Class >>> extends DIGlobalCxPDD> dd) { > >>> // > >>> // return Singletons.createNonNull(dd, new > >>> Factory0Adapter() { > >>> // @Override > >>> // public T get() { > >>> // return createWithContext(dd, null, > null); > >>> // } > >>> // }); > >>> //} > >>> > >>> > --------------------------------------------------------------------- > >>> Brings a new exception: > >>> > >>> > >>> > >>> ********************* error in file > >>> > F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob > >>> al/DIFW.class) > >>> ********************* while trying to read constant > pool entry 72 > >>> > >>> #70 = Utf8 all > >>> #71 = Utf8 > >>> Ljava/util/List<+Lwf/core/util/factory/Factory<+TT;-TP;>;>; > >>> #72 = Utf8 Ljava/util/List; > >>> #73 = Utf8 get0 > >>> #74 = Utf8 > >>> (Ljava/lang/Class;)Lwf/core/util/factory/Factory0; > >>> > >>> Comment out: > >>> > >>> //List P>> all > >>> = DIFWImp.getAll(dd, context); > >>> > >>> //noinspection unchecked > >>> return null;//(List>)all; > >>> > >>> > --------------------------------------------------------------------- > >>> > >>> Brings a new exception: > >>> > >>> ********************* while trying to read constant pool > >>> entry 162 > >>> > >>> #161 = Utf8 > >>> > Ljava/lang/Class<+Lwf/core/util/factory/di/core/DIAbstractDD<-Ljava/lang/Void;+TT;-TP;>;>; > >>> #162 = Utf8 wf/core/util/packing/Params2 > >>> #163 = Class #162 // > >>> wf/core/util/packing/Params2 > >>> #164 = Utf8 > >>> > (Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; > >>> #165 = NameAndType #34:#164 // > >>> > create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; > >>> #166 = Methodref #163.#165 // > >>> > wf/core/util/packing/Params2.create:(Ljava/lang/Object;Ljava/lang/Object;)Lwf/core/util/packing/Params2; > >>> #167 = Utf8 > >>> > Ljava/lang/Class<+Lwf/core/util/factory/di/factory/DIGlobalCxPDD;>;>; > >>> > >>> > >>> > >>> Thx > >>> Boaz > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Mon, Mar 24, 2014 at 6:40 PM, Boaz Nahum > >>> > >> wrote: > >>> > >>> Thx > >>> > >>> ********************* error in file > >>> > F:\views2\BoazMainWF_JDK8_LANG_ON_p\Qsnap\Qrelease\Jar\Core.jar(wf/core/util/factory/di/glob > >>> al/DIFW.class) > >>> ********************* while trying to read constant > >>> pool entry 64 > >>> > >>> Attachedfiles DIFW{.java, .class,$*.class} > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Mon, Mar 24, 2014 at 3:52 PM, Vicente-Arturo > >>> Romero-Zaldivar > >>> >> wrote: > >>> > >>> On 24/03/14 13:50, Boaz Nahum wrote: > >>>> is repo http://hg.openjdk.java.net/jdk8/jdk8 > is good > >>>> enough, or maybe other > >>> > >>> Please use this one: > http://hg.openjdk.java.net/jdk8/tl/ > >>> > >>> > >>>> > >>>> > >>>> On Mon, Mar 24, 2014 at 3:45 PM, Vicente-Arturo > >>>> Romero-Zaldivar > >>>> >> wrote: > >>>> > >>>> I usually do this with Linux, if you have > Linux > >>>> you can go to your jdk repo, to the langtools > >>>> folder and do: > >>>> > >>>> patch -p1 < /path/to/mypatch > >>>> > >>>> after that you can rebuild again the jdk > and you > >>>> will have the patched javac. > >>>> > >>>> Vicente > >>>> > >>>> > >>>> On 24/03/14 13:41, Boaz Nahum wrote: > >>>>> Please send my link to instruction how > to apply > >>>>> pathc (I know how to compile JDK, never > before > >>>>> applied a patch) > >>>>> > >>>>> > >>>>> On Mon, Mar 24, 2014 at 3:34 PM, > Vicente-Arturo > >>>>> Romero-Zaldivar > > >>>>> >> wrote: > >>>>> > >>>>> Hi Boaz, > >>>>> > >>>>> Please try the attached patch and > send me > >>>>> the obtained information along with the > >>>>> failing .class file. > >>>>> > >>>>> Thanks, > >>>>> Vicente > >>>>> > >>>>> > >>>>> On 24/03/14 13:07, Boaz Nahum wrote: > >>>>>> It happens both with 1.8.0_20-ea and > >>>>>> 1.8.0-b132 > >>>>>> > >>>>>> The javac (with -verbose) output > >>>>>> > https://drive.google.com/file/d/0B4MyZ6FK5jswZVZWV0VMSnE3c0k/edit?usp=sharing > >>>>>> > >>>>>> I didn't tired with > >>>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/ > >>>>>> I need to re-setup by jdk build > environment > >>>>>> > >>>>>> > >>>>>> many thanks > >>>>>> Boaz > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Mar 24, 2014 at 1:24 PM, > >>>>>> Vicente-Arturo Romero-Zaldivar > >>>>>> > >>>>>> >> wrote: > >>>>>> > >>>>>> Hi Boaz, > >>>>>> > >>>>>> OK it seems like we both need more > >>>>>> information :) > >>>>>> > >>>>>> What version of javac is this? Can you > >>>>>> get the last javac from > >>>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/ > >>>>>> and try to reproduce the issue? > Do you > >>>>>> get any meaningful information > after > >>>>>> executing javac with plain "-verbose" > >>>>>> option? > >>>>>> > >>>>>> Thanks, > >>>>>> Vicente > >>>>>> > >>>>>> > >>>>>> On 24/03/14 07:10, Boaz Nahum > wrote: > >>>>>>> > >>>>>>> That what I'm asking help for - to > >>>>>>> isolate the problematic source. > >>>>>>> But from what I learnt - it is > >>>>>>> combination of source and > >>>>>>> dependencies. The same source > >>>>>>> ***passed*** if it is complied with a > >>>>>>> dependency that wasn't compile with > >>>>>>> "-parameters". > >>>>>>> What I need is a flag (or a patch) > >>>>>>> that causes the compiler to emit > >>>>>>> verbose information > >>>>>>> > >>>>>>> Thanks > >>>>>>> Boaz > >>>>>>> > >>>>>>> On Mar 23, 2014 9:18 PM, > >>>>>>> "Vicente-Arturo Romero-Zaldivar" > >>>>>>> > >>>>>>> >> > >>>>>>> wrote: > >>>>>>> > >>>>>>> Hi Boaz, > >>>>>>> > >>>>>>> Do you have an isolated test case? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Vicente > >>>>>>> > >>>>>>> On 23/03/14 12:40, Boaz Nahum wrote: > >>>>>>>> Actaully > >>>>>>>> '-XDverboseCompilePolicy and > >>>>>>>> -Xdiags:verbose' are not > >>>>>>>> ignored, it is just that the > >>>>>>>> exception occurs too early. If I > >>>>>>>> remove '-parameters' then they > >>>>>>>> do the work .... > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sun, Mar 23, 2014 at 2:29 PM, > >>>>>>>> Boaz Nahum > >>>>>>>> >> wrote: > >>>>>>>> > >>>>>>>> When compiling our code with > >>>>>>>> '-parameters' (1.8.0_20-ea > >>>>>>>> and 1.8.0-b132), we got > >>>>>>>> this exception: > >>>>>>>> > >>>>>>>> An exception has occurred in > >>>>>>>> the compiler (1.8.0). Please > >>>>>>>> file a bug at the Java > >>>>>>>> Developer/bugreport) after > >>>>>>>> checking the Bug Parade for > >>>>>>>> duplicates. Include your > >>>>>>>> program and the following > >>>>>>>> diagnostic in your report. > >>>>>>>> Thank you. > >>>>>>>> > >>>>>>>> java.lang.ClassCastException: java.lang.String > >>>>>>>> cannot be cast to > >>>>>>>> com.sun.tools.javac.util.Name > > > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:602) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.setParameterNames(ClassReader.java:2130) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2031) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2234) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2306) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2493) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2424) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:244) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2605) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1868) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2107) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3358) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3257) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.comp.Attr.attribTree(Attr.java:596) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.comp.Attr.attribType(Attr.java:658) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.comp.Attr.attribType(Attr.java:651) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:836) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:556) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.comp.Enter.complete(Enter.java:497) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.comp.Enter.main(Enter.java:475) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) > >>>>>>>> at > >>>>>>>> > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:523) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:381) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:370) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.main.Main.compile(Main.java:361) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.Main.compile(Main.java:56) > >>>>>>>> at > >>>>>>>> com.sun.tools.javac.Main.main(Main.java:42) > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Boaz > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> In order to isolate the > >>>>>>>> problematic code, I add > >>>>>>>> -XDverboseCompilePolicy and > >>>>>>>> -Xdiags:verbose, without luck. > >>>>>>>> Why they are ignored ? > >>>>>>>> > >>>>>>>> Please note that an > >>>>>>>> annotation processor is > >>>>>>>> involved. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Fri Mar 28 07:08:58 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 28 Mar 2014 00:08:58 -0700 Subject: JLS tweaks In-Reply-To: <532318F5.90700@oracle.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> <532318F5.90700@oracle.com> Message-ID: On Mar 14, 2014, at 7:57 AM, Brian Goetz wrote: > This "improvement" was deemed a bad idea in 2006 and is still a bad idea: > > https://bugs.openjdk.java.net/browse/JDK-4093999 FTR, I added a lengthy comment to that bug which gives what I think is the best set of workarounds for running code before the "super" call. At dinner tonight I thought of an extra wrinkle or two which perhaps haven't been documented before. The current rule is good enough and really, really, really simple. There are tastier fish to fry. Best wishes, ? John P.S. Jon G., sorry about the extra language-design noise on your javac list. This stuff belongs on a successor to the Coin[1] project, whose coin-dev[2] would be the right forum for such ideas, if someone could be found to run it. [1] http://blogs.oracle.com/darcy/entry/project_coin_rocks [2] http://mail.openjdk.java.net/pipermail/coin-dev/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie at dellroad.org Fri Mar 28 16:03:34 2014 From: archie at dellroad.org (Archie Cobbs) Date: Fri, 28 Mar 2014 11:03:34 -0500 Subject: JLS tweaks In-Reply-To: References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> <532318F5.90700@oracle.com> Message-ID: On Fri, Mar 28, 2014 at 2:08 AM, John Rose wrote: > P.S. Jon G., sorry about the extra language-design noise on your javac > list. This stuff belongs on a successor to the Coin[1] project, whose > coin-dev[2] would be the right forum for such ideas, if someone could be > found to run it. > I completely agree... it turns out this list is not the right place to discuss language change proposals. At least, nobody here seems very interested in actually discussing mine, and as a result I feel like I'm just annoying people and wasting everyone's time. A project Coin successor with a separate, dedicated mailing list might make more sense. The current process, which I have been trying to follow, is failing to gather enough interest and discussion to progress toward a conclusion. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Mon Mar 31 20:45:43 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 31 Mar 2014 13:45:43 -0700 Subject: JLS tweaks In-Reply-To: References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> <532318F5.90700@oracle.com> Message-ID: Random comments: - John, many thanks for your bug update with the clever workarounds! - The current rules are annoying, and I lean towards fixing them (but I'm not offering to do the work!) - It would be good if there was a permanent mailing list (and bug category) for specification changes (JLS and JVMS) instead of spinning up a mailing list only for major features. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Mon Mar 31 21:01:17 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 31 Mar 2014 14:01:17 -0700 Subject: JLS tweaks In-Reply-To: References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> <532318F5.90700@oracle.com> Message-ID: <5339D79D.2050106@oracle.com> On 3/31/2014 1:45 PM, Martin Buchholz wrote: > - It would be good if there was a permanent mailing list (and bug > category) for specification changes (JLS and JVMS) instead of spinning > up a mailing list only for major features. Please distinguish "specification changes" from "language/VM changes": - "specification changes" concern changes in the text of the JLS and JVMS. There have long been aliases for feedback about errors, omissions, and ambiguities in the text - see [1] and [2] for the most recent info. There has long been a bug category too - recall "java/java/specification" in Bugtraq, now "specification" in JBS. People use these channels all the time. - "language/VM changes" concern changes in the design of the Java language and abstract JVM. compiler-dev, hotspot-dev, and their associated JBS components are assuredly not the right place. Alex [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-1.html#jls-1.5 [2] http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-1.html#jvms-1.5 From sam at sampullara.com Fri Mar 7 05:53:53 2014 From: sam at sampullara.com (Sam Pullara) Date: Fri, 07 Mar 2014 05:53:53 -0000 Subject: Lambda and multi-catch In-Reply-To: <531955F2.1010602@oracle.com> References: <53185C2D.4090907@univ-mlv.fr> <531955F2.1010602@oracle.com> Message-ID: It is throwing an NPE when he dereferences the null o -- I thought the same thing the first time I looked at it. Sam On Thu, Mar 6, 2014 at 9:15 PM, David Holmes wrote: > On 6/03/2014 9:29 PM, Remi Forax wrote: > > A colleague of mine have find a hairy bug, > > here is a simple code to reproduce it. > > > > import java.io.IOException; > > > > public class FunWithMultiCatch { > > public static void main(String[] args) { > > Runnable r = () -> { > > try { > > Object o = null; > > o.getClass(); > > throw new IOException(); > > } catch(IOException | IllegalArgumentException e) { > > System.out.println("KO !"); > > } catch(RuntimeException e) { > > System.out.println("OK !"); > > } > > }; > > r.run(); > > } > > } > > > > It prints 'KO !' :( > > What am I missing? We throw IOException and have a catch block for > IOException so I would expect it to print "KO !". > > I'm more surprised that a non-lambda version prints "OK !" > > > The problem can be reproduced for any multi-catch inside a lambda, > > the exception table is clearly wrong, the IOException and IAE are merged > > to their common supertype (java.lang.Exception). > > That would definitely seem wrong, but more of an issue with catching > RuntimeExceptions in the first block that should be handled by the > second catch block. eg change it to throw IllegalStateException() instead: > > if (false) throw new IOException(); > throw new IllegalStateException(); > > -> "KO !" !!!WT! > > David > ----- > > > private static void lambda$main$0(); > > Code: > > 0: aconst_null > > ... > > 14: athrow > > 15: astore_0 > > 16: getstatic #8 // Field > > java/lang/System.out:Ljava/io/PrintStream; > > 19: ldc #9 // String OK ! > > 21: invokevirtual #10 // Method > > java/io/PrintStream.println:(Ljava/lang/String;)V > > 24: goto 36 > > 27: astore_0 > > 28: getstatic #8 // Field > > java/lang/System.out:Ljava/io/PrintStream; > > 31: ldc #12 // String KO ! > > 33: invokevirtual #10 // Method > > java/io/PrintStream.println:(Ljava/lang/String;)V > > 36: return > > Exception table: > > from to target type > > 0 15 15 Class > > java/lang/Exception <------------ Oops > > 0 15 27 Class java/lang/RuntimeException > > > > The current workaround is to not use a multi-catch in a lambda. > > > > It seems that some version of Eclipse had the same issue but it's fixed > > with the one I use (from 21 feb). > > > > cheers, > > R?mi > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav.r.akesson at gmail.com Fri Mar 7 19:29:26 2014 From: gustav.r.akesson at gmail.com (=?ISO-8859-1?Q?Gustav_=C5kesson?=) Date: Fri, 07 Mar 2014 19:29:26 -0000 Subject: Lambda and multi-catch In-Reply-To: <5319640A.7060507@oracle.com> References: <53185C2D.4090907@univ-mlv.fr> <531955F2.1010602@oracle.com> <5319640A.7060507@oracle.com> Message-ID: Hi, I too was a bit confused by the example. :-) I assume this nasty bug is already registered? Best regards, Gustav ?kesson Den 7 mar 2014 07:17 skrev "David Holmes" : > On 7/03/2014 3:53 PM, Sam Pullara wrote: > > It is throwing an NPE when he dereferences the null o -- I thought the > > same thing the first time I looked at it. > > Ughhh. That was unnecessarily obscure. > > So the issue is that use of Exception is catching exceptions it should not. > > Thanks Sam. > > David > > > Sam > > > > > > > > On Thu, Mar 6, 2014 at 9:15 PM, David Holmes > > wrote: > > > > On 6/03/2014 9:29 PM, Remi Forax wrote: > > > A colleague of mine have find a hairy bug, > > > here is a simple code to reproduce it. > > > > > > import java.io.IOException; > > > > > > public class FunWithMultiCatch { > > > public static void main(String[] args) { > > > Runnable r = () -> { > > > try { > > > Object o = null; > > > o.getClass(); > > > throw new IOException(); > > > } catch(IOException | IllegalArgumentException e) { > > > System.out.println("KO !"); > > > } catch(RuntimeException e) { > > > System.out.println("OK !"); > > > } > > > }; > > > r.run(); > > > } > > > } > > > > > > It prints 'KO !' :( > > > > What am I missing? We throw IOException and have a catch block for > > IOException so I would expect it to print "KO !". > > > > I'm more surprised that a non-lambda version prints "OK !" > > > > > The problem can be reproduced for any multi-catch inside a lambda, > > > the exception table is clearly wrong, the IOException and IAE are > > merged > > > to their common supertype (java.lang.Exception). > > > > That would definitely seem wrong, but more of an issue with catching > > RuntimeExceptions in the first block that should be handled by the > > second catch block. eg change it to throw IllegalStateException() > > instead: > > > > if (false) throw new IOException(); > > throw new IllegalStateException(); > > > > -> "KO !" !!!WT! > > > > David > > ----- > > > > > private static void lambda$main$0(); > > > Code: > > > 0: aconst_null > > > ... > > > 14: athrow > > > 15: astore_0 > > > 16: getstatic #8 // Field > > > java/lang/System.out:Ljava/io/PrintStream; > > > 19: ldc #9 // String OK ! > > > 21: invokevirtual #10 // Method > > > java/io/PrintStream.println:(Ljava/lang/String;)V > > > 24: goto 36 > > > 27: astore_0 > > > 28: getstatic #8 // Field > > > java/lang/System.out:Ljava/io/PrintStream; > > > 31: ldc #12 // String KO ! > > > 33: invokevirtual #10 // Method > > > java/io/PrintStream.println:(Ljava/lang/String;)V > > > 36: return > > > Exception table: > > > from to target type > > > 0 15 15 Class > > > java/lang/Exception <------------ Oops > > > 0 15 27 Class java/lang/RuntimeException > > > > > > The current workaround is to not use a multi-catch in a lambda. > > > > > > It seems that some version of Eclipse had the same issue but it's > > fixed > > > with the one I use (from 21 feb). > > > > > > cheers, > > > R?mi > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: