From martinrb at google.com Tue Apr 1 23:09:11 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 1 Apr 2014 16:09:11 -0700 Subject: JLS tweaks In-Reply-To: <5339D79D.2050106@oracle.com> References: <5314BFAA.7040606@oracle.com> <53159118.7000802@univ-mlv.fr> <53218391.2030205@gmail.com> <532186AF.4000909@gmail.com> <5323092D.7030101@redhat.com> <532318F5.90700@oracle.com> <5339D79D.2050106@oracle.com> Message-ID: I continue to think that "components" should have an associated mailing list. Elsewhere you wrote rather clearly, Proposals for new features in the Java programming language are no longer being accepted or maintained in the Java bug database. This also applies to proposals for new features in the Java Virtual Machine (that is, in the abstract JVM, as opposed to a JVM implementation like HotSpot). All proposals for new features should be made through the "JDK Enhancement - Proposal & Roadmap Process" described athttp://openjdk.java.net/jeps/1. https://bugs.openjdk.java.net/browse/JDK-8029988 So if you start a JEP, you apparently get a discussion list for that JEP, but you'll likely end up with few passers-by on such a list. As it stands, there is no good place to discuss speculative features that may lead to a future JEP. On Mon, Mar 31, 2014 at 2:01 PM, Alex Buckley wrote: > On 3/31/2014 1:45 PM, Martin Buchholz wrote: > >> - It would be good if there was a permanent mailing list (and bug >> category) for specification changes (JLS and JVMS) instead of spinning >> up a mailing list only for major features. >> > > Please distinguish "specification changes" from "language/VM changes": > > - "specification changes" concern changes in the text of the JLS and JVMS. > There have long been aliases for feedback about errors, omissions, and > ambiguities in the text - see [1] and [2] for the most recent info. There > has long been a bug category too - recall "java/java/specification" in > Bugtraq, now "specification" in JBS. People use these channels all the time. > > - "language/VM changes" concern changes in the design of the Java language > and abstract JVM. compiler-dev, hotspot-dev, and their associated JBS > components are assuredly not the right place. > > Alex > > [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-1.html#jls-1.5 > [2] http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-1.html#jvms-1.5 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sunny.Chan at gs.com Wed Apr 2 02:30:33 2014 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Wed, 2 Apr 2014 10:30:33 +0800 Subject: Request for Review [8u20]: backport 8034048 javac crash with method references plus lambda plus var args. Message-ID: <1CF6FDFD0639DF478B44651D79ECE704A4EA0138@GSCMHKP12EX.firmwide.corp.gs.com> Can I get the review to backport the following fix to jdk8u, please? Bugs: https://bugs.openjdk.java.net/browse/JDK-8034048 https://bugs.openjdk.java.net/browse/JDK-8035972 Both has been Integrated in jdk9: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/008f76d3209a (8034048) http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/b03893804cd3 (8035972) I have merged both of these patch against jdk8u and I have attached the patch for review. Sunny Chan, Executive Director, Technology Goldman Sachs (Asia) L.L.C. | 68th Floor | Cheung Kong Center | 2 Queens Road Central | Hong Kong email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8034048-for-8u.patch Type: application/octet-stream Size: 2572 bytes Desc: 8034048-for-8u.patch URL: From paul.govereau at oracle.com Thu Apr 3 15:54:09 2014 From: paul.govereau at oracle.com (Paul Govereau) Date: Thu, 03 Apr 2014 11:54:09 -0400 Subject: Request for Review [8u20]: backport 8034048 javac crash with method references plus lambda plus var args. In-Reply-To: <533C5575.80807@oracle.com> References: <1CF6FDFD0639DF478B44651D79ECE704A4EA0138@GSCMHKP12EX.firmwide.corp.gs.com> <533C5575.80807@oracle.com> Message-ID: <533D8421.4000708@oracle.com> Hello, I will back-port these changes to 8u20. The tracking issue is here: https://bugs.openjdk.java.net/browse/JDK-8039178 Paul > -------- Original Message -------- > Subject: Request for Review [8u20]: backport 8034048 javac crash with > method references plus lambda plus var args. > Date: Wed, 2 Apr 2014 10:30:33 +0800 > From: Chan, Sunny > To: 'compiler-dev at openjdk.java.net' > > > > Can I get the review to backport the following fix to jdk8u, please? > > Bugs: > > https://bugs.openjdk.java.net/browse/JDK-8034048 > > https://bugs.openjdk.java.net/browse/JDK-8035972 > > Both has been Integrated in jdk9: > > http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/008f76d3209a (8034048) > > http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/b03893804cd3 (8035972) > > I have merged both of these patch against jdk8u and I have attached the > patch for review. > > *Sunny Chan*, Executive Director, Technology > > Goldman Sachs (Asia) L.L.C. | 68th Floor | Cheung Kong Center | 2 Queens > Road Central | Hong Kong > > email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 > > This message may contain information that is confidential or > privileged. If you are not the intended recipient, please advise the > sender immediately and delete this message. See > http://www.gs.com/disclaimer/emailfor further information on > confidentiality and the risks inherent in electronic communication. > > > From cushon at google.com Thu Apr 3 17:40:40 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 3 Apr 2014 10:40:40 -0700 Subject: [PATCH]: javac[8,9] with jdk7 Message-ID: On Wed, Mar 26, 2014 at 1:34 AM, Joel Borggr?n-Franck < joel.franck at oracle.com> wrote: > having javac run with JRE n-1 in a degraded state would be a nice > contribution if the patches aren't too intrusive. It sounded like that was the general consensus, so I put together a patch to allow javac 9 to run on jre 7 in a degraded state. That means: - warnings aren't generated for annotation processors that support RELEASE_7 when the source level is 8 or 9 (because the RELEASE_8 and RELEASE_9 constants aren't available) - the native headers feature is disabled (because StandardLocations.NATIVE_HEADER_OUTPUT isn't available) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # HG changeset patch # User Liam Miller-Cushon # Date 1396544631 25200 # Thu Apr 03 10:03:51 2014 -0700 # Node ID ca676423ae58b3f4a87fb89c380d39d8d087a149 # Parent e25d44c21b29e155734f8d832f2edac3d0debe35 Allow javac 9 to run on jre 7 in a degraded state. diff -r e25d44c21b29 -r ca676423ae58 src/share/classes/com/sun/tools/javac/code/Source.java --- a/src/share/classes/com/sun/tools/javac/code/Source.java Thu Mar 27 11:38:37 2014 -0700 +++ b/src/share/classes/com/sun/tools/javac/code/Source.java Thu Apr 03 10:03:51 2014 -0700 @@ -246,11 +246,32 @@ case JDK1_7: return RELEASE_7; case JDK1_8: - return RELEASE_8; + return release8; case JDK1_9: - return RELEASE_9; + return release9; default: return null; } } + + /** {@link SourceVersion.RELEASE_8}, or the latest release if it doesn't exist. */ + private static final SourceVersion release8 = getLatestSupportedSourceVersion("RELEASE_8"); + + /** {@link SourceVersion.RELEASE_9}, or the latest release if it doesn't exist. */ + private static final SourceVersion release9 = getLatestSupportedSourceVersion("RELEASE_9"); + + /** + * Allow javac to compile with -source N and -target N while running on JRE N-1. + * + * If SourceVersion.RELEASE_N does not exist, fall back to using the latest available release. + * This will prevent warnings from being issued about annotation processors that do not support + * source version N, but will otherwise allow javac to run normally and generate version N + * bytecode. + */ + private static SourceVersion getLatestSupportedSourceVersion(String name) { + try { + return SourceVersion.valueOf(name); + } catch (IllegalArgumentException useLatestInstead) {} + return SourceVersion.latest(); + } } diff -r e25d44c21b29 -r ca676423ae58 src/share/classes/com/sun/tools/javac/file/Locations.java --- a/src/share/classes/com/sun/tools/javac/file/Locations.java Thu Mar 27 11:38:37 2014 -0700 +++ b/src/share/classes/com/sun/tools/javac/file/Locations.java Thu Apr 03 10:03:51 2014 -0700 @@ -48,6 +48,7 @@ import com.sun.tools.javac.code.Lint; import com.sun.tools.javac.main.Option; +import com.sun.tools.javac.util.List; import com.sun.tools.javac.util.ListBuffer; import com.sun.tools.javac.util.Log; import com.sun.tools.javac.util.Options; @@ -651,15 +652,18 @@ handlersForLocation = new HashMap<>(); handlersForOption = new EnumMap<>(Option.class); - LocationHandler[] handlers = { + List handlers = List.of( new BootClassPathLocationHandler(), new ClassPathLocationHandler(), new SimpleLocationHandler(StandardLocation.SOURCE_PATH, Option.SOURCEPATH), new SimpleLocationHandler(StandardLocation.ANNOTATION_PROCESSOR_PATH, Option.PROCESSORPATH), new OutputLocationHandler((StandardLocation.CLASS_OUTPUT), Option.D), - new OutputLocationHandler((StandardLocation.SOURCE_OUTPUT), Option.S), - new OutputLocationHandler((StandardLocation.NATIVE_HEADER_OUTPUT), Option.H) - }; + new OutputLocationHandler((StandardLocation.SOURCE_OUTPUT), Option.S)); + + if (hasNativeHeaderOutput()) { + handlers = handlers.append( + new OutputLocationHandler(nativeHeaderOutput(), Option.H)); + } for (LocationHandler h: handlers) { handlersForLocation.put(h.location, h); @@ -668,6 +672,42 @@ } } + private static final JavacFileManager.Location nativeHeaderOutput; + static { + JavacFileManager.Location result = null; + for (StandardLocation location : StandardLocation.values()) { + if (location.getName().equals("NATIVE_HEADER_OUTPUT")) { + result = location; + break; + } + } + nativeHeaderOutput = result; + } + + /** + * Test whether StandardLocation.NATIVE_HEADER_OUTPUT is available (i.e. the current JRE is + * version 8 or greater). + * + * @return true if StandardLocation.NATIVE_HEADER_OUTPUT exists + */ + public static boolean hasNativeHeaderOutput() { + return nativeHeaderOutput != null; + } + + /** + * Provide StandardLocation.NATIVE_HEADER_OUTPUT if it is available. This is needed for runtime + * compatibility with JRE 7. + * + * @return StandardLocation.NATIVE_HEADER_OUTPUT + * @throws NullPointerException if StandardLocation.NATIVE_HEADER_OUTPUT does not exist + */ + public static JavacFileManager.Location nativeHeaderOutput() { + if (nativeHeaderOutput == null) { + throw new NullPointerException(); + } + return nativeHeaderOutput; + } + boolean handleOption(Option option, String value) { LocationHandler h = handlersForOption.get(option); return (h == null ? false : h.handleOption(option, value)); diff -r e25d44c21b29 -r ca676423ae58 src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java --- a/src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java Thu Mar 27 11:38:37 2014 -0700 +++ b/src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java Thu Apr 03 10:03:51 2014 -0700 @@ -42,6 +42,7 @@ import com.sun.tools.javac.code.Symbol.ClassSymbol; import com.sun.tools.javac.code.Symbol.VarSymbol; import com.sun.tools.javac.code.Symtab; +import com.sun.tools.javac.file.Locations; import com.sun.tools.javac.code.Type; import com.sun.tools.javac.code.Types; import com.sun.tools.javac.model.JavacElements; @@ -171,7 +172,7 @@ public FileObject write(ClassSymbol c) throws IOException { String className = c.flatName().toString(); FileObject outFile - = fileManager.getFileForOutput(StandardLocation.NATIVE_HEADER_OUTPUT, + = fileManager.getFileForOutput(Locations.nativeHeaderOutput(), "", className.replaceAll("[.$]", "_") + ".h", null); PrintWriter out = new PrintWriter(outFile.openWriter()); try { diff -r e25d44c21b29 -r ca676423ae58 src/share/classes/com/sun/tools/javac/main/JavaCompiler.java --- a/src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Thu Mar 27 11:38:37 2014 -0700 +++ b/src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Thu Apr 03 10:03:51 2014 -0700 @@ -56,6 +56,7 @@ import com.sun.tools.javac.comp.*; import com.sun.tools.javac.comp.CompileStates.CompileState; import com.sun.tools.javac.file.JavacFileManager; +import com.sun.tools.javac.file.Locations; import com.sun.tools.javac.jvm.*; import com.sun.tools.javac.parser.*; import com.sun.tools.javac.processing.*; @@ -1564,7 +1565,8 @@ if (usePrintSource) file = printSource(env, cdef); else { - if (fileManager.hasLocation(StandardLocation.NATIVE_HEADER_OUTPUT) + if (Locations.hasNativeHeaderOutput() + && fileManager.hasLocation(Locations.nativeHeaderOutput()) && jniWriter.needsHeader(cdef.sym)) { jniWriter.write(cdef.sym); } diff -r e25d44c21b29 -r ca676423ae58 src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java --- a/src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java Thu Mar 27 11:38:37 2014 -0700 +++ b/src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java Thu Apr 03 10:03:51 2014 -0700 @@ -25,6 +25,7 @@ package com.sun.tools.sjavac.comp; +import com.sun.tools.javac.file.Locations; import com.sun.tools.javac.util.ListBuffer; import java.io.IOException; import java.io.PrintWriter; @@ -175,7 +176,8 @@ { FileObject file = super.getFileForOutput(location, packageName, relativeName, sibling); if (file == null) return file; - if (location.equals(StandardLocation.NATIVE_HEADER_OUTPUT) && + if (Locations.hasNativeHeaderOutput() && + location.equals(Locations.nativeHeaderOutput()) && file instanceof JavaFileObject) { file = new SmartFileObject((JavaFileObject)file, stdout); packageName = ":" + packageNameFromFileName(relativeName); From forax at univ-mlv.fr Thu Apr 3 18:30:58 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 03 Apr 2014 20:30:58 +0200 Subject: [PATCH]: javac[8,9] with jdk7 In-Reply-To: References: Message-ID: <533DA8E2.7040301@univ-mlv.fr> On 04/03/2014 07:40 PM, Liam Miller-Cushon wrote: > On Wed, Mar 26, 2014 at 1:34 AM, Joel Borggr?n-Franck > > wrote: > > having javac run with JRE n-1 in a degraded state would be a nice > contribution if the patches aren't too intrusive. > > > It sounded like that was the general consensus, so I put together a > patch to allow javac 9 to run on jre 7 in a degraded state. javac9 ?? I was thinking it was about running javac8 with jdk7 and not javac9 with jdk7, I have no problem with the former but I'm strongly against the later, there are several parts of javac that can be simplified by using lambdas instead of inner classes so javac9 should not have a dependency on JRE n-2. regards, R?mi From martinrb at google.com Thu Apr 3 18:51:56 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 3 Apr 2014 11:51:56 -0700 Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8? In-Reply-To: <533D93E3.4030301@oracle.com> References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com> <533D93E3.4030301@oracle.com> Message-ID: On Thu, Apr 3, 2014 at 10:01 AM, Joe Darcy wrote: > On 04/03/2014 09:33 AM, Martin Buchholz wrote: > > > > > On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy wrote: > >> A broader question this issue raises is why are components like corba >> built using the book JDK rather than the JDK they are a part of? > > > If we're cross-compiling, the JDK being built may never be executable > > > But the code in the jdk repository in JDK N is built such that it can use > the language features and new libraries of JDK N. In contrast, the code in > the corba (and IIRC jaxp and jaxws) repo is restricted to using features in > the boot JDK, typically JDK (N-1). > No problem. Java and bytecode are both architecture-independent, and langtools can be compiled and run using JDK N-1, so: compile JDK N langtools using JDK N-1 langtools, then compile the rest of the JDK using JRE N-1 executing JDK N langtools as "Just another portable Java program". Except for the small problem of collisions between javac.jar and rt.jar, e.g. SourceVersion that Liam is trying to find a solution for (not involving -Xbootclasspath/p:) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu Apr 3 19:51:52 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 3 Apr 2014 12:51:52 -0700 Subject: [PATCH]: javac N with jdk N-1 Message-ID: On Thu, Apr 3, 2014 at 11:30 AM, Remi Forax wrote: > javac9 ?? > > I was thinking it was about running javac8 with jdk7 and not javac9 with > jdk7, > I have no problem with the former but I'm strongly against the later, > there are several parts of javac that can be simplified by using lambdas > instead of inner classes > so javac9 should not have a dependency on JRE n-2. > Sorry, I was unclear - my proposal is still to allow javac N on jdk N-1, where the specific N I'm interested in is 8. I understand that the javac 9 code base will start using java 8 language features. The fact that the patch would currently allow javac9 to run on jdk7 is just an artifact of javac9 not yet having diverged very far from javac8. I guess my patch should target 8u directly, rather than going into 9 and being backported? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Thu Apr 3 21:01:32 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 3 Apr 2014 14:01:32 -0700 Subject: [PATCH]: javac[8,9] with jdk7 In-Reply-To: <533DA8E2.7040301@univ-mlv.fr> References: <533DA8E2.7040301@univ-mlv.fr> Message-ID: Although this change does make javac9 run on JDK7, that's not what's important about it. The changes that Liam is making here will be important for running every future N on every future N-1. Basically, javacN should *never* depend on SourceVersion.RELEASE_N. This happens (coincidentally) to allow javac9 to run on JDK7, but that's not something that is necessarily a feature requirement. Jeremy On Thu, Apr 3, 2014 at 11:30 AM, Remi Forax wrote: > On 04/03/2014 07:40 PM, Liam Miller-Cushon wrote: > > On Wed, Mar 26, 2014 at 1:34 AM, Joel Borggr?n-Franck < >> joel.franck at oracle.com > wrote: >> >> having javac run with JRE n-1 in a degraded state would be a nice >> contribution if the patches aren't too intrusive. >> >> >> It sounded like that was the general consensus, so I put together a patch >> to allow javac 9 to run on jre 7 in a degraded state. >> > > javac9 ?? > > I was thinking it was about running javac8 with jdk7 and not javac9 with > jdk7, > I have no problem with the former but I'm strongly against the later, > there are several parts of javac that can be simplified by using lambdas > instead of inner classes > so javac9 should not have a dependency on JRE n-2. > > regards, > R?mi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Thu Apr 3 22:05:27 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 04 Apr 2014 00:05:27 +0200 Subject: [PATCH]: javac N with jdk N-1 In-Reply-To: References: Message-ID: <533DDB27.6030506@univ-mlv.fr> On 04/03/2014 09:51 PM, Liam Miller-Cushon wrote: > On Thu, Apr 3, 2014 at 11:30 AM, Remi Forax > wrote: > > javac9 ?? > > I was thinking it was about running javac8 with jdk7 and not > javac9 with jdk7, > I have no problem with the former but I'm strongly against the later, > there are several parts of javac that can be simplified by using > lambdas instead of inner classes > so javac9 should not have a dependency on JRE n-2. > > > Sorry, I was unclear - my proposal is still to allow javac N on jdk > N-1, where the specific N I'm interested in is 8. I understand that > the javac 9 code base will start using java 8 language features. > > The fact that the patch would currently allow javac9 to run on jdk7 is > just an artifact of javac9 not yet having diverged very far from javac8. ok, got it. > > I guess my patch should target 8u directly, rather than going into 9 > and being backported? not sure, I will let Jon answer to that question. R?mi From forax at univ-mlv.fr Thu Apr 3 22:06:45 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 04 Apr 2014 00:06:45 +0200 Subject: [PATCH]: javac[8,9] with jdk7 In-Reply-To: References: <533DA8E2.7040301@univ-mlv.fr> Message-ID: <533DDB75.5020809@univ-mlv.fr> On 04/03/2014 11:01 PM, Jeremy Manson wrote: > Although this change does make javac9 run on JDK7, that's not what's > important about it. The changes that Liam is making here will be > important for running every future N on every future N-1. Basically, > javacN should *never* depend on SourceVersion.RELEASE_N. > > This happens (coincidentally) to allow javac9 to run on JDK7, but > that's not something that is necessarily a feature requirement. > > Jeremy ok, sorry, I overreact. cheers, R?mi > > > On Thu, Apr 3, 2014 at 11:30 AM, Remi Forax > wrote: > > On 04/03/2014 07:40 PM, Liam Miller-Cushon wrote: > > On Wed, Mar 26, 2014 at 1:34 AM, Joel Borggr?n-Franck > > >> wrote: > > having javac run with JRE n-1 in a degraded state would be > a nice > contribution if the patches aren't too intrusive. > > > It sounded like that was the general consensus, so I put > together a patch to allow javac 9 to run on jre 7 in a > degraded state. > > > javac9 ?? > > I was thinking it was about running javac8 with jdk7 and not > javac9 with jdk7, > I have no problem with the former but I'm strongly against the later, > there are several parts of javac that can be simplified by using > lambdas instead of inner classes > so javac9 should not have a dependency on JRE n-2. > > regards, > R?mi > > From oehrstroem at gmail.com Fri Apr 4 06:54:57 2014 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 4 Apr 2014 08:54:57 +0200 Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8? In-Reply-To: References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com> <533D93E3.4030301@oracle.com> Message-ID: > > On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy wrote: >> >>> A broader question this issue raises is why are components like corba >>> built using the book JDK rather than the JDK they are a part of? >> >> As Alan said, for historical reasons only. If you wanted to actually compile corba/jaxp/jaxws using the new jdk, it would be trivial to change the build system to do so, since we already do so with nashorn. //Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaelesgarro at gmail.com Fri Apr 4 07:54:00 2014 From: raffaelesgarro at gmail.com (Raffaele Sgarro) Date: Fri, 4 Apr 2014 09:54:00 +0200 Subject: Accessing static members on type variables Message-ID: Consider the following code (ideone ): class Outer { public static final String FIELD = "Success!";} class Test { public String test() { return T.FIELD; } } Does the JSL allow a type variable T to be used to access static members of its upper bound? -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Apr 4 07:59:43 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 04 Apr 2014 09:59:43 +0200 Subject: Accessing static members on type variables In-Reply-To: References: Message-ID: <533E666F.7000100@univ-mlv.fr> On 04/04/2014 09:54 AM, Raffaele Sgarro wrote: > Consider the following code (ideone ): > > class Outer{ > public static final String FIELD= "Success!"; > } > > class Test{ > public String test() { > return T.FIELD; > } > } > Does the JSL allow a type variable T to be used to access static > members of its upper bound? No ! R?mi From raffaelesgarro at gmail.com Fri Apr 4 08:06:47 2014 From: raffaelesgarro at gmail.com (Raffaele Sgarro) Date: Fri, 4 Apr 2014 10:06:47 +0200 Subject: Accessing static members on type variables In-Reply-To: <533E666F.7000100@univ-mlv.fr> References: <533E666F.7000100@univ-mlv.fr> Message-ID: Still, it compiles and runs successfully, so there must be some piece of code in the compiler that replaces the type variable with its bound, and that piece of code must be intentional. I didn't test with JDK8 (or any compiler other than 1.7) 2014-04-04 9:59 GMT+02:00 Remi Forax : > On 04/04/2014 09:54 AM, Raffaele Sgarro wrote: > >> Consider the following code (ideone ): >> >> >> class Outer{ >> public static final String FIELD= "Success!"; >> } >> >> class Test{ >> >> public String test() { >> return T.FIELD; >> } } >> Does the JSL allow a type variable T to be used to access static members >> of its upper bound? >> > > No ! > > R?mi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Apr 4 15:40:49 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 04 Apr 2014 17:40:49 +0200 Subject: [PATCH]: javac[8,9] with jdk7 In-Reply-To: References: Message-ID: <533ED281.1010705@oracle.com> Liam, I tried the patch, using this sample code: --- interface ID { public default void test() {} } --- Running (using JDK 7): $ java -jar javac.jar -Xprint ID.java leads to the attached exception1.txt. Using the attached ScanningProcessor.java, running: $ java -jar javac.jar -processorpath -processor ScanningProcessor ID.java leads to the attached exception2.txt. I suspect there may be other similar problems around TypeKind.INTERSECTION - I wonder if there is an automated way to look for problems like this? Jan On 04/03/2014 07:40 PM, Liam Miller-Cushon wrote: > On Wed, Mar 26, 2014 at 1:34 AM, Joel Borggr?n-Franck > > wrote: > > having javac run with JRE n-1 in a degraded state would be a nice > contribution if the patches aren't too intrusive. > > > It sounded like that was the general consensus, so I put together a > patch to allow javac 9 to run on jre 7 in a degraded state. That means: > > - warnings aren't generated for annotation processors that support > RELEASE_7 when the source level is 8 or 9 (because the RELEASE_8 and > RELEASE_9 constants aren't available) > > - the native headers feature is disabled (because > StandardLocations.NATIVE_HEADER_OUTPUT isn't available) -------------- next part -------------- An annotation processor threw an uncaught exception. Consult the following stack trace for details. java.lang.EnumConstantNotPresentException: javax.lang.model.SourceVersion.RELEASE_9 at sun.reflect.annotation.EnumConstantNotPresentExceptionProxy.generateException(EnumConstantNotPresentExceptionProxy.java:47) at sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:75) at com.sun.proxy.$Proxy4.value(Unknown Source) at javax.annotation.processing.AbstractProcessor.getSupportedSourceVersion(AbstractProcessor.java:130) at com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.checkSourceVersionCompatibility(JavacProcessingEnvironment.java:531) at com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.(JavacProcessingEnvironment.java:502) at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:597) at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:689) at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91) at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1034) at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1175) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1176) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) at com.sun.tools.javac.main.Main.compile(Main.java:526) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:56) at com.sun.tools.javac.Main.main(Main.java:42) -------------- next part -------------- A non-text attachment was scrubbed... Name: ScanningProcessor.java Type: text/x-java Size: 846 bytes Desc: not available URL: -------------- next part -------------- modifiers: [abstract] warning: No SupportedSourceVersion annotation found on ScanningProcessor, returning RELEASE_6. warning: Supported source version 'RELEASE_6' from annotation processor 'ScanningProcessor' less than -source '1.9' An annotation processor threw an uncaught exception. Consult the following stack trace for details. java.lang.NoSuchFieldError: DEFAULT at com.sun.tools.javac.code.Flags.asModifierSet(Flags.java:318) at com.sun.tools.javac.code.Symbol$MethodSymbol.getModifiers(Symbol.java:1339) at ScanningProcessor$1.scan(ScanningProcessor.java:17) at ScanningProcessor$1.scan(ScanningProcessor.java:14) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:131) at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:171) at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:1151) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:141) at ScanningProcessor$1.scan(ScanningProcessor.java:18) at ScanningProcessor$1.scan(ScanningProcessor.java:14) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:131) at ScanningProcessor.process(ScanningProcessor.java:14) at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793) at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:704) at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91) at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1034) at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1175) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1176) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) at com.sun.tools.javac.main.Main.compile(Main.java:526) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:56) at com.sun.tools.javac.Main.main(Main.java:42) From oehrstroem at gmail.com Fri Apr 4 17:26:21 2014 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 4 Apr 2014 19:26:21 +0200 Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8? In-Reply-To: <440FD96F-2D8D-4FA1-86A1-57E4E246B4E1@gmail.com> References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com> <533D93E3.4030301@oracle.com> <440FD96F-2D8D-4FA1-86A1-57E4E246B4E1@gmail.com> Message-ID: You are right Kelly, the old build system did use the idlj from the boot jdk. The new build, does build a bootstrap idlj, as can be seen here: he http://hg.openjdk.java.net/jdk9/jdk9/corba/file/14e7fbdd1dcb/make/GensrcCorba.gmk And uses this bootstrap idlj to compile the idl files, so at least that odd boot jdk dependency is removed. //Fredrik 2014-04-04 17:57 GMT+02:00 Kelly O'Hair : > As I recall, corba builds do some code generation with idlj, which is in > corba I think, so a boot jdk version of idlj > would need to be built and run with the boot jdk, then you could build > everything with the new jdk. > Or so I recall.. > > -kto > > On Apr 3, 2014, at 11:54 PM, Fredrik ?hrstr?m wrote: > > >> > >> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy wrote: > >>> > >>>> A broader question this issue raises is why are components like corba > >>>> built using the book JDK rather than the JDK they are a part of? > >>> > >>> As Alan said, for historical reasons only. If you wanted to actually > > compile corba/jaxp/jaxws using the new jdk, it would be trivial to change > > the build system to do so, since we already do so with nashorn. > > > > //Fredrik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Apr 4 18:20:51 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 04 Apr 2014 11:20:51 -0700 Subject: Accessing static members on type variables In-Reply-To: References: Message-ID: <533EF803.6000701@oracle.com> Membership of the type variable T is specified by JLS 4.4 and 4.9. The members of T are the same as the members of a class QQQ whose direct superclass is Outer. Since QQQ would inherit FIELD from Outer, T has a member FIELD. There is nothing special about FIELD being static. Alex On 4/4/2014 12:54 AM, Raffaele Sgarro wrote: > Consider the following code (ideone ): > > class Outer{ > public static final String FIELD= "Success!"; > } > > class Test{ > public String test() { > return T.FIELD; > } > } > > Does the JSL allow a type variable T to be used to access static members > of its upper bound? From forax at univ-mlv.fr Fri Apr 4 18:47:55 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 04 Apr 2014 20:47:55 +0200 Subject: Accessing static members on type variables In-Reply-To: <533EF803.6000701@oracle.com> References: <533EF803.6000701@oracle.com> Message-ID: <533EFE5B.9090606@univ-mlv.fr> On 04/04/2014 08:20 PM, Alex Buckley wrote: > Membership of the type variable T is specified by JLS 4.4 and 4.9. The > members of T are the same as the members of a class QQQ whose direct > superclass is Outer. Since QQQ would inherit FIELD from Outer, T has a > member FIELD. There is nothing special about FIELD being static. > > Alex My bad, I've read the email of Raffaele too fast, I was thinking of bug 7022052, see https://bugs.openjdk.java.net/browse/JDK-7022052 Anyway, it's quite ugly. R?mi > > On 4/4/2014 12:54 AM, Raffaele Sgarro wrote: >> Consider the following code (ideone ): >> >> class Outer{ >> public static final String FIELD= "Success!"; >> } >> >> class Test{ >> public String test() { >> return T.FIELD; >> } >> } >> >> Does the JSL allow a type variable T to be used to access static members >> of its upper bound? From cushon at google.com Fri Apr 4 19:22:01 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 4 Apr 2014 12:22:01 -0700 Subject: [PATCH]: javac[8,9] with jdk7 In-Reply-To: <533ED281.1010705@oracle.com> References: <533ED281.1010705@oracle.com> Message-ID: Jan, Thanks for trying the patch. I will update it to handle Modifier.DEFAULT and TypeKind.INTERSECTION. I was testing primarily with java 7 source and java 7 annotations processors, so the issue you discovered didn't come up. In the case of the -Xprint crash, PrintingProcessor will need to be updated to support SourceVersion.latest() instead of using RELEASE_8 explicitly. I agree that an automatic way to find these problems would be nice. Perhaps some subset of the test coverage could be run without the -Xbootclasspath hack, but that might get tricky in areas where javac's behaviour will have to regress on jre n-1. On Fri, Apr 4, 2014 at 8:40 AM, Jan Lahoda wrote: > Liam, > > I tried the patch, using this sample code: > --- > interface ID { > public default void test() {} > } > --- > > Running (using JDK 7): > $ java -jar javac.jar -Xprint ID.java > leads to the attached exception1.txt. > > Using the attached ScanningProcessor.java, running: > $ java -jar javac.jar -processorpath -processor ScanningProcessor > ID.java > > leads to the attached exception2.txt. I suspect there may be other similar > problems around TypeKind.INTERSECTION - I wonder if there is an automated > way to look for problems like this? > > Jan > > > On 04/03/2014 07:40 PM, Liam Miller-Cushon wrote: > >> On Wed, Mar 26, 2014 at 1:34 AM, Joel Borggr?n-Franck >> > wrote: >> >> having javac run with JRE n-1 in a degraded state would be a nice >> contribution if the patches aren't too intrusive. >> >> >> It sounded like that was the general consensus, so I put together a >> patch to allow javac 9 to run on jre 7 in a degraded state. That means: >> >> - warnings aren't generated for annotation processors that support >> RELEASE_7 when the source level is 8 or 9 (because the RELEASE_8 and >> RELEASE_9 constants aren't available) >> >> - the native headers feature is disabled (because >> StandardLocations.NATIVE_HEADER_OUTPUT isn't available) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaelesgarro at gmail.com Fri Apr 4 19:52:22 2014 From: raffaelesgarro at gmail.com (Raffaele Sgarro) Date: Fri, 4 Apr 2014 21:52:22 +0200 Subject: Accessing static members on type variables In-Reply-To: <533EFE5B.9090606@univ-mlv.fr> References: <533EF803.6000701@oracle.com> <533EFE5B.9090606@univ-mlv.fr> Message-ID: Thanks guys. Already seen that paragraph of 4.4, and despite the vague warning, I assumed it was ok and tried to understand how the call is dispatched. So I looked into *"15.12.1. Compile-Time Step 1: Determine Class or Interface to Search"*, but: - If the form is *TypeName* . *[TypeArguments]* *Identifier*, then the type to search is the type denoted by *TypeName*. - If the form is *ExpressionName* . *[TypeArguments]* *Identifier*, then the class or interface to search is the declared type T of the variable denoted by *ExpressionName* if T is a class or interface type, or the upper bound of T if T is a type variable. - If the form is *Primary* . *[TypeArguments]* *Identifier*, then let T be the type of the *Primary* expression. The class or interface to search is T if T is a class or interface type, or the upper bound of T if T is a type variable. I know it's difficult to dig into "Section 6: Names", and that's just for curiosity's sake, but it'd be very interesting to know how things go on from this point. BTW, I tried javac8, javac7 and JDT, and all three exhibit the same behavior. 2014-04-04 20:47 GMT+02:00 Remi Forax : > On 04/04/2014 08:20 PM, Alex Buckley wrote: > >> Membership of the type variable T is specified by JLS 4.4 and 4.9. The >> members of T are the same as the members of a class QQQ whose direct >> superclass is Outer. Since QQQ would inherit FIELD from Outer, T has a >> member FIELD. There is nothing special about FIELD being static. >> >> Alex >> > > My bad, I've read the email of Raffaele too fast, > I was thinking of bug 7022052, see https://bugs.openjdk.java.net/ > browse/JDK-7022052 > > Anyway, it's quite ugly. > > R?mi > > > >> On 4/4/2014 12:54 AM, Raffaele Sgarro wrote: >> >>> Consider the following code (ideone ): >>> >>> class Outer{ >>> public static final String FIELD= "Success!"; >>> } >>> >>> class Test{ >>> public String test() { >>> return T.FIELD; >>> } >>> } >>> >>> Does the JSL allow a type variable T to be used to access static members >>> of its upper bound? >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Apr 4 19:56:44 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 04 Apr 2014 12:56:44 -0700 Subject: Accessing static members on type variables In-Reply-To: References: <533EF803.6000701@oracle.com> <533EFE5B.9090606@univ-mlv.fr> Message-ID: <533F0E7C.30400@oracle.com> Your code said T.FIELD, which is a field access dependent on the members of type T. I don't know why you're looking at method invocation. On 4/4/2014 12:52 PM, Raffaele Sgarro wrote: > Thanks guys. > > Already seen that paragraph of 4.4, and despite the vague warning, I > assumed it was ok and tried to understand how the call is dispatched. So > I looked into /"15.12.1. Compile-Time Step 1: Determine Class or > Interface to Search"/, but: > > * > > If the form is /TypeName/ |.| /[TypeArguments]/ /Identifier/, then > the type to search is the type denoted by /TypeName/. > > * > > If the form is /ExpressionName/ |.| /[TypeArguments]/ > /Identifier/, then the class or interface to search is the declared > type T of the variable denoted by /ExpressionName/ if T is a class > or interface type, or the upper bound of T if T is a type variable. > > * > > If the form is /Primary/ |.| /[TypeArguments]/ /Identifier/, then > let T be the type of the /Primary/ expression. The class or > interface to search is T if T is a class or interface type, or the > upper bound of T if T is a type variable. > > > I know it's difficult to dig into "Section 6: Names", and that's just > for curiosity's sake, but it'd be very interesting to know how things go > on from this point. BTW, I tried javac8, javac7 and JDT, and all three > exhibit the same behavior. > > > 2014-04-04 20:47 GMT+02:00 Remi Forax >: > > On 04/04/2014 08:20 PM, Alex Buckley wrote: > > Membership of the type variable T is specified by JLS 4.4 and > 4.9. The members of T are the same as the members of a class QQQ > whose direct superclass is Outer. Since QQQ would inherit FIELD > from Outer, T has a member FIELD. There is nothing special about > FIELD being static. > > Alex > > > My bad, I've read the email of Raffaele too fast, > I was thinking of bug 7022052, see > https://bugs.openjdk.java.net/__browse/JDK-7022052 > > > Anyway, it's quite ugly. > > R?mi > > > > On 4/4/2014 12:54 AM, Raffaele Sgarro wrote: > > Consider the following code (ideone ): > > class Outer{ > public static final String FIELD= "Success!"; > } > > class Test{ > public String test() { > return T.FIELD; > } > } > > Does the JSL allow a type variable T to be used to access > static members > of its upper bound? > > > From raffaelesgarro at gmail.com Fri Apr 4 20:39:28 2014 From: raffaelesgarro at gmail.com (Raffaele Sgarro) Date: Fri, 4 Apr 2014 22:39:28 +0200 Subject: Accessing static members on type variables In-Reply-To: <533F0E7C.30400@oracle.com> References: <533EF803.6000701@oracle.com> <533EFE5B.9090606@univ-mlv.fr> <533F0E7C.30400@oracle.com> Message-ID: Because I put online the sample with a field, but my original case used a method. 2014-04-04 21:56 GMT+02:00 Alex Buckley : > Your code said T.FIELD, which is a field access dependent on the members > of type T. I don't know why you're looking at method invocation. > > > On 4/4/2014 12:52 PM, Raffaele Sgarro wrote: > >> Thanks guys. >> >> Already seen that paragraph of 4.4, and despite the vague warning, I >> assumed it was ok and tried to understand how the call is dispatched. So >> I looked into /"15.12.1. Compile-Time Step 1: Determine Class or >> Interface to Search"/, but: >> >> * >> >> If the form is /TypeName/ |.| /[TypeArguments]/ /Identifier/, then >> the type to search is the type denoted by /TypeName/. >> >> * >> >> If the form is /ExpressionName/ |.| /[TypeArguments]/ >> /Identifier/, then the class or interface to search is the declared >> type T of the variable denoted by /ExpressionName/ if T is a class >> >> or interface type, or the upper bound of T if T is a type variable. >> >> * >> >> If the form is /Primary/ |.| /[TypeArguments]/ /Identifier/, then >> let T be the type of the /Primary/ expression. The class or >> >> interface to search is T if T is a class or interface type, or the >> upper bound of T if T is a type variable. >> >> >> I know it's difficult to dig into "Section 6: Names", and that's just >> for curiosity's sake, but it'd be very interesting to know how things go >> on from this point. BTW, I tried javac8, javac7 and JDT, and all three >> exhibit the same behavior. >> >> >> 2014-04-04 20:47 GMT+02:00 Remi Forax > >: >> >> >> On 04/04/2014 08:20 PM, Alex Buckley wrote: >> >> Membership of the type variable T is specified by JLS 4.4 and >> 4.9. The members of T are the same as the members of a class QQQ >> whose direct superclass is Outer. Since QQQ would inherit FIELD >> from Outer, T has a member FIELD. There is nothing special about >> FIELD being static. >> >> Alex >> >> >> My bad, I've read the email of Raffaele too fast, >> I was thinking of bug 7022052, see >> https://bugs.openjdk.java.net/__browse/JDK-7022052 >> >> >> >> Anyway, it's quite ugly. >> >> R?mi >> >> >> >> On 4/4/2014 12:54 AM, Raffaele Sgarro wrote: >> >> Consider the following code (ideone > >): >> >> class Outer{ >> public static final String FIELD= "Success!"; >> } >> >> class Test{ >> public String test() { >> return T.FIELD; >> } >> } >> >> Does the JSL allow a type variable T to be used to access >> static members >> of its upper bound? >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Apr 4 21:45:27 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 Apr 2014 14:45:27 -0700 Subject: [PATCH]: javac N with jdk N-1 In-Reply-To: References: Message-ID: <533F27F7.7000309@oracle.com> On 04/03/2014 12:51 PM, Liam Miller-Cushon wrote: > On Thu, Apr 3, 2014 at 11:30 AM, Remi Forax > wrote: > > javac9 ?? > > I was thinking it was about running javac8 with jdk7 and not > javac9 with jdk7, > I have no problem with the former but I'm strongly against the later, > there are several parts of javac that can be simplified by using > lambdas instead of inner classes > so javac9 should not have a dependency on JRE n-2. > > > Sorry, I was unclear - my proposal is still to allow javac N on jdk > N-1, where the specific N I'm interested in is 8. I understand that > the javac 9 code base will start using java 8 language features. > > The fact that the patch would currently allow javac9 to run on jdk7 is > just an artifact of javac9 not yet having diverged very far from javac8. > > I guess my patch should target 8u directly, rather than going into 9 > and being backported? Generally, fixes go to 9 first, and are then backported. I don't see a compelling need to deviate from that policy in this case. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Apr 4 22:32:10 2014 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 04 Apr 2014 15:32:10 -0700 Subject: [PATCH]: javac[8,9] with jdk7 In-Reply-To: References: <533ED281.1010705@oracle.com> Message-ID: <533F32EA.3030805@oracle.com> Hello, A few general notes here, you can look at the maintenance reviews of JSRs 199 and 269 to get an idea of the new-in-8 API that javac might be using: https://jcp.org/aboutJava/communityprocess/mrel/jsr199/index.html https://jcp.org/aboutJava/communityprocess/mrel/jsr269/index2.html At the start of JDK (N+1), a new SourceVersion constant for (N+1) is added. Later in the release, changes to the language model can be expected to accommodate any language changes in the release as well as general improvements to the API. I'd like to see a crisper description of what the intended behavior is running the javac from JDK (N+1) on top JDK N. In particular, what is the expected interaction with the SourceVersion latest and latestSupported methods. Note that in JDK 9 preparatory work has begun to implement JEP 182: Policy for Retiring javac -source and -target Options http://openjdk.java.net/jeps/182 In other words, the javac in JDK 9 will only support -source / -target values of 6/1.6, 7/1.8, 8/1.8, and 9/1.9. If this javac were run on top of JDK 8, it would *not* support -source/-target 5/1.5 and earlier. Cheers, -Joe On 4/4/2014 12:22 PM, Liam Miller-Cushon wrote: > Jan, > > Thanks for trying the patch. I will update it to handle > Modifier.DEFAULT and TypeKind.INTERSECTION. I was testing primarily > with java 7 source and java 7 annotations processors, so the issue you > discovered didn't come up. > > In the case of the -Xprint crash, PrintingProcessor will need to be > updated to support SourceVersion.latest() instead of using RELEASE_8 > explicitly. > > I agree that an automatic way to find these problems would be nice. > Perhaps some subset of the test coverage could be run without the > -Xbootclasspath hack, but that might get tricky in areas where javac's > behaviour will have to regress on jre n-1. > > > On Fri, Apr 4, 2014 at 8:40 AM, Jan Lahoda > wrote: > > Liam, > > I tried the patch, using this sample code: > --- > interface ID { > public default void test() {} > } > --- > > Running (using JDK 7): > $ java -jar javac.jar -Xprint ID.java > leads to the attached exception1.txt. > > Using the attached ScanningProcessor.java, running: > $ java -jar javac.jar -processorpath -processor > ScanningProcessor ID.java > > leads to the attached exception2.txt. I suspect there may be other > similar problems around TypeKind.INTERSECTION - I wonder if there > is an automated way to look for problems like this? > > Jan > > > On 04/03/2014 07:40 PM, Liam Miller-Cushon wrote: > > On Wed, Mar 26, 2014 at 1:34 AM, Joel Borggr?n-Franck > > >> wrote: > > having javac run with JRE n-1 in a degraded state would be > a nice > contribution if the patches aren't too intrusive. > > > It sounded like that was the general consensus, so I put > together a > patch to allow javac 9 to run on jre 7 in a degraded state. > That means: > > - warnings aren't generated for annotation processors that support > RELEASE_7 when the source level is 8 or 9 (because the > RELEASE_8 and > RELEASE_9 constants aren't available) > > - the native headers feature is disabled (because > StandardLocations.NATIVE_HEADER_OUTPUT isn't available) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Apr 4 22:33:26 2014 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 04 Apr 2014 15:33:26 -0700 Subject: [PATCH]: javac N with jdk N-1 In-Reply-To: <533F27F7.7000309@oracle.com> References: <533F27F7.7000309@oracle.com> Message-ID: <533F3336.8010406@oracle.com> On 4/4/2014 2:45 PM, Jonathan Gibbons wrote: > > On 04/03/2014 12:51 PM, Liam Miller-Cushon wrote: >> On Thu, Apr 3, 2014 at 11:30 AM, Remi Forax > > wrote: >> >> javac9 ?? >> >> I was thinking it was about running javac8 with jdk7 and not >> javac9 with jdk7, >> I have no problem with the former but I'm strongly against the later, >> there are several parts of javac that can be simplified by using >> lambdas instead of inner classes >> so javac9 should not have a dependency on JRE n-2. >> >> >> Sorry, I was unclear - my proposal is still to allow javac N on jdk >> N-1, where the specific N I'm interested in is 8. I understand that >> the javac 9 code base will start using java 8 language features. >> >> The fact that the patch would currently allow javac9 to run on jdk7 >> is just an artifact of javac9 not yet having diverged very far from >> javac8. >> >> I guess my patch should target 8u directly, rather than going into 9 >> and being backported? > > Generally, fixes go to 9 first, and are then backported. I don't see > a compelling need to deviate from that policy in this case. > > -- Jon > > And I don't think the javac in JDK 9 should be altered to run on top of JDK 7. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From kellyohair at gmail.com Fri Apr 4 15:57:23 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Fri, 4 Apr 2014 08:57:23 -0700 Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8? In-Reply-To: References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com> <533D93E3.4030301@oracle.com> Message-ID: <440FD96F-2D8D-4FA1-86A1-57E4E246B4E1@gmail.com> As I recall, corba builds do some code generation with idlj, which is in corba I think, so a boot jdk version of idlj would need to be built and run with the boot jdk, then you could build everything with the new jdk. Or so I recall.. -kto On Apr 3, 2014, at 11:54 PM, Fredrik ?hrstr?m wrote: >> >> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy wrote: >>> >>>> A broader question this issue raises is why are components like corba >>>> built using the book JDK rather than the JDK they are a part of? >>> >>> As Alan said, for historical reasons only. If you wanted to actually > compile corba/jaxp/jaxws using the new jdk, it would be trivial to change > the build system to do so, since we already do so with nashorn. > > //Fredrik From kellyohair at gmail.com Fri Apr 4 17:36:19 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Fri, 4 Apr 2014 10:36:19 -0700 Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8? In-Reply-To: References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com> <533D93E3.4030301@oracle.com> <440FD96F-2D8D-4FA1-86A1-57E4E246B4E1@gmail.com> Message-ID: <0B83528A-90D2-4E9E-9054-0F2937628314@gmail.com> Good to hear. -kto On Apr 4, 2014, at 10:26 AM, Fredrik ?hrstr?m wrote: > You are right Kelly, the old build system did use the idlj from the boot jdk. > > The new build, does build a bootstrap idlj, as can be seen here: > he http://hg.openjdk.java.net/jdk9/jdk9/corba/file/14e7fbdd1dcb/make/GensrcCorba.gmk > > And uses this bootstrap idlj to compile the idl files, so at least that odd boot jdk dependency is removed. > > //Fredrik > > > > > 2014-04-04 17:57 GMT+02:00 Kelly O'Hair : > As I recall, corba builds do some code generation with idlj, which is in corba I think, so a boot jdk version of idlj > would need to be built and run with the boot jdk, then you could build everything with the new jdk. > Or so I recall.. > > -kto > > On Apr 3, 2014, at 11:54 PM, Fredrik ?hrstr?m wrote: > > >> > >> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy wrote: > >>> > >>>> A broader question this issue raises is why are components like corba > >>>> built using the book JDK rather than the JDK they are a part of? > >>> > >>> As Alan said, for historical reasons only. If you wanted to actually > > compile corba/jaxp/jaxws using the new jdk, it would be trivial to change > > the build system to do so, since we already do so with nashorn. > > > > //Fredrik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaelesgarro at gmail.com Mon Apr 7 17:02:28 2014 From: raffaelesgarro at gmail.com (Raffaele Sgarro) Date: Mon, 7 Apr 2014 19:02:28 +0200 Subject: [BUG] Missing error? blank final may not have been initialized Message-ID: ?16 states: For every access of a local variable or blank final field x, x must be definitely assigned before the access, or a compile-time error occurs. Such an assignment is defined to occur if and only if either the simple name of the variable (or, for a field, its simple name qualified by this) occurs on the left hand side of an assignment operator. Consider the following code: class Ideone { public interface Provider { String get(); } public static class Outer { private final String data; private final String token; private final Provider secretProvider = new Provider() { public String get() { return data; } }; public Outer() { token = secretProvider.get(); data = "FOOBAR"; } public String getToken() { return token; } } public static void main (String[] args) throws java.lang.Exception { Outer outer = new Outer(); System.out.println(outer.getToken()); // Prints null }} Note that if I used a lambda expression, instead, javac would have complained. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Mon Apr 7 22:09:20 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 07 Apr 2014 15:09:20 -0700 Subject: [BUG] Missing error? blank final may not have been initialized In-Reply-To: References: Message-ID: <53432210.80709@oracle.com> I don't believe javac has ever given an error in this case. It would be unreasonable to require 'data' to be definitely assigned before the body of the anonymous class. OTOH, names in the body of a lambda expression are specified as if they appear outside the lambda expression, where 'data' would be definitely unassigned, so an error is due there. Alex On 4/7/2014 10:02 AM, Raffaele Sgarro wrote: > ?16 states: > > For every access of a local variable or blank final field x, x must be > definitely assigned before the access, or a compile-time error occurs. > > Consider the following code: > > class Ideone{ > > public interface Provider{ String get(); } > > public static class Outer{ > > private final String data; > private final String token; > private final Provider secretProvider= new Provider() { > public String get() { > return data; > } > }; > > public Outer() { > token= secretProvider.get(); > data= "FOOBAR"; > } > > public String getToken() { > return token; > } > > } > > public static void main(String[] args) throws java.lang.Exception { > Outer outer= new Outer(); > System.out.println(outer.getToken()); // Prints null > } > } > > Note that if I used a lambda expression, instead, javac would have > complained. From raffaelesgarro at gmail.com Mon Apr 7 22:50:12 2014 From: raffaelesgarro at gmail.com (Raffaele Sgarro) Date: Tue, 8 Apr 2014 00:50:12 +0200 Subject: [BUG] Missing error? blank final may not have been initialized In-Reply-To: <53432210.80709@oracle.com> References: <53432210.80709@oracle.com> Message-ID: Hi Alex, In fact, the lambda behavior is correct to me. Why do you think it would be unreasonable for the anonymous? 2014-04-08 0:09 GMT+02:00 Alex Buckley : > I don't believe javac has ever given an error in this case. It would be > unreasonable to require 'data' to be definitely assigned before the body of > the anonymous class. OTOH, names in the body of a lambda expression are > specified as if they appear outside the lambda expression, where 'data' > would be definitely unassigned, so an error is due there. > > Alex > > > On 4/7/2014 10:02 AM, Raffaele Sgarro wrote: > >> ?16 states: >> >> For every access of a local variable or blank final field x, x must be >> definitely assigned before the access, or a compile-time error occurs. >> >> Consider the following code: >> >> class Ideone{ >> >> public interface Provider{ String get(); } >> >> public static class Outer{ >> >> private final String data; >> private final String token; >> private final Provider secretProvider= new >> Provider() { >> >> public String get() { >> return data; >> } >> }; >> >> public Outer() { >> token= secretProvider.get(); >> data= "FOOBAR"; >> >> } >> >> public String getToken() { >> return token; >> } >> >> } >> >> public static void main(String[] args) throws >> java.lang.Exception { >> Outer outer= new Outer(); >> >> System.out.println(outer.getToken()); // Prints null >> } >> } >> >> Note that if I used a lambda expression, instead, javac would have >> complained. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Apr 8 00:06:29 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 07 Apr 2014 17:06:29 -0700 Subject: [BUG] Missing error? blank final may not have been initialized In-Reply-To: References: <53432210.80709@oracle.com> Message-ID: <53433D85.70604@oracle.com> The question for compiler-dev is not whether the DU/DA analysis within anonymous classes is reasonable, but whether there's been a regression in javac. I know Paul and Jan are working on DU/DA analysis at the moment, maybe they could comment. Alex On 4/7/2014 3:50 PM, Raffaele Sgarro wrote: > Hi Alex, > > In fact, the lambda behavior is correct to me. Why do you think it would > be unreasonable for the anonymous? > > > 2014-04-08 0:09 GMT+02:00 Alex Buckley >: > > I don't believe javac has ever given an error in this case. It would > be unreasonable to require 'data' to be definitely assigned before > the body of the anonymous class. OTOH, names in the body of a lambda > expression are specified as if they appear outside the lambda > expression, where 'data' would be definitely unassigned, so an error > is due there. > > Alex > > > On 4/7/2014 10:02 AM, Raffaele Sgarro wrote: > > ?16 states: > > For every access of a local variable or blank final field x, x > must be > definitely assigned before the access, or a compile-time error > occurs. > > Consider the following code: > > class Ideone{ > > public interface Provider{ String get(); } > > public static class Outer{ > > private final String data; > private final String token; > private final Provider secretProvider= new > Provider() { > > public String get() { > return data; > } > }; > > public Outer() { > token= secretProvider.get(); > data= "FOOBAR"; > > } > > public String getToken() { > return token; > } > > } > > public static void main(String[] args) throws > java.lang.Exception { > Outer outer= new Outer(); > > System.out.println(outer.__getToken()); // > Prints null > } > } > > Note that if I used a lambda expression, instead, javac would have > complained. > > From jan.lahoda at oracle.com Tue Apr 8 16:37:19 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 08 Apr 2014 18:37:19 +0200 Subject: [BUG] Missing error? blank final may not have been initialized In-Reply-To: <53433D85.70604@oracle.com> References: <53432210.80709@oracle.com> <53433D85.70604@oracle.com> Message-ID: <534425BF.50607@oracle.com> On 04/08/2014 02:06 AM, Alex Buckley wrote: > The question for compiler-dev is not whether the DU/DA analysis within > anonymous classes is reasonable, but whether there's been a regression > in javac. I know Paul and Jan are working on DU/DA analysis at the > moment, maybe they could comment. I don't think there is a regression in javac - I was able to compile the provided code with "1.4.2_07" javac. Intuitively, considering the methods declared in the anonymous innerclass to be outside of the expression that contains the new instance expression itself seems reasonable to me. Note that if the access is moved to the initializer of the anonymous class, it is flagged as an error (which makes sense to me). Jan > > Alex > > On 4/7/2014 3:50 PM, Raffaele Sgarro wrote: >> Hi Alex, >> >> In fact, the lambda behavior is correct to me. Why do you think it would >> be unreasonable for the anonymous? >> >> >> 2014-04-08 0:09 GMT+02:00 Alex Buckley > >: >> >> I don't believe javac has ever given an error in this case. It would >> be unreasonable to require 'data' to be definitely assigned before >> the body of the anonymous class. OTOH, names in the body of a lambda >> expression are specified as if they appear outside the lambda >> expression, where 'data' would be definitely unassigned, so an error >> is due there. >> >> Alex >> >> >> On 4/7/2014 10:02 AM, Raffaele Sgarro wrote: >> >> ?16 states: >> >> For every access of a local variable or blank final field x, x >> must be >> definitely assigned before the access, or a compile-time error >> occurs. >> >> Consider the following code: >> >> class Ideone{ >> >> public interface Provider{ String get(); } >> >> public static class Outer{ >> >> private final String data; >> private final String token; >> private final Provider secretProvider= new >> Provider() { >> >> public String get() { >> return data; >> } >> }; >> >> public Outer() { >> token= secretProvider.get(); >> data= "FOOBAR"; >> >> } >> >> public String getToken() { >> return token; >> } >> >> } >> >> public static void main(String[] args) throws >> java.lang.Exception { >> Outer outer= new Outer(); >> >> System.out.println(outer.__getToken()); // >> Prints null >> } >> } >> >> Note that if I used a lambda expression, instead, javac would >> have >> complained. >> >> From cushon at google.com Tue Apr 8 16:42:07 2014 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 8 Apr 2014 09:42:07 -0700 Subject: [PATCH]: javac N with jdk (N-1) Message-ID: Hello, > I'd like to see a crisper description of what the intended behavior is running the javac from JDK (N+1) on top JDK N. I'll try to make my suggestion more precise: javac N should provide an implementation of version N-1 of JSRs 199 and 269 that works with JDK N-1. For example: the absence of SourceVersion.RELEASE_8 shouldn't prevent javac 8 from compiling java 7 code and using java 7-compatible annotation processors while running on JDK 7 . The changes I'm suggesting would also allow javac N to perform command-line batch compilations of java N while running on JDK N-1, assuming those compilations didn't involve java N annotation processors. I'm not suggesting that javac N should somehow implement version N of JSRs 199 and 269 in a way that works with JDK N-1. (I realize that isn't possible, given the way the updates are structured.) > In particular, what is the expected interaction with the SourceVersion latest and latestSupported methods. When using javac N with JDK N-1, the JDK N-1 SourceVersion would still be used, so latest and latestSupported would both return RELEASE_(N-1). That seems like the desired behaviour: RELEASE_(N-1) is the latest version that can be modeled by version N-1 of the JSR 269 API, and also the latest version that is supported on JDK N-1. On Fri, Apr 4, 2014 at 3:32 PM, Joseph Darcy wrote: > Hello, > > A few general notes here, you can look at the maintenance reviews of JSRs > 199 and 269 to get an idea of the new-in-8 API that javac might be using: > > https://jcp.org/aboutJava/communityprocess/mrel/jsr199/index.html > https://jcp.org/aboutJava/communityprocess/mrel/jsr269/index2.html > > At the start of JDK (N+1), a new SourceVersion constant for (N+1) is > added. Later in the release, changes to the language model can be expected > to accommodate any language changes in the release as well as general > improvements to the API. > > I'd like to see a crisper description of what the intended behavior is > running the javac from JDK (N+1) on top JDK N. In particular, what is the > expected interaction with the SourceVersion latest and latestSupported > methods. > > Note that in JDK 9 preparatory work has begun to implement > > JEP 182: Policy for Retiring javac -source and -target Options > http://openjdk.java.net/jeps/182 > > In other words, the javac in JDK 9 will only support -source / -target > values of 6/1.6, 7/1.8, 8/1.8, and 9/1.9. If this javac were run on top of > JDK 8, it would *not* support -source/-target 5/1.5 and earlier. > > Cheers, > > -Joe > > > On 4/4/2014 12:22 PM, Liam Miller-Cushon wrote: > > Jan, > > Thanks for trying the patch. I will update it to handle Modifier.DEFAULT > and TypeKind.INTERSECTION. I was testing primarily with java 7 source and > java 7 annotations processors, so the issue you discovered didn't come up. > > In the case of the -Xprint crash, PrintingProcessor will need to be > updated to support SourceVersion.latest() instead of using RELEASE_8 > explicitly. > > I agree that an automatic way to find these problems would be nice. > Perhaps some subset of the test coverage could be run without the > -Xbootclasspath hack, but that might get tricky in areas where javac's > behaviour will have to regress on jre n-1. > > > On Fri, Apr 4, 2014 at 8:40 AM, Jan Lahoda wrote: > >> Liam, >> >> I tried the patch, using this sample code: >> --- >> interface ID { >> public default void test() {} >> } >> --- >> >> Running (using JDK 7): >> $ java -jar javac.jar -Xprint ID.java >> leads to the attached exception1.txt. >> >> Using the attached ScanningProcessor.java, running: >> $ java -jar javac.jar -processorpath -processor ScanningProcessor >> ID.java >> >> leads to the attached exception2.txt. I suspect there may be other >> similar problems around TypeKind.INTERSECTION - I wonder if there is an >> automated way to look for problems like this? >> >> Jan >> >> >> On 04/03/2014 07:40 PM, Liam Miller-Cushon wrote: >> >>> On Wed, Mar 26, 2014 at 1:34 AM, Joel Borggr?n-Franck >>> > wrote: >>> >>> having javac run with JRE n-1 in a degraded state would be a nice >>> contribution if the patches aren't too intrusive. >>> >>> >>> It sounded like that was the general consensus, so I put together a >>> patch to allow javac 9 to run on jre 7 in a degraded state. That means: >>> >>> - warnings aren't generated for annotation processors that support >>> RELEASE_7 when the source level is 8 or 9 (because the RELEASE_8 and >>> RELEASE_9 constants aren't available) >>> >>> - the native headers feature is disabled (because >>> StandardLocations.NATIVE_HEADER_OUTPUT isn't available) >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaelesgarro at gmail.com Tue Apr 8 21:24:30 2014 From: raffaelesgarro at gmail.com (Raffaele Sgarro) Date: Tue, 8 Apr 2014 23:24:30 +0200 Subject: [BUG] Missing error? blank final may not have been initialized In-Reply-To: <534425BF.50607@oracle.com> References: <53432210.80709@oracle.com> <53433D85.70604@oracle.com> <534425BF.50607@oracle.com> Message-ID: Hi Jan, I'm sure it's not a regression, and I agree this behavior is reasonable and nobody writes code like that - just wonder if it follows the spec or if the spec needs to be updated. I saw this code on a message board where the anonymous class (compiling) was contrasted with the lambda (not compiling). Moreover, it only showed up because, after the update to JDK8, NetBeans suggested the original author to replace the anonymous with a lambda - and the suggestion turned out to be a failure, because after the "translation" the code did not compile anymore. To me the contrast with the lambda is key here, because it's feels wrong the compiler behaves in two different ways. We all know lambdas and anonymous classes are totally different beasts, but the semantic is the same wrt this situation, while the compiler is inconsistent: it screws because the blank final can be accessed before being assigned, but only if it's a lambda, not if it's an anonymous, despite the fact that both are instance fields, so can only be leaked before a ctor ends. I think arguing about the lambda machinary and other compiler internals doesn't buy anything to us in this case - I expect an explicit rule here, not reasons why javac might not be wrong in doing this and also might not be wrong in doing that even if the two are opposite behaviors 2014-04-08 18:37 GMT+02:00 Jan Lahoda : > On 04/08/2014 02:06 AM, Alex Buckley wrote: > >> The question for compiler-dev is not whether the DU/DA analysis within >> anonymous classes is reasonable, but whether there's been a regression >> in javac. I know Paul and Jan are working on DU/DA analysis at the >> moment, maybe they could comment. >> > > I don't think there is a regression in javac - I was able to compile the > provided code with "1.4.2_07" javac. Intuitively, considering the methods > declared in the anonymous innerclass to be outside of the expression that > contains the new instance expression itself seems reasonable to me. Note > that if the access is moved to the initializer of the anonymous class, it > is flagged as an error (which makes sense to me). > > Jan > > > >> Alex >> >> On 4/7/2014 3:50 PM, Raffaele Sgarro wrote: >> >>> Hi Alex, >>> >>> In fact, the lambda behavior is correct to me. Why do you think it would >>> be unreasonable for the anonymous? >>> >>> >>> 2014-04-08 0:09 GMT+02:00 Alex Buckley >> >: >>> >>> I don't believe javac has ever given an error in this case. It would >>> be unreasonable to require 'data' to be definitely assigned before >>> the body of the anonymous class. OTOH, names in the body of a lambda >>> expression are specified as if they appear outside the lambda >>> expression, where 'data' would be definitely unassigned, so an error >>> is due there. >>> >>> Alex >>> >>> >>> On 4/7/2014 10:02 AM, Raffaele Sgarro wrote: >>> >>> ?16 states: >>> >>> For every access of a local variable or blank final field x, x >>> must be >>> definitely assigned before the access, or a compile-time error >>> occurs. >>> >>> Consider the following code: >>> >>> class Ideone{ >>> >>> public interface Provider{ String get(); } >>> >>> public static class Outer{ >>> >>> private final String data; >>> private final String token; >>> private final Provider secretProvider= new >>> Provider() { >>> >>> public String get() { >>> return data; >>> } >>> }; >>> >>> public Outer() { >>> token= secretProvider.get(); >>> data= "FOOBAR"; >>> >>> } >>> >>> public String getToken() { >>> return token; >>> } >>> >>> } >>> >>> public static void main(String[] args) throws >>> java.lang.Exception { >>> Outer outer= new Outer(); >>> >>> System.out.println(outer.__getToken()); // >>> Prints null >>> } >>> } >>> >>> Note that if I used a lambda expression, instead, javac would >>> have >>> complained. >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Apr 9 12:13:35 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 09 Apr 2014 14:13:35 +0200 Subject: [BUG] Missing error? blank final may not have been initialized In-Reply-To: References: <53432210.80709@oracle.com> <53433D85.70604@oracle.com> <534425BF.50607@oracle.com> Message-ID: <5345396F.3040401@oracle.com> On 04/08/2014 11:24 PM, Raffaele Sgarro wrote: > Hi Jan, > > I'm sure it's not a regression, and I agree this behavior is reasonable > and nobody writes code like that - just wonder if it follows the spec or > if the spec needs to be updated. > > I saw this code on a message board where the anonymous class (compiling) > was contrasted with the lambda (not compiling). Moreover, it only showed > up because, after the update to JDK8, NetBeans suggested the original > author to replace the anonymous with a lambda - and the suggestion > turned out to be a failure, because after the "translation" the code did > not compile anymore. I've opened a bug for NetBeans: https://netbeans.org/bugzilla/show_bug.cgi?id=243695 (Thanks for the report.) > > To me the contrast with the lambda is key here, because it's feels wrong > the compiler behaves in two different ways. We all know lambdas and > anonymous classes are totally different beasts, but the semantic is the > same wrt this situation, while the compiler is inconsistent: it screws > because the blank final can be accessed before being assigned, but only > if it's a lambda, not if it's an anonymous, despite the fact that both > are instance fields, so can only be leaked before a ctor ends. I think > arguing about the lambda machinary and other compiler internals doesn't > buy anything to us in this case - I expect an explicit rule here, not > reasons why javac might not be wrong in doing this and also might not be > wrong in doing that even if the two are opposite behaviors JLS 16.2.2 says: A blank final member field V is definitely assigned (and moreover is not definitely unassigned) before the block (?14.2) that is the body of any method in the scope of V and before the declaration of any class declared within the scope of V. So not generating the compile-time error for the access inside the anonymous innerclass' methods seems appropriate to me. Jan > > > 2014-04-08 18:37 GMT+02:00 Jan Lahoda >: > > On 04/08/2014 02:06 AM, Alex Buckley wrote: > > The question for compiler-dev is not whether the DU/DA analysis > within > anonymous classes is reasonable, but whether there's been a > regression > in javac. I know Paul and Jan are working on DU/DA analysis at the > moment, maybe they could comment. > > > I don't think there is a regression in javac - I was able to compile > the provided code with "1.4.2_07" javac. Intuitively, considering > the methods declared in the anonymous innerclass to be outside of > the expression that contains the new instance expression itself > seems reasonable to me. Note that if the access is moved to the > initializer of the anonymous class, it is flagged as an error (which > makes sense to me). > > Jan > > > > Alex > > On 4/7/2014 3:50 PM, Raffaele Sgarro wrote: > > Hi Alex, > > In fact, the lambda behavior is correct to me. Why do you > think it would > be unreasonable for the anonymous? > > > 2014-04-08 0:09 GMT+02:00 Alex Buckley > > >>: > > I don't believe javac has ever given an error in this > case. It would > be unreasonable to require 'data' to be definitely > assigned before > the body of the anonymous class. OTOH, names in the > body of a lambda > expression are specified as if they appear outside the > lambda > expression, where 'data' would be definitely > unassigned, so an error > is due there. > > Alex > > > On 4/7/2014 10:02 AM, Raffaele Sgarro wrote: > > ?16 states: > > For every access of a local variable or blank final > field x, x > must be > definitely assigned before the access, or a > compile-time error > occurs. > > Consider the following code: > > class Ideone{ > > public interface Provider{ String > get(); } > > public static class Outer{ > > private final String data; > private final String token; > private final Provider > secretProvider= new > Provider() { > > public String get() { > return data; > } > }; > > public Outer() { > token= secretProvider.get(); > data= "FOOBAR"; > > } > > public String getToken() { > return token; > } > > } > > public static void main(String[] args) > throws > java.lang.Exception { > Outer outer= new Outer(); > > > System.out.println(outer.____getToken()); // > Prints null > } > } > > Note that if I used a lambda expression, instead, > javac would > have > complained. > > > From martinrb at google.com Fri Apr 11 19:57:13 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Apr 2014 12:57:13 -0700 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> Message-ID: It's surprising that javac does not eliminate the redundant initializations to null. Initializing to null has documentation value (suggesting that the constructor will not assign a value; null is a "valid" value). How about fixing javac instead? On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou wrote: > Hello all; > > This is a simple cleanup changeset that removes redundant initialization > of fields to null from a number of collection classes. These field > initializations may seem cheap but they do have a cost: > > - For volatile fields there is a measurable cost on some benchmarks for > these extra initializations. > > - Larger byte code in methods. > > - For transient fields the initialization is misleading since it does not > occur on deserialization. > > https://bugs.openjdk.java.net/browse/JDK-8035284 > http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ > > Redundant null initializations in other components/packages will be > handled in separate issues. > > Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.duigou at oracle.com Fri Apr 11 20:04:15 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 Apr 2014 13:04:15 -0700 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> Message-ID: <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> Apparently javac did at elide the "extraneous" null initialization at one point and it was deemed to have been contrary to point #4 of the procedure in JLS 12.5 (http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D) Mike On Apr 11 2014, at 12:57 , Martin Buchholz wrote: > It's surprising that javac does not eliminate the redundant initializations to null. Initializing to null has documentation value (suggesting that the constructor will not assign a value; null is a "valid" value). How about fixing javac instead? > > > On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou wrote: > Hello all; > > This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: > > - For volatile fields there is a measurable cost on some benchmarks for these extra initializations. > > - Larger byte code in methods. > > - For transient fields the initialization is misleading since it does not occur on deserialization. > > https://bugs.openjdk.java.net/browse/JDK-8035284 > http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ > > Redundant null initializations in other components/packages will be handled in separate issues. > > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Fri Apr 11 20:09:31 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Apr 2014 21:09:31 +0100 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> Message-ID: <416789C9-F133-4198-BE77-DD5ABC67DE9D@oracle.com> > On 11 Apr 2014, at 21:04, Mike Duigou wrote: > > Apparently javac did at elide the "extraneous" null initialization at one point and it was deemed to have been contrary to point #4 of the procedure in JLS 12.5 (http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D) I remember talking to Maurizio about this a few years ago. I think he mentioned something similar. -Chris. > > Mike > > >> On Apr 11 2014, at 12:57 , Martin Buchholz wrote: >> >> It's surprising that javac does not eliminate the redundant initializations to null. Initializing to null has documentation value (suggesting that the constructor will not assign a value; null is a "valid" value). How about fixing javac instead? >> >> >> On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou wrote: >> Hello all; >> >> This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: >> >> - For volatile fields there is a measurable cost on some benchmarks for these extra initializations. >> >> - Larger byte code in methods. >> >> - For transient fields the initialization is misleading since it does not occur on deserialization. >> >> https://bugs.openjdk.java.net/browse/JDK-8035284 >> http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ >> >> Redundant null initializations in other components/packages will be handled in separate issues. >> >> Mike > From mike.duigou at oracle.com Fri Apr 11 20:11:19 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 Apr 2014 13:11:19 -0700 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <416789C9-F133-4198-BE77-DD5ABC67DE9D@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> <416789C9-F133-4198-BE77-DD5ABC67DE9D@oracle.com> Message-ID: <194BB8B0-5020-4704-9D59-C20832C25603@oracle.com> I and others have tried to track down the compiler issue in which this change was made. If anyone can point us in the right direction it would be nice to reference that issue. Mike On Apr 11 2014, at 13:09 , Chris Hegarty wrote: > >> On 11 Apr 2014, at 21:04, Mike Duigou wrote: >> >> Apparently javac did at elide the "extraneous" null initialization at one point and it was deemed to have been contrary to point #4 of the procedure in JLS 12.5 (http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D) > > I remember talking to Maurizio about this a few years ago. I think he mentioned something similar. > > -Chris. > >> >> Mike >> >> >>> On Apr 11 2014, at 12:57 , Martin Buchholz wrote: >>> >>> It's surprising that javac does not eliminate the redundant initializations to null. Initializing to null has documentation value (suggesting that the constructor will not assign a value; null is a "valid" value). How about fixing javac instead? >>> >>> >>> On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou wrote: >>> Hello all; >>> >>> This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: >>> >>> - For volatile fields there is a measurable cost on some benchmarks for these extra initializations. >>> >>> - Larger byte code in methods. >>> >>> - For transient fields the initialization is misleading since it does not occur on deserialization. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8035284 >>> http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ >>> >>> Redundant null initializations in other components/packages will be handled in separate issues. >>> >>> Mike >> From martinrb at google.com Fri Apr 11 20:38:43 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Apr 2014 13:38:43 -0700 Subject: RFR: 8035284: (xs) Remove redundant null initialization In-Reply-To: <194BB8B0-5020-4704-9D59-C20832C25603@oracle.com> References: <19EAF2D4-E628-42DA-BC77-657D526B5488@oracle.com> <7376D6A7-0475-4BEB-A427-EB71BA4F7DF3@oracle.com> <416789C9-F133-4198-BE77-DD5ABC67DE9D@oracle.com> <194BB8B0-5020-4704-9D59-C20832C25603@oracle.com> Message-ID: I see now that the semantics of private Foo foo = null; and private Foo foo; are different, because in the first case foo may have been set to non-null by other code textually "left" to the initialization to null. Conceptually a variable explicitly initialized to null is initialized twice - first the initialization to null promised by the JVM, and then the explicit initialization to null. The compiler may be able to elide the assignment, but only by doing an analysis of all possible executions. And for volatile fields, it is reasonable (if you squint) to expect that a true volatile store is performed even if the VM can prove that "this" does not escape the constructor. Change approved! Still, it makes me sad. We will also cleanse jsr166 sources of these redundant initializations. On Fri, Apr 11, 2014 at 1:11 PM, Mike Duigou wrote: > I and others have tried to track down the compiler issue in which this > change was made. If anyone can point us in the right direction it would be > nice to reference that issue. > > Mike > > On Apr 11 2014, at 13:09 , Chris Hegarty wrote: > > > > >> On 11 Apr 2014, at 21:04, Mike Duigou wrote: > >> > >> Apparently javac did at elide the "extraneous" null initialization at > one point and it was deemed to have been contrary to point #4 of the > procedure in JLS 12.5 ( > http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D > ) > > > > I remember talking to Maurizio about this a few years ago. I think he > mentioned something similar. > > > > -Chris. > > > >> > >> Mike > >> > >> > >>> On Apr 11 2014, at 12:57 , Martin Buchholz > wrote: > >>> > >>> It's surprising that javac does not eliminate the redundant > initializations to null. Initializing to null has documentation value > (suggesting that the constructor will not assign a value; null is a "valid" > value). How about fixing javac instead? > >>> > >>> > >>> On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou > wrote: > >>> Hello all; > >>> > >>> This is a simple cleanup changeset that removes redundant > initialization of fields to null from a number of collection classes. These > field initializations may seem cheap but they do have a cost: > >>> > >>> - For volatile fields there is a measurable cost on some benchmarks > for these extra initializations. > >>> > >>> - Larger byte code in methods. > >>> > >>> - For transient fields the initialization is misleading since it does > not occur on deserialization. > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8035284 > >>> http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ > >>> > >>> Redundant null initializations in other components/packages will be > handled in separate issues. > >>> > >>> Mike > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oehrstroem at gmail.com Wed Apr 16 09:18:17 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 16 Apr 2014 11:18:17 +0200 Subject: RFR: 8037085: add support to sjavac to exclude/include directory names instead of only package names. Message-ID: The previous RFR tried to solve both this simple problem and the larger rewrite of the options but seems to be stalled due to problems with the Windows build. Since it is very inconvenient to have a broken sjavac in jdk9/jdk9, perhaps someone within Oracle could take this simple patch (almost identical to Andrea's original patch) through a jprt spin, and if it works, apply it? Then sjavac starts working again, and we can continue to work on sjavac in our normal build env. http://cr.openjdk.java.net/~ohrstrom/webrevs-8037085/ //Fredrik 2014-03-19 9:49 GMT+01:00 Andreas Lundblad : > Hi compiler-dev + build-dev, > > Please review the fix for JDK-8035063 and JDK-8037085 which involves > changes to sjavac (option handling) and dev/ + dev/jdk build files. > > > Description: > > - Sjavac relied on passing around the main arg array to whatever part of > the code that were potentially affected by command line options. The patch > restructures the code so that all option are validated and parsed up front. > > - A recent commit in the JDK repository exposed another sjavac bug caused > by having directory names that were not valid package identifiers. The > patch changes sjavac to handle directories instead of packages... > > - ...which required modifying a couple of .gmk so that arguments are > passed as directories (separated by "/") instead of packages (separated > with ".") > > - Finally the patch adds a couple of unit tests which cover the new code. > > > Link to webrevs: > http://cr.openjdk.java.net/~alundblad/8035063/ > - dev build (dev/make/common/JavaCompilation.gmk) > - jdk build (dev/jdk/make/CompileJavaClasses.gmk) > - langtools (the sjavac changes + tests) > > > Links to bug reports: > https://bugs.openjdk.java.net/browse/JDK-8035063 > https://bugs.openjdk.java.net/browse/JDK-8037085 > > -- Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed Apr 16 18:59:06 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Apr 2014 11:59:06 -0700 Subject: JEP 118 works with Lambda ? In-Reply-To: References: Message-ID: <534ED2FA.7040206@oracle.com> // Adding compiler-dev Since lambda expressions are expressions, they cannot be reflected over directly. However, if you know the method that a lambda expression is compiled to, then you can obviously call getParameters() on the java.lang.reflect.Method object. That said, even if you compiled with -parameters, there are bugs in the name generation for parameters of the method, so Parameter.getName() doesn't work. This has been discussed on compiler-dev and is being fixed for JDK 8u20. Alex On 4/16/2014 11:43 AM, Luan Cestari wrote: > Hi, Good morning/afternoon/evening! =) > > I got this email from a reply of help at openjdk.java.net ( from > https://bugs.openjdk.java.net/secure/Dashboard.jspa , where I was thinking > to create an issue (maybe for enhance or bug, not really sure). > > I got a problem during a test using the getName from Parameter (from JEP > 118, new in Java 8) with Lambda expression (also new in Java 8). I made a > simple class to reproduce the issue which I posted here > https://gist.github.com/luan-cestari/10902418 , where the getName works > fine using other classes like in this other code I made > https://gist.github.com/luan-cestari/10902332. I started to investigate > that after I saw a gist ( https://gist.github.com/galdosd/10823529, which > also created a discussion on > http://www.reddit.com/r/java/comments/2360is/pretty_map_literals_for_java_8/) > saying that feature worked fine for him, so I talked with some guys in > IRC ( OFTC#openjdk ), but we wasn't sure if it is a bug or not. > > I searched a bit and I found the following: > > - In http://openjdk.java.net/jeps/118 , it doesnt say about any > exception around the Lambda functions > - In Oracle documentation it mentions the JVM parameter that have to be > used during the compilation to that work fine > http://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html > - In javadoc there is no more details about that (I think it could make > more clear that there is a JVM parameter or maybe it is possible to have > this kind of parameter. Also it could say about execptions such as Lambda > expressions) > http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Parameter.html#getName-- > - I also saw a mail list ( > http://mail.openjdk.java.net/pipermail/lambda-dev/2013-January/007548.html) > where Remi and Brian exchanged some mails where he said it is had the > JEP > 118 due there are people that want thing in a way and people who doesn't > want some changes > - In that mail, they cited this document > http://cr.openjdk.java.net/~abuckley/8misc.pdf which I think that some > parts of it are in JVM spec ( > - http://docs.oracle.com/javase/specs/ like > http://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf and > http://docs.oracle.com/javase/specs/jls/se8/jls8.pdf > - ) but it just say the class structure in bytecode, nothing about > Lambda and JEP 118 > > As far as I know, Lambda will create some symbolic invocation using > invokedynamic which is different than creating anonymous classes, so this > might be the root cause of the issue. But maybe there is some difference in > the native implementations (for example, in my case I'm using Fedora 20 > with OpenJDK Runtime Environment (build 1.8.0-b132) / OpenJDK 64-Bit Server > VM (build 25.0-b70, mixed mode)). In the IRC, people said that maybe the > IDE was generating the inner classes to make it work, but that would make a > problem during the runtime if a different tool (like maven) compiles the > project. > > In summary, is the right behavior for JEP 118 return argx due lambda > expressions? Maybe we could enhance it to make some new features (for Java > 9 ). > > Thank you in advance, > > Kindest regards, > > Luan Cestari > > "All the gold which is under or upon the earth is not enough to give in > exchange for virtue." > Plato > "At his best, man is the noblest of all animals; separated from law and > justice he is the worst." > "A true friend is one soul in two bodies." > Aristotle > "The only limit to your impact is your imagination and commitment." > Tony Robbins > From brian.goetz at oracle.com Wed Apr 16 19:54:50 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 16 Apr 2014 15:54:50 -0400 Subject: JEP 118 works with Lambda ? In-Reply-To: <534ED2FA.7040206@oracle.com> References: <534ED2FA.7040206@oracle.com> Message-ID: <534EE00A.1060502@oracle.com> The short answer is: the code being referred to (that synthesizes "map literals") has no claim to ever work. (And in fact, it does not work on the reference implementation, but I've heard tell it does "work" when compiled with ECJ.) And that it does not work is not a bug. Lambda expressions are expressions, not methods. There is no reflection on expressions. A lambda expression evaluates to an instance of a class implementing its target type. There is (by design) no guarantee what the name of that class is, whether that class is shared with that of other lambda expressions, or what the parameter names of its methods are. A compiler implementation may or may not choose to desugar lambda expressions to methods. If it does, it may or may not preserve the parameter names as they appear in source code. And if it does, this may freely change from day to day. To claim there is no "exception" for lambdas has it backwards; lambdas are not methods, and there is no way to reflect over them. On 4/16/2014 2:59 PM, Alex Buckley wrote: > // Adding compiler-dev > > Since lambda expressions are expressions, they cannot be reflected over > directly. However, if you know the method that a lambda expression is > compiled to, then you can obviously call getParameters() on the > java.lang.reflect.Method object. > > That said, even if you compiled with -parameters, there are bugs in the > name generation for parameters of the method, so Parameter.getName() > doesn't work. This has been discussed on compiler-dev and is being fixed > for JDK 8u20. > > Alex > > On 4/16/2014 11:43 AM, Luan Cestari wrote: >> Hi, Good morning/afternoon/evening! =) >> >> I got this email from a reply of help at openjdk.java.net ( from >> https://bugs.openjdk.java.net/secure/Dashboard.jspa , where I was >> thinking >> to create an issue (maybe for enhance or bug, not really sure). >> >> I got a problem during a test using the getName from Parameter (from JEP >> 118, new in Java 8) with Lambda expression (also new in Java 8). I made a >> simple class to reproduce the issue which I posted here >> https://gist.github.com/luan-cestari/10902418 , where the getName works >> fine using other classes like in this other code I made >> https://gist.github.com/luan-cestari/10902332. I started to investigate >> that after I saw a gist ( https://gist.github.com/galdosd/10823529, which >> also created a discussion on >> http://www.reddit.com/r/java/comments/2360is/pretty_map_literals_for_java_8/) >> >> saying that feature worked fine for him, so I talked with some guys in >> IRC ( OFTC#openjdk ), but we wasn't sure if it is a bug or not. >> >> I searched a bit and I found the following: >> >> - In http://openjdk.java.net/jeps/118 , it doesnt say about any >> exception around the Lambda functions >> - In Oracle documentation it mentions the JVM parameter that have >> to be >> used during the compilation to that work fine >> >> http://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html >> >> - In javadoc there is no more details about that (I think it could >> make >> more clear that there is a JVM parameter or maybe it is possible >> to have >> this kind of parameter. Also it could say about execptions such as >> Lambda >> expressions) >> >> http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Parameter.html#getName-- >> >> - I also saw a mail list ( >> >> http://mail.openjdk.java.net/pipermail/lambda-dev/2013-January/007548.html) >> >> where Remi and Brian exchanged some mails where he said it is had the >> JEP >> 118 due there are people that want thing in a way and people who >> doesn't >> want some changes >> - In that mail, they cited this document >> http://cr.openjdk.java.net/~abuckley/8misc.pdf which I think that >> some >> parts of it are in JVM spec ( >> - http://docs.oracle.com/javase/specs/ like >> http://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf and >> http://docs.oracle.com/javase/specs/jls/se8/jls8.pdf >> - ) but it just say the class structure in bytecode, nothing about >> Lambda and JEP 118 >> >> As far as I know, Lambda will create some symbolic invocation using >> invokedynamic which is different than creating anonymous classes, so this >> might be the root cause of the issue. But maybe there is some >> difference in >> the native implementations (for example, in my case I'm using Fedora 20 >> with OpenJDK Runtime Environment (build 1.8.0-b132) / OpenJDK 64-Bit >> Server >> VM (build 25.0-b70, mixed mode)). In the IRC, people said that maybe the >> IDE was generating the inner classes to make it work, but that would >> make a >> problem during the runtime if a different tool (like maven) compiles the >> project. >> >> In summary, is the right behavior for JEP 118 return argx due lambda >> expressions? Maybe we could enhance it to make some new features (for >> Java >> 9 ). >> >> Thank you in advance, >> >> Kindest regards, >> >> Luan Cestari >> >> "All the gold which is under or upon the earth is not enough to give in >> exchange for virtue." >> Plato >> "At his best, man is the noblest of all animals; separated from law and >> justice he is the worst." >> "A true friend is one soul in two bodies." >> Aristotle >> "The only limit to your impact is your imagination and commitment." >> Tony Robbins >> From forax at univ-mlv.fr Thu Apr 17 08:00:14 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 17 Apr 2014 10:00:14 +0200 Subject: JEP 118 works with Lambda ? In-Reply-To: <534EE00A.1060502@oracle.com> References: <534ED2FA.7040206@oracle.com> <534EE00A.1060502@oracle.com> Message-ID: <534F8A0E.5010706@univ-mlv.fr> On 04/16/2014 09:54 PM, Brian Goetz wrote: > The short answer is: the code being referred to (that synthesizes "map > literals") has no claim to ever work. (And in fact, it does not work > on the reference implementation, but I've heard tell it does "work" > when compiled with ECJ.) And that it does not work is not a bug. > > Lambda expressions are expressions, not methods. There is no > reflection on expressions. A lambda expression evaluates to an > instance of a class implementing its target type. There is (by > design) no guarantee what the name of that class is, whether that > class is shared with that of other lambda expressions, or what the > parameter names of its methods are. > > A compiler implementation may or may not choose to desugar lambda > expressions to methods. If it does, it may or may not preserve the > parameter names as they appear in source code. And if it does, this > may freely change from day to day. > > To claim there is no "exception" for lambdas has it backwards; lambdas > are not methods, and there is no way to reflect over them. While I fully agree about the fact that the parameter names are not available for lambda, there is a special kind of lambda that is required by the spec to be desugared to method by the compiler. serializable lambda, a serializable lambda keep meta-data useful to re-create itself and the format of the serialization is fully specified by the spec [1]. Because the documentation of SerializedLambda explicitly refers to an implementation method, a serializable lambda must have an underlying method. R?mi [1] http://docs.oracle.com/javase/8/docs/api/java/lang/invoke/SerializedLambda.html > > > > On 4/16/2014 2:59 PM, Alex Buckley wrote: >> // Adding compiler-dev >> >> Since lambda expressions are expressions, they cannot be reflected over >> directly. However, if you know the method that a lambda expression is >> compiled to, then you can obviously call getParameters() on the >> java.lang.reflect.Method object. >> >> That said, even if you compiled with -parameters, there are bugs in the >> name generation for parameters of the method, so Parameter.getName() >> doesn't work. This has been discussed on compiler-dev and is being fixed >> for JDK 8u20. >> >> Alex >> >> On 4/16/2014 11:43 AM, Luan Cestari wrote: >>> Hi, Good morning/afternoon/evening! =) >>> >>> I got this email from a reply of help at openjdk.java.net ( from >>> https://bugs.openjdk.java.net/secure/Dashboard.jspa , where I was >>> thinking >>> to create an issue (maybe for enhance or bug, not really sure). >>> >>> I got a problem during a test using the getName from Parameter (from >>> JEP >>> 118, new in Java 8) with Lambda expression (also new in Java 8). I >>> made a >>> simple class to reproduce the issue which I posted here >>> https://gist.github.com/luan-cestari/10902418 , where the getName works >>> fine using other classes like in this other code I made >>> https://gist.github.com/luan-cestari/10902332. I started to investigate >>> that after I saw a gist ( https://gist.github.com/galdosd/10823529, >>> which >>> also created a discussion on >>> http://www.reddit.com/r/java/comments/2360is/pretty_map_literals_for_java_8/) >>> >>> >>> saying that feature worked fine for him, so I talked with some guys in >>> IRC ( OFTC#openjdk ), but we wasn't sure if it is a bug or not. >>> >>> I searched a bit and I found the following: >>> >>> - In http://openjdk.java.net/jeps/118 , it doesnt say about any >>> exception around the Lambda functions >>> - In Oracle documentation it mentions the JVM parameter that have >>> to be >>> used during the compilation to that work fine >>> >>> http://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html >>> >>> >>> - In javadoc there is no more details about that (I think it could >>> make >>> more clear that there is a JVM parameter or maybe it is possible >>> to have >>> this kind of parameter. Also it could say about execptions such as >>> Lambda >>> expressions) >>> >>> http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Parameter.html#getName-- >>> >>> >>> - I also saw a mail list ( >>> >>> http://mail.openjdk.java.net/pipermail/lambda-dev/2013-January/007548.html) >>> >>> >>> where Remi and Brian exchanged some mails where he said it is had the >>> JEP >>> 118 due there are people that want thing in a way and people who >>> doesn't >>> want some changes >>> - In that mail, they cited this document >>> http://cr.openjdk.java.net/~abuckley/8misc.pdf which I think that >>> some >>> parts of it are in JVM spec ( >>> - http://docs.oracle.com/javase/specs/ like >>> http://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf and >>> http://docs.oracle.com/javase/specs/jls/se8/jls8.pdf >>> - ) but it just say the class structure in bytecode, nothing about >>> Lambda and JEP 118 >>> >>> As far as I know, Lambda will create some symbolic invocation using >>> invokedynamic which is different than creating anonymous classes, so >>> this >>> might be the root cause of the issue. But maybe there is some >>> difference in >>> the native implementations (for example, in my case I'm using Fedora 20 >>> with OpenJDK Runtime Environment (build 1.8.0-b132) / OpenJDK 64-Bit >>> Server >>> VM (build 25.0-b70, mixed mode)). In the IRC, people said that maybe >>> the >>> IDE was generating the inner classes to make it work, but that would >>> make a >>> problem during the runtime if a different tool (like maven) compiles >>> the >>> project. >>> >>> In summary, is the right behavior for JEP 118 return argx due lambda >>> expressions? Maybe we could enhance it to make some new features (for >>> Java >>> 9 ). >>> >>> Thank you in advance, >>> >>> Kindest regards, >>> >>> Luan Cestari >>> >>> "All the gold which is under or upon the earth is not enough to give in >>> exchange for virtue." >>> Plato >>> "At his best, man is the noblest of all animals; separated from law and >>> justice he is the worst." >>> "A true friend is one soul in two bodies." >>> Aristotle >>> "The only limit to your impact is your imagination and commitment." >>> Tony Robbins >>> From weijun.wang at oracle.com Tue Apr 22 01:18:45 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 22 Apr 2014 09:18:45 +0800 Subject: try-with-resources on arbitrary multiple files? Message-ID: If I copy a file to another I can try (src = open(ifile); dest = open(ofile)) { while (!src.EOF) dest.write(src.read()); } but what if there are multiple destinations? Is there something like try (src = open(ifile); manager = new CloseableManager()) { for (ofile: ofiles) { manager.register(open(ofile)); } while (!src.EOF) { buffer = src.read(); for (dest: manager) dest.write(buffer); } } Thanks Max From paul.sandoz at oracle.com Tue Apr 22 08:47:23 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Apr 2014 10:47:23 +0200 Subject: try-with-resources on arbitrary multiple files? In-Reply-To: References: Message-ID: On Apr 22, 2014, at 3:18 AM, Wang Weijun wrote: > If I copy a file to another I can > > try (src = open(ifile); dest = open(ofile)) { > while (!src.EOF) dest.write(src.read()); > } > > but what if there are multiple destinations? Is there something like > Not that i am aware of. A fun little trick you can do is the following: File ifile = null; List dests = new ArrayList<>(); try (InputStream src = open(ifile); AutoCloseable ac = () -> closeAll(dests)) { dests.add(...); .... } static void closeAll(Collection l) throws IOException { ... } But still that does not avoid the main work of closing stuff. Paul. > try (src = open(ifile); manager = new CloseableManager()) { > for (ofile: ofiles) { > manager.register(open(ofile)); > } > while (!src.EOF) { > buffer = src.read(); > for (dest: manager) dest.write(buffer); > } > } > > Thanks > Max > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From david.lloyd at redhat.com Tue Apr 22 13:35:53 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 22 Apr 2014 08:35:53 -0500 Subject: Possible javac bug around final and covariant overrides Message-ID: <53567039.2090103@redhat.com> 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? -- - DML From stuart.marks at oracle.com Tue Apr 22 20:24:20 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 22 Apr 2014 13:24:20 -0700 Subject: adding default method changes interface initialization order? Message-ID: <5356CFF4.8040404@oracle.com> Hi all, It seems like the presence of a default method in an interface will change the timing of when that interface is initialized. Interface initialization is covered by JLS 12.4.1 [1]. Example 12.4.1-3 illustrates this: interface I { int i = 1, ii = Test.out("ii", 2); } interface J extends I { int j = Test.out("j", 3), jj = Test.out("jj", 4); } interface K extends J { int k = Test.out("k", 5); } class Test { public static void main(String[] args) { System.out.println(J.i); System.out.println(K.j); } static int out(String s, int i) { System.out.println(s + "=" + i); return i; } } The expected output is: 1 j=3 jj=4 3 Indeed, I get the expected output for the example as it stands. However, if a default method is added to interface I, the behavior of the program changes. Consider: interface I { int i = 1, ii = Test.out("ii", 2); default void method() { } // causes initialization! } The output changes to: 1 ii=2 j=3 jj=4 3 That is, the "ii=2" line indicates that interface I has now been initialized where it hadn't been before. The mere presence of a default method seems to trigger the change, even if the default method is never called, referenced, or overridden. Is this a bug? (Hat tip to Sotirios Delimanolis for asking this on StackOverflow. [2]) s'marks [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4.1 [2] http://stackoverflow.com/questions/23096084/when-is-an-interface-with-a-default-method-initialized s'marks From alex.buckley at oracle.com Tue Apr 22 21:23:55 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Apr 2014 14:23:55 -0700 Subject: adding default method changes interface initialization order? In-Reply-To: <5356CFF4.8040404@oracle.com> References: <5356CFF4.8040404@oracle.com> Message-ID: <5356DDEB.50300@oracle.com> // Adding lambda-dev; follow-ups to both lists please. Default methods are not specified to cause any change in interface initialization. In principle the body of a default method can execute without the declaring interface having been initialized; if the body should touch a static field of the interface, then the interface must immediately be initialized. However, that behavior might be a surprise. So surprising, in fact, that HotSpot seems to be cautiously initializing superinterfaces in advance of the default method ever being invoked. JSR 335 people should comment on this. Are all superinterfaces initialized, or just those with default methods? In addition, if the default method body invokes a static method of the interface, then initialization must occur - yet JLS8 12.4.1 does not require it ("T is a class and a static method declared by T is invoked.") That's a straight spec bug - but note that specifying superinterface initialization due to default methods will make it moot. Alex On 4/22/2014 1:24 PM, Stuart Marks wrote: > Hi all, > > It seems like the presence of a default method in an interface will > change the timing of when that interface is initialized. > > Interface initialization is covered by JLS 12.4.1 [1]. Example 12.4.1-3 > illustrates this: > > interface I { > int i = 1, ii = Test.out("ii", 2); > } > interface J extends I { > int j = Test.out("j", 3), jj = Test.out("jj", 4); > } > interface K extends J { > int k = Test.out("k", 5); > } > class Test { > public static void main(String[] args) { > System.out.println(J.i); > System.out.println(K.j); > } > static int out(String s, int i) { > System.out.println(s + "=" + i); > return i; > } > } > > The expected output is: > > 1 > j=3 > jj=4 > 3 > > Indeed, I get the expected output for the example as it stands. However, > if a default method is added to interface I, the behavior of the program > changes. Consider: > > interface I { > int i = 1, ii = Test.out("ii", 2); > default void method() { } // causes initialization! > } > > The output changes to: > > 1 > ii=2 > j=3 > jj=4 > 3 > > That is, the "ii=2" line indicates that interface I has now been > initialized where it hadn't been before. The mere presence of a default > method seems to trigger the change, even if the default method is never > called, referenced, or overridden. > > Is this a bug? > > (Hat tip to Sotirios Delimanolis for asking this on StackOverflow. [2]) > > s'marks > > > [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4.1 > > [2] > http://stackoverflow.com/questions/23096084/when-is-an-interface-with-a-default-method-initialized > > > > s'marks From victorwssilva at gmail.com Wed Apr 23 03:57:49 2014 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Wed, 23 Apr 2014 00:57:49 -0300 Subject: Type inference of non-existent method references crashes the compiler Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Wed Apr 23 08:36:16 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 23 Apr 2014 10:36:16 +0200 Subject: adding default method changes interface initialization order? In-Reply-To: <5356DDEB.50300@oracle.com> References: <5356CFF4.8040404@oracle.com> <5356DDEB.50300@oracle.com> Message-ID: <86E81817-837A-402D-86DC-8DAF6DDAE04F@oracle.com> On Apr 22, 2014, at 11:23 PM, Alex Buckley wrote: > // Adding lambda-dev; follow-ups to both lists please. > > Default methods are not specified to cause any change in interface initialization. In principle the body of a default method can execute without the declaring interface having been initialized; if the body should touch a static field of the interface, then the interface must immediately be initialized. > > However, that behavior might be a surprise. So surprising, in fact, that HotSpot seems to be cautiously initializing superinterfaces in advance of the default method ever being invoked. JSR 335 people should comment on this. Are all superinterfaces initialized, or just those with default methods? > It appears to be all interfaces in the path traversed in the interface hierarchy up to and including the last superinterface declaring a default method. See example below that has a diamond pattern. The output is: #: initializing Test2$J #: initializing Test2$JN #: initializing Test2$L 4 Comment out the default method on J and uncomment that on K and interfaces in the other path are initialized: #: initializing Test2$K #: initializing Test2$KN #: initializing Test2$L 4 If a default method is only declared on I then all interfaces get initialized. #: initializing Test2$I #: initializing Test2$J #: initializing Test2$JN #: initializing Test2$K #: initializing Test2$KN #: initializing Test2$L 4 Paul. > In addition, if the default method body invokes a static method of the interface, then initialization must occur - yet JLS8 12.4.1 does not require it ("T is a class and a static method declared by T is invoked.") That's a straight spec bug - but note that specifying superinterface initialization due to default methods will make it moot. > > Alex > public class Test2 { interface I { int v = Test2.out(I.class, 1); // default void x() {} } interface J extends I { int v = Test2.out(J.class, 2); default void x() {} } interface JN extends J { int v = Test2.out(JN.class, 2); } interface K extends I { int v = Test2.out(K.class, 3); // default void x() {} } interface KN extends K { int v = Test2.out(KN.class, 3); } interface L extends JN, KN { int v = Test2.out(L.class, 4); // default void x() {} } public static void main(String[] args) { System.out.println(L.v); } static int out(Class c, int i) { System.out.println("#: initializing " + c.getName()); return i; } } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.buckley at oracle.com Wed Apr 23 18:47:38 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 23 Apr 2014 11:47:38 -0700 Subject: adding default method changes interface initialization order? In-Reply-To: <86E81817-837A-402D-86DC-8DAF6DDAE04F@oracle.com> References: <5356CFF4.8040404@oracle.com> <5356DDEB.50300@oracle.com> <86E81817-837A-402D-86DC-8DAF6DDAE04F@oracle.com> Message-ID: <53580ACA.6030208@oracle.com> Paul, thanks. Nice little elongated diamond you have there! Dan, Karen, looks like a significant under-specification and/or over-implementation here. Thoughts? Leonid, something to be aware of in the JCK coverage of default methods. Alex On 4/23/2014 1:36 AM, Paul Sandoz wrote: > > On Apr 22, 2014, at 11:23 PM, Alex Buckley wrote: > >> // Adding lambda-dev; follow-ups to both lists please. >> >> Default methods are not specified to cause any change in interface initialization. In principle the body of a default method can execute without the declaring interface having been initialized; if the body should touch a static field of the interface, then the interface must immediately be initialized. >> >> However, that behavior might be a surprise. So surprising, in fact, that HotSpot seems to be cautiously initializing superinterfaces in advance of the default method ever being invoked. JSR 335 people should comment on this. Are all superinterfaces initialized, or just those with default methods? >> > > It appears to be all interfaces in the path traversed in the interface hierarchy up to and including the last superinterface declaring a default method. See example below that has a diamond pattern. The output is: > > #: initializing Test2$J > #: initializing Test2$JN > #: initializing Test2$L > 4 > > Comment out the default method on J and uncomment that on K and interfaces in the other path are initialized: > > #: initializing Test2$K > #: initializing Test2$KN > #: initializing Test2$L > 4 > > If a default method is only declared on I then all interfaces get initialized. > > #: initializing Test2$I > #: initializing Test2$J > #: initializing Test2$JN > #: initializing Test2$K > #: initializing Test2$KN > #: initializing Test2$L > 4 > > Paul. > >> In addition, if the default method body invokes a static method of the interface, then initialization must occur - yet JLS8 12.4.1 does not require it ("T is a class and a static method declared by T is invoked.") That's a straight spec bug - but note that specifying superinterface initialization due to default methods will make it moot. >> >> Alex >> > > public class Test2 { > > interface I { > int v = Test2.out(I.class, 1); > > // default void x() {} > } > > interface J extends I { > int v = Test2.out(J.class, 2); > > default void x() {} > } > > interface JN extends J { > int v = Test2.out(JN.class, 2); > } > > interface K extends I { > int v = Test2.out(K.class, 3); > > // default void x() {} > } > > interface KN extends K { > int v = Test2.out(KN.class, 3); > } > > interface L extends JN, KN { > int v = Test2.out(L.class, 4); > > // default void x() {} > } > > public static void main(String[] args) { > System.out.println(L.v); > } > > static int out(Class c, int i) { > System.out.println("#: initializing " + c.getName()); > return i; > } > > } > From martinrb at google.com Thu Apr 24 07:02:51 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Apr 2014 00:02:51 -0700 Subject: buglets in build.xml Message-ID: If I build ALL THE LANGTOOLS JARS, ant -Dboot.java.home=$jdk build build-all-tools I notice: the manifest of sjavac.jar has the self-referential and non-sensical Class-Path: sjavac.jar --- The manifest of dist/lib/javah.jar has Class-Path: javac.jar BUT The manifest of dist/bootstrap/lib/javah.jar has Class-Path: javadoc.jar doclets.jar javac.jar Those should be the same. It looks like the fix in http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/c287d51c57da 6572945: javah should be written as an annotation processor, not a doclet is incomplete. --- I see doclets.jar's Class-Path is javadoc.jar. Should it also include javac.jar? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at hibernate.org Thu Apr 24 20:46:26 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 24 Apr 2014 22:46:26 +0200 Subject: Repeatable annotations one Java <= 7 Message-ID: Hi, I'd like to mark an annotation type as repeatable via Java 8's @Repeatable meta-annotation. The code accessing the annotation explicitly checks for the container annotation, so it works on Java 8 (where the compiler creates an instance of the container annotation) and on older versions (where the container type must be used explicitly). Now it's my understanding that annotation types not being present at runtime don't cause issues when loading classes annotated with them. But at compile time a warning is issued when compiling code using the annotation on older Java versions (the compilation still succeeds): "Cannot find annotation method 'value()' in type 'java.lang.annotation.Repeatable': class file for java.lang.annotation.Repeatable not found" Is there a way for suppressing that specific compiler warning (but keep others)? I think this would be helpful to allow library authors making existing annotation types repeatable - thus increasing usability on Java 8 - while staying compatible with older Java versions in the described way. Or is this actually a bad pattern and one should create a new repeatable variant of such an annotation type and distribute it separately (e.g. using a classifier such as "jdk8" in Maven artifact terms)? Many thanks, --Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu Apr 24 20:56:22 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 24 Apr 2014 13:56:22 -0700 Subject: Repeatable annotations one Java <= 7 In-Reply-To: References: Message-ID: <53597A76.9060203@oracle.com> Assuming you have @Foo(...) on (say) a class declaration, javac needs to load the annotation type Foo to check that @Foo's element-value pairs are commensurate with the elements declared in Foo. Any meta-annotation on Foo will then have its own annotation type loaded; it is unreasonable to expect otherwise. By marking your annotation type as repeatable, you are committing that it [and any annotations of that type] will only be compiled on JDK 8 and above, where j.l.a.Repeatable can be loaded. Alex On 4/24/2014 1:46 PM, Gunnar Morling wrote: > Hi, > > I'd like to mark an annotation type as repeatable via Java 8's > @Repeatable meta-annotation. > > The code accessing the annotation explicitly checks for the container > annotation, so it works on Java 8 (where the compiler creates an > instance of the container annotation) and on older versions (where the > container type must be used explicitly). > > Now it's my understanding that annotation types not being present at > runtime don't cause issues when loading classes annotated with them. But > at compile time a warning is issued when compiling code using the > annotation on older Java versions (the compilation still succeeds): > > "Cannot find annotation method 'value()' in type > 'java.lang.annotation.Repeatable': class file for > java.lang.annotation.Repeatable not found" > > Is there a way for suppressing that specific compiler warning (but keep > others)? I think this would be helpful to allow library authors making > existing annotation types repeatable - thus increasing usability on Java > 8 - while staying compatible with older Java versions in the described way. > > Or is this actually a bad pattern and one should create a new repeatable > variant of such an annotation type and distribute it separately (e.g. > using a classifier such as "jdk8" in Maven artifact terms)? > > Many thanks, > > --Gunnar > From gunnar at hibernate.org Thu Apr 24 21:58:23 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 24 Apr 2014 23:58:23 +0200 Subject: Repeatable annotations one Java <= 7 In-Reply-To: <53597A76.9060203@oracle.com> References: <53597A76.9060203@oracle.com> Message-ID: Alex, Thanks for the prompt response and clarification. Based on that, I think I'll create another variant of my annotation type and provide two artifacts, one with the variant for Java <= 7 and one for Java 8. --Gunnar 2014-04-24 22:56 GMT+02:00 Alex Buckley : > Assuming you have @Foo(...) on (say) a class declaration, javac needs to > load the annotation type Foo to check that @Foo's element-value pairs are > commensurate with the elements declared in Foo. Any meta-annotation on Foo > will then have its own annotation type loaded; it is unreasonable to expect > otherwise. > > By marking your annotation type as repeatable, you are committing that it > [and any annotations of that type] will only be compiled on JDK 8 and > above, where j.l.a.Repeatable can be loaded. > > Alex > > > On 4/24/2014 1:46 PM, Gunnar Morling wrote: > >> Hi, >> >> I'd like to mark an annotation type as repeatable via Java 8's >> @Repeatable meta-annotation. >> >> The code accessing the annotation explicitly checks for the container >> annotation, so it works on Java 8 (where the compiler creates an >> instance of the container annotation) and on older versions (where the >> container type must be used explicitly). >> >> Now it's my understanding that annotation types not being present at >> runtime don't cause issues when loading classes annotated with them. But >> at compile time a warning is issued when compiling code using the >> annotation on older Java versions (the compilation still succeeds): >> >> "Cannot find annotation method 'value()' in type >> 'java.lang.annotation.Repeatable': class file for >> java.lang.annotation.Repeatable not found" >> >> Is there a way for suppressing that specific compiler warning (but keep >> others)? I think this would be helpful to allow library authors making >> existing annotation types repeatable - thus increasing usability on Java >> 8 - while staying compatible with older Java versions in the described >> way. >> >> Or is this actually a bad pattern and one should create a new repeatable >> variant of such an annotation type and distribute it separately (e.g. >> using a classifier such as "jdk8" in Maven artifact terms)? >> >> Many thanks, >> >> --Gunnar >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.field at oracle.com Tue Apr 29 20:43:23 2014 From: robert.field at oracle.com (Robert Field) Date: Tue, 29 Apr 2014 13:43:23 -0700 Subject: RFR 8036942: Fix handling of multi-catch within a lambda Message-ID: <53600EEB.2070302@oracle.com> Please review compiler (javac) fix for: https://bugs.openjdk.java.net/browse/JDK-8036942 Webrev: http://cr.openjdk.java.net/~rfield/8036942/ The correct tree structure was not being created for a local variable of union type moved into a lambda method. The full (un-erased) type needed to be passed to tree construction and tree construction needed to handle the of union types. Thanks, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.field at oracle.com Wed Apr 30 00:10:01 2014 From: robert.field at oracle.com (Robert Field) Date: Tue, 29 Apr 2014 17:10:01 -0700 Subject: RFR 8029852 and 8029725: lambda instantiates enclosing local class Message-ID: <53603F59.7060406@oracle.com> Please review compiler (javac) fix for: https://bugs.openjdk.java.net/browse/JDK-8029852 https://bugs.openjdk.java.net/browse/JDK-8029725 Webrev: http://cr.openjdk.java.net/~rfield/8029852and8029725/ 8029852: Bad code generated (VerifyError) when lambda instantiates enclosing local class and has captured variables. Add special capture handling. 8029725: Lambda reference to containing local class causes javac infinite recursion. Add tracking of processed classes to prevent looping. Thanks, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Wed Apr 30 13:33:08 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 30 Apr 2014 15:33:08 +0200 Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily complex and platform dependent way Message-ID: <20140430133307.GA13604@e6430> 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 daniel.smith at oracle.com Wed Apr 30 19:11:18 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 30 Apr 2014 13:11:18 -0600 Subject: JEP proposal: Improved variance for generic classes and interfaces Message-ID: <7EDE129E-3B6A-406C-A981-322A76539AA1@oracle.com> Please see the attached JEP document, proposing a language enhancement to improve variance. This is only a draft; it has not yet been "Posted" (see http://openjdk.java.net/jeps/0 for process information). Feedback from all quarters is welcome. (Caveat: please ignore syntax -- it is only for illustration.) --Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: