From jhs at edg.com Thu May 1 14:32:35 2014 From: jhs at edg.com (John Spicer) Date: Thu, 1 May 2014 10:32:35 -0400 Subject: Annotations on generic constructors Message-ID: <73C228F2-D310-485B-8FBD-83787806F36F@edg.com> javac accepts this usage: import java.lang.annotation.ElementType; import java.lang.annotation.Target; @Target(ElementType.TYPE_USE) @interface T { } class X {

@T X() { } } but that seems to be prohibited by the constructor declaration syntax, which only allows annotations before the TypeParameters. Should this case be rejected? John Spicer -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.schindl at bestsolution.at Thu May 1 16:11:05 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 01 May 2014 18:11:05 +0200 Subject: Possible Bug in javac unchecked cast detection Message-ID: <53627219.10500@bestsolution.at> Hi, While cleaning up the javafx codebase (who has a lot of use of generics) I came across casts the eclipse java compiler marks as unchecked while javac -Xlint:all does not warn about. The following snippet shows gist of the problem: > package a; > > public class CastTest { > public interface BaseInterface { > > } > > public interface SubInterfaceA extends BaseInterface { > > } > > public interface SubInterfaceB extends BaseInterface { > > } > > public static void main(String[] args) { > SubInterfaceA a = null; > SubInterfaceB b = (SubInterfaceB) a; // javac does not warn > b = (SubInterfaceB)(BaseInterface)a; > > } > } I first thought of a bug in the eclipse compiler but they claim their compiler is correct because the spec says: > "A cast from a type S to a parameterized type (?4.5) T is unchecked > unless at least one of the following is true: > * S <: T > * All of the type arguments (?4.5.1) of T are unbounded wildcards > * T <: S and S has no subtype X other than T where the type arguments > of X are not contained in the type arguments of T." So before fileing a bug and start fixing the javafx code I wanted to get feedback from the compiler gurus on this list who is right and who is wrong. Thanks Tom From alex.buckley at oracle.com Thu May 1 18:41:24 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 01 May 2014 11:41:24 -0700 Subject: Possible Bug in javac unchecked cast detection In-Reply-To: <53627219.10500@bestsolution.at> References: <53627219.10500@bestsolution.at> Message-ID: <53629554.7050208@oracle.com> Eclipse is right. Given the interface declarations below, a cast from SubInterfaceA to SubInterfaceB is unchecked. By JLS 5.5.2, an unchecked warning is due unless @SuppressWarnings is in effect; lint mode doesn't matter. Alex On 5/1/2014 9:11 AM, Tom Schindl wrote: > Hi, > > While cleaning up the javafx codebase (who has a lot of use of generics) > I came across casts the eclipse java compiler marks as unchecked while > javac -Xlint:all does not warn about. > > The following snippet shows gist of the problem: > >> package a; >> >> public class CastTest { >> public interface BaseInterface { >> >> } >> >> public interface SubInterfaceA extends BaseInterface { >> >> } >> >> public interface SubInterfaceB extends BaseInterface { >> >> } >> >> public static void main(String[] args) { >> SubInterfaceA a = null; >> SubInterfaceB b = (SubInterfaceB) a; // javac does not warn >> b = (SubInterfaceB)(BaseInterface)a; >> >> } >> } > > I first thought of a bug in the eclipse compiler but they claim their > compiler is correct because the spec says: > > >> "A cast from a type S to a parameterized type (?4.5) T is unchecked >> unless at least one of the following is true: >> * S <: T >> * All of the type arguments (?4.5.1) of T are unbounded wildcards >> * T <: S and S has no subtype X other than T where the type arguments >> of X are not contained in the type arguments of T." > > So before fileing a bug and start fixing the javafx code I wanted to get > feedback from the compiler gurus on this list who is right and who is wrong. > > Thanks > > Tom > From alex.buckley at oracle.com Thu May 1 18:52:01 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 01 May 2014 11:52:01 -0700 Subject: Annotations on generic constructors In-Reply-To: <73C228F2-D310-485B-8FBD-83787806F36F@edg.com> References: <73C228F2-D310-485B-8FBD-83787806F36F@edg.com> Message-ID: <536297D1.2010200@oracle.com> See the thread "Queries about JDK-8035890" on type-annotations-dev: http://mail.openjdk.java.net/pipermail/type-annotations-dev/2014-March/thread.html. I wouldn't bet on javac allowing that @T for much longer. (I assumed Werner would file a spec bug, but that has not happened.) Alex On 5/1/2014 7:32 AM, John Spicer wrote: > javac accepts this usage: > > import java.lang.annotation.ElementType; > import java.lang.annotation.Target; > @Target(ElementType.TYPE_USE) > @interface T { } > class X { >

@T X() { } > } > > but that seems to be prohibited by the constructor declaration syntax, > which only allows annotations before the TypeParameters. > > Should this case be rejected? > > John Spicer From tom.schindl at bestsolution.at Fri May 2 08:12:08 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 02 May 2014 10:12:08 +0200 Subject: Possible Bug in javac unchecked cast detection In-Reply-To: <53629554.7050208@oracle.com> References: <53627219.10500@bestsolution.at> <53629554.7050208@oracle.com> Message-ID: <53635358.7010706@bestsolution.at> Hi Alex, Thanks for the confirmation. I'll file a bug against javac then. What I don't yet understand how one can fix such a situation without a warning or why JLS does not allow the cast. I can fix the unchecked warning with but then (if turned on in my Eclipse I get a warning about an unnecessary typecast - so do IntelliJ users) b = (SubInterfaceB)(BaseInterface)a; which of course is correct because one does not need to cast SubInterfaceA to BaseInterface. The only solution to work without any warning suppression is using an intermediate variable. BaseInterface temp = a; b = (SubInterfaceB)temp; what i don't fully grasp then why JLS does not directly allow me to cast from SubInterfaceA to SubInterfaceB. Tom On 01.05.14 20:41, Alex Buckley wrote: > Eclipse is right. Given the interface declarations below, a cast from > SubInterfaceA to SubInterfaceB is unchecked. By JLS > 5.5.2, an unchecked warning is due unless @SuppressWarnings is in > effect; lint mode doesn't matter. > > Alex > > On 5/1/2014 9:11 AM, Tom Schindl wrote: >> Hi, >> >> While cleaning up the javafx codebase (who has a lot of use of generics) >> I came across casts the eclipse java compiler marks as unchecked while >> javac -Xlint:all does not warn about. >> >> The following snippet shows gist of the problem: >> >>> package a; >>> >>> public class CastTest { >>> public interface BaseInterface { >>> >>> } >>> >>> public interface SubInterfaceA extends BaseInterface { >>> >>> } >>> >>> public interface SubInterfaceB extends BaseInterface { >>> >>> } >>> >>> public static void main(String[] args) { >>> SubInterfaceA a = null; >>> SubInterfaceB b = (SubInterfaceB) a; // javac >>> does not warn >>> b = (SubInterfaceB)(BaseInterface)a; >>> >>> } >>> } >> >> I first thought of a bug in the eclipse compiler but they claim their >> compiler is correct because the spec says: >> >> >>> "A cast from a type S to a parameterized type (?4.5) T is unchecked >>> unless at least one of the following is true: >>> * S <: T >>> * All of the type arguments (?4.5.1) of T are unbounded wildcards >>> * T <: S and S has no subtype X other than T where the type >>> arguments >>> of X are not contained in the type arguments of T." >> >> So before fileing a bug and start fixing the javafx code I wanted to get >> feedback from the compiler gurus on this list who is right and who is >> wrong. >> >> Thanks >> >> Tom >> From alex.buckley at oracle.com Fri May 2 19:55:29 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 02 May 2014 12:55:29 -0700 Subject: Possible Bug in javac unchecked cast detection In-Reply-To: <53635358.7010706@bestsolution.at> References: <53627219.10500@bestsolution.at> <53629554.7050208@oracle.com> <53635358.7010706@bestsolution.at> Message-ID: <5363F831.1040400@oracle.com> If none of the interface declarations were generic, then the language would happily accept the cast from SubInterfaceA to SubInterfaceB; as JLS 5.5.1 says, "the cast is always legal at compile time (because even if T does not implement S, a subclass of T might)." With generic declarations, the unchecked cast rules come into play, aiming to warn you if anything happens that could possibly lead to a ClassCastException at run time. These rules could have been smarter, to detect the common superinterface of SubInterfaceA and SubInterfaceB, but that decision was not taken in 1998. Alex On 5/2/2014 1:12 AM, Tom Schindl wrote: > Hi Alex, > > Thanks for the confirmation. I'll file a bug against javac then. What I > don't yet understand how one can fix such a situation without a warning > or why JLS does not allow the cast. > > I can fix the unchecked warning with but then (if turned on in my > Eclipse I get a warning about an unnecessary typecast - so do IntelliJ > users) > > b = (SubInterfaceB)(BaseInterface)a; > > which of course is correct because one does not need to cast > SubInterfaceA to BaseInterface. The only solution to work without > any warning suppression is using an intermediate variable. > > BaseInterface temp = a; > b = (SubInterfaceB)temp; > > what i don't fully grasp then why JLS does not directly allow me to cast > from SubInterfaceA to SubInterfaceB. > > Tom > > On 01.05.14 20:41, Alex Buckley wrote: >> Eclipse is right. Given the interface declarations below, a cast from >> SubInterfaceA to SubInterfaceB is unchecked. By JLS >> 5.5.2, an unchecked warning is due unless @SuppressWarnings is in >> effect; lint mode doesn't matter. >> >> Alex >> >> On 5/1/2014 9:11 AM, Tom Schindl wrote: >>> Hi, >>> >>> While cleaning up the javafx codebase (who has a lot of use of generics) >>> I came across casts the eclipse java compiler marks as unchecked while >>> javac -Xlint:all does not warn about. >>> >>> The following snippet shows gist of the problem: >>> >>>> package a; >>>> >>>> public class CastTest { >>>> public interface BaseInterface { >>>> >>>> } >>>> >>>> public interface SubInterfaceA extends BaseInterface { >>>> >>>> } >>>> >>>> public interface SubInterfaceB extends BaseInterface { >>>> >>>> } >>>> >>>> public static void main(String[] args) { >>>> SubInterfaceA a = null; >>>> SubInterfaceB b = (SubInterfaceB) a; // javac >>>> does not warn >>>> b = (SubInterfaceB)(BaseInterface)a; >>>> >>>> } >>>> } >>> >>> I first thought of a bug in the eclipse compiler but they claim their >>> compiler is correct because the spec says: >>> >>> >>>> "A cast from a type S to a parameterized type (?4.5) T is unchecked >>>> unless at least one of the following is true: >>>> * S <: T >>>> * All of the type arguments (?4.5.1) of T are unbounded wildcards >>>> * T <: S and S has no subtype X other than T where the type >>>> arguments >>>> of X are not contained in the type arguments of T." >>> >>> So before fileing a bug and start fixing the javafx code I wanted to get >>> feedback from the compiler gurus on this list who is right and who is >>> wrong. >>> >>> Thanks >>> >>> Tom >>> > From jonathan.gibbons at oracle.com Fri May 2 22:01:17 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 02 May 2014 15:01:17 -0700 Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way In-Reply-To: <20140430133307.GA13604@e6430> References: <20140430133307.GA13604@e6430> Message-ID: <536415AD.4070107@oracle.com> The code to use NUL or /dev/null is somewhat icky. Is that actually the behavior you want? How about using ProcessBuilder.Redirect.INHERIT instead? -- Jon On 04/30/2014 06:33 AM, Andreas Lundblad wrote: > Hi compiler-dev, > > Please review this small fix for JDK-8042088 which changes how sjavac spawns background processes. > > Description: > Sjavac starts a background server through a shell (cmd on windows, and /bin/sh on other systems). This patch changes this so that the background service is launched directly instead. > > Link to webrev: > http://cr.openjdk.java.net/~alundblad/8042088 > > Link to bug report: > https://bugs.openjdk.java.net/browse/JDK-8042088 > > -- Andreas From andreas.lundblad at oracle.com Mon May 5 09:17:59 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Mon, 5 May 2014 11:17:59 +0200 Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way In-Reply-To: <536415AD.4070107@oracle.com> References: <20140430133307.GA13604@e6430> <536415AD.4070107@oracle.com> Message-ID: <20140505091758.GB13904@e6430> On Fri, May 02, 2014 at 03:01:17PM -0700, Jonathan Gibbons wrote: > The code to use NUL or /dev/null is somewhat icky. Is that actually > the behavior you want? > How about using ProcessBuilder.Redirect.INHERIT instead? I don't think we want the output of the background sjavac server to be interleaved with the output of the sjavac instance that spawned it. (Especially since the log of the background server would be chopped off once the foreground process terminates.) The reason I can't simply leave the whole redirect logic out is because the background process halts once it's output buffer is full. The output of the background process *has* to be consumed in one way or another. I could solve this by spawning a separate thread in the foreground process whose sole purpose is to read and discand output from the background process: Thread discardOutputThread = new Thread() { public void run() { InputStream is = p.getInputStream(); try { while (is.read() != -1); } catch (IOException e) { } } }; discardOutputThread.setDaemon(true); discardOutputThread.start(); It just feels a bit awkward to leave a running dummy thread behind, and I can't find any documentation on what happens when the foreground process terminates and this thread stops. (Although it *did* work on when I tested it on Windows 2003 and Ubuntu.) So, while the NUL or /dev/null workaround does have a grain of platform dependency, I still thought it was the cleanest solution. I'm ready to reconsider this if others think differently. I'm somewhat surprised that there is no ProcessBuilder.Redirect.DISCARD. Does anybody know why such option is "missing"? :-( -- Andreas From oehrstroem at gmail.com Mon May 5 11:18:03 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Mon, 5 May 2014 13:18:03 +0200 Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way In-Reply-To: <20140505091758.GB13904@e6430> References: <20140430133307.GA13604@e6430> <536415AD.4070107@oracle.com> <20140505091758.GB13904@e6430> Message-ID: The output from stdout and stderr from the background must always be logged into a file. The default name for that file is portfile+".stdouterr" Thus you could replace stdouterrfile == null with assert(stdouterrfile != null && stdouterrfile.length() >= 1) And get rid of /dev/null etc. For example if the background jvm cannot start, for example you supplied a bad -Xms setting, you need to see the error message somewhere. It is not a good idea to force the client jvm to keep running. The client and the server must be independent. 2014-05-05 11:17 GMT+02:00 Andreas Lundblad : > On Fri, May 02, 2014 at 03:01:17PM -0700, Jonathan Gibbons wrote: > > The code to use NUL or /dev/null is somewhat icky. Is that actually > > the behavior you want? > > How about using ProcessBuilder.Redirect.INHERIT instead? > > I don't think we want the output of the background sjavac server to be > interleaved with the output of the sjavac instance that spawned it. > (Especially since the log of the background server would be chopped off > once the foreground process terminates.) > > The reason I can't simply leave the whole redirect logic out is because > the background process halts once it's output buffer is full. The output of > the background process *has* to be consumed in one way or another. I could > solve this by spawning a separate thread in the foreground process whose > sole purpose is to read and discand output from the background process: > > Thread discardOutputThread = new Thread() { > public void run() { > InputStream is = p.getInputStream(); > try { while (is.read() != -1); } > catch (IOException e) { } > } > }; > discardOutputThread.setDaemon(true); > discardOutputThread.start(); > > It just feels a bit awkward to leave a running dummy thread behind, and I > can't find any documentation on what happens when the foreground process > terminates and this thread stops. (Although it *did* work on when I tested > it on Windows 2003 and Ubuntu.) > > So, while the NUL or /dev/null workaround does have a grain of platform > dependency, I still thought it was the cleanest solution. I'm ready to > reconsider this if others think differently. > > I'm somewhat surprised that there is no ProcessBuilder.Redirect.DISCARD. > Does anybody know why such option is "missing"? :-( > > -- Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkweteyimdaisy at gmail.com Mon May 5 13:55:38 2014 From: nkweteyimdaisy at gmail.com (Daisy Nkweteyim) Date: Mon, 5 May 2014 14:55:38 +0100 Subject: Building Javac Code Message-ID: Hi I hope I'm on the right mailing list. I downloaded the javac source code from http://hg.openjdk.java.net/jdk7/jdk7/langtools. I looked at the README on how to build it here 1). First of all I don't have the exact files and directories indicated in the README 2) To build I have to access the installation directory then run ant. How is the download? ? zip file installed? Thanks.? *Daisy Nkweteyim Cameroon* ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon May 5 19:52:37 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 05 May 2014 12:52:37 -0700 Subject: interactions between type annotations and language model APIs. Message-ID: <5367EC05.50900@oracle.com> In cleaning up the reference implementation of type annotations, we've uncovered some questions pertaining to the interactions between the type annotations and language model APIs. In particular, TypeMirror is now an AnnotatedConstruct, and various methods in javax.lang.model.util.Types return computed TypeMirrors -- for example, capture(TypeMirror), directSupertypes(TypeMirror), erasure(TypeMirror), etc. In cases where the argument has type annotations, what type annotations (if any) should appear on the return value? It would help to see clarification added to the specifications, either generally, or on a case-by-case basis for the affected methods. -- Jon From eric.mccorkle at oracle.com Mon May 5 20:36:21 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 05 May 2014 16:36:21 -0400 Subject: interactions between type annotations and language model APIs. In-Reply-To: <5367EC05.50900@oracle.com> References: <5367EC05.50900@oracle.com> Message-ID: <5367F645.50502@oracle.com> An additional question I would like to raise deals with the relationship between type annotations and subtyping. Offhand, there are four possible ways by which annotations might interact with subtying: covariance (the annotation is preserved for all subtypes, but not supertypes), contravariance (the annotation is preserved for all supertypes, but not subtypes), anyvariance (the annotation is preserved for both super- and subtypes), and invariance (the annotation is not preserved). Additionally, there's the question of whether for some interface I and annotation @A, one can have both I and @A I in an interface heirarchy. I'll put forward that type annotations need to be able to support all these possibilities, and that there ought to be additional facilities for defining how a given annotation type behaves in these contexts. These are all future-facing considerations, of course. I'm mentioning them here because they came up in discussions of the issues Jon raised, but they do not need to be addressed in the same timeline. On 05/05/14 15:52, Jonathan Gibbons wrote: > In cleaning up the reference implementation of type annotations, we've > uncovered some questions pertaining to the interactions between the type > annotations and language model APIs. > > In particular, TypeMirror is now an AnnotatedConstruct, and various > methods in javax.lang.model.util.Types return computed TypeMirrors -- > for example, capture(TypeMirror), directSupertypes(TypeMirror), > erasure(TypeMirror), etc. > > In cases where the argument has type annotations, what type annotations > (if any) should appear on the return value? > > It would help to see clarification added to the specifications, either > generally, or on a case-by-case basis for the affected methods. > > -- Jon -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 303 bytes Desc: not available URL: From alex.buckley at oracle.com Mon May 5 20:48:38 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 05 May 2014 13:48:38 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <5367EC05.50900@oracle.com> References: <5367EC05.50900@oracle.com> Message-ID: <5367F926.30009@oracle.com> On 5/5/2014 12:52 PM, Jonathan Gibbons wrote: > In particular, TypeMirror is now an AnnotatedConstruct, and various > methods in javax.lang.model.util.Types return computed TypeMirrors -- > for example, capture(TypeMirror), directSupertypes(TypeMirror), > erasure(TypeMirror), etc. Right, because jx.l.m.t.TypeMirror always represented the use of a type at a particular location in source - which can now usually be annotated. > In cases where the argument has type annotations, what type annotations > (if any) should appear on the return value? > > It would help to see clarification added to the specifications, either > generally, or on a case-by-case basis for the affected methods. To be specific, the "generator" methods in jx.l.m.u.Types are these ten: asMemberOf boxedClass capture directSupertypes erasure getArrayType getDeclaredType x2 getWildcardType unboxedType Generally, the "correct" thing to do would be to inspect the TypeMirror argument and thread its type annotations into the TypeMirror result. But not always: just because '@Foo String' appears in source does not mean that calling directSupertypes on its mirror should return '@Foo Object'. There is also a limitation of the API for wildcard annotations: getWildcardType could produce a mirror for '? extends @Foo ...' and '? super @Foo ...' but not '@Foo ? extends ...' or '@Foo ? super ...'. Joe, what is your view on retrofitting type annotations into Types? Alex From jonathan.gibbons at oracle.com Tue May 6 15:36:08 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 06 May 2014 08:36:08 -0700 Subject: Building Javac Code In-Reply-To: References: Message-ID: <53690168.1050109@oracle.com> Unless you have specific reasons for using jdk7, I recommend using the latest released version of javac in the jdk8 repositories. If you are new to OpenJDK, I would recommend getting the full source code for OpenJDK and building that, which includes building javac. The build system in JDK 8 is much improved over that in JDK 7 and makes building the full product much easier. You can find build instructions by searching for "build OpenJDK 8". -- Jon On 05/05/2014 06:55 AM, Daisy Nkweteyim wrote: > Hi > I hope I'm on the right mailing list. > I downloaded the javac source code from > http://hg.openjdk.java.net/jdk7/jdk7/langtools. I looked at the README > on how to build it here > 1). First of all I don't have the exact files and directories > indicated in the README > 2) To build I have to access the installation directory then run ant. > How is the download? > ? zip file installed? > > Thanks. ? > > /Daisy Nkweteyim > Cameroon/ > ? ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue May 6 15:41:41 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 06 May 2014 16:41:41 +0100 Subject: Type inference of non-existent method references crashes the compiler In-Reply-To: References: Message-ID: <536902B5.1060509@oracle.com> Hi Victor, Thanks for the report. I'm looking at it, Vicente On 23/04/14 04:57, Victor Williams Stafusa da Silva wrote: > Hi. > I just created a new bug report titled "Type inference of non-existent > method references crashes the compiler" > > Basically, the following code crashes the compiler (1.8.0_05) with a > NullPointerException: > > class TestBug { > static TestBug bug() { > return new TestBug<>(TestBug::doNotExists); > } > } > > I am new to this discussion list and just want to know if somebody > already saw that bug before. > > Victor Williams Stafusa da Silva From nkweteyimdaisy at gmail.com Tue May 6 15:56:13 2014 From: nkweteyimdaisy at gmail.com (Daisy Nkweteyim) Date: Tue, 6 May 2014 16:56:13 +0100 Subject: Building Javac Code In-Reply-To: <53690168.1050109@oracle.com> References: <53690168.1050109@oracle.com> Message-ID: Hi, Thanks for your replies. I found out that boot.java.home was not defined in my build.properties so I just added it there. I ran ant and build was successful. Thanks again. On Tue, May 6, 2014 at 4:36 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Unless you have specific reasons for using jdk7, I recommend using the > latest released version of javac in the jdk8 repositories. > > If you are new to OpenJDK, I would recommend getting the full source code > for OpenJDK and building that, which includes building javac. The build > system in JDK 8 is much improved over that in JDK 7 and makes building the > full product much easier. You can find build instructions by searching > for "build OpenJDK 8". > > -- Jon > > > On 05/05/2014 06:55 AM, Daisy Nkweteyim wrote: > > Hi > I hope I'm on the right mailing list. > I downloaded the javac source code from > http://hg.openjdk.java.net/jdk7/jdk7/langtools. I looked at the README > on how to build it here > 1). First of all I don't have the exact files and directories indicated > in the README > 2) To build I have to access the installation directory then run ant. How > is the download? > ? zip file installed? > > Thanks. ? > > > *Daisy Nkweteyim Cameroon* > ? ? > > > -- *Daisy Nkweteyim Cameroon* -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue May 6 18:18:06 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 6 May 2014 11:18:06 -0700 Subject: question about applicability inference with wildcards and deferred types Message-ID: I encountered an example where javac8 can't perform applicability inference for a method in the presence of wildcards. This only occurs with -source 8 -target 8. I think it is related to JDK-7177387, since the behaviour goes away when Source.allowPoly() is disabled. Here's the code: === import java.util.List; abstract class Test { abstract List copyOf(List lx); abstract List filter(List lx); // This works: void f(List lx) { copyOf(filter(lx)); } // This doesn't: void g(List lx) { copyOf(filter(lx)); } } === The interesting bit of the error message is: error: method copyOf in class Test cannot be applied to given types; ... List cannot be converted to List I think that the logic in Types.containsType could be improved to handle this case better. Turning on the debug output (Types.debugContainsType) reveals that javac is checking: does "? extends capture#630 of ?" contain "capture#630 of ?" ? => U(capture#630 of ?) <: U(? extends capture#630 of ?) => java.lang.Object <: capture#630 of ? => false My theory is that prior to javac8 the inferencer did not encounter wildcards whose bound was a captured wildcard (? extends CAP of ?), and that changed with the addition of deferred types in JDK-7177387. Perhaps some additional logic could be added to containsType(T, S) to deal with S being the upper bound of T? Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Tue May 6 22:17:46 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 7 May 2014 00:17:46 +0200 Subject: RFR: 8042441: sjavac does not properly track dependencies in two cases. Message-ID: Hi compiler-dev, Please review this fix for JDK-8042441 which fixes two dependency tracking failures in sjavac. Description: A fully qualified identifier for example "alfa.A a;" is not tracked, but "import alfa.A; ... A a;" is tracked. The fix tracks the fully qualified identifier by instrumenting Attr.java with a reportDependence in the same way that Resolve.java is already instrumented. Thanks Jan Lahoda for the help on where to instrument. Also, the previous change from . to / in the arguments accidentally broke the dependencies inside the javac_state file. A trivial fix is supplied for this, however the tests did not catch this, since the tests did not use packages with more than one level, ie no dots...thus the tests are improved to actually detect this kind of error. Link to webrev: http://cr.openjdk.java.net/~ohrstrom/webrev-8042441/ Link to bug report: https://bugs.openjdk.java.net/browse/JDK-8042441 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue May 6 22:57:31 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 06 May 2014 15:57:31 -0700 Subject: RFR: 8042441: sjavac does not properly track dependencies in two cases. In-Reply-To: References: Message-ID: <536968DB.4090201@oracle.com> Fredrik, It seems to me you are fixing two issues here -- dependency tracking failures and test failures. Also, in Attr.java, you have "broken" a javac convention of placing private utility methods nearby their usage, introduced by a "// where" comment. By placing the new method where you have, you have separated visitSelect from the "// where" method that follows it. -- Jon On 05/06/2014 03:17 PM, Fredrik ?hrstr?m wrote: > Hi compiler-dev, > > Please review this fix for JDK-8042441 which fixes two dependency > tracking failures in sjavac. > > Description: > A fully qualified identifier for example "alfa.A a;" is not tracked, > but "import alfa.A; ... A a;" is tracked. The fix tracks the fully > qualified identifier by instrumenting Attr.java with a > reportDependence in the same way that Resolve.java is already > instrumented. Thanks Jan Lahoda for the help on where to instrument. > > Also, the previous change from . to / in the arguments accidentally > broke the dependencies inside the javac_state file. A trivial fix is > supplied for this, however the tests did not catch this, since the > tests did not use packages with more than one level, ie no dots...thus > the tests are improved to actually detect this kind of error. > > Link to webrev: > http://cr.openjdk.java.net/~ohrstrom/webrev-8042441/ > > > Link to bug report: > https://bugs.openjdk.java.net/browse/JDK-8042441 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Wed May 7 06:05:20 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 7 May 2014 08:05:20 +0200 Subject: RFR: 8042441: sjavac does not properly track dependencies in two cases. In-Reply-To: <536968DB.4090201@oracle.com> References: <536968DB.4090201@oracle.com> Message-ID: 2014-05-07 0:57 GMT+02:00 Jonathan Gibbons : > > > Also, in Attr.java, you have "broken" a javac convention of placing > private utility methods nearby their usage, introduced by a "// where" > comment. By placing the new method where you have, you have separated > visitSelect from the "// where" method that follows it. > I see. Fixed. Uploaded the fixed webrev in place. Please reload. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Wed May 7 14:51:31 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 7 May 2014 16:51:31 +0200 Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way In-Reply-To: References: <20140430133307.GA13604@e6430> <536415AD.4070107@oracle.com> <20140505091758.GB13904@e6430> Message-ID: <20140507145130.GH13904@e6430> On Mon, May 05, 2014 at 01:18:03PM +0200, Fredrik ?hrstr?m wrote: > The output from stdout and stderr from the background must always be logged > into a file. The default name for that file is portfile+".stdouterr" > Thus you could replace stdouterrfile == null with > > assert(stdouterrfile != null && stdouterrfile.length() >= 1) > > And get rid of /dev/null etc. Fixed. (I went for IllegalArgumentException to avoid nasty exceptions when running without -ea.) See new revision here: http://cr.openjdk.java.net/~alundblad/8042088/webrev.01/ -- Andreas From jonathan.gibbons at oracle.com Wed May 7 14:55:46 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 May 2014 07:55:46 -0700 Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way In-Reply-To: References: <20140430133307.GA13604@e6430> <536415AD.4070107@oracle.com> <20140505091758.GB13904@e6430> Message-ID: <536A4972.1020300@oracle.com> javac never uses assert. We have a set of methods in javac.util.Assert that can be used instead. -- Jon On 05/05/2014 04:18 AM, Fredrik ?hrstr?m wrote: > The output from stdout and stderr from the background must always be > logged into a file. The default name for that file is > portfile+".stdouterr" > Thus you could replace stdouterrfile == null with > > assert(stdouterrfile != null && stdouterrfile.length() >= 1) > > And get rid of /dev/null etc. > > For example if the background jvm cannot start, for example you > supplied a bad -Xms setting, you need to see the error message somewhere. > It is not a good idea to force the client jvm to keep running. The > client and the server must be independent. > > > > > 2014-05-05 11:17 GMT+02:00 Andreas Lundblad > >: > > On Fri, May 02, 2014 at 03:01:17PM -0700, Jonathan Gibbons wrote: > > The code to use NUL or /dev/null is somewhat icky. Is that actually > > the behavior you want? > > How about using ProcessBuilder.Redirect.INHERIT instead? > > I don't think we want the output of the background sjavac server > to be interleaved with the output of the sjavac instance that > spawned it. (Especially since the log of the background server > would be chopped off once the foreground process terminates.) > > The reason I can't simply leave the whole redirect logic out is > because the background process halts once it's output buffer is > full. The output of the background process *has* to be consumed in > one way or another. I could solve this by spawning a separate > thread in the foreground process whose sole purpose is to read and > discand output from the background process: > > Thread discardOutputThread = new Thread() { > public void run() { > InputStream is = p.getInputStream(); > try { while (is.read() != -1); } > catch (IOException e) { } > } > }; > discardOutputThread.setDaemon(true); > discardOutputThread.start(); > > It just feels a bit awkward to leave a running dummy thread > behind, and I can't find any documentation on what happens when > the foreground process terminates and this thread stops. (Although > it *did* work on when I tested it on Windows 2003 and Ubuntu.) > > So, while the NUL or /dev/null workaround does have a grain of > platform dependency, I still thought it was the cleanest solution. > I'm ready to reconsider this if others think differently. > > I'm somewhat surprised that there is no > ProcessBuilder.Redirect.DISCARD. Does anybody know why such option > is "missing"? :-( > > -- Andreas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Wed May 7 18:51:35 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 7 May 2014 20:51:35 +0200 Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way In-Reply-To: <20140507145130.GH13904@e6430> References: <20140430133307.GA13604@e6430> <536415AD.4070107@oracle.com> <20140505091758.GB13904@e6430> <20140507145130.GH13904@e6430> Message-ID: Very nice cleanup! 2014-05-07 16:51 GMT+02:00 Andreas Lundblad : > On Mon, May 05, 2014 at 01:18:03PM +0200, Fredrik ?hrstr?m wrote: > > The output from stdout and stderr from the background must always be > logged > > into a file. The default name for that file is portfile+".stdouterr" > > Thus you could replace stdouterrfile == null with > > > > assert(stdouterrfile != null && stdouterrfile.length() >= 1) > > > > And get rid of /dev/null etc. > > Fixed. (I went for IllegalArgumentException to avoid nasty exceptions when > running without -ea.) > > See new revision here: > > http://cr.openjdk.java.net/~alundblad/8042088/webrev.01/ > > -- Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Wed May 7 21:34:24 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 7 May 2014 23:34:24 +0200 Subject: RFR: 8042441: sjavac does not properly track dependencies in two cases. In-Reply-To: References: <536968DB.4090201@oracle.com> Message-ID: And I shrunk the size of the webrev in place, please reload and reread. 2014-05-07 8:05 GMT+02:00 Fredrik ?hrstr?m : > 2014-05-07 0:57 GMT+02:00 Jonathan Gibbons : > >> >> Also, in Attr.java, you have "broken" a javac convention of placing >> private utility methods nearby their usage, introduced by a "// where" >> comment. By placing the new method where you have, you have separated >> visitSelect from the "// where" method that follows it. >> > > I see. Fixed. Uploaded the fixed webrev in place. Please reload. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Wed May 7 21:36:21 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 7 May 2014 23:36:21 +0200 Subject: RFR: 8042699: sjavac does not properly track dependencies Message-ID: Hi compiler-dev, Please review this fix for JDK-8042699 which fixes a dependency tracking failures in sjavac. Description: The previous change from . to / in the arguments accidentally broke the dependencies inside the javac_state file. A trivial fix is supplied for this, however the tests did not catch this, since the tests did not use packages with more than one level, ie no dots...thus the tests are improved to actually detect this kind of error. Link to webrev: http://cr.openjdk.java.net/~ohrstrom/webrev-8042699/ Link to bug report: https://bugs.openjdk.java.net/browse/JDK-8042699 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed May 7 21:38:41 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 May 2014 14:38:41 -0700 Subject: RFR: 8042441: sjavac does not properly track dependencies in two cases. In-Reply-To: References: <536968DB.4090201@oracle.com> Message-ID: <536AA7E1.8030801@oracle.com> The test needs the bug number 8042441 in the @bug line for the test, but other than that, you're good to go. -- Jon ] On 05/07/2014 02:34 PM, Fredrik ?hrstr?m wrote: > And I shrunk the size of the webrev in place, please reload and reread. > > > 2014-05-07 8:05 GMT+02:00 Fredrik ?hrstr?m >: > > 2014-05-07 0:57 GMT+02:00 Jonathan Gibbons > >: > > > Also, in Attr.java, you have "broken" a javac convention of > placing private utility methods nearby their usage, introduced > by a "// where" comment. By placing the new method where you > have, you have separated visitSelect from the "// where" > method that follows it. > > > I see. Fixed. Uploaded the fixed webrev in place. Please reload. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed May 7 21:40:58 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 May 2014 14:40:58 -0700 Subject: RFR: 8042699: sjavac does not properly track dependencies In-Reply-To: References: Message-ID: <536AA86A.5090700@oracle.com> Add the bug number 8042699 into the @bug line in the test and you're good to go. You need the bug number to be present so that down stream processes can verify that there was a specified test added that is directly relevant to the fix. -- Jon On 05/07/2014 02:36 PM, Fredrik ?hrstr?m wrote: > Hi compiler-dev, > > Please review this fix for JDK-8042699 which fixes a dependency > tracking failures in sjavac. > > Description: > The previous change from . to / in the arguments accidentally broke > the dependencies inside the javac_state file. A trivial fix is > supplied for this, however the tests did not catch this, since the > tests did not use packages with more than one level, ie no dots...thus > the tests are improved to actually detect this kind of error. > > Link to webrev: > http://cr.openjdk.java.net/~ohrstrom/webrev-8042699/ > > > Link to bug report: > https://bugs.openjdk.java.net/browse/JDK-8042699 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.mccorkle at oracle.com Wed May 7 23:08:03 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 07 May 2014 19:08:03 -0400 Subject: Public review for 8040327: Eliminate AnnotatedType Message-ID: <536ABCD3.5070109@oracle.com> Hello, This is the first of a series of patches which implement a significant overhaul of type annotations code in the javac frontend. This patch eliminates the AnnotatedType class, replacing its functionality by storing annotations on the Type class itself. This will eventually be rolled into a more general type metadata framework that has been planned as part of ongoing work. Note that this patch is also being reviewed by the langtools team using the Crucible tool. The webrev can be found here: http://cr.openjdk.java.net/~emc/8040327/ The following patches are also under initial review, and will be posted soon: 1) A patch which replaces much of the functionality in TypeAnnotations.java with code integrated directly into the MemberEnter and Attr phases. The end result is that Attribute.TypeCompound objects will now contain the correct position from the moment they are created, and the position field will be final. This patch is known colloquially as the "positions patch", though its scope has grown considerably beyond that. 2) A follow-up patch which removes code dead code that was replaced by the positions patch, and removes some code duplication that was introduced by that patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 303 bytes Desc: not available URL: From philip.race at oracle.com Thu May 8 16:35:56 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 08 May 2014 09:35:56 -0700 Subject: JDK9 build failure on Windows : javac OutOfMemoryError In-Reply-To: <532224DF.9070202@oracle.com> References: <5320D57D.1040708@oracle.com> <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com> <5320DCEB.10205@oracle.com> <532224DF.9070202@oracle.com> Message-ID: <536BB26C.80507@oracle.com> Do we yet have a definitive answer to whether this is a javac bug or something that needs to be fixed in the build ? -phil. On 3/13/14 2:36 PM, Bradford Wetmore wrote: > Phil, > > That looks exactly like my problem. > > http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012089.html > Subject: Heads Up: OutOfMemoryError when building a 64-bit JDK 9 > using a 32-bit bootdir. > > > Yes, 32 bit it appears, although I didn't supply the boot dir option, > > it chose it all by itself. > > I *BELIEVE* that for the bootdirs discovery (I haven't checked the > code), if a JDK isn't given one with config's --with-boot-jdk, it > defaults to whatever JDK is found in the path. I typically only > install a 32-bit one, as several applets I use require 32-bit only. > > > Who can dig into how much heap is actually needed and see if some new > > bug is requiring more than that ? > > As for how much head is actually needed, I haven't dug into it, but > just doing a simple javac -XmxXXXM Foo.java, I could only get up to > about 1500M. I wasn't able to build on my laptop, but my lab machine > worked just fine, so it's probably close to the border. > > Brad > > > > > > > On 3/12/2014 3:17 PM, Phil Race wrote: >> Yes, 32 bit it appears, although I didn't supply the boot dir option, it >> chose it all by itself. >> Who can dig into how much heap is actually needed and see if some new >> bug is >> requiring more than that ? >> >> -phil. >> >> On 3/12/2014 3:06 PM, Mike Duigou wrote: >>> Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last >>> week. The problem in his case was that the 32 bit VM couldn't get a >>> large enough heap. Switching to a 64 bit boot jdk resolved the issue >>> for him. >>> >>> Mike >>> >>> On Mar 12 2014, at 14:45 , Phil Race wrote: >>> >>>> I'm on Windows 7 64 bit and I've quit every app except for my >>>> console windows >>>> yet I still get this error below. >>>> >>>> How can I get past this ? >>>> >>>> -phil. >>>> >>>> ---------- >>>> ## Starting jdk >>>> Compiling 9635 files for BUILD_JDK >>>> >>>> >>>> The system is out of resources. >>>> Consult the following stack trace for details. >>>> java.lang.OutOfMemoryError: Java heap space >>>> at >>>> com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja >>>> va:780) >>>> .... >>>> .... >>>> >>>> make[2]: *** >>>> [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch] >>>> >>>> Error 3 >>>> BuildJdk.gmk:64: recipe for target `classes-only' failed >>>> make[1]: *** [classes-only] Error 2 >>>> /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target >>>> `jdk-only' failed >>>> make: *** [jdk-only] Error 2 >>>> --------------------- >> From vicente.romero at oracle.com Thu May 8 19:21:57 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 08 May 2014 20:21:57 +0100 Subject: Possible javac bug around final and covariant overrides In-Reply-To: <53567039.2090103@redhat.com> References: <53567039.2090103@redhat.com> Message-ID: <536BD955.7070904@oracle.com> Hi David, IMO this is a bug. I have filed https://bugs.openjdk.java.net/browse/JDK-8042785 to track it. Thanks for your report, Vicente On 22/04/14 14:35, David M. Lloyd wrote: > While exploring adding covariant overrides for Buffer classes, it was > discovered that javac is not making synthetic methods for covariant > overrides match the finality of the covariant method. > > Simple illustration: > > public class Test { > public Object foo() { return null; } > } > public class TestSub extends Test { > public final String foo() { return null; } > } > > Yields (javap output): > > public class Test { > public Test(); > public java.lang.Object foo(); > } > public class TestSub extends Test { > public TestSub(); > public final java.lang.String foo(); > public java.lang.Object foo(); // <- not final?! > } > > Is there a good reason for this? Hypothetically it would seem that > this might prevent HotSpot from modifying calls to the synthetic > method to be monomorphic. Is this a legitimate concern? > From wdietl at gmail.com Thu May 8 20:23:11 2014 From: wdietl at gmail.com (Werner Dietl) Date: Thu, 8 May 2014 16:23:11 -0400 Subject: Public review for 8040327: Eliminate AnnotatedType In-Reply-To: <536ABCD3.5070109@oracle.com> References: <536ABCD3.5070109@oracle.com> Message-ID: Hi Eric, I had a quick look and notice: com/sun/tools/javac/code/Printer.java: + List annos = t.getAnnotationMirrors(); + if (!annos.isEmpty()) { + if (prefix) sb.append(' '); + sb.append(t.getAnnotationMirrors()); The last line could use annos instead of calling t.getAnnotationMirrors again. + private void printBrackets(Type t, StringBuilder sb, Locale locale) { Type arrel = t; while (arrel.hasTag(TypeTag.ARRAY)) { - if (arrel.isAnnotated()) { - sb.append(' '); - sb.append(arrel.getAnnotationMirrors()); - sb.append(' '); - } + sb.append(printAnnotations(t, true)); sb.append("[]"); - arrel = arrel.unannotatedType(); arrel = ((ArrayType) arrel).elemtype; } } This change seems wrong. Previously, the type annotations on arrel were printed on each iteration of the loop. Now, each iteration prints the annotations on "t" - the top-level type. The added line should be sb.append(printAnnotation(arrel, true)); @Override public String visitMethodType(MethodType t, Locale locale) { - return "(" + printMethodArgs(t.argtypes, false, locale) + ")" + visit(t.restype, locale); + return printAnnotations(t) + "(" + + printMethodArgs(t.argtypes, false, locale) + ")" + + visit(t.restype, locale); } What is the meaning of type annotations on a MethodType? We have TAs on the return type of a method or constructor, but those are in t.restype. I don't see what annotations a MethodType itself should contain and why they would be separate from restype. Should TAs on the receiver of a method be printed instead (in the right location)? Same comment for MethodType.toString() later in the diff. MethodType.annotatedType correctly raises an error, so I don't see why toString outputs it. I'll wait with adapting the Checker Framework until all three patches are available and can then give more detailed feedback. cu, WMD. On Wed, May 7, 2014 at 7:08 PM, Eric McCorkle wrote: > Hello, > > This is the first of a series of patches which implement a significant > overhaul of type annotations code in the javac frontend. This patch > eliminates the AnnotatedType class, replacing its functionality by > storing annotations on the Type class itself. > > This will eventually be rolled into a more general type metadata > framework that has been planned as part of ongoing work. > > Note that this patch is also being reviewed by the langtools team using > the Crucible tool. > > The webrev can be found here: > http://cr.openjdk.java.net/~emc/8040327/ > > > The following patches are also under initial review, and will be posted > soon: > > 1) A patch which replaces much of the functionality in > TypeAnnotations.java with code integrated directly into the MemberEnter > and Attr phases. The end result is that Attribute.TypeCompound objects > will now contain the correct position from the moment they are created, > and the position field will be final. This patch is known colloquially > as the "positions patch", though its scope has grown considerably beyond > that. > > 2) A follow-up patch which removes code dead code that was replaced by > the positions patch, and removes some code duplication that was > introduced by that patch. -- http://www.google.com/profiles/wdietl From alex.buckley at oracle.com Thu May 8 22:55:06 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 08 May 2014 15:55:06 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <5367F926.30009@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> Message-ID: <536C0B4A.5000901@oracle.com> On 5/5/2014 1:48 PM, Alex Buckley wrote: > To be specific, the "generator" methods in jx.l.m.u.Types are these ten: > > asMemberOf > boxedClass > capture > directSupertypes > erasure > getArrayType > getDeclaredType x2 > getWildcardType > unboxedType boxedClass(PrimitiveType) returns a TypeElement, i.e., a declaration, so any type annotations on the PrimitiveType mirror are irrelevant. So we're down to nine methods. Eric, you indicated that you're already preserving type annotations "everywhere they ought to be". For each of the nine Types methods that generate a TypeMirror, can you sketch (one line) what the preservation involves? If the answer is often "it's obvious", then I'll write the obvious thing for the API spec. Alex From eric.mccorkle at oracle.com Thu May 8 23:06:53 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 08 May 2014 19:06:53 -0400 Subject: Clarification for CantAnnotateStaticClass2 test Message-ID: <536C0E0D.6030701@oracle.com> Hello, In the test CantAnnotateStaticClass2, the following lines appear. @TB Outer f1; @TB Outer.Inner f1a; @TB Outer.SInner f2a; // err @TB Outer.IInner f3a; // err In the second line, TB annotates a static class from which a member is being selected, which should result in an error, but the test does not expect an error message. Should there, in fact, be an error message? Thanks, Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 303 bytes Desc: not available URL: From alex.buckley at oracle.com Thu May 8 23:19:41 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 08 May 2014 16:19:41 -0700 Subject: Clarification for CantAnnotateStaticClass2 test In-Reply-To: <536C0E0D.6030701@oracle.com> References: <536C0E0D.6030701@oracle.com> Message-ID: <536C110D.8070105@oracle.com> Good question, but the test is correct in not expecting an error from f1a. See http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-October/000198.html and the ensuing rules in JLS8 9.7.4 about an "admissible" type annotation. Alex On 5/8/2014 4:06 PM, Eric McCorkle wrote: > Hello, > > In the test CantAnnotateStaticClass2, the following lines appear. > > > @TB Outer f1; > @TB Outer.Inner f1a; > @TB Outer.SInner f2a; // err > @TB Outer.IInner f3a; // err > > In the second line, TB annotates a static class from which a member is > being selected, which should result in an error, but the test does not > expect an error message. Should there, in fact, be an error message? > > Thanks, > Eric > From eric.mccorkle at oracle.com Thu May 8 23:42:51 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 08 May 2014 19:42:51 -0400 Subject: interactions between type annotations and language model APIs. In-Reply-To: <536C0B4A.5000901@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536C0B4A.5000901@oracle.com> Message-ID: <536C167B.5070906@oracle.com> On 05/08/14 18:55, Alex Buckley wrote: > On 5/5/2014 1:48 PM, Alex Buckley wrote: >> To be specific, the "generator" methods in jx.l.m.u.Types are these ten: >> >> asMemberOf >> boxedClass >> capture >> directSupertypes >> erasure >> getArrayType >> getDeclaredType x2 >> getWildcardType >> unboxedType > > boxedClass(PrimitiveType) returns a TypeElement, i.e., a declaration, so > any type annotations on the PrimitiveType mirror are irrelevant. So > we're down to nine methods. > > Eric, you indicated that you're already preserving type annotations > "everywhere they ought to be". For each of the nine Types methods that > generate a TypeMirror, can you sketch (one line) what the preservation > involves? If the answer is often "it's obvious", then I'll write the > obvious thing for the API spec. I will make an opportunistic plug here for adding a unit test suite to the core parts of the pipeline, which would allow us to examine these sorts of questions in much greater detail... In the patch currently under review, (which eliminates AnnotatedType), the primary goal is to preserve the visible functioning of javac. This goal is assisted by the fact that javac makes most of its important decisions using type annotations attached to either Symbol's or JCTree's, not Type's (in the cases where it didn't I wound up having to make modifications anyway, due to the elimination of AnnotatedType). I have added code that preserves type annotations everywhere that a type (which can carry them) is copied, through Mappings. The only exception to this is a mapping on Wildcards, because the only use does not look at annotations. Annotations are currently disallowed on ForAll, MethodType, and the various types (not an exhaustive list) that exist to assist type inference. I make no attempt to preserve them through inference, because doing so is highly nontrivial. Annotations are preserved through erasure. This was the behavior of javac before the patch, and changing it may have nontrivial effects. So if it is to be changed, that needs to be filed as a separate issue. Annotations are not preserved when creating supertypes, lower or upper-bounds. -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 303 bytes Desc: not available URL: From erik.joelsson at oracle.com Fri May 9 08:38:02 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 09 May 2014 10:38:02 +0200 Subject: JDK9 build failure on Windows : javac OutOfMemoryError In-Reply-To: <536BB26C.80507@oracle.com> References: <5320D57D.1040708@oracle.com> <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com> <5320DCEB.10205@oracle.com> <532224DF.9070202@oracle.com> <536BB26C.80507@oracle.com> Message-ID: <536C93EA.5050209@oracle.com> I do not know and I don't see what could be done from the build point of view. When we restructure the source for modules, each unit of compilation will be much smaller so the problem will most likely go away. /Erik On 2014-05-08 18:35, Phil Race wrote: > Do we yet have a definitive answer to whether this is a javac bug > or something that needs to be fixed in the build ? > > -phil. > > On 3/13/14 2:36 PM, Bradford Wetmore wrote: >> Phil, >> >> That looks exactly like my problem. >> >> http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012089.html >> Subject: Heads Up: OutOfMemoryError when building a 64-bit JDK 9 >> using a 32-bit bootdir. >> >> > Yes, 32 bit it appears, although I didn't supply the boot dir option, >> > it chose it all by itself. >> >> I *BELIEVE* that for the bootdirs discovery (I haven't checked the >> code), if a JDK isn't given one with config's --with-boot-jdk, it >> defaults to whatever JDK is found in the path. I typically only >> install a 32-bit one, as several applets I use require 32-bit only. >> >> > Who can dig into how much heap is actually needed and see if some new >> > bug is requiring more than that ? >> >> As for how much head is actually needed, I haven't dug into it, but >> just doing a simple javac -XmxXXXM Foo.java, I could only get up to >> about 1500M. I wasn't able to build on my laptop, but my lab machine >> worked just fine, so it's probably close to the border. >> >> Brad >> >> >> >> >> >> >> On 3/12/2014 3:17 PM, Phil Race wrote: >>> Yes, 32 bit it appears, although I didn't supply the boot dir >>> option, it >>> chose it all by itself. >>> Who can dig into how much heap is actually needed and see if some new >>> bug is >>> requiring more than that ? >>> >>> -phil. >>> >>> On 3/12/2014 3:06 PM, Mike Duigou wrote: >>>> Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last >>>> week. The problem in his case was that the 32 bit VM couldn't get a >>>> large enough heap. Switching to a 64 bit boot jdk resolved the issue >>>> for him. >>>> >>>> Mike >>>> >>>> On Mar 12 2014, at 14:45 , Phil Race wrote: >>>> >>>>> I'm on Windows 7 64 bit and I've quit every app except for my >>>>> console windows >>>>> yet I still get this error below. >>>>> >>>>> How can I get past this ? >>>>> >>>>> -phil. >>>>> >>>>> ---------- >>>>> ## Starting jdk >>>>> Compiling 9635 files for BUILD_JDK >>>>> >>>>> >>>>> The system is out of resources. >>>>> Consult the following stack trace for details. >>>>> java.lang.OutOfMemoryError: Java heap space >>>>> at >>>>> com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja >>>>> va:780) >>>>> .... >>>>> .... >>>>> >>>>> make[2]: *** >>>>> [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch] >>>>> >>>>> Error 3 >>>>> BuildJdk.gmk:64: recipe for target `classes-only' failed >>>>> make[1]: *** [classes-only] Error 2 >>>>> /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target >>>>> `jdk-only' failed >>>>> make: *** [jdk-only] Error 2 >>>>> --------------------- >>> > From joe.darcy at oracle.com Fri May 9 15:24:52 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 09 May 2014 08:24:52 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <5367F926.30009@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> Message-ID: <536CF344.5090402@oracle.com> Hello, On 5/5/2014 1:48 PM, Alex Buckley wrote: > On 5/5/2014 12:52 PM, Jonathan Gibbons wrote: >> In particular, TypeMirror is now an AnnotatedConstruct, and various >> methods in javax.lang.model.util.Types return computed TypeMirrors -- >> for example, capture(TypeMirror), directSupertypes(TypeMirror), >> erasure(TypeMirror), etc. > > Right, because jx.l.m.t.TypeMirror always represented the use of a > type at a particular location in source - which can now usually be > annotated. > >> In cases where the argument has type annotations, what type annotations >> (if any) should appear on the return value? >> >> It would help to see clarification added to the specifications, either >> generally, or on a case-by-case basis for the affected methods. > > To be specific, the "generator" methods in jx.l.m.u.Types are these ten: > > asMemberOf > boxedClass > capture > directSupertypes > erasure > getArrayType > getDeclaredType x2 > getWildcardType > unboxedType > > Generally, the "correct" thing to do would be to inspect the > TypeMirror argument and thread its type annotations into the > TypeMirror result. But not always: just because '@Foo String' appears > in source does not mean that calling directSupertypes on its mirror > should return '@Foo Object'. There is also a limitation of the API for > wildcard annotations: getWildcardType could produce a mirror for '? > extends @Foo ...' and '? super @Foo ...' but not '@Foo ? extends ...' > or '@Foo ? super ...'. > > Joe, what is your view on retrofitting type annotations into Types? > Hmm. My first reaction here is that these methods should by default ignore annotations and we should add another utility method or two like: T withAnnotations(T typeMirror, List annotations) T withAnnotations(T typeMirror, AnnotatedConstruct annotationHost) to allow the annotations savvy user to perform whatever annotation passing along or computation is appropriate for the problem domain. -Joe From daniel.smith at oracle.com Fri May 9 15:59:19 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 9 May 2014 09:59:19 -0600 Subject: question about applicability inference with wildcards and deferred types In-Reply-To: References: Message-ID: Hi Liam, Thanks for the test. This is a bug in the 'containsType' code that I've been looking into recently. I've added this example to the comments. Report is here: https://bugs.openjdk.java.net/browse/JDK-8039214 ?Dan On May 6, 2014, at 12:18 PM, Liam Miller-Cushon wrote: > I encountered an example where javac8 can't perform applicability inference for a method in the presence of wildcards. This only occurs with -source 8 -target 8. I think it is related to JDK-7177387, since the behaviour goes away when Source.allowPoly() is disabled. > > Here's the code: > > === > import java.util.List; > > abstract class Test { > abstract List copyOf(List lx); > abstract List filter(List lx); > > // This works: > void f(List lx) { > copyOf(filter(lx)); > } > > // This doesn't: > void g(List lx) { > copyOf(filter(lx)); > } > } > === > > The interesting bit of the error message is: > > error: method copyOf in class Test cannot be applied to given types; > ... > List cannot be converted to List > > I think that the logic in Types.containsType could be improved to handle this case better. Turning on the debug output (Types.debugContainsType) reveals that javac is checking: > > does "? extends capture#630 of ?" contain "capture#630 of ?" ? > => U(capture#630 of ?) <: U(? extends capture#630 of ?) > => java.lang.Object <: capture#630 of ? > => false > > My theory is that prior to javac8 the inferencer did not encounter wildcards whose bound was a captured wildcard (? extends CAP of ?), and that changed with the addition of deferred types in JDK-7177387. Perhaps some additional logic could be added to containsType(T, S) to deal with S being the upper bound of T? > > Thanks, > Liam > From eric.mccorkle at oracle.com Fri May 9 19:49:04 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 09 May 2014 15:49:04 -0400 Subject: Public review of rearchitected front-end type annotations pipeline Message-ID: <536D3130.2010500@oracle.com> Hello, This is the public review of the second in my series of patches dealing with type annotations. http://cr.openjdk.java.net/~emc/8027262/ This patch rearchitects the type annotations pipeline, integrating handling of type annotations directly into the javac MemberEnter/Annotate/Attr pipeline. It represents the majority of the work I have been doing regarding type annotations for 8u20. The handling of type annotations is now dispatched by the MemberEnter or Attr visitors and uses information from those visitors. Most of the actual functionality is now implemented in Annotate. The new test Stress.java is the test for this patch. Stress.java will cause 8-release javac to fail with an assertion failure. Its addition to the test suite demonstrates that this change fixes those cases. This patch addresses a number of JBS issues: https://bugs.openjdk.java.net/browse/JDK-8027262 https://bugs.openjdk.java.net/browse/JDK-8027261 https://bugs.openjdk.java.net/browse/JDK-8027258 https://bugs.openjdk.java.net/browse/JDK-8027182 and possibly others as well. Note: this patch does not attempt to remove code made obsolete; however, any such code is very clearly marked as deprecated. Removal of dead code will be done in the last of the series. This patch also does not attempt to re-enable tests which were previously disabled. That will be done as a separate patch 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: From wdietl at gmail.com Fri May 9 20:20:28 2014 From: wdietl at gmail.com (Werner Dietl) Date: Fri, 9 May 2014 16:20:28 -0400 Subject: Public review of rearchitected front-end type annotations pipeline In-Reply-To: <536D3130.2010500@oracle.com> References: <536D3130.2010500@oracle.com> Message-ID: Hi Eric, two quick questions: - I don't see "Stress" anywhere in the patch. Is that test case included? - Is there a reason to not use @Deprecated for the classes/methods that will be removed? Is this a good time to adapt the Checker Framework to these changes or should I wait for patch 3? Thanks, cu, WMD. On Fri, May 9, 2014 at 3:49 PM, Eric McCorkle wrote: > Hello, > > This is the public review of the second in my series of patches dealing > with type annotations. > > http://cr.openjdk.java.net/~emc/8027262/ > > This patch rearchitects the type annotations pipeline, integrating > handling of type annotations directly into the javac > MemberEnter/Annotate/Attr pipeline. It represents the majority of the > work I have been doing regarding type annotations for 8u20. > > The handling of type annotations is now dispatched by the MemberEnter or > Attr visitors and uses information from those visitors. Most of the > actual functionality is now implemented in Annotate. > > The new test Stress.java is the test for this patch. Stress.java will > cause 8-release javac to fail with an assertion failure. Its addition > to the test suite demonstrates that this change fixes those cases. > > This patch addresses a number of JBS issues: > https://bugs.openjdk.java.net/browse/JDK-8027262 > https://bugs.openjdk.java.net/browse/JDK-8027261 > https://bugs.openjdk.java.net/browse/JDK-8027258 > https://bugs.openjdk.java.net/browse/JDK-8027182 > and possibly others as well. > > Note: this patch does not attempt to remove code made obsolete; however, > any such code is very clearly marked as deprecated. Removal of dead > code will be done in the last of the series. This patch also does not > attempt to re-enable tests which were previously disabled. That will be > done as a separate patch as well. -- http://www.google.com/profiles/wdietl From eric.mccorkle at oracle.com Fri May 9 20:34:38 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 09 May 2014 16:34:38 -0400 Subject: Public review of rearchitected front-end type annotations pipeline In-Reply-To: References: <536D3130.2010500@oracle.com> Message-ID: <536D3BDE.3010806@oracle.com> On 05/09/14 16:20, Werner Dietl wrote: > Hi Eric, > > two quick questions: > > - I don't see "Stress" anywhere in the patch. Is that test case included? Apologies, Stress.java got left out by accident. That has been corrected. > - Is there a reason to not use @Deprecated for the classes/methods > that will be removed? There are still some uses of the deprecated code, which will produce warnings. Since javac is required to compile with -Werror, we can't have warnings. > Is this a good time to adapt the Checker Framework to these changes or > should I wait for patch 3? You should be fine. Patch 3 does some very minor code moving, and a whole lot of removal. -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From wdietl at gmail.com Fri May 9 20:48:36 2014 From: wdietl at gmail.com (Werner Dietl) Date: Fri, 9 May 2014 16:48:36 -0400 Subject: Public review of rearchitected front-end type annotations pipeline In-Reply-To: <536D3BDE.3010806@oracle.com> References: <536D3130.2010500@oracle.com> <536D3BDE.3010806@oracle.com> Message-ID: >> two quick questions: >> >> - I don't see "Stress" anywhere in the patch. Is that test case included? > > Apologies, Stress.java got left out by accident. That has been corrected. Would it be better to write that test in the "referenceinfos" style? At the moment Stress just makes sure that all the different syntax elements work, which other tests in "newlocations" also do. It's not clear which of the examples in Stress previously worked and which didn't. The "referenceinfos" style of tests would also make sure that the generated bytecode contains the correct type annotations. >> - Is there a reason to not use @Deprecated for the classes/methods >> that will be removed? > > There are still some uses of the deprecated code, which will produce > warnings. Since javac is required to compile with -Werror, we can't > have warnings. Ok, then I just make them @Deprecated locally to make it easier to find my uses of these methods. >> Is this a good time to adapt the Checker Framework to these changes or >> should I wait for patch 3? > > You should be fine. Patch 3 does some very minor code moving, and a > whole lot of removal. Is there a timeline for this patch? If it also comes within a few days, I'll rather wait for it. cu, WMD. -- http://www.google.com/profiles/wdietl From eric.mccorkle at oracle.com Fri May 9 20:55:25 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 09 May 2014 16:55:25 -0400 Subject: Public review of rearchitected front-end type annotations pipeline In-Reply-To: References: <536D3130.2010500@oracle.com> <536D3BDE.3010806@oracle.com> Message-ID: <536D40BD.9020106@oracle.com> On 05/09/14 16:48, Werner Dietl wrote: >>> two quick questions: >>> >>> - I don't see "Stress" anywhere in the patch. Is that test case included? >> >> Apologies, Stress.java got left out by accident. That has been corrected. > > Would it be better to write that test in the "referenceinfos" style? > At the moment Stress just makes sure that all the different syntax > elements work, which other tests in "newlocations" also do. It's not > clear which of the examples in Stress previously worked and which > didn't. > The "referenceinfos" style of tests would also make sure that the > generated bytecode contains the correct type annotations. > The idea of Stress is to hit a whole bunch of edge cases. While I'm not opposed to expanding the newlocations tests (or preferably, writing a combo-test), I would prefer to put Stress in as-is. There is also the fact that it is a kind of regression test, as it crashes 8-release javac. >>> Is this a good time to adapt the Checker Framework to these changes or >>> should I wait for patch 3? >> >> You should be fine. Patch 3 does some very minor code moving, and a >> whole lot of removal. > > Is there a timeline for this patch? If it also comes within a few > days, I'll rather wait for it. > The dead code patch depends on this one (obviously), and unfortunately, my only option for review until this patch goes in is to post a diff. Ideally, this patch will be committed some time early next week, at which point the dead code patch will immediately go up for review. -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From alex.buckley at oracle.com Fri May 9 21:36:16 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 09 May 2014 14:36:16 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <536CF344.5090402@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> Message-ID: <536D4A50.4070303@oracle.com> Joe, On 5/9/2014 8:24 AM, Joe Darcy wrote: > My first reaction here is that these methods should by default ignore > annotations and we should add another utility method or two like: > > T withAnnotations(T typeMirror, List AnnotationMirror> annotations) > > T withAnnotations(T typeMirror, > AnnotatedConstruct annotationHost) > > to allow the annotations savvy user to perform whatever annotation > passing along or computation is appropriate for the problem domain. In other words, specify in javax.lang.model.util.Types that it is unspecified as to the presence of type annotations in a TypeMirror object returned by a Types' method ? And also, specify builder methods that decorate an existing TypeMirror object with type annotations ? This approach sidesteps the complexities (alluded to in my prior mail) of trying to enrich certain methods' results with type annotations. This approach also exposes that "there's more than one way to do it", so we should not rush into decisions that ultimately will be part of JSR 269's next Maintenance Review. Do you keep a to-do list for 269 somewhere? Alex From wdietl at gmail.com Fri May 9 21:53:33 2014 From: wdietl at gmail.com (Werner Dietl) Date: Fri, 9 May 2014 17:53:33 -0400 Subject: Public review of rearchitected front-end type annotations pipeline In-Reply-To: <536D40BD.9020106@oracle.com> References: <536D3130.2010500@oracle.com> <536D3BDE.3010806@oracle.com> <536D40BD.9020106@oracle.com> Message-ID: In test/tools/javac/warnings/suppress/TypeAnnotations.out 9 warnings are removed. For example, line 23 uses a @Deprecated type annotation in a cast twice. Why don't you expect the warnings for this anymore? cu, WMD. On Fri, May 9, 2014 at 4:55 PM, Eric McCorkle wrote: > On 05/09/14 16:48, Werner Dietl wrote: >>>> two quick questions: >>>> >>>> - I don't see "Stress" anywhere in the patch. Is that test case included? >>> >>> Apologies, Stress.java got left out by accident. That has been corrected. >> >> Would it be better to write that test in the "referenceinfos" style? >> At the moment Stress just makes sure that all the different syntax >> elements work, which other tests in "newlocations" also do. It's not >> clear which of the examples in Stress previously worked and which >> didn't. >> The "referenceinfos" style of tests would also make sure that the >> generated bytecode contains the correct type annotations. >> > > The idea of Stress is to hit a whole bunch of edge cases. While I'm not > opposed to expanding the newlocations tests (or preferably, writing a > combo-test), I would prefer to put Stress in as-is. > > There is also the fact that it is a kind of regression test, as it > crashes 8-release javac. > >>>> Is this a good time to adapt the Checker Framework to these changes or >>>> should I wait for patch 3? >>> >>> You should be fine. Patch 3 does some very minor code moving, and a >>> whole lot of removal. >> >> Is there a timeline for this patch? If it also comes within a few >> days, I'll rather wait for it. >> > > The dead code patch depends on this one (obviously), and unfortunately, > my only option for review until this patch goes in is to post a diff. > > Ideally, this patch will be committed some time early next week, at > which point the dead code patch will immediately go up for review. -- http://www.google.com/profiles/wdietl From joe.darcy at oracle.com Fri May 9 22:38:33 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 09 May 2014 15:38:33 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <536D4A50.4070303@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> Message-ID: <536D58E9.8030009@oracle.com> Hi Alex, On 5/9/2014 2:36 PM, Alex Buckley wrote: > Joe, > > On 5/9/2014 8:24 AM, Joe Darcy wrote: >> My first reaction here is that these methods should by default ignore >> annotations and we should add another utility method or two like: >> >> T withAnnotations(T typeMirror, List> AnnotationMirror> annotations) >> >> T withAnnotations(T typeMirror, >> AnnotatedConstruct annotationHost) >> >> to allow the annotations savvy user to perform whatever annotation >> passing along or computation is appropriate for the problem domain. > > In other words, specify in javax.lang.model.util.Types that it is > unspecified as to the presence of type annotations in a TypeMirror > object returned by a Types' method ? Or even go further and state no annotations are propagated. > And also, specify builder methods that decorate an existing TypeMirror > object with type annotations ? Right. > > This approach sidesteps the complexities (alluded to in my prior mail) > of trying to enrich certain methods' results with type annotations. Indeed. > > This approach also exposes that "there's more than one way to do it", > so we should not rush into decisions that ultimately will be part of > JSR 269's next Maintenance Review. Do you keep a to-do list for 269 > somewhere? > Given the desired semantics of the annotations being used in these cases are largely extra-lingual, I don't think trying to specify their propagation in javax.lang.model is wise. For tracking purposes, a JBS bug in core-libs / javax.lang.model would be appropriate. Thanks, -Joe From alex.buckley at oracle.com Fri May 9 22:59:02 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 09 May 2014 15:59:02 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <536D58E9.8030009@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536D58E9.8030009@oracle.com> Message-ID: <536D5DB6.1080706@oracle.com> On 5/9/2014 3:38 PM, Joe Darcy wrote: > Given the desired semantics of the annotations being used in these cases > are largely extra-lingual, I don't think trying to specify their > propagation in javax.lang.model is wise. Clearly, general TypeMirror combinators in jx.l.m.u.Types are not expected to be sensitive to the meaning of type annotations. For example, isSameType is not expected to compare type annotations within its two TypeMirror arguments. But while the _semantics_ of the annotations are extra-lingual, their _existence_ is not. That's why I called out specific TypeMirror generators in jx.l.m.u.Types. For example, if I have a TypeMirror that represents '@Foo List', and I pass it to the erasure method, then I could reasonably expect to get back a TypeMirror that represents '@Foo List'. Similarly for getArrayType, getDeclaredType, etc. All that said, preserving the existence of type annotations in all TypeMirror generators is quite complicated. > For tracking purposes, a JBS bug in core-libs / javax.lang.model would > be appropriate. It's not clear to me what the actual behavior of Types' methods is today, which is why I proposed to specify that it's not specified (inspired by Class#getDeclaredMethods being specified to return methods in an unspecified order). Jon, Eric, would that be OK? Alex From eric.mccorkle at oracle.com Fri May 9 23:21:25 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 09 May 2014 19:21:25 -0400 Subject: Public review of rearchitected front-end type annotations pipeline In-Reply-To: References: <536D3130.2010500@oracle.com> <536D3BDE.3010806@oracle.com> <536D40BD.9020106@oracle.com> Message-ID: <536D62F5.6000008@oracle.com> On 05/09/14 17:53, Werner Dietl wrote: > In test/tools/javac/warnings/suppress/TypeAnnotations.out > 9 warnings are removed. > For example, line 23 uses a @Deprecated type annotation in a cast twice. > Why don't you expect the warnings for this anymore? If you look, you will notice that all the removed warnings are duplicates of other warnings. There was a bug in the original implementation that apparently caused warnings coming from annotations on instanceof and cast (and probably other things) to be emitted twice. -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From wdietl at gmail.com Fri May 9 23:24:44 2014 From: wdietl at gmail.com (Werner Dietl) Date: Fri, 9 May 2014 19:24:44 -0400 Subject: Public review of rearchitected front-end type annotations pipeline In-Reply-To: <536D62F5.6000008@oracle.com> References: <536D3130.2010500@oracle.com> <536D3BDE.3010806@oracle.com> <536D40BD.9020106@oracle.com> <536D62F5.6000008@oracle.com> Message-ID: Ah, sorry for missing that! cu, WMD. On Fri, May 9, 2014 at 7:21 PM, Eric McCorkle wrote: > On 05/09/14 17:53, Werner Dietl wrote: >> In test/tools/javac/warnings/suppress/TypeAnnotations.out >> 9 warnings are removed. >> For example, line 23 uses a @Deprecated type annotation in a cast twice. >> Why don't you expect the warnings for this anymore? > > If you look, you will notice that all the removed warnings are > duplicates of other warnings. > > There was a bug in the original implementation that apparently caused > warnings coming from annotations on instanceof and cast (and probably > other things) to be emitted twice. -- http://www.google.com/profiles/wdietl From jonathan.gibbons at oracle.com Sat May 10 00:03:38 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 09 May 2014 17:03:38 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <536D5DB6.1080706@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536D58E9.8030009@oracle.com> <536D5DB6.1080706@oracle.com> Message-ID: <536D6CDA.5060506@oracle.com> On 05/09/2014 03:59 PM, Alex Buckley wrote: > On 5/9/2014 3:38 PM, Joe Darcy wrote: >> Given the desired semantics of the annotations being used in these cases >> are largely extra-lingual, I don't think trying to specify their >> propagation in javax.lang.model is wise. > > Clearly, general TypeMirror combinators in jx.l.m.u.Types are not > expected to be sensitive to the meaning of type annotations. For > example, isSameType is not expected to compare type annotations within > its two TypeMirror arguments. > > But while the _semantics_ of the annotations are extra-lingual, their > _existence_ is not. That's why I called out specific TypeMirror > generators in jx.l.m.u.Types. For example, if I have a TypeMirror that > represents '@Foo List', and I pass it to the erasure method, > then I could reasonably expect to get back a TypeMirror that > represents '@Foo List'. Similarly for getArrayType, getDeclaredType, etc. > > All that said, preserving the existence of type annotations in all > TypeMirror generators is quite complicated. > >> For tracking purposes, a JBS bug in core-libs / javax.lang.model would >> be appropriate. > > It's not clear to me what the actual behavior of Types' methods is > today, which is why I proposed to specify that it's not specified > (inspired by Class#getDeclaredMethods being specified to return > methods in an unspecified order). > > Jon, Eric, would that be OK? > > Alex It seems to me that specifying the behavior to be unspecified is (a) avoiding the issue and (b) not helpful to clients. It's one thing to say the order of methods in a class is unspecified, when it is clear that no semantic change occurs if they are shuffled, but it is another to say, "eh, they may be there, they may not be there". Any client wanting to build deterministic behavior on top of an API like that now has to deal with the possibility that none, some or all of the annotations may survive the call. I like your differentiation between the semantics of type annotations and the existence of type annotations. I think the spec-gurus for javax.lang.model, having determined that the number of generator methods is countable on their two hands, could determine a boolean value for each finger and give a thumbs up or thumbs down as to whether the annos survive the call. If in doubt, specify that none survive, and give clients a determinsitic base on which to build their own type systems. -- Jon From brucechapman at paradise.net.nz Sun May 11 08:35:34 2014 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Sun, 11 May 2014 20:35:34 +1200 Subject: interactions between type annotations and language model APIs. In-Reply-To: <536D4A50.4070303@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> Message-ID: <536F3656.1050100@paradise.net.nz> I think you are on the right track here. Types' methods would probably strip type annotations, but provide tools for the user to reinsert them when the user knows that is appropriate and valuable given the semantics of the annotation and what the code is trying to do. I am presuming Joe's second method would in some way back substitute an annotated type for an (possibly) unannotated type within the typeMirror argument? withAnnotations(typeof(List), typeof(@Nullable String)> would return typeof(List<@Nullable String>? if so, what happens when the second argument appears more than once in the first argument? e.g. Map? Despite these difficulties, I still think stripping then tools to reinsert the type annotations is what would be most useful. The alternative would be some way to tell types' method what should happen. Bruce On 10/05/2014 9:36 a.m., Alex Buckley wrote: > Joe, > > On 5/9/2014 8:24 AM, Joe Darcy wrote: >> My first reaction here is that these methods should by default ignore >> annotations and we should add another utility method or two like: >> >> T withAnnotations(T typeMirror, List> AnnotationMirror> annotations) >> >> T withAnnotations(T typeMirror, >> AnnotatedConstruct annotationHost) >> >> to allow the annotations savvy user to perform whatever annotation >> passing along or computation is appropriate for the problem domain. > > In other words, specify in javax.lang.model.util.Types that it is > unspecified as to the presence of type annotations in a TypeMirror > object returned by a Types' method ? And also, specify builder methods > that decorate an existing TypeMirror object with type annotations ? > > This approach sidesteps the complexities (alluded to in my prior mail) > of trying to enrich certain methods' results with type annotations. > > This approach also exposes that "there's more than one way to do it", > so we should not rush into decisions that ultimately will be part of > JSR 269's next Maintenance Review. Do you keep a to-do list for 269 > somewhere? > > Alex > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From joe.darcy at oracle.com Sun May 11 16:23:58 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 11 May 2014 09:23:58 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <536F3656.1050100@paradise.net.nz> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536F3656.1050100@paradise.net.nz> Message-ID: <536FA41E.5090708@oracle.com> Hi Bruce, On 5/11/2014 1:35 AM, Bruce Chapman wrote: > I think you are on the right track here. Types' methods would probably > strip type annotations, but provide tools for the user to reinsert > them when the user knows that is appropriate and valuable given the > semantics of the annotation and what the code is trying to do. I am > presuming Joe's second method would in some way back substitute an > annotated type for an (possibly) unannotated type within the > typeMirror argument? The intention is the second method was that the returned value would be a wrapper around the first argument that had the annotations of the second argument. > > withAnnotations(typeof(List), typeof(@Nullable String)> would > return typeof(List<@Nullable String>? I intended this to return @Nullable List > > if so, what happens when the second argument appears more than once in > the first argument? e.g. Map? > > Despite these difficulties, I still think stripping then tools to > reinsert the type annotations is what would be most useful. > > The alternative would be some way to tell types' method what should > happen. I don't see you good way to approach that problem. Stripping the annotations and allowing them to be added, gives interested parties full control while being a tractable API. Thanks, -Joe > > Bruce > > > On 10/05/2014 9:36 a.m., Alex Buckley wrote: >> Joe, >> >> On 5/9/2014 8:24 AM, Joe Darcy wrote: >>> My first reaction here is that these methods should by default ignore >>> annotations and we should add another utility method or two like: >>> >>> T withAnnotations(T typeMirror, List>> AnnotationMirror> annotations) >>> >>> T withAnnotations(T typeMirror, >>> AnnotatedConstruct annotationHost) >>> >>> to allow the annotations savvy user to perform whatever annotation >>> passing along or computation is appropriate for the problem domain. >> >> In other words, specify in javax.lang.model.util.Types that it is >> unspecified as to the presence of type annotations in a TypeMirror >> object returned by a Types' method ? And also, specify builder >> methods that decorate an existing TypeMirror object with type >> annotations ? >> >> This approach sidesteps the complexities (alluded to in my prior >> mail) of trying to enrich certain methods' results with type >> annotations. >> >> This approach also exposes that "there's more than one way to do it", >> so we should not rush into decisions that ultimately will be part of >> JSR 269's next Maintenance Review. Do you keep a to-do list for 269 >> somewhere? >> >> Alex >> > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > From brucechapman at paradise.net.nz Mon May 12 09:17:53 2014 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Mon, 12 May 2014 21:17:53 +1200 Subject: interactions between type annotations and language model APIs. In-Reply-To: <536FA41E.5090708@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536F3656.1050100@paradise.net.nz> <536FA41E.5090708@oracle.com> Message-ID: <537091C1.8040009@paradise.net.nz> On 12/05/2014 4:23 a.m., Joe Darcy wrote: > Hi Bruce, > On 5/11/2014 1:35 AM, Bruce Chapman wrote: >> I think you are on the right track here. Types' methods would >> probably strip type annotations, but provide tools for the user to >> reinsert them when the user knows that is appropriate and valuable >> given the semantics of the annotation and what the code is trying to >> do. I am presuming Joe's second method would in some way back >> substitute an annotated type for an (possibly) unannotated type >> within the typeMirror argument? > > The intention is the second method was that the returned value would > be a wrapper around the first argument that had the annotations of the > second argument. So wouldn't the second argument be better as List? > >> >> withAnnotations(typeof(List), typeof(@Nullable String)> would >> return typeof(List<@Nullable String>? > > I intended this to return > > @Nullable List So how would we construct (for example) List<@Nullable String> if Types.getDeclaredType() stripped @Nullable off String, and there is no deep back substitution? And given that deep back substitution is also problematic, could it work if we had an explicit function to (possibly recursively) strip all annotations from a type, or strip specified (with a List) annotations from a type, but did not strip in Types' existing methods? We might also need a stripAnnotationsExcept(TypeMirror t, List retainedAnnotationTypes) to provide for all possibilities. Along with something to add annotations, I think that would provide a full set of construction techniques. Users would still need to write their own versions of Types.isXXX() if the annotations were significant for their use case. Are Michael Ernst and JSR308 E.G. across this thread? Bruce > >> >> if so, what happens when the second argument appears more than once >> in the first argument? e.g. Map? >> >> Despite these difficulties, I still think stripping then tools to >> reinsert the type annotations is what would be most useful. >> >> The alternative would be some way to tell types' method what should >> happen. > > I don't see you good way to approach that problem. Stripping the > annotations and allowing them to be added, gives interested parties > full control while being a tractable API. > > Thanks, > > -Joe > >> >> Bruce >> >> >> On 10/05/2014 9:36 a.m., Alex Buckley wrote: >>> Joe, >>> >>> On 5/9/2014 8:24 AM, Joe Darcy wrote: >>>> My first reaction here is that these methods should by default ignore >>>> annotations and we should add another utility method or two like: >>>> >>>> T withAnnotations(T typeMirror, List>>> AnnotationMirror> annotations) >>>> >>>> T withAnnotations(T typeMirror, >>>> AnnotatedConstruct annotationHost) >>>> >>>> to allow the annotations savvy user to perform whatever annotation >>>> passing along or computation is appropriate for the problem domain. >>> >>> In other words, specify in javax.lang.model.util.Types that it is >>> unspecified as to the presence of type annotations in a TypeMirror >>> object returned by a Types' method ? And also, specify builder >>> methods that decorate an existing TypeMirror object with type >>> annotations ? >>> >>> This approach sidesteps the complexities (alluded to in my prior >>> mail) of trying to enrich certain methods' results with type >>> annotations. >>> >>> This approach also exposes that "there's more than one way to do >>> it", so we should not rush into decisions that ultimately will be >>> part of JSR 269's next Maintenance Review. Do you keep a to-do list >>> for 269 somewhere? >>> >>> Alex >>> >> >> >> --- >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> http://www.avast.com >> > > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From daniel.smith at oracle.com Mon May 12 18:16:05 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 12 May 2014 12:16:05 -0600 Subject: RFR: JDK-8042882: Support verbosity options in langtools testing Message-ID: A patch to enhance langtools/test/Makefile is inline, below. This addresses JDK-8042882, adding a variable to control verbosity. I've also slipped in a fix for JDK-8032441, eliminating the use of the MaxPermSize JVM option (deprecated in 8, gone in 9) when running JCK tests. ?Dan # HG changeset patch # Parent e5d0d7510671bc6725cb0f231553697bf6ca76b6 diff -r e5d0d7510671 test/Makefile --- a/test/Makefile Fri May 09 14:56:59 2014 -0600 +++ b/test/Makefile Mon May 12 12:05:29 2014 -0600 @@ -186,6 +186,12 @@ JTREG_OPTIONS += -timeoutFactor:$(JTREG_TIMEOUT_FACTOR) endif +# Default verbosity setting for jtreg +JTREG_VERBOSE = fail,error,nopass + +# Default verbosity setting for jck +JCK_VERBOSE = non-pass + # Assertions: some tests show failures when assertions are enabled. # Since javac is typically loaded via the bootclassloader (either via TESTJAVA # or TESTBOOTCLASSPATH), you may need -esa to enable assertions in javac. @@ -256,6 +262,8 @@ # Version of java used to run jtreg. Should normally be the same as TESTJAVA # TESTJAVA # Version of java to be tested. +# JTREG_VERBOSE +# Verbosity setting for jtreg # JTREG_OPTIONS # Additional options for jtreg # JTREG_TESTDIRS @@ -273,7 +281,7 @@ JT_JAVA=$(JT_JAVA) $(JTREG) \ -J-Xmx512m \ -vmoption:-Xmx768m \ - -a -ignore:quiet -v:fail,error,nopass \ + -a -ignore:quiet $(if $(JTREG_VERBOSE),-v:$(JTREG_VERBOSE)) \ -r:$(JTREG_OUTPUT_DIR)/JTreport \ -w:$(JTREG_OUTPUT_DIR)/JTwork \ -jdk:$(TESTJAVA) \ @@ -312,6 +320,8 @@ # Default is JDK 7 # TESTJAVA # Version of java to be tested. +# JCK_VERBOSE +# Verbosity setting for jtjck # JCK_COMPILER_OPTIONS # Additional options for JCK-compiler # JCK_COMPILER_TESTDIRS @@ -325,9 +335,9 @@ @rm -f -r $(JCK_COMPILER_OUTPUT_DIR)/work $(JCK_COMPILER_OUTPUT_DIR)/report \ $(JCK_COMPILER_OUTPUT_DIR)/diff.html $(JCK_COMPILER_OUTPUT_DIR)/status.txt @mkdir -p $(JCK_COMPILER_OUTPUT_DIR) - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \ + $(JT_JAVA)/bin/java -Xmx512m \ -jar $(JCK_HOME)/JCK-compiler-8/lib/jtjck.jar \ - -v:non-pass \ + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \ -r:$(JCK_COMPILER_OUTPUT_DIR)/report \ -w:$(JCK_COMPILER_OUTPUT_DIR)/work \ -jdk:$(TESTJAVA) \ @@ -361,6 +371,8 @@ # Version of java used to run JCK. Should normally be the same as TESTJAVA # TESTJAVA # Version of java to be tested. +# JCK_VERBOSE +# Verbosity setting for jtjck # JCK_RUNTIME_OPTIONS # Additional options for JCK-runtime # JCK_RUNTIME_TESTDIRS @@ -374,9 +386,9 @@ @rm -f -r $(JCK_RUNTIME_OUTPUT_DIR)/work $(JCK_RUNTIME_OUTPUT_DIR)/report \ $(JCK_RUNTIME_OUTPUT_DIR)/diff.html $(JCK_RUNTIME_OUTPUT_DIR)/status.txt @mkdir -p $(JCK_RUNTIME_OUTPUT_DIR) - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \ + $(JT_JAVA)/bin/java -Xmx512m \ -jar $(JCK_HOME)/JCK-runtime-8/lib/jtjck.jar \ - -v:non-pass \ + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \ -r:$(JCK_RUNTIME_OUTPUT_DIR)/report \ -w:$(JCK_RUNTIME_OUTPUT_DIR)/work \ -jdk:$(TESTJAVA) \ From alex.buckley at oracle.com Mon May 12 21:13:25 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 12 May 2014 14:13:25 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <537091C1.8040009@paradise.net.nz> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536F3656.1050100@paradise.net.nz> <536FA41E.5090708@oracle.com> <537091C1.8040009@paradise.net.nz> Message-ID: <53713975.80205@oracle.com> On 5/12/2014 2:17 AM, Bruce Chapman wrote: > Are Michael Ernst and JSR308 E.G. across this thread? JSR 308 has had its Final Release, so officially the EG has disbanded, and Mike and I are co-Maintenance Leads. I have cc'd him so he is aware of this thread. That said, the reflective aspects of JSR 308 - Core Reflection, Language Model, and Annotation Processing - were generally handled by Oracle. Alex From alex.buckley at oracle.com Mon May 12 21:26:09 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 12 May 2014 14:26:09 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <536D6CDA.5060506@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536D58E9.8030009@oracle.com> <536D5DB6.1080706@oracle.com> <536D6CDA.5060506@oracle.com> Message-ID: <53713C71.3000402@oracle.com> On 5/9/2014 5:03 PM, Jonathan Gibbons wrote: > If in doubt, specify that none survive, and give clients a determinsitic > base on which to build their own type systems. This seems to be the right approach, given the limitations of the existing Types API and the many possible operations for adding, deleting, and replacing type annotations. I will file a JBS bug to specify that no type annotations appear in the return values of Types' methods. Actually designing new methods in Types, or even a whole new API, is beyond the scope the bug; it would require a JEP. Alex From mike.duigou at oracle.com Mon May 12 21:33:45 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 12 May 2014 14:33:45 -0700 Subject: RFR: JDK-8042882: Support verbosity options in langtools testing In-Reply-To: References: Message-ID: <5E8F9C91-D94D-45DF-B5B0-7C60381B6618@oracle.com> Looks good to me. A very useful addition that I plan to port to the jdk repo. Mike On May 12 2014, at 11:16 , Dan Smith wrote: > A patch to enhance langtools/test/Makefile is inline, below. > > This addresses JDK-8042882, adding a variable to control verbosity. I've also slipped in a fix for JDK-8032441, eliminating the use of the MaxPermSize JVM option (deprecated in 8, gone in 9) when running JCK tests. > > ?Dan > > # HG changeset patch > # Parent e5d0d7510671bc6725cb0f231553697bf6ca76b6 > > diff -r e5d0d7510671 test/Makefile > --- a/test/Makefile Fri May 09 14:56:59 2014 -0600 > +++ b/test/Makefile Mon May 12 12:05:29 2014 -0600 > @@ -186,6 +186,12 @@ > JTREG_OPTIONS += -timeoutFactor:$(JTREG_TIMEOUT_FACTOR) > endif > > +# Default verbosity setting for jtreg > +JTREG_VERBOSE = fail,error,nopass > + > +# Default verbosity setting for jck > +JCK_VERBOSE = non-pass > + > # Assertions: some tests show failures when assertions are enabled. > # Since javac is typically loaded via the bootclassloader (either via TESTJAVA > # or TESTBOOTCLASSPATH), you may need -esa to enable assertions in javac. > @@ -256,6 +262,8 @@ > # Version of java used to run jtreg. Should normally be the same as TESTJAVA > # TESTJAVA > # Version of java to be tested. > +# JTREG_VERBOSE > +# Verbosity setting for jtreg > # JTREG_OPTIONS > # Additional options for jtreg > # JTREG_TESTDIRS > @@ -273,7 +281,7 @@ > JT_JAVA=$(JT_JAVA) $(JTREG) \ > -J-Xmx512m \ > -vmoption:-Xmx768m \ > - -a -ignore:quiet -v:fail,error,nopass \ > + -a -ignore:quiet $(if $(JTREG_VERBOSE),-v:$(JTREG_VERBOSE)) \ > -r:$(JTREG_OUTPUT_DIR)/JTreport \ > -w:$(JTREG_OUTPUT_DIR)/JTwork \ > -jdk:$(TESTJAVA) \ > @@ -312,6 +320,8 @@ > # Default is JDK 7 > # TESTJAVA > # Version of java to be tested. > +# JCK_VERBOSE > +# Verbosity setting for jtjck > # JCK_COMPILER_OPTIONS > # Additional options for JCK-compiler > # JCK_COMPILER_TESTDIRS > @@ -325,9 +335,9 @@ > @rm -f -r $(JCK_COMPILER_OUTPUT_DIR)/work $(JCK_COMPILER_OUTPUT_DIR)/report \ > $(JCK_COMPILER_OUTPUT_DIR)/diff.html $(JCK_COMPILER_OUTPUT_DIR)/status.txt > @mkdir -p $(JCK_COMPILER_OUTPUT_DIR) > - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \ > + $(JT_JAVA)/bin/java -Xmx512m \ > -jar $(JCK_HOME)/JCK-compiler-8/lib/jtjck.jar \ > - -v:non-pass \ > + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \ > -r:$(JCK_COMPILER_OUTPUT_DIR)/report \ > -w:$(JCK_COMPILER_OUTPUT_DIR)/work \ > -jdk:$(TESTJAVA) \ > @@ -361,6 +371,8 @@ > # Version of java used to run JCK. Should normally be the same as TESTJAVA > # TESTJAVA > # Version of java to be tested. > +# JCK_VERBOSE > +# Verbosity setting for jtjck > # JCK_RUNTIME_OPTIONS > # Additional options for JCK-runtime > # JCK_RUNTIME_TESTDIRS > @@ -374,9 +386,9 @@ > @rm -f -r $(JCK_RUNTIME_OUTPUT_DIR)/work $(JCK_RUNTIME_OUTPUT_DIR)/report \ > $(JCK_RUNTIME_OUTPUT_DIR)/diff.html $(JCK_RUNTIME_OUTPUT_DIR)/status.txt > @mkdir -p $(JCK_RUNTIME_OUTPUT_DIR) > - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \ > + $(JT_JAVA)/bin/java -Xmx512m \ > -jar $(JCK_HOME)/JCK-runtime-8/lib/jtjck.jar \ > - -v:non-pass \ > + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \ > -r:$(JCK_RUNTIME_OUTPUT_DIR)/report \ > -w:$(JCK_RUNTIME_OUTPUT_DIR)/work \ > -jdk:$(TESTJAVA) \ > From joe.darcy at oracle.com Mon May 12 21:39:26 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 12 May 2014 14:39:26 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <537091C1.8040009@paradise.net.nz> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536F3656.1050100@paradise.net.nz> <536FA41E.5090708@oracle.com> <537091C1.8040009@paradise.net.nz> Message-ID: <53713F8E.1060009@oracle.com> Hi Bruce, On 5/12/2014 2:17 AM, Bruce Chapman wrote: > On 12/05/2014 4:23 a.m., Joe Darcy wrote: >> Hi Bruce, >> On 5/11/2014 1:35 AM, Bruce Chapman wrote: >>> I think you are on the right track here. Types' methods would >>> probably strip type annotations, but provide tools for the user to >>> reinsert them when the user knows that is appropriate and valuable >>> given the semantics of the annotation and what the code is trying to >>> do. I am presuming Joe's second method would in some way back >>> substitute an annotated type for an (possibly) unannotated type >>> within the typeMirror argument? >> >> The intention is the second method was that the returned value would >> be a wrapper around the first argument that had the annotations of >> the second argument. > So wouldn't the second argument be better as List? To flesh out the semantics of the two methods I proposed: T withAnnotations(T typeMirror, List annotations) T withAnnotations(T typeMirror, AnnotatedConstruct annotationHost) Both methods would return a wrapper object around the first argument. The second argument would supply the annotations for the wrapper object. In the first method, the annotation mirrors would be used; in the second method, the wrapper would use the annotations on the second argument (perhaps after some applicability checks). The second method has intended to support use cases like "this type should be regarded as having the same annotations as this object, perhaps some supertype, etc." At least with this API sketch, this is a low-level API that would have the expressibility to create any annotation structure. However, it might not be very convenient to use for complicated transformations. -Joe From alex.buckley at oracle.com Mon May 12 22:01:07 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 12 May 2014 15:01:07 -0700 Subject: interactions between type annotations and language model APIs. In-Reply-To: <53713C71.3000402@oracle.com> References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536D58E9.8030009@oracle.com> <536D5DB6.1080706@oracle.com> <536D6CDA.5060506@oracle.com> <53713C71.3000402@oracle.com> Message-ID: <537144A3.9040107@oracle.com> On 5/12/2014 2:26 PM, Alex Buckley wrote: > I will file a JBS bug to specify that no type annotations appear in the > return values of Types' methods. Actually designing new methods in > Types, or even a whole new API, is beyond the scope the bug; it would > require a JEP. https://bugs.openjdk.java.net/browse/JDK-8042981 From eric.mccorkle at oracle.com Thu May 15 16:40:48 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 15 May 2014 12:40:48 -0400 Subject: Public review of rearchitected front-end type annotations pipeline In-Reply-To: <536D3130.2010500@oracle.com> References: <536D3130.2010500@oracle.com> Message-ID: <5374EE10.5060500@oracle.com> I have integrated a number of edits to the patch, from both the public and internal reviews, and I have fixed a few issues I found. A new version has been posted here: http://cr.openjdk.java.net/~emc/8027262/webrev.01/ It is likely that this change will be integrated later today, or tomorrow. At that point, I will post the third and final patch in the series. On 05/09/14 15:49, Eric McCorkle wrote: > Hello, > > This is the public review of the second in my series of patches dealing > with type annotations. > > http://cr.openjdk.java.net/~emc/8027262/ > > This patch rearchitects the type annotations pipeline, integrating > handling of type annotations directly into the javac > MemberEnter/Annotate/Attr pipeline. It represents the majority of the > work I have been doing regarding type annotations for 8u20. > > The handling of type annotations is now dispatched by the MemberEnter or > Attr visitors and uses information from those visitors. Most of the > actual functionality is now implemented in Annotate. > > The new test Stress.java is the test for this patch. Stress.java will > cause 8-release javac to fail with an assertion failure. Its addition > to the test suite demonstrates that this change fixes those cases. > > This patch addresses a number of JBS issues: > https://bugs.openjdk.java.net/browse/JDK-8027262 > https://bugs.openjdk.java.net/browse/JDK-8027261 > https://bugs.openjdk.java.net/browse/JDK-8027258 > https://bugs.openjdk.java.net/browse/JDK-8027182 > and possibly others as well. > > Note: this patch does not attempt to remove code made obsolete; however, > any such code is very clearly marked as deprecated. Removal of dead > code will be done in the last of the series. This patch also does not > attempt to re-enable tests which were previously disabled. That will be > done as a separate patch as well. > -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From eric.mccorkle at oracle.com Fri May 16 11:53:36 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 16 May 2014 07:53:36 -0400 Subject: CFV: New jdk9 Committer- Paul Govereau Message-ID: <5375FC40.40607@oracle.com> I hereby nominate Paul Govereau for jdk9 committer Paul joined the langtools team at Oracle in December of 2013, and has contributed a number of patches to both the jdk9 and 8u langtools repository. The following is a list of his contributions to jdk9: 8033437: javac, inconsistent generic types behaviour when compiling together vs. separate 8030046: javac incorrectly handles absolute paths in manifest classpath 8039026: Definitely unassigned field can be accessed 8041521: JDK-8034245 breaks a bootcycle build 8034245: Refactor TopLevel tree node. 8038023: Compiler crash ClassCastException 8015499: javac, Gen is generating extra checkcast instructions in some corner cases 8023945: javac wrongly allows a subclass of an anonymous class 8034933: Update documentation for Types.directSupertypes to clarify behavior 8025505: Constant folding deficiency 8036007: javac crashes when encountering an unresolvable interface 8035972: missing test file for 8034048 6533516: Warning needed for file with future time stamps 8034048: javac crash with method references plus lambda plus var args 8030726: tools/javac/NoStringToLower.java fails due to enforcement no use of String.toLowerCase on non-langtools classes 8030642: Add golden files to javac/limits Votes are due by May 30, 2014. Only current jdk9 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Eric McCorkle [1]http://openjdk.java.net/census [2]http://openjdk.java.net/projects/#committer-vote -------------- next part -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 303 bytes Desc: not available URL: From vicente.romero at oracle.com Fri May 16 13:35:47 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 16 May 2014 14:35:47 +0100 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: <53761433.4090808@oracle.com> vote: yes Vicente On 16/05/14 12:53, Eric McCorkle wrote: > I hereby nominate Paul Govereau for jdk9 committer > > Paul joined the langtools team at Oracle in December of 2013, and has > contributed a number of patches to both the jdk9 and 8u langtools > repository. > > The following is a list of his contributions to jdk9: > > 8033437: javac, inconsistent generic types behaviour when compiling > together vs. separate > 8030046: javac incorrectly handles absolute paths in manifest classpath > 8039026: Definitely unassigned field can be accessed > 8041521: JDK-8034245 breaks a bootcycle build > 8034245: Refactor TopLevel tree node. > 8038023: Compiler crash ClassCastException > 8015499: javac, Gen is generating extra checkcast instructions in some > corner cases > 8023945: javac wrongly allows a subclass of an anonymous class > 8034933: Update documentation for Types.directSupertypes to clarify behavior > 8025505: Constant folding deficiency > 8036007: javac crashes when encountering an unresolvable interface > 8035972: missing test file for 8034048 > 6533516: Warning needed for file with future time stamps > 8034048: javac crash with method references plus lambda plus var args > 8030726: tools/javac/NoStringToLower.java fails due to enforcement no > use of String.toLowerCase on non-langtools classes > 8030642: Add golden files to javac/limits > > Votes are due by May 30, 2014. > > Only current jdk9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > Eric McCorkle > > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > From karen.kinnear at oracle.com Fri May 16 14:48:05 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 16 May 2014 10:48:05 -0400 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: <6498E2DF-E40C-46EC-83F4-3FED868E337C@oracle.com> Vote: yes On May 16, 2014, at 7:53 AM, Eric McCorkle wrote: > I hereby nominate Paul Govereau for jdk9 committer > > Paul joined the langtools team at Oracle in December of 2013, and has > contributed a number of patches to both the jdk9 and 8u langtools > repository. > > The following is a list of his contributions to jdk9: > > 8033437: javac, inconsistent generic types behaviour when compiling > together vs. separate > 8030046: javac incorrectly handles absolute paths in manifest classpath > 8039026: Definitely unassigned field can be accessed > 8041521: JDK-8034245 breaks a bootcycle build > 8034245: Refactor TopLevel tree node. > 8038023: Compiler crash ClassCastException > 8015499: javac, Gen is generating extra checkcast instructions in some > corner cases > 8023945: javac wrongly allows a subclass of an anonymous class > 8034933: Update documentation for Types.directSupertypes to clarify behavior > 8025505: Constant folding deficiency > 8036007: javac crashes when encountering an unresolvable interface > 8035972: missing test file for 8034048 > 6533516: Warning needed for file with future time stamps > 8034048: javac crash with method references plus lambda plus var args > 8030726: tools/javac/NoStringToLower.java fails due to enforcement no > use of String.toLowerCase on non-langtools classes > 8030642: Add golden files to javac/limits > > Votes are due by May 30, 2014. > > Only current jdk9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > Eric McCorkle > > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > From staffan.larsen at oracle.com Fri May 16 15:28:52 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 16 May 2014 17:28:52 +0200 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: Vote: yes On 16 maj 2014, at 13:53, Eric McCorkle wrote: > I hereby nominate Paul Govereau for jdk9 committer > > Paul joined the langtools team at Oracle in December of 2013, and has > contributed a number of patches to both the jdk9 and 8u langtools > repository. > > The following is a list of his contributions to jdk9: > > 8033437: javac, inconsistent generic types behaviour when compiling > together vs. separate > 8030046: javac incorrectly handles absolute paths in manifest classpath > 8039026: Definitely unassigned field can be accessed > 8041521: JDK-8034245 breaks a bootcycle build > 8034245: Refactor TopLevel tree node. > 8038023: Compiler crash ClassCastException > 8015499: javac, Gen is generating extra checkcast instructions in some > corner cases > 8023945: javac wrongly allows a subclass of an anonymous class > 8034933: Update documentation for Types.directSupertypes to clarify behavior > 8025505: Constant folding deficiency > 8036007: javac crashes when encountering an unresolvable interface > 8035972: missing test file for 8034048 > 6533516: Warning needed for file with future time stamps > 8034048: javac crash with method references plus lambda plus var args > 8030726: tools/javac/NoStringToLower.java fails due to enforcement no > use of String.toLowerCase on non-langtools classes > 8030642: Add golden files to javac/limits > > Votes are due by May 30, 2014. > > Only current jdk9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > Eric McCorkle > > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > From john.r.rose at oracle.com Fri May 16 15:34:26 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 16 May 2014 08:34:26 -0700 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: <95C1FD44-5068-42AC-AFE0-26952DC14EE1@oracle.com> Vote: yes ? John > On May 16, 2014, at 4:53 AM, Eric McCorkle wrote: > > I hereby nominate Paul Govereau for jdk9 committer From mike.duigou at oracle.com Fri May 16 15:58:24 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 16 May 2014 08:58:24 -0700 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: Vote: YES On May 16 2014, at 04:53 , Eric McCorkle wrote: > I hereby nominate Paul Govereau for jdk9 committer > > Paul joined the langtools team at Oracle in December of 2013, and has > contributed a number of patches to both the jdk9 and 8u langtools > repository. > > The following is a list of his contributions to jdk9: > > 8033437: javac, inconsistent generic types behaviour when compiling > together vs. separate > 8030046: javac incorrectly handles absolute paths in manifest classpath > 8039026: Definitely unassigned field can be accessed > 8041521: JDK-8034245 breaks a bootcycle build > 8034245: Refactor TopLevel tree node. > 8038023: Compiler crash ClassCastException > 8015499: javac, Gen is generating extra checkcast instructions in some > corner cases > 8023945: javac wrongly allows a subclass of an anonymous class > 8034933: Update documentation for Types.directSupertypes to clarify behavior > 8025505: Constant folding deficiency > 8036007: javac crashes when encountering an unresolvable interface > 8035972: missing test file for 8034048 > 6533516: Warning needed for file with future time stamps > 8034048: javac crash with method references plus lambda plus var args > 8030726: tools/javac/NoStringToLower.java fails due to enforcement no > use of String.toLowerCase on non-langtools classes > 8030642: Add golden files to javac/limits > > Votes are due by May 30, 2014. > > Only current jdk9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > Eric McCorkle > > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > From Xuelei.Fan at Oracle.Com Fri May 16 16:06:37 2014 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Sat, 17 May 2014 00:06:37 +0800 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: <5D82E5A1-EA2A-485F-A504-7754F0FC2B01@Oracle.Com> Vote: yes. Xuelei > On May 16, 2014, at 7:53 PM, Eric McCorkle wrote: > > I hereby nominate Paul Govereau for jdk9 committer > > Paul joined the langtools team at Oracle in December of 2013, and has > contributed a number of patches to both the jdk9 and 8u langtools > repository. > > The following is a list of his contributions to jdk9: > > 8033437: javac, inconsistent generic types behaviour when compiling > together vs. separate > 8030046: javac incorrectly handles absolute paths in manifest classpath > 8039026: Definitely unassigned field can be accessed > 8041521: JDK-8034245 breaks a bootcycle build > 8034245: Refactor TopLevel tree node. > 8038023: Compiler crash ClassCastException > 8015499: javac, Gen is generating extra checkcast instructions in some > corner cases > 8023945: javac wrongly allows a subclass of an anonymous class > 8034933: Update documentation for Types.directSupertypes to clarify behavior > 8025505: Constant folding deficiency > 8036007: javac crashes when encountering an unresolvable interface > 8035972: missing test file for 8034048 > 6533516: Warning needed for file with future time stamps > 8034048: javac crash with method references plus lambda plus var args > 8030726: tools/javac/NoStringToLower.java fails due to enforcement no > use of String.toLowerCase on non-langtools classes > 8030642: Add golden files to javac/limits > > Votes are due by May 30, 2014. > > Only current jdk9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > Eric McCorkle > > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > From vicente.romero at oracle.com Fri May 16 17:11:40 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 16 May 2014 18:11:40 +0100 Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785 Message-ID: <537646CC.4090008@oracle.com> Hi Alex, Regarding the bug report in the subject. I initially considered it a bug but now I'm wondering about the meaning of a final flag in a bridge method. Also I didn't find in the spec a reference saying what flags can be applied to bridge methods. For example can a bridge method be strictfp too? Thanks, Vicente From david.lloyd at redhat.com Fri May 16 17:19:55 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 16 May 2014 12:19:55 -0500 Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785 In-Reply-To: <537646CC.4090008@oracle.com> References: <537646CC.4090008@oracle.com> Message-ID: <537648BB.8090601@redhat.com> On 05/16/2014 12:11 PM, Vicente-Arturo Romero-Zaldivar wrote: > Hi Alex, > > Regarding the bug report in the subject. I initially considered it a bug > but now I'm wondering about the meaning of a final flag in a bridge > method. Also I didn't find in the spec a reference saying what flags can > be applied to bridge methods. For example can a bridge method be > strictfp too? > > Thanks, > Vicente Why would a final flag have any different meaning for a bridge method? Also, I don't see any reason why strictfp would be disallowed (bridge methods do have bodies after all), though it might not be "strictly" useful in practice. Maybe it'd be relevant to instrumentors though? -- - DML From alex.buckley at oracle.com Fri May 16 19:38:15 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 16 May 2014 12:38:15 -0700 Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785 In-Reply-To: <537646CC.4090008@oracle.com> References: <537646CC.4090008@oracle.com> Message-ID: <53766927.2030008@oracle.com> Hi Vicente, On 5/16/2014 10:11 AM, Vicente-Arturo Romero-Zaldivar wrote: > Regarding the bug report in the subject. I initially considered it a bug > but now I'm wondering about the meaning of a final flag in a bridge > method. Also I didn't find in the spec a reference saying what flags can > be applied to bridge methods. For example can a bridge method be > strictfp too? As David indicated, there is no "problem" with a bridge method being marked final (or strictfp) in the class file. It's syntactically legal (access_flags allows it) and semantically level (you can meaningfully have a bridge method that is not overrideable). My concern is with unforeseen consequences at the language level. Today it is possible to override a bridge method - yes, it's almost certainly accidental, but if we start making some bridge methods final then some programs are going to break. But, the number of such programs will be low, and arguably they never deserved to compile. So, I would go ahead with the bug fix. Alex From david.lloyd at redhat.com Fri May 16 19:46:48 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 16 May 2014 14:46:48 -0500 Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785 In-Reply-To: <53766927.2030008@oracle.com> References: <537646CC.4090008@oracle.com> <53766927.2030008@oracle.com> Message-ID: <53766B28.3010706@redhat.com> On 05/16/2014 02:38 PM, Alex Buckley wrote: > Hi Vicente, > > On 5/16/2014 10:11 AM, Vicente-Arturo Romero-Zaldivar wrote: >> Regarding the bug report in the subject. I initially considered it a bug >> but now I'm wondering about the meaning of a final flag in a bridge >> method. Also I didn't find in the spec a reference saying what flags can >> be applied to bridge methods. For example can a bridge method be >> strictfp too? > > As David indicated, there is no "problem" with a bridge method being > marked final (or strictfp) in the class file. It's syntactically legal > (access_flags allows it) and semantically level (you can meaningfully > have a bridge method that is not overrideable). > > My concern is with unforeseen consequences at the language level. Today > it is possible to override a bridge method - yes, it's almost certainly > accidental, but if we start making some bridge methods final then some > programs are going to break. But, the number of such programs will be > low, and arguably they never deserved to compile. So, I would go ahead > with the bug fix. Not to mention any program which is relying on finality as a security mechanism... -- - DML From vicente.romero at oracle.com Fri May 16 21:09:41 2014 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 16 May 2014 22:09:41 +0100 Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785 In-Reply-To: <53766B28.3010706@redhat.com> References: <537646CC.4090008@oracle.com> <53766927.2030008@oracle.com> <53766B28.3010706@redhat.com> Message-ID: <53767E95.9090005@oracle.com> Hi Alex, Thanks for your replay. I already have a fix for this bug that is copying flags like final and strictfp from the original method to the bridge method, and no one else. But I preferred to double check with you before going on with the fix. Thanks, Vicente On 16/05/14 20:46, David M. Lloyd wrote: > On 05/16/2014 02:38 PM, Alex Buckley wrote: >> Hi Vicente, >> >> On 5/16/2014 10:11 AM, Vicente-Arturo Romero-Zaldivar wrote: >>> Regarding the bug report in the subject. I initially considered it a >>> bug >>> but now I'm wondering about the meaning of a final flag in a bridge >>> method. Also I didn't find in the spec a reference saying what flags >>> can >>> be applied to bridge methods. For example can a bridge method be >>> strictfp too? >> >> As David indicated, there is no "problem" with a bridge method being >> marked final (or strictfp) in the class file. It's syntactically legal >> (access_flags allows it) and semantically level (you can meaningfully >> have a bridge method that is not overrideable). >> >> My concern is with unforeseen consequences at the language level. Today >> it is possible to override a bridge method - yes, it's almost certainly >> accidental, but if we start making some bridge methods final then some >> programs are going to break. But, the number of such programs will be >> low, and arguably they never deserved to compile. So, I would go ahead >> with the bug fix. > > Not to mention any program which is relying on finality as a security > mechanism... > From david.r.chase at oracle.com Fri May 16 12:14:53 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 16 May 2014 08:14:53 -0400 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: <7EB574BC-F75E-4FCF-A1BA-DEC3AAC012A5@oracle.com> Vote: yes On 2014-05-16, at 7:53 AM, Eric McCorkle wrote: > I hereby nominate Paul Govereau for jdk9 committer > > Paul joined the langtools team at Oracle in December of 2013, and has > contributed a number of patches to both the jdk9 and 8u langtools > repository. > > The following is a list of his contributions to jdk9: > > 8033437: javac, inconsistent generic types behaviour when compiling > together vs. separate > 8030046: javac incorrectly handles absolute paths in manifest classpath > 8039026: Definitely unassigned field can be accessed > 8041521: JDK-8034245 breaks a bootcycle build > 8034245: Refactor TopLevel tree node. > 8038023: Compiler crash ClassCastException > 8015499: javac, Gen is generating extra checkcast instructions in some > corner cases > 8023945: javac wrongly allows a subclass of an anonymous class > 8034933: Update documentation for Types.directSupertypes to clarify behavior > 8025505: Constant folding deficiency > 8036007: javac crashes when encountering an unresolvable interface > 8035972: missing test file for 8034048 > 6533516: Warning needed for file with future time stamps > 8034048: javac crash with method references plus lambda plus var args > 8030726: tools/javac/NoStringToLower.java fails due to enforcement no > use of String.toLowerCase on non-langtools classes > 8030642: Add golden files to javac/limits > > Votes are due by May 30, 2014. > > Only current jdk9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > Eric McCorkle > > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From yumin.qi at oracle.com Fri May 16 15:43:36 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 16 May 2014 08:43:36 -0700 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: <53763228.20006@oracle.com> Vote: Yes On 5/16/2014 4:53 AM, Eric McCorkle wrote: > I hereby nominate Paul Govereau for jdk9 committer > > Paul joined the langtools team at Oracle in December of 2013, and has > contributed a number of patches to both the jdk9 and 8u langtools > repository. > > The following is a list of his contributions to jdk9: > > 8033437: javac, inconsistent generic types behaviour when compiling > together vs. separate > 8030046: javac incorrectly handles absolute paths in manifest classpath > 8039026: Definitely unassigned field can be accessed > 8041521: JDK-8034245 breaks a bootcycle build > 8034245: Refactor TopLevel tree node. > 8038023: Compiler crash ClassCastException > 8015499: javac, Gen is generating extra checkcast instructions in some > corner cases > 8023945: javac wrongly allows a subclass of an anonymous class > 8034933: Update documentation for Types.directSupertypes to clarify behavior > 8025505: Constant folding deficiency > 8036007: javac crashes when encountering an unresolvable interface > 8035972: missing test file for 8034048 > 6533516: Warning needed for file with future time stamps > 8034048: javac crash with method references plus lambda plus var args > 8030726: tools/javac/NoStringToLower.java fails due to enforcement no > use of String.toLowerCase on non-langtools classes > 8030642: Add golden files to javac/limits > > Votes are due by May 30, 2014. > > Only current jdk9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > Eric McCorkle > > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > From serguei.spitsyn at oracle.com Tue May 20 07:18:32 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 20 May 2014 00:18:32 -0700 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: <537B01C8.7060601@oracle.com> Vote: yes From kumar.x.srinivasan at oracle.com Wed May 21 18:21:18 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 21 May 2014 11:21:18 -0700 Subject: CFV: New jdk9 Committer- Paul Govereau In-Reply-To: <5375FC40.40607@oracle.com> References: <5375FC40.40607@oracle.com> Message-ID: <537CEE9E.60201@oracle.com> Vote: yes Kumar On 5/16/2014 4:53 AM, Eric McCorkle wrote: > I hereby nominate Paul Govereau for jdk9 committer > > Paul joined the langtools team at Oracle in December of 2013, and has > contributed a number of patches to both the jdk9 and 8u langtools > repository. > > The following is a list of his contributions to jdk9: > > 8033437: javac, inconsistent generic types behaviour when compiling > together vs. separate > 8030046: javac incorrectly handles absolute paths in manifest classpath > 8039026: Definitely unassigned field can be accessed > 8041521: JDK-8034245 breaks a bootcycle build > 8034245: Refactor TopLevel tree node. > 8038023: Compiler crash ClassCastException > 8015499: javac, Gen is generating extra checkcast instructions in some > corner cases > 8023945: javac wrongly allows a subclass of an anonymous class > 8034933: Update documentation for Types.directSupertypes to clarify behavior > 8025505: Constant folding deficiency > 8036007: javac crashes when encountering an unresolvable interface > 8035972: missing test file for 8034048 > 6533516: Warning needed for file with future time stamps > 8034048: javac crash with method references plus lambda plus var args > 8030726: tools/javac/NoStringToLower.java fails due to enforcement no > use of String.toLowerCase on non-langtools classes > 8030642: Add golden files to javac/limits > > Votes are due by May 30, 2014. > > Only current jdk9 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > Eric McCorkle > > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > From joe.darcy at oracle.com Tue May 27 16:35:49 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 27 May 2014 09:35:49 -0700 Subject: Question on JEP 119: javax.lang.model Implementation Backed by Core Reflection In-Reply-To: <53831018.3060703@linux.vnet.ibm.com> References: <53831018.3060703@linux.vnet.ibm.com> Message-ID: <5384BEE5.20301@oracle.com> On 05/26/2014 02:57 AM, Shi Jun Zhang wrote: > Hi, > > I'm interested in the implementation of JEP 119, however there is no > RFE in this JEP [1]. What I only find is a changeset for 8004133 [2] > in langtools repository and it only provides a sample Java file. > > My question is that is this the only change for this JEP 119? Is there > any new API provided as it is described in the JEP? > > [1] http://openjdk.java.net/jeps/119 > [2] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/bcd927639039 > Hello, In JDK 8, the sample code you found is the extent of the javax.lang.model implementation backed by core reflection feature. HTH, -Joe From joe.darcy at oracle.com Wed May 28 02:14:23 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 27 May 2014 19:14:23 -0700 Subject: Draft JEP for comment: Milling Project Coin: softening some rough edges Message-ID: <5385467F.9010107@oracle.com> Hello, For your consideration, I submit a draft JEP covering Milling Project Coin: softening some rough edges https://bugs.openjdk.java.net/browse/JDK-8042880 Full text of the JEP is below. To be clear, this is *not* a call to run "Coin 2.0," nor is it an effort to work on features that were dropped from Project Coin. This JEP is just to describe some maintenance-level changes, most of which were identified as possible future work in the JSR 334 drafts. Thanks, -Joe Summary The small language changes included in Project Coin / JSR 334 as part of JDK 7 / Java SE 7 have been easy to use and have worked well in practice. However, several amendments could address a few rough edges of those changes. Non-goals This JEP does *not* propose to run a "Coin 2.0" effort or to generally solicit new language proposals. Description Three amendments to the Project Coin features are proposed: 1) Allow @SafeVargs on private instance methods. The @SafeVarargs annotation can only be applied to methods which cannot be overridden, including static methods and final instance methods. Private instance methods are another use case that @SafeVargs could accommodate. 2) Allow effectively final variables to be used as resources in the try-with-resources statement. The final version of try-with-resources statement in Java SE 7 requires a fresh variable to be declared for each resource being managed by the statement. This was a change from earlier iterations of the feature. The public review draft of JSR 334 discusses the rationale for the change from the early draft review version of try-with-resource which allowed an expression managed by the statement. The JSR 334 expert group was in favor of an additional refinement of try-with-resources: if the resource is referenced by a final or effectively final variable, a try-with-resources statement can manage the resource without a new variable being declared. This restricted expression being managed by a try-with-resources statement avoids the semantic issues which motivated removing general expression support. At the time the expert group settled on this refinement, there was insufficient time in the release schedule to accommodate the change. 3) Allow diamond with inner classes if the argument type of the inferred type is denotable. Because the inferred type using diamond with an inner class constructor could be outside of the set of types supported by the signature attribute, using diamond with inner classes was disallowed in Java SE 7. As noted in the JSR 334 proposed final draft, it would be possible to ease this restriction if the inferred type was denotable. In the space of Java language changes, these refinements are very small changes. The @SafeVarags change might only involve changing a sentence or two of the specification with a similarly sized change in javac. However, as with any Java language change, care must be taken to handle all the pieces of the platform that need updating. Testing The language changes would require the usual unit and regression tests for javac. The JCK compiler suite would need to be updated, both positive tests and negative tests. From jose.cornado at gmail.com Wed May 28 17:32:01 2014 From: jose.cornado at gmail.com (=?UTF-8?Q?Jos=C3=A9_Cornado?=) Date: Wed, 28 May 2014 11:32:01 -0600 Subject: help with unusual warning Message-ID: Hello! I just got this message: Note: Cannot write values to this compiler: com.sun.tools.javac.processing.JavacProcessingEnvironment This is the first time I have seen it. I am scratching my head why this would be happening . Is this the right group to address this? Thanks a lot!!! -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed May 28 19:28:49 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 28 May 2014 12:28:49 -0700 Subject: help with unusual warning In-Reply-To: References: Message-ID: <538638F1.7020203@oracle.com> What tools are you using and what command line or other activity are you doing to provoke this message? -- Jon On 05/28/2014 10:32 AM, Jos? Cornado wrote: > Hello! > > I just got this message: > > Note: Cannot write values to this compiler: > com.sun.tools.javac.processing.JavacProcessingEnvironment > > This is the first time I have seen it. I am scratching my head why > this would be happening . > > Is this the right group to address this? > > > Thanks a lot!!! > > -- > Jos? Cornado > > -- > > home: http://www.efekctive.com > blog: http://blogging.efekctive.com > ---------------------- > > Everything has been said before, but since nobody listens we have to > keep going back and beginning all over again. > > Andre Gide > > -- > Jos? Cornado > > -- > > home: http://www.efekctive.com > blog: http://blogging.efekctive.com > ---------------------- > > Everything has been said before, but since nobody listens we have to > keep going back and beginning all over again. > > Andre Gide -------------- next part -------------- An HTML attachment was scrubbed... URL: