From jan.lahoda at oracle.com Tue Apr 3 12:06:34 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 3 Apr 2018 14:06:34 +0200 Subject: RFR : JDK-8189765: Improve error reporting for compiling against package not visible due to modules Message-ID: <5AC36E4A.3080701@oracle.com> Hi, When a type cannot be found, javac tries to find it in modules not read by the current module and in not exported packages of any module. But the current search does not search in the unnamed module. The proposed patch is to search in the unnamed module. Webrev: http://cr.openjdk.java.net/~jlahoda/8189765/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8189765 Thanks, Jan From maurizio.cimadamore at oracle.com Wed Apr 4 09:37:56 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 4 Apr 2018 10:37:56 +0100 Subject: RFR : JDK-8189765: Improve error reporting for compiling against package not visible due to modules In-Reply-To: <5AC36E4A.3080701@oracle.com> References: <5AC36E4A.3080701@oracle.com> Message-ID: Looks good Maurizio On 03/04/18 13:06, Jan Lahoda wrote: > Hi, > > When a type cannot be found, javac tries to find it in modules not > read by the current module and in not exported packages of any module. > But the current search does not search in the unnamed module. The > proposed patch is to search in the unnamed module. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8189765/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8189765 > > Thanks, > ??? Jan From orionllmain at gmail.com Wed Apr 4 11:12:36 2018 From: orionllmain at gmail.com (Zheka Kozlov) Date: Wed, 4 Apr 2018 18:12:36 +0700 Subject: Bug in Java 9 compiler Message-ID: I think I found a javac bug which is reproduced on Java 9/10/11, but not on Java 8. I created a repository with a minimal, reproducible and verifiable example: https://github.com/orionll/javac-bug There are three Java files: org/example/Common.java (empty file) org/example/impl/Common.java org/example/impl/Util.java Util.java imports org.example.* and refers to a Common.X field. This is a totally legitimate code, but javac fails with an error saying that org/example/Common.java does not contain a class org.example.Common (it doesn't have to). -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Fri Apr 6 16:07:10 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 06 Apr 2018 16:07:10 +0000 Subject: RFR: JDK-8201251: The tests for JDK-8187247 should be under test/langtools Message-ID: Hi, The tests for JDK-8187247 were added to test/tools/javac instead of test/langtools/tools/javac. This patch moves them to the correct location. Webrev: http://cr.openjdk.java.net/~cushon/8201251/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8201251 Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Apr 6 17:44:44 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 6 Apr 2018 10:44:44 -0700 Subject: RFR: JDK-8201251: The tests for JDK-8187247 should be under test/langtools In-Reply-To: References: Message-ID: Looks fine; cheers, -Joe On 4/6/2018 9:07 AM, Liam Miller-Cushon wrote: > Hi, > > The tests for?JDK-8187247 were added to test/tools/javac instead of > test/langtools/tools/javac. This patch moves them to the correct location. > > Webrev: http://cr.openjdk.java.net/~cushon/8201251/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201251 > > Thanks, > Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From paranoiabla at gmail.com Sun Apr 8 07:54:20 2018 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Sun, 8 Apr 2018 10:54:20 +0300 Subject: java.lang.UnsupportedOperationException with JDK9 and JDK10 Message-ID: Hello everyone, I'm posting my question here, because I'm not sure if it is a bug, or perhaps just the default behavior changed in JDK9. I have custom annotation processor which has the following method: protected T getAnnotationMember(AnnotationMirror annotation, String member) { return processingEnv.getElementUtils().getElementValuesWithDefaults(annotation).entrySet().stream().filter( e -> Objects.equals(member, e.getKey().getSimpleName().toString())).map(element -> { @SuppressWarnings("unchecked") T value = (T) element.getValue().getValue(); // ---> EXCEPTION HAPPENS HERE!!!!! This is line 89 return value; }).findFirst().orElseThrow( () -> new IllegalArgumentException(String.format("Member '%s' not found in mirror for annotation [%s]", member, annotation))); } it pretty much tries to find all classes with this annotation: @interface GeneratorFilter { /** * Exclude code generator classes such that will not be applied by the processor. * * @return the generators to exclude. */ Class[] exclude() default {}; /** * Include code generator classes even when not registered as a service. * * @return the generators to include. */ Class[] include() default {}; } and get the value of the exclude() method. However with JDK9 or JDK10 I get this exception: Caused by: java.lang.UnsupportedOperationException at jdk.compiler/com.sun.tools.javac.code.Attribute.getValue(Attribute.java:58) at com.nemesis.platform.core.mixin.processor.AbstractMixInAnnotationProcessor.lambda$getAnnotationMember$2(AbstractMixInAnnotationProcessor.java:89) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) at java.base/java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1812) 1) At the time of evaluation with Java8: - element = LinkedHashMap$Entry ("exclude()" -> "{}") - element.getValue() = Attribute$Array ({}) - element.getValue().getValue() = List (size = 0) 2) At the time of evaluation with Java9/Java10: - element = LinkedHashMap$Entry ("exclude()" -> "{}") - element.getValue() = ClassReader$ArrayAttributeProxy ({}) - element.getValue().getValue() = UnsupportedOperationException Is this a bug, or the behaviour changed? How can I access the value of exclude() method with JDK9 or JDK10? Thank you. -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Apr 11 20:11:46 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Apr 2018 13:11:46 -0700 Subject: RFR 8199194: Add javac support for preview features In-Reply-To: <337174a4-d291-0f04-e154-24b29d305fa4@oracle.com> References: <337174a4-d291-0f04-e154-24b29d305fa4@oracle.com> Message-ID: <5ACE6C02.7050908@oracle.com> +1. Nice. -- Jon On 03/29/2018 10:31 AM, Maurizio Cimadamore wrote: > Hi, > Here's a langtools patch to support preview language features as > described in JEP 12 [1]. There's also a pending CSR [2] request that > describes the set of changes introduced by this patch in great details. > > Webrev can be found here (the webrev contains also a preview of the > new diagnostics emitted by javac, for a quicker evaluation) > > http://cr.openjdk.java.net/~mcimadamore/8199194/ > > > Implementation-wise, the main decision was how to model preview > support. Should it be an extra source (and target) level? I tried to > go there, as it seems the path of least resistance, but was ultimately > too messy. The main problem we face is that both Source and Target are > enums - completely static entities; so we can't attach a lot of state > to them (which is needed to generate some of the diagnostics required > by the JEP). At the same time, that seems to break an important > invariant, that all Source/Target versions should have a corresponding > flag that can be passed to the -source/--release options. That is, if > 'preview' is an hidden source level, javac has to start distinguishing > about public levels and private ones. > > Instead, I came up with a different approach - there is a new Preview > class in langtools, which acts as a 'coordinator' for the preview > feature. This means that usages of preview features are reported > through this Preview class by other javac classes. Thanks to this, we > now can collect all uses of preview features in a single place, and > generate diagnostics accordingly. > > The mapping of which features are preview features is completely > ad-hoc, which I think it's desirable. We could add a 'preview' token > to Source.Feature - but I think it's best to ask Preview directly if a > given Feature is preview or not. This has some advantages: > > * when a feature goes from preview to stable, we only need to remove > the mapping from Preview - Source stays as is > * we can exploit the indirection to support test flavors which treat > every feature as 'preview'. I used this extensively to be able to > generate diagnostic tests. > > Diagnostic-wise, using preview features with --enable-preview, will > generate a note similar to the one for unchecked warnings; users can > recompile with the -Xlint:preview flag to get more detailed messages > about preview feature usages. Note that by usages here I also mean > attempts to load classfiles which have the minor version set to the > special preview value (hence, some changes to ClassReader were needed). > > To demonstrate how the preview support could be leveraged, I tweaked > the methods in JavacParser::checkSourceLevel and > JavaTokenizer::checkSourceLevel - if the feature to be checked is a > preview feature (this test can be forced using the -XDforcePreview > flag), then extra checks are carried out, to make sure that preview > support is indeed enabled. > > Since the set of preview features is currently empty, this patch > should result in no observable change in the behavior of the javac > compiler. > > > Cheers > Maurizio > > [1] - http://openjdk.java.net/jeps/12 > [2] - https://bugs.openjdk.java.net/browse/JDK-8200312 > > From maurizio.cimadamore at oracle.com Thu Apr 12 13:20:34 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 12 Apr 2018 14:20:34 +0100 Subject: RFR 8199194: Add javac support for preview features In-Reply-To: <5ACE6C02.7050908@oracle.com> References: <337174a4-d291-0f04-e154-24b29d305fa4@oracle.com> <5ACE6C02.7050908@oracle.com> Message-ID: <6ea7021d-b211-0677-c642-658d60ce9983@oracle.com> Thanks - pushed Maurizio On 11/04/18 21:11, Jonathan Gibbons wrote: > +1. > > Nice. > > -- Jon > > On 03/29/2018 10:31 AM, Maurizio Cimadamore wrote: >> Hi, >> Here's a langtools patch to support preview language features as >> described in JEP 12 [1]. There's also a pending CSR [2] request that >> describes the set of changes introduced by this patch in great details. >> >> Webrev can be found here (the webrev contains also a preview of the >> new diagnostics emitted by javac, for a quicker evaluation) >> >> http://cr.openjdk.java.net/~mcimadamore/8199194/ >> >> >> Implementation-wise, the main decision was how to model preview >> support. Should it be an extra source (and target) level? I tried to >> go there, as it seems the path of least resistance, but was >> ultimately too messy. The main problem we face is that both Source >> and Target are enums - completely static entities; so we can't attach >> a lot of state to them (which is needed to generate some of the >> diagnostics required by the JEP). At the same time, that seems to >> break an important invariant, that all Source/Target versions should >> have a corresponding flag that can be passed to the -source/--release >> options. That is, if 'preview' is an hidden source level, javac has >> to start distinguishing about public levels and private ones. >> >> Instead, I came up with a different approach - there is a new Preview >> class in langtools, which acts as a 'coordinator' for the preview >> feature. This means that usages of preview features are reported >> through this Preview class by other javac classes. Thanks to this, we >> now can collect all uses of preview features in a single place, and >> generate diagnostics accordingly. >> >> The mapping of which features are preview features is completely >> ad-hoc, which I think it's desirable. We could add a 'preview' token >> to Source.Feature - but I think it's best to ask Preview directly if >> a given Feature is preview or not. This has some advantages: >> >> * when a feature goes from preview to stable, we only need to remove >> the mapping from Preview - Source stays as is >> * we can exploit the indirection to support test flavors which treat >> every feature as 'preview'. I used this extensively to be able to >> generate diagnostic tests. >> >> Diagnostic-wise, using preview features with --enable-preview, will >> generate a note similar to the one for unchecked warnings; users can >> recompile with the -Xlint:preview flag to get more detailed messages >> about preview feature usages. Note that by usages here I also mean >> attempts to load classfiles which have the minor version set to the >> special preview value (hence, some changes to ClassReader were needed). >> >> To demonstrate how the preview support could be leveraged, I tweaked >> the methods in JavacParser::checkSourceLevel and >> JavaTokenizer::checkSourceLevel - if the feature to be checked is a >> preview feature (this test can be forced using the -XDforcePreview >> flag), then extra checks are carried out, to make sure that preview >> support is indeed enabled. >> >> Since the set of preview features is currently empty, this patch >> should result in no observable change in the behavior of the javac >> compiler. >> >> >> Cheers >> Maurizio >> >> [1] - http://openjdk.java.net/jeps/12 >> [2] - https://bugs.openjdk.java.net/browse/JDK-8200312 >> >> > From jonathan.gibbons at oracle.com Thu Apr 12 20:15:24 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Apr 2018 13:15:24 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs Message-ID: <5ACFBE5C.1080508@oracle.com> Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs. The work is described in the JEP and CSR, and falls into various parts: * The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file. There are no changes to javac itself. JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Apr 12 20:17:03 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Apr 2018 22:17:03 +0200 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: On 2018-04-12 22:15, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > ?* The part to handle the new command-line options is in the native > ?? Java launcher code. > ?* The part to invoke the compiler and subsequently execute the code > ?? found in the source file is in a new class in the jdk.compiler module. > ?* There are some minor Makefile changes, to add support for a new > ?? resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ Build changes look trivially fine. /Magnus > > -- Jon From maurizio.cimadamore at oracle.com Thu Apr 12 20:46:54 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 12 Apr 2018 21:46:54 +0100 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: Looks great - some initial comments (I can't really comment on the launcher changes): * This logic is efficient: int magic = (in.read() << 8) + in.read(); boolean shebang = magic == (('#' << 8) + '!'); but convoluted to read; perhaps could be improved slightly by making '#' << 8) + '!' a static constant, and comparing against that. * I note that the reading logic in general could be simplified, e.g. using Files.lines(Path) - but I assume that you wrote the code as is for performance reasons (e.g. to avoid creating too many string objects) ? * I see that both the file manager and the class loader reasonably share the same context: a Map. I would make this more explicit, by having a Context class, whose state is the map, and then have the context provide two methods: getClassLoader() getFileManager() This way the sharing will be automatic, no need to extract one field from one place and pass it over to the other place. * Big whohoo for being able to use the enhanced diagnostic framework with a couple of tweaks on the makefile - I hope that would have been the case when I put in the support, but since we have never done it - wasn't 100% sure it would work ;-) Overall I like it quite a lot and I think you went for a really clean design - kudos! Maurizio On 12/04/18 21:15, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Apr 13 05:20:14 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 13 Apr 2018 13:20:14 +0800 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com> On 4/13/18 4:15 AM, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > ?* The part to handle the new command-line options is in the native > ?? Java launcher code. > ?* The part to invoke the compiler and subsequently execute the code > ?? found in the source file is in a new class in the jdk.compiler module. > ?* There are some minor Makefile changes, to add support for a new > ?? resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ This looks quite good to me.? One small comment on the source launcher Main class: 122 } catch (InvocationTargetException e) { 123 // leave VM to handle the stacktrace, in the standard manner 124 throw e.getTargetException(); 125 } 387 } catch (InvocationTargetException e) { 388 // remove stack frames for source launcher 389 int invocationFrames = e.getStackTrace().length; 390 Throwable target = e.getTargetException(); 391 StackTraceElement[] targetTrace = target.getStackTrace(); 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); 393 throw e; 394 } This could simply throw target instead of the InvocationTargetException and then the main method can propagate the target, if thrown. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Apr 13 09:08:38 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Apr 2018 11:08:38 +0200 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <5AD07396.1050908@oracle.com> The javac part looks OK to me. A nit comment, in: launcher/Main.java/MemoryFileManager#createInMemoryClassFile, there is: return new FilterOutputStream(new ByteArrayOutputStream()) { ... It could I think be written as: return new ByteArrayOutputStream() { @Override public void close() throws IOException { super.close(); byte[] bytes = toByteArray(); map.put(className, bytes); } }; (I.e. without the cast to ByteArrayOutputStream.) Jan On 12.4.2018 22:15, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon From maurizio.cimadamore at oracle.com Fri Apr 13 10:43:28 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Apr 2018 11:43:28 +0100 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: References: <5ACFBE5C.1080508@oracle.com> Message-ID: <4913267c-9341-29e8-611c-b8e7766a733a@oracle.com> One small followup question - the test SourceLauncherTest is not covering any shebang cases - is that deliberate? I see that those seem to be covered in the launcher test too, but I wonder if we should have tests for clearly broken stuff, such as '#' '#!' '#!\n' Another small question - I see that the shebang process essentially replaces the first line separator with \n - that is probably ok given that the file is processed internally after that - but I wonder if you have thought about pros and cons of preserving the original line separator. Cheers Maurizio On 12/04/18 21:46, Maurizio Cimadamore wrote: > Looks great - some initial comments (I can't really comment on the > launcher changes): > > * This logic is efficient: > > int magic = (in.read() << 8) + in.read(); > boolean shebang = magic == (('#' << 8) + '!'); > > but convoluted to read; perhaps could be improved slightly by making > '#' << 8) + '!' a static constant, and comparing against that. > > * I note that the reading logic in general could be simplified, e.g. > using Files.lines(Path) - but I assume that you wrote the code as is > for performance reasons (e.g. to avoid creating too many string > objects) ? > > * I see that both the file manager and the class loader reasonably > share the same context: a Map. I would make this more > explicit, by having a Context class, whose state is the map, and then > have the context provide two methods: > > getClassLoader() > getFileManager() > > This way the sharing will be automatic, no need to extract one field > from one place and pass it over to the other place. > > * Big whohoo for being able to use the enhanced diagnostic framework > with a couple of tweaks on the makefile - I hope that would have been > the case when I put in the support, but since we have never done it - > wasn't 100% sure it would work ;-) > > > Overall I like it quite a lot and I think you went for a really clean > design - kudos! > > Maurizio > > > > On 12/04/18 21:15, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> ? * The part to handle the new command-line options is in the native >> ??? Java launcher code. >> ? * The part to invoke the compiler and subsequently execute the code >> ??? found in the source file is in a new class in the jdk.compiler >> module. >> ? * There are some minor Makefile changes, to add support for a new >> ??? resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >> >> -- Jon > From maurizio.cimadamore at oracle.com Fri Apr 13 13:46:13 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Apr 2018 14:46:13 +0100 Subject: RFR 8201498: test/langtools/tools/javac/diags/CheckExamples.java 6 errors occurred Message-ID: <41f7c4ee-582e-cab3-6b8c-e321266b187d@oracle.com> The diagnostic test for the preview 'additional' diagnostic is failing intermittently. This patch disables it until we figure out exactly why that happens. http://cr.openjdk.java.net/~mcimadamore/8201498/ Maurizio From maurizio.cimadamore at oracle.com Fri Apr 13 14:15:28 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Apr 2018 15:15:28 +0100 Subject: RFR 8201498: test/langtools/tools/javac/diags/CheckExamples.java 6 errors occurred In-Reply-To: <41f7c4ee-582e-cab3-6b8c-e321266b187d@oracle.com> References: <41f7c4ee-582e-cab3-6b8c-e321266b187d@oracle.com> Message-ID: <5fd628bf-deca-12d8-ece0-84d0bb422837@oracle.com> And here's an attempt to fix the underlying issue. The theory is that, by the time we get to compile the PreviewPluralAdditional example, a Bar.class already exists in jtreg scratch folder. This might well be the case, given that there's another Bar class around (that of the PreviewPlural example). So a solution would be to rename both Bar classes to something more unambiguous. The order in which examples are ran depends on the behavior of File.listFiles(), not 100% sure why that would return different files in different order. http://cr.openjdk.java.net/~mcimadamore/8201498_v2/ Maurizio On 13/04/18 14:46, Maurizio Cimadamore wrote: > The diagnostic test for the preview 'additional' diagnostic is failing > intermittently. This patch disables it until we figure out exactly why > that happens. > > http://cr.openjdk.java.net/~mcimadamore/8201498/ > > Maurizio > From jan.lahoda at oracle.com Fri Apr 13 14:45:04 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Apr 2018 16:45:04 +0200 Subject: RFR 8201498: test/langtools/tools/javac/diags/CheckExamples.java 6 errors occurred In-Reply-To: <5fd628bf-deca-12d8-ece0-84d0bb422837@oracle.com> References: <41f7c4ee-582e-cab3-6b8c-e321266b187d@oracle.com> <5fd628bf-deca-12d8-ece0-84d0bb422837@oracle.com> Message-ID: <5AD0C270.5090908@oracle.com> On 13.4.2018 16:15, Maurizio Cimadamore wrote: > And here's an attempt to fix the underlying issue. The theory is that, > by the time we get to compile the PreviewPluralAdditional example, a > Bar.class already exists in jtreg scratch folder. This might well be the > case, given that there's another Bar class around (that of the > PreviewPlural example). So a solution would be to rename both Bar > classes to something more unambiguous. The order in which examples are > ran depends on the behavior of File.listFiles(), not 100% sure why that > would return different files in different order. > > http://cr.openjdk.java.net/~mcimadamore/8201498_v2/ Seems reasonable. Thanks, Jan > > Maurizio > > > > On 13/04/18 14:46, Maurizio Cimadamore wrote: >> The diagnostic test for the preview 'additional' diagnostic is failing >> intermittently. This patch disables it until we figure out exactly why >> that happens. >> >> http://cr.openjdk.java.net/~mcimadamore/8201498/ >> >> Maurizio >> > From cushon at google.com Fri Apr 13 17:00:46 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 13 Apr 2018 17:00:46 +0000 Subject: RFR: JDK-8160601: unexpected error compiling @Deprecated package Message-ID: Hi, javac currently rejects package-info declarations that contain both an `@deprecated` javadoc tag and annotations by reporting a misleading 'modifier deprecated not allowed' diagnostic. This change causes `@deprecated` javadoc to be ignored, which is consistent with the `@Deprecated` annotation is handled on packages. bug: https://bugs.openjdk.java.net/browse/JDK-8160601 webrev: http://cr.openjdk.java.net/~cushon/8160601/webrev.00/ Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.x.nazarov at oracle.com Fri Apr 13 17:28:19 2018 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Fri, 13 Apr 2018 10:28:19 -0700 Subject: RFR 8199194: Add javac support for preview features In-Reply-To: <6ea7021d-b211-0677-c642-658d60ce9983@oracle.com> References: <337174a4-d291-0f04-e154-24b29d305fa4@oracle.com> <5ACE6C02.7050908@oracle.com> <6ea7021d-b211-0677-c642-658d60ce9983@oracle.com> Message-ID: <6BFFA0F3-664B-47BD-97F5-A6EA43639470@oracle.com> Line code coverage. Just FYI ?Andrei -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: report.txt URL: -------------- next part -------------- > On 12 Apr 2018, at 06:20, Maurizio Cimadamore wrote: > > Thanks - pushed > > Maurizio > > > On 11/04/18 21:11, Jonathan Gibbons wrote: >> +1. >> >> Nice. >> >> -- Jon >> >> On 03/29/2018 10:31 AM, Maurizio Cimadamore wrote: >>> Hi, >>> Here's a langtools patch to support preview language features as described in JEP 12 [1]. There's also a pending CSR [2] request that describes the set of changes introduced by this patch in great details. >>> >>> Webrev can be found here (the webrev contains also a preview of the new diagnostics emitted by javac, for a quicker evaluation) >>> >>> http://cr.openjdk.java.net/~mcimadamore/8199194/ >>> >>> >>> Implementation-wise, the main decision was how to model preview support. Should it be an extra source (and target) level? I tried to go there, as it seems the path of least resistance, but was ultimately too messy. The main problem we face is that both Source and Target are enums - completely static entities; so we can't attach a lot of state to them (which is needed to generate some of the diagnostics required by the JEP). At the same time, that seems to break an important invariant, that all Source/Target versions should have a corresponding flag that can be passed to the -source/--release options. That is, if 'preview' is an hidden source level, javac has to start distinguishing about public levels and private ones. >>> >>> Instead, I came up with a different approach - there is a new Preview class in langtools, which acts as a 'coordinator' for the preview feature. This means that usages of preview features are reported through this Preview class by other javac classes. Thanks to this, we now can collect all uses of preview features in a single place, and generate diagnostics accordingly. >>> >>> The mapping of which features are preview features is completely ad-hoc, which I think it's desirable. We could add a 'preview' token to Source.Feature - but I think it's best to ask Preview directly if a given Feature is preview or not. This has some advantages: >>> >>> * when a feature goes from preview to stable, we only need to remove the mapping from Preview - Source stays as is >>> * we can exploit the indirection to support test flavors which treat every feature as 'preview'. I used this extensively to be able to generate diagnostic tests. >>> >>> Diagnostic-wise, using preview features with --enable-preview, will generate a note similar to the one for unchecked warnings; users can recompile with the -Xlint:preview flag to get more detailed messages about preview feature usages. Note that by usages here I also mean attempts to load classfiles which have the minor version set to the special preview value (hence, some changes to ClassReader were needed). >>> >>> To demonstrate how the preview support could be leveraged, I tweaked the methods in JavacParser::checkSourceLevel and JavaTokenizer::checkSourceLevel - if the feature to be checked is a preview feature (this test can be forced using the -XDforcePreview flag), then extra checks are carried out, to make sure that preview support is indeed enabled. >>> >>> Since the set of preview features is currently empty, this patch should result in no observable change in the behavior of the javac compiler. >>> >>> >>> Cheers >>> Maurizio >>> >>> [1] - http://openjdk.java.net/jeps/12 >>> [2] - https://bugs.openjdk.java.net/browse/JDK-8200312 >>> >>> >> > From forax at univ-mlv.fr Sat Apr 14 17:44:30 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 14 Apr 2018 19:44:30 +0200 (CEST) Subject: Interface private & "default" added by javac In-Reply-To: <1995180891.172965.1523707401329@mail.yahoo.com> References: <1995180891.172965.1523707401329.ref@mail.yahoo.com> <1995180891.172965.1523707401329@mail.yahoo.com> Message-ID: <1300658429.2602195.1523727870704.JavaMail.zimbra@u-pem.fr> < Was sent to the wrong mailing list > default is a keyword in Java the Language but it doesn't exist at bytecode level (non abstract is enough), so it seems you decompiler add the keyword default for every methods non-abstract in an interface, your compiler is wrong. If you use javap -private InterfacePrivateMethod.class, you get Compiled from "InterfacePrivateMethod.java" public interface InterfacePrivateMethod { public void foo(); private void print(); } cheers, R?mi > De: "Ionut" > ?: "hotspot compiler" , "Ionut B" > > Envoy?: Samedi 14 Avril 2018 14:03:21 > Objet: Interface private & "default" added by javac > Hello All, > I have an initial interface containing one default and one private method: > public interface InterfacePrivateMethod { > default void foo(){ > print(); > } > private void print() { > System.out.println("Private Method"); > } > } > After I compile it with javac and then decompile, the class I get looks like: > public interface InterfacePrivateMethod { > default void foo() { > this.print(); > } > private default void print() { // private default !? > System.out.println("Private Method"); > } > } > Basically javac inserts default in the private method signature. > Could you please provide more details about this, why is that? > At the Java source code level a private method cannot be default in the same > time inside an Interface. > Thanks a lot, > Ionut -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sun Apr 15 12:11:00 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 15 Apr 2018 14:11:00 +0200 Subject: Equivalent .class fields should share the same symbol Message-ID: Hi, As mentioned in [1], equivalent .class fields should share the same symbol. The fix below caches .class symbols per unique type. All javac tests are passing successfully. Does this look reasonable? Thanks, Bernard [1] http://mail.openjdk.java.net/pipermail/amber-dev/2018-April/002897.html diff -r 8c85a1855e10 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java Fri Apr 13 11:14:49 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java Sun Apr 15 13:42:07 2018 +0200 @@ -247,6 +247,8 @@ */ private final Map modules = new LinkedHashMap<>(); + public final Map _class = new HashMap<>(); + public void initType(Type type, ClassSymbol c) { type.tsym = c; typeOfTag[type.getTag().ordinal()] = type; diff -r 8c85a1855e10 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Fri Apr 13 11:14:49 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Sun Apr 15 13:42:07 2018 +0200 @@ -3734,8 +3734,11 @@ Type t = syms.classType; List typeargs = List.of(types.erasure(site)); t = new ClassType(t.getEnclosingType(), typeargs, t.tsym); - return new VarSymbol( + VarSymbol _class = new VarSymbol( STATIC | PUBLIC | FINAL, names._class, t, site.tsym); + VarSymbol existing = syms._class.putIfAbsent( + new Types.UniqueType(site, types), _class); + return existing != null ? existing : _class; } else { // We are seeing a plain identifier as selector. Symbol sym = rs.findIdentInType(env, site, name, resultInfo.pkind); @@ -3776,8 +3779,11 @@ Type t = syms.classType; Type arg = types.boxedClass(site).type; t = new ClassType(t.getEnclosingType(), List.of(arg), t.tsym); - return new VarSymbol( + VarSymbol _class = new VarSymbol( STATIC | PUBLIC | FINAL, names._class, t, site.tsym); + VarSymbol existing = syms._class.putIfAbsent( + new Types.UniqueType(site, types), _class); + return existing != null ? existing : _class; } else { log.error(pos, Errors.CantDeref(site)); return syms.errSymbol; diff -r 8c85a1855e10 test/langtools/tools/javac/lambda/deduplication/Deduplication.java --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java Fri Apr 13 11:14:49 2018 -0700 +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java Sun Apr 15 13:42:07 2018 +0200 @@ -38,6 +38,21 @@ (Runnable) () -> { ( (Runnable) () -> {} ).run(); } ); + group( + (Runnable) () -> { Deduplication.class.toString(); }, + (Runnable) () -> { Deduplication.class.toString(); } + ); + + group( + (Runnable) () -> { Integer[].class.toString(); }, + (Runnable) () -> { Integer[].class.toString(); } + ); + + group( + (Runnable) () -> { char.class.toString(); }, + (Runnable) () -> { char.class.toString(); } + ); + group((Function) x -> x.hashCode()); group((Function) x -> x.hashCode()); From forax at univ-mlv.fr Sun Apr 15 12:31:58 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 15 Apr 2018 14:31:58 +0200 (CEST) Subject: Equivalent .class fields should share the same symbol In-Reply-To: References: Message-ID: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> Hi, You can use Map.computeIfAbsent instead of putIfAbsent to avoid to create the Symbol before checking if one exist or not. Also you using _class for several purpose, the Map should be named classes and the local variable classSymbol or something like that. cheers, R?mi ----- Mail original ----- > De: "B. Blaser" > ?: "compiler-dev" > Envoy?: Dimanche 15 Avril 2018 14:11:00 > Objet: Equivalent .class fields should share the same symbol > Hi, > > As mentioned in [1], equivalent .class fields should share the same symbol. > The fix below caches .class symbols per unique type. > > All javac tests are passing successfully. > > Does this look reasonable? > > Thanks, > Bernard > > [1] http://mail.openjdk.java.net/pipermail/amber-dev/2018-April/002897.html > > diff -r 8c85a1855e10 > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > Sun Apr 15 13:42:07 2018 +0200 > @@ -247,6 +247,8 @@ > */ > private final Map modules = new LinkedHashMap<>(); > > + public final Map _class = new HashMap<>(); > + > public void initType(Type type, ClassSymbol c) { > type.tsym = c; > typeOfTag[type.getTag().ordinal()] = type; > diff -r 8c85a1855e10 > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > Sun Apr 15 13:42:07 2018 +0200 > @@ -3734,8 +3734,11 @@ > Type t = syms.classType; > List typeargs = List.of(types.erasure(site)); > t = new ClassType(t.getEnclosingType(), typeargs, t.tsym); > - return new VarSymbol( > + VarSymbol _class = new VarSymbol( > STATIC | PUBLIC | FINAL, names._class, t, site.tsym); > + VarSymbol existing = syms._class.putIfAbsent( > + new Types.UniqueType(site, types), _class); > + return existing != null ? existing : _class; > } else { > // We are seeing a plain identifier as selector. > Symbol sym = rs.findIdentInType(env, site, name, > resultInfo.pkind); > @@ -3776,8 +3779,11 @@ > Type t = syms.classType; > Type arg = types.boxedClass(site).type; > t = new ClassType(t.getEnclosingType(), > List.of(arg), t.tsym); > - return new VarSymbol( > + VarSymbol _class = new VarSymbol( > STATIC | PUBLIC | FINAL, names._class, t, site.tsym); > + VarSymbol existing = syms._class.putIfAbsent( > + new Types.UniqueType(site, types), _class); > + return existing != null ? existing : _class; > } else { > log.error(pos, Errors.CantDeref(site)); > return syms.errSymbol; > diff -r 8c85a1855e10 > test/langtools/tools/javac/lambda/deduplication/Deduplication.java > --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java > Sun Apr 15 13:42:07 2018 +0200 > @@ -38,6 +38,21 @@ > (Runnable) () -> { ( (Runnable) () -> {} ).run(); } > ); > > + group( > + (Runnable) () -> { Deduplication.class.toString(); }, > + (Runnable) () -> { Deduplication.class.toString(); } > + ); > + > + group( > + (Runnable) () -> { Integer[].class.toString(); }, > + (Runnable) () -> { Integer[].class.toString(); } > + ); > + > + group( > + (Runnable) () -> { char.class.toString(); }, > + (Runnable) () -> { char.class.toString(); } > + ); > + > group((Function) x -> x.hashCode()); > group((Function) x -> x.hashCode()); From bsrbnd at gmail.com Sun Apr 15 16:34:57 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 15 Apr 2018 18:34:57 +0200 Subject: Equivalent .class fields should share the same symbol In-Reply-To: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, On 15 April 2018 at 14:31, Remi Forax wrote: > Hi, > You can use Map.computeIfAbsent instead of putIfAbsent to avoid to create the Symbol before checking if one exist or not. > > Also you using _class for several purpose, the Map should be named classes and the local variable classSymbol or something like that. > > cheers, > R?mi Thanks for your feedback, nice suggestions. Here is the updated version. Cheers, Bernard diff -r 8c85a1855e10 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java Fri Apr 13 11:14:49 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java Sun Apr 15 17:15:36 2018 +0200 @@ -247,6 +247,8 @@ */ private final Map modules = new LinkedHashMap<>(); + public final Map classFields = new HashMap<>(); + public void initType(Type type, ClassSymbol c) { type.tsym = c; typeOfTag[type.getTag().ordinal()] = type; diff -r 8c85a1855e10 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Fri Apr 13 11:14:49 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Sun Apr 15 17:15:36 2018 +0200 @@ -3731,11 +3731,14 @@ } else if (name == names._class) { // In this case, we have already made sure in // visitSelect that qualifier expression is a type. - Type t = syms.classType; - List typeargs = List.of(types.erasure(site)); - t = new ClassType(t.getEnclosingType(), typeargs, t.tsym); - return new VarSymbol( - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); + return syms.classFields.computeIfAbsent( + new Types.UniqueType(site, types), k -> { + Type t = syms.classType; + List typeargs = List.of(types.erasure(site)); + t = new ClassType(t.getEnclosingType(), typeargs, t.tsym); + return new VarSymbol( + STATIC | PUBLIC | FINAL, names._class, t, site.tsym); + }); } else { // We are seeing a plain identifier as selector. Symbol sym = rs.findIdentInType(env, site, name, resultInfo.pkind); @@ -3773,11 +3776,14 @@ if (name == names._class) { // In this case, we have already made sure in Select that // qualifier expression is a type. - Type t = syms.classType; - Type arg = types.boxedClass(site).type; - t = new ClassType(t.getEnclosingType(), List.of(arg), t.tsym); - return new VarSymbol( - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); + return syms.classFields.computeIfAbsent( + new Types.UniqueType(site, types), k -> { + Type t = syms.classType; + Type arg = types.boxedClass(site).type; + t = new ClassType(t.getEnclosingType(), List.of(arg), t.tsym); + return new VarSymbol( + STATIC | PUBLIC | FINAL, names._class, t, site.tsym); + }); } else { log.error(pos, Errors.CantDeref(site)); return syms.errSymbol; diff -r 8c85a1855e10 test/langtools/tools/javac/lambda/deduplication/Deduplication.java --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java Fri Apr 13 11:14:49 2018 -0700 +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java Sun Apr 15 17:15:36 2018 +0200 @@ -38,6 +38,21 @@ (Runnable) () -> { ( (Runnable) () -> {} ).run(); } ); + group( + (Runnable) () -> { Deduplication.class.toString(); }, + (Runnable) () -> { Deduplication.class.toString(); } + ); + + group( + (Runnable) () -> { Integer[].class.toString(); }, + (Runnable) () -> { Integer[].class.toString(); } + ); + + group( + (Runnable) () -> { char.class.toString(); }, + (Runnable) () -> { char.class.toString(); } + ); + group((Function) x -> x.hashCode()); group((Function) x -> x.hashCode()); From vicente.romero at oracle.com Mon Apr 16 14:07:00 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 16 Apr 2018 10:07:00 -0400 Subject: Equivalent .class fields should share the same symbol In-Reply-To: References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> Message-ID: <625d4a44-3d82-a2d8-16ee-cb0f8cd5b340@oracle.com> Hi Bernard, The change looks good. Suggestion: it would be nice to include some regression tests with it, Thanks, Vicente On 04/15/2018 12:34 PM, B. Blaser wrote: > Hi R?mi, > > On 15 April 2018 at 14:31, Remi Forax wrote: >> Hi, >> You can use Map.computeIfAbsent instead of putIfAbsent to avoid to create the Symbol before checking if one exist or not. >> >> Also you using _class for several purpose, the Map should be named classes and the local variable classSymbol or something like that. >> >> cheers, >> R?mi > Thanks for your feedback, nice suggestions. > Here is the updated version. > > Cheers, > Bernard > > diff -r 8c85a1855e10 > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > Sun Apr 15 17:15:36 2018 +0200 > @@ -247,6 +247,8 @@ > */ > private final Map modules = new LinkedHashMap<>(); > > + public final Map classFields = new > HashMap<>(); > + > public void initType(Type type, ClassSymbol c) { > type.tsym = c; > typeOfTag[type.getTag().ordinal()] = type; > diff -r 8c85a1855e10 > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > Sun Apr 15 17:15:36 2018 +0200 > @@ -3731,11 +3731,14 @@ > } else if (name == names._class) { > // In this case, we have already made sure in > // visitSelect that qualifier expression is a type. > - Type t = syms.classType; > - List typeargs = List.of(types.erasure(site)); > - t = new ClassType(t.getEnclosingType(), typeargs, t.tsym); > - return new VarSymbol( > - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); > + return syms.classFields.computeIfAbsent( > + new Types.UniqueType(site, types), k -> { > + Type t = syms.classType; > + List typeargs = List.of(types.erasure(site)); > + t = new ClassType(t.getEnclosingType(), > typeargs, t.tsym); > + return new VarSymbol( > + STATIC | PUBLIC | FINAL, > names._class, t, site.tsym); > + }); > } else { > // We are seeing a plain identifier as selector. > Symbol sym = rs.findIdentInType(env, site, name, > resultInfo.pkind); > @@ -3773,11 +3776,14 @@ > if (name == names._class) { > // In this case, we have already made sure in Select that > // qualifier expression is a type. > - Type t = syms.classType; > - Type arg = types.boxedClass(site).type; > - t = new ClassType(t.getEnclosingType(), > List.of(arg), t.tsym); > - return new VarSymbol( > - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); > + return syms.classFields.computeIfAbsent( > + new Types.UniqueType(site, types), k -> { > + Type t = syms.classType; > + Type arg = types.boxedClass(site).type; > + t = new ClassType(t.getEnclosingType(), > List.of(arg), t.tsym); > + return new VarSymbol( > + STATIC | PUBLIC | FINAL, > names._class, t, site.tsym); > + }); > } else { > log.error(pos, Errors.CantDeref(site)); > return syms.errSymbol; > diff -r 8c85a1855e10 > test/langtools/tools/javac/lambda/deduplication/Deduplication.java > --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java > Sun Apr 15 17:15:36 2018 +0200 > @@ -38,6 +38,21 @@ > (Runnable) () -> { ( (Runnable) () -> {} ).run(); } > ); > > + group( > + (Runnable) () -> { Deduplication.class.toString(); }, > + (Runnable) () -> { Deduplication.class.toString(); } > + ); > + > + group( > + (Runnable) () -> { Integer[].class.toString(); }, > + (Runnable) () -> { Integer[].class.toString(); } > + ); > + > + group( > + (Runnable) () -> { char.class.toString(); }, > + (Runnable) () -> { char.class.toString(); } > + ); > + > group((Function) x -> x.hashCode()); > group((Function) x -> x.hashCode()); From jan.lahoda at oracle.com Mon Apr 16 15:02:36 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 16 Apr 2018 17:02:36 +0200 Subject: Equivalent .class fields should share the same symbol In-Reply-To: References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> Message-ID: <5AD4BB0C.2060402@oracle.com> Hi Bernard, There are two things I wonder about: -can the key to the map be TypeSymbol? Basically "site.tsym" instead of "new Types.UniqueType(site...)". To me that would feel simpler. -should there be a method in Symtab managing the map? Something like: Symtab.getClassField(TypeSymbol tsym) {/*create the VarSymbol is needed*/} Thanks, Jan On 15.4.2018 18:34, B. Blaser wrote: > Hi R?mi, > > On 15 April 2018 at 14:31, Remi Forax wrote: >> Hi, >> You can use Map.computeIfAbsent instead of putIfAbsent to avoid to create the Symbol before checking if one exist or not. >> >> Also you using _class for several purpose, the Map should be named classes and the local variable classSymbol or something like that. >> >> cheers, >> R?mi > > Thanks for your feedback, nice suggestions. > Here is the updated version. > > Cheers, > Bernard > > diff -r 8c85a1855e10 > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > Sun Apr 15 17:15:36 2018 +0200 > @@ -247,6 +247,8 @@ > */ > private final Map modules = new LinkedHashMap<>(); > > + public final Map classFields = new > HashMap<>(); > + > public void initType(Type type, ClassSymbol c) { > type.tsym = c; > typeOfTag[type.getTag().ordinal()] = type; > diff -r 8c85a1855e10 > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > Sun Apr 15 17:15:36 2018 +0200 > @@ -3731,11 +3731,14 @@ > } else if (name == names._class) { > // In this case, we have already made sure in > // visitSelect that qualifier expression is a type. > - Type t = syms.classType; > - List typeargs = List.of(types.erasure(site)); > - t = new ClassType(t.getEnclosingType(), typeargs, t.tsym); > - return new VarSymbol( > - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); > + return syms.classFields.computeIfAbsent( > + new Types.UniqueType(site, types), k -> { > + Type t = syms.classType; > + List typeargs = List.of(types.erasure(site)); > + t = new ClassType(t.getEnclosingType(), > typeargs, t.tsym); > + return new VarSymbol( > + STATIC | PUBLIC | FINAL, > names._class, t, site.tsym); > + }); > } else { > // We are seeing a plain identifier as selector. > Symbol sym = rs.findIdentInType(env, site, name, > resultInfo.pkind); > @@ -3773,11 +3776,14 @@ > if (name == names._class) { > // In this case, we have already made sure in Select that > // qualifier expression is a type. > - Type t = syms.classType; > - Type arg = types.boxedClass(site).type; > - t = new ClassType(t.getEnclosingType(), > List.of(arg), t.tsym); > - return new VarSymbol( > - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); > + return syms.classFields.computeIfAbsent( > + new Types.UniqueType(site, types), k -> { > + Type t = syms.classType; > + Type arg = types.boxedClass(site).type; > + t = new ClassType(t.getEnclosingType(), > List.of(arg), t.tsym); > + return new VarSymbol( > + STATIC | PUBLIC | FINAL, > names._class, t, site.tsym); > + }); > } else { > log.error(pos, Errors.CantDeref(site)); > return syms.errSymbol; > diff -r 8c85a1855e10 > test/langtools/tools/javac/lambda/deduplication/Deduplication.java > --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java > Sun Apr 15 17:15:36 2018 +0200 > @@ -38,6 +38,21 @@ > (Runnable) () -> { ( (Runnable) () -> {} ).run(); } > ); > > + group( > + (Runnable) () -> { Deduplication.class.toString(); }, > + (Runnable) () -> { Deduplication.class.toString(); } > + ); > + > + group( > + (Runnable) () -> { Integer[].class.toString(); }, > + (Runnable) () -> { Integer[].class.toString(); } > + ); > + > + group( > + (Runnable) () -> { char.class.toString(); }, > + (Runnable) () -> { char.class.toString(); } > + ); > + > group((Function) x -> x.hashCode()); > group((Function) x -> x.hashCode()); > From bsrbnd at gmail.com Mon Apr 16 17:06:34 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Apr 2018 19:06:34 +0200 Subject: Equivalent .class fields should share the same symbol In-Reply-To: <625d4a44-3d82-a2d8-16ee-cb0f8cd5b340@oracle.com> References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> <625d4a44-3d82-a2d8-16ee-cb0f8cd5b340@oracle.com> Message-ID: Hi Vicente, On 16 April 2018 at 16:07, Vicente Romero wrote: > Hi Bernard, > > The change looks good. Suggestion: it would be nice to include some > regression tests with it, > > Thanks, > Vicente I added this use case to the de-duplication test (at the end of the patch) since the problem appears in such situations. Did you miss it or do you have any other idea in mind? Thanks, Bernard > On 04/15/2018 12:34 PM, B. Blaser wrote: >> >> Hi R?mi, >> >> On 15 April 2018 at 14:31, Remi Forax wrote: >>> >>> Hi, >>> You can use Map.computeIfAbsent instead of putIfAbsent to avoid to create >>> the Symbol before checking if one exist or not. >>> >>> Also you using _class for several purpose, the Map should be named >>> classes and the local variable classSymbol or something like that. >>> >>> cheers, >>> R?mi >> >> Thanks for your feedback, nice suggestions. >> Here is the updated version. >> >> Cheers, >> Bernard >> >> diff -r 8c85a1855e10 >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >> Fri Apr 13 11:14:49 2018 -0700 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >> Sun Apr 15 17:15:36 2018 +0200 >> @@ -247,6 +247,8 @@ >> */ >> private final Map modules = new >> LinkedHashMap<>(); >> >> + public final Map classFields = new >> HashMap<>(); >> + >> public void initType(Type type, ClassSymbol c) { >> type.tsym = c; >> typeOfTag[type.getTag().ordinal()] = type; >> diff -r 8c85a1855e10 >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >> Fri Apr 13 11:14:49 2018 -0700 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >> Sun Apr 15 17:15:36 2018 +0200 >> @@ -3731,11 +3731,14 @@ >> } else if (name == names._class) { >> // In this case, we have already made sure in >> // visitSelect that qualifier expression is a type. >> - Type t = syms.classType; >> - List typeargs = List.of(types.erasure(site)); >> - t = new ClassType(t.getEnclosingType(), typeargs, >> t.tsym); >> - return new VarSymbol( >> - STATIC | PUBLIC | FINAL, names._class, t, >> site.tsym); >> + return syms.classFields.computeIfAbsent( >> + new Types.UniqueType(site, types), k -> { >> + Type t = syms.classType; >> + List typeargs = >> List.of(types.erasure(site)); >> + t = new ClassType(t.getEnclosingType(), >> typeargs, t.tsym); >> + return new VarSymbol( >> + STATIC | PUBLIC | FINAL, >> names._class, t, site.tsym); >> + }); >> } else { >> // We are seeing a plain identifier as selector. >> Symbol sym = rs.findIdentInType(env, site, name, >> resultInfo.pkind); >> @@ -3773,11 +3776,14 @@ >> if (name == names._class) { >> // In this case, we have already made sure in Select >> that >> // qualifier expression is a type. >> - Type t = syms.classType; >> - Type arg = types.boxedClass(site).type; >> - t = new ClassType(t.getEnclosingType(), >> List.of(arg), t.tsym); >> - return new VarSymbol( >> - STATIC | PUBLIC | FINAL, names._class, t, >> site.tsym); >> + return syms.classFields.computeIfAbsent( >> + new Types.UniqueType(site, types), k -> { >> + Type t = syms.classType; >> + Type arg = types.boxedClass(site).type; >> + t = new ClassType(t.getEnclosingType(), >> List.of(arg), t.tsym); >> + return new VarSymbol( >> + STATIC | PUBLIC | FINAL, >> names._class, t, site.tsym); >> + }); >> } else { >> log.error(pos, Errors.CantDeref(site)); >> return syms.errSymbol; >> diff -r 8c85a1855e10 >> test/langtools/tools/javac/lambda/deduplication/Deduplication.java >> --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java >> Fri Apr 13 11:14:49 2018 -0700 >> +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java >> Sun Apr 15 17:15:36 2018 +0200 >> @@ -38,6 +38,21 @@ >> (Runnable) () -> { ( (Runnable) () -> {} ).run(); } >> ); >> >> + group( >> + (Runnable) () -> { Deduplication.class.toString(); }, >> + (Runnable) () -> { Deduplication.class.toString(); } >> + ); >> + >> + group( >> + (Runnable) () -> { Integer[].class.toString(); }, >> + (Runnable) () -> { Integer[].class.toString(); } >> + ); >> + >> + group( >> + (Runnable) () -> { char.class.toString(); }, >> + (Runnable) () -> { char.class.toString(); } >> + ); >> + >> group((Function) x -> x.hashCode()); >> group((Function) x -> x.hashCode()); > > From bsrbnd at gmail.com Mon Apr 16 17:31:01 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Apr 2018 19:31:01 +0200 Subject: Equivalent .class fields should share the same symbol In-Reply-To: <5AD4BB0C.2060402@oracle.com> References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> <5AD4BB0C.2060402@oracle.com> Message-ID: Hi Jan, On 16 April 2018 at 17:02, Jan Lahoda wrote: > Hi Bernard, > > There are two things I wonder about: > -can the key to the map be TypeSymbol? Basically "site.tsym" instead of "new > Types.UniqueType(site...)". To me that would feel simpler. I had the feeling that using 'site.tsym' might fail with arrays, but I'll check this. > -should there be a method in Symtab managing the map? Something like: > Symtab.getClassField(TypeSymbol tsym) {/*create the VarSymbol is needed*/} I'll take a look if you think it's worth adding a method for this. > Thanks, > Jan Thanks, Bernard From jan.lahoda at oracle.com Mon Apr 16 17:40:55 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 16 Apr 2018 19:40:55 +0200 Subject: Equivalent .class fields should share the same symbol In-Reply-To: References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> <5AD4BB0C.2060402@oracle.com> Message-ID: <5AD4E027.2040605@oracle.com> On 16.4.2018 19:31, B. Blaser wrote: > Hi Jan, > > On 16 April 2018 at 17:02, Jan Lahoda wrote: >> Hi Bernard, >> >> There are two things I wonder about: >> -can the key to the map be TypeSymbol? Basically "site.tsym" instead of "new >> Types.UniqueType(site...)". To me that would feel simpler. > > I had the feeling that using 'site.tsym' might fail with arrays, but > I'll check this. You are probably right this won't work. Sorry, I didn't figure that out - I was checking primitives, and those seemed that could work. > >> -should there be a method in Symtab managing the map? Something like: >> Symtab.getClassField(TypeSymbol tsym) {/*create the VarSymbol is needed*/} > > I'll take a look if you think it's worth adding a method for this. I think it would be nicer than maintaining the map from another class, if possible/doable. Thanks, Jan > >> Thanks, >> Jan > > Thanks, > Bernard > From vicente.romero at oracle.com Mon Apr 16 20:23:11 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 16 Apr 2018 16:23:11 -0400 Subject: Equivalent .class fields should share the same symbol In-Reply-To: References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> <625d4a44-3d82-a2d8-16ee-cb0f8cd5b340@oracle.com> Message-ID: On 04/16/2018 01:06 PM, B. Blaser wrote: > Hi Vicente, > > On 16 April 2018 at 16:07, Vicente Romero wrote: >> Hi Bernard, >> >> The change looks good. Suggestion: it would be nice to include some >> regression tests with it, >> >> Thanks, >> Vicente > I added this use case to the de-duplication test (at the end of the > patch) since the problem appears in such situations. > Did you miss it or do you have any other idea in mind? I guess I was thinking about a dedicated test, probably a combo test, but yes I guess that reusing the deduplication test could be a good start > > Thanks, > Bernard Vicente > > >> On 04/15/2018 12:34 PM, B. Blaser wrote: >>> Hi R?mi, >>> >>> On 15 April 2018 at 14:31, Remi Forax wrote: >>>> Hi, >>>> You can use Map.computeIfAbsent instead of putIfAbsent to avoid to create >>>> the Symbol before checking if one exist or not. >>>> >>>> Also you using _class for several purpose, the Map should be named >>>> classes and the local variable classSymbol or something like that. >>>> >>>> cheers, >>>> R?mi >>> Thanks for your feedback, nice suggestions. >>> Here is the updated version. >>> >>> Cheers, >>> Bernard >>> >>> diff -r 8c85a1855e10 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >>> Fri Apr 13 11:14:49 2018 -0700 >>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >>> Sun Apr 15 17:15:36 2018 +0200 >>> @@ -247,6 +247,8 @@ >>> */ >>> private final Map modules = new >>> LinkedHashMap<>(); >>> >>> + public final Map classFields = new >>> HashMap<>(); >>> + >>> public void initType(Type type, ClassSymbol c) { >>> type.tsym = c; >>> typeOfTag[type.getTag().ordinal()] = type; >>> diff -r 8c85a1855e10 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >>> Fri Apr 13 11:14:49 2018 -0700 >>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >>> Sun Apr 15 17:15:36 2018 +0200 >>> @@ -3731,11 +3731,14 @@ >>> } else if (name == names._class) { >>> // In this case, we have already made sure in >>> // visitSelect that qualifier expression is a type. >>> - Type t = syms.classType; >>> - List typeargs = List.of(types.erasure(site)); >>> - t = new ClassType(t.getEnclosingType(), typeargs, >>> t.tsym); >>> - return new VarSymbol( >>> - STATIC | PUBLIC | FINAL, names._class, t, >>> site.tsym); >>> + return syms.classFields.computeIfAbsent( >>> + new Types.UniqueType(site, types), k -> { >>> + Type t = syms.classType; >>> + List typeargs = >>> List.of(types.erasure(site)); >>> + t = new ClassType(t.getEnclosingType(), >>> typeargs, t.tsym); >>> + return new VarSymbol( >>> + STATIC | PUBLIC | FINAL, >>> names._class, t, site.tsym); >>> + }); >>> } else { >>> // We are seeing a plain identifier as selector. >>> Symbol sym = rs.findIdentInType(env, site, name, >>> resultInfo.pkind); >>> @@ -3773,11 +3776,14 @@ >>> if (name == names._class) { >>> // In this case, we have already made sure in Select >>> that >>> // qualifier expression is a type. >>> - Type t = syms.classType; >>> - Type arg = types.boxedClass(site).type; >>> - t = new ClassType(t.getEnclosingType(), >>> List.of(arg), t.tsym); >>> - return new VarSymbol( >>> - STATIC | PUBLIC | FINAL, names._class, t, >>> site.tsym); >>> + return syms.classFields.computeIfAbsent( >>> + new Types.UniqueType(site, types), k -> { >>> + Type t = syms.classType; >>> + Type arg = types.boxedClass(site).type; >>> + t = new ClassType(t.getEnclosingType(), >>> List.of(arg), t.tsym); >>> + return new VarSymbol( >>> + STATIC | PUBLIC | FINAL, >>> names._class, t, site.tsym); >>> + }); >>> } else { >>> log.error(pos, Errors.CantDeref(site)); >>> return syms.errSymbol; >>> diff -r 8c85a1855e10 >>> test/langtools/tools/javac/lambda/deduplication/Deduplication.java >>> --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java >>> Fri Apr 13 11:14:49 2018 -0700 >>> +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java >>> Sun Apr 15 17:15:36 2018 +0200 >>> @@ -38,6 +38,21 @@ >>> (Runnable) () -> { ( (Runnable) () -> {} ).run(); } >>> ); >>> >>> + group( >>> + (Runnable) () -> { Deduplication.class.toString(); }, >>> + (Runnable) () -> { Deduplication.class.toString(); } >>> + ); >>> + >>> + group( >>> + (Runnable) () -> { Integer[].class.toString(); }, >>> + (Runnable) () -> { Integer[].class.toString(); } >>> + ); >>> + >>> + group( >>> + (Runnable) () -> { char.class.toString(); }, >>> + (Runnable) () -> { char.class.toString(); } >>> + ); >>> + >>> group((Function) x -> x.hashCode()); >>> group((Function) x -> x.hashCode()); >> From bsrbnd at gmail.com Mon Apr 16 22:28:23 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 17 Apr 2018 00:28:23 +0200 Subject: Equivalent .class fields should share the same symbol In-Reply-To: <5AD4E027.2040605@oracle.com> References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> <5AD4BB0C.2060402@oracle.com> <5AD4E027.2040605@oracle.com> Message-ID: On 16 April 2018 at 19:40, Jan Lahoda wrote: > On 16.4.2018 19:31, B. Blaser wrote: >> >> Hi Jan, >> >> On 16 April 2018 at 17:02, Jan Lahoda wrote: >>> >>> Hi Bernard, >>> >>> [...] >>> >>> -should there be a method in Symtab managing the map? Something like: >>> Symtab.getClassField(TypeSymbol tsym) {/*create the VarSymbol is >>> needed*/} >> >> >> I'll take a look if you think it's worth adding a method for this. > > > I think it would be nicer than maintaining the map from another class, if > possible/doable. > > Thanks, > Jan Here it is, javac tests are OK. Cheers, Bernard diff -r 8c85a1855e10 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java Fri Apr 13 11:14:49 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java Mon Apr 16 23:33:02 2018 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -51,6 +51,7 @@ import com.sun.tools.javac.code.Type.JCVoidType; import com.sun.tools.javac.code.Type.MethodType; import com.sun.tools.javac.code.Type.UnknownType; +import com.sun.tools.javac.code.Types.UniqueType; import com.sun.tools.javac.comp.Modules; import com.sun.tools.javac.util.Assert; import com.sun.tools.javac.util.Context; @@ -247,6 +248,26 @@ */ private final Map modules = new LinkedHashMap<>(); + private final Map classFields = new HashMap<>(); + + public VarSymbol getClassField(Type type, Types types) { + return classFields.computeIfAbsent( + new UniqueType(type, types), k -> { + Type arg = null; + if (type.getTag() == ARRAY || type.getTag() == CLASS) + arg = types.erasure(type); + else if (type.isPrimitiveOrVoid()) + arg = types.boxedClass(type).type; + else + throw new AssertionError(type); + + Type t = new ClassType( + classType.getEnclosingType(), List.of(arg), classType.tsym); + return new VarSymbol( + STATIC | PUBLIC | FINAL, names._class, t, type.tsym); + }); + } + public void initType(Type type, ClassSymbol c) { type.tsym = c; typeOfTag[type.getTag().ordinal()] = type; diff -r 8c85a1855e10 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Fri Apr 13 11:14:49 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Mon Apr 16 23:33:02 2018 +0200 @@ -3731,11 +3731,7 @@ } else if (name == names._class) { // In this case, we have already made sure in // visitSelect that qualifier expression is a type. - Type t = syms.classType; - List typeargs = List.of(types.erasure(site)); - t = new ClassType(t.getEnclosingType(), typeargs, t.tsym); - return new VarSymbol( - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); + return syms.getClassField(site, types); } else { // We are seeing a plain identifier as selector. Symbol sym = rs.findIdentInType(env, site, name, resultInfo.pkind); @@ -3773,11 +3769,7 @@ if (name == names._class) { // In this case, we have already made sure in Select that // qualifier expression is a type. - Type t = syms.classType; - Type arg = types.boxedClass(site).type; - t = new ClassType(t.getEnclosingType(), List.of(arg), t.tsym); - return new VarSymbol( - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); + return syms.getClassField(site, types); } else { log.error(pos, Errors.CantDeref(site)); return syms.errSymbol; diff -r 8c85a1855e10 test/langtools/tools/javac/lambda/deduplication/Deduplication.java --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java Fri Apr 13 11:14:49 2018 -0700 +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java Mon Apr 16 23:33:02 2018 +0200 @@ -38,6 +38,31 @@ (Runnable) () -> { ( (Runnable) () -> {} ).run(); } ); + group( + (Runnable) () -> { Deduplication.class.toString(); }, + (Runnable) () -> { Deduplication.class.toString(); } + ); + + group( + (Runnable) () -> { Integer[].class.toString(); }, + (Runnable) () -> { Integer[].class.toString(); } + ); + + group( + (Runnable) () -> { char.class.toString(); }, + (Runnable) () -> { char.class.toString(); } + ); + + group( + (Runnable) () -> { Void.class.toString(); }, + (Runnable) () -> { Void.class.toString(); } + ); + + group( + (Runnable) () -> { void.class.toString(); }, + (Runnable) () -> { void.class.toString(); } + ); + group((Function) x -> x.hashCode()); group((Function) x -> x.hashCode()); From cushon at google.com Tue Apr 17 18:50:07 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 17 Apr 2018 18:50:07 +0000 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 In-Reply-To: References: <5A998145.1050105@oracle.com> Message-ID: Hi Jan, Is this patch blocked on anything? I'm looking forward to back-porting it once it's finalized. On Fri, Mar 2, 2018 at 10:44 PM Liam Miller-Cushon wrote: > Hi Jan, > > >> Liam, could you please check if this helps with your real-world case? >> > > The numbers for the original compilation look great: > before: avg 299.9s, stddev 56.5s > after: avg 155.1s, stddev 24.8s > > That compilation is large and is less pathological than the repro in the > bug (it's not just doing import resolution), so it's not surprising that it > still takes some time. > > Thanks, > Liam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Mon Apr 23 08:31:19 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 23 Apr 2018 10:31:19 +0200 Subject: Equivalent .class fields should share the same symbol In-Reply-To: References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> <5AD4BB0C.2060402@oracle.com> <5AD4E027.2040605@oracle.com> Message-ID: Is there something left to do with this? Tier1 seems OK (jdk & langtools are successful and hotspot looks quite good modulo some unrelated issues on my system [1]). Thanks, Bernard [1] http://mail.openjdk.java.net/pipermail/amber-dev/2018-April/003031.html On 17 April 2018 at 00:28, B. Blaser wrote: > On 16 April 2018 at 19:40, Jan Lahoda wrote: >> On 16.4.2018 19:31, B. Blaser wrote: >>> >>> Hi Jan, >>> >>> On 16 April 2018 at 17:02, Jan Lahoda wrote: >>>> >>>> Hi Bernard, >>>> >>>> [...] >>>> >>>> -should there be a method in Symtab managing the map? Something like: >>>> Symtab.getClassField(TypeSymbol tsym) {/*create the VarSymbol is >>>> needed*/} >>> >>> >>> I'll take a look if you think it's worth adding a method for this. >> >> >> I think it would be nicer than maintaining the map from another class, if >> possible/doable. >> >> Thanks, >> Jan > > Here it is, javac tests are OK. > Cheers, > Bernard > > diff -r 8c85a1855e10 > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java > Mon Apr 16 23:33:02 2018 +0200 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -51,6 +51,7 @@ > import com.sun.tools.javac.code.Type.JCVoidType; > import com.sun.tools.javac.code.Type.MethodType; > import com.sun.tools.javac.code.Type.UnknownType; > +import com.sun.tools.javac.code.Types.UniqueType; > import com.sun.tools.javac.comp.Modules; > import com.sun.tools.javac.util.Assert; > import com.sun.tools.javac.util.Context; > @@ -247,6 +248,26 @@ > */ > private final Map modules = new LinkedHashMap<>(); > > + private final Map classFields = new > HashMap<>(); > + > + public VarSymbol getClassField(Type type, Types types) { > + return classFields.computeIfAbsent( > + new UniqueType(type, types), k -> { > + Type arg = null; > + if (type.getTag() == ARRAY || type.getTag() == CLASS) > + arg = types.erasure(type); > + else if (type.isPrimitiveOrVoid()) > + arg = types.boxedClass(type).type; > + else > + throw new AssertionError(type); > + > + Type t = new ClassType( > + classType.getEnclosingType(), List.of(arg), > classType.tsym); > + return new VarSymbol( > + STATIC | PUBLIC | FINAL, names._class, t, type.tsym); > + }); > + } > + > public void initType(Type type, ClassSymbol c) { > type.tsym = c; > typeOfTag[type.getTag().ordinal()] = type; > diff -r 8c85a1855e10 > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > Mon Apr 16 23:33:02 2018 +0200 > @@ -3731,11 +3731,7 @@ > } else if (name == names._class) { > // In this case, we have already made sure in > // visitSelect that qualifier expression is a type. > - Type t = syms.classType; > - List typeargs = List.of(types.erasure(site)); > - t = new ClassType(t.getEnclosingType(), typeargs, t.tsym); > - return new VarSymbol( > - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); > + return syms.getClassField(site, types); > } else { > // We are seeing a plain identifier as selector. > Symbol sym = rs.findIdentInType(env, site, name, > resultInfo.pkind); > @@ -3773,11 +3769,7 @@ > if (name == names._class) { > // In this case, we have already made sure in Select that > // qualifier expression is a type. > - Type t = syms.classType; > - Type arg = types.boxedClass(site).type; > - t = new ClassType(t.getEnclosingType(), > List.of(arg), t.tsym); > - return new VarSymbol( > - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); > + return syms.getClassField(site, types); > } else { > log.error(pos, Errors.CantDeref(site)); > return syms.errSymbol; > diff -r 8c85a1855e10 > test/langtools/tools/javac/lambda/deduplication/Deduplication.java > --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java > Fri Apr 13 11:14:49 2018 -0700 > +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java > Mon Apr 16 23:33:02 2018 +0200 > @@ -38,6 +38,31 @@ > (Runnable) () -> { ( (Runnable) () -> {} ).run(); } > ); > > + group( > + (Runnable) () -> { Deduplication.class.toString(); }, > + (Runnable) () -> { Deduplication.class.toString(); } > + ); > + > + group( > + (Runnable) () -> { Integer[].class.toString(); }, > + (Runnable) () -> { Integer[].class.toString(); } > + ); > + > + group( > + (Runnable) () -> { char.class.toString(); }, > + (Runnable) () -> { char.class.toString(); } > + ); > + > + group( > + (Runnable) () -> { Void.class.toString(); }, > + (Runnable) () -> { Void.class.toString(); } > + ); > + > + group( > + (Runnable) () -> { void.class.toString(); }, > + (Runnable) () -> { void.class.toString(); } > + ); > + > group((Function) x -> x.hashCode()); > group((Function) x -> x.hashCode()); From jan.lahoda at oracle.com Mon Apr 23 12:43:01 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 23 Apr 2018 14:43:01 +0200 Subject: Equivalent .class fields should share the same symbol In-Reply-To: References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> <5AD4BB0C.2060402@oracle.com> <5AD4E027.2040605@oracle.com> Message-ID: <5ADDD4D5.3070607@oracle.com> I think the patch itself is OK, but I concur with Vicente that we may want focused testing. I've put the patch here: http://cr.openjdk.java.net/~jlahoda/8202141/webrev.00/ And added a test that does not depend on the lambda deduplication. Vicente, what do you think? Thanks, Jan On 23.4.2018 10:31, B. Blaser wrote: > Is there something left to do with this? > Tier1 seems OK (jdk & langtools are successful and hotspot looks quite > good modulo some unrelated issues on my system [1]). > > Thanks, > Bernard > > [1] http://mail.openjdk.java.net/pipermail/amber-dev/2018-April/003031.html > > On 17 April 2018 at 00:28, B. Blaser wrote: >> On 16 April 2018 at 19:40, Jan Lahoda wrote: >>> On 16.4.2018 19:31, B. Blaser wrote: >>>> >>>> Hi Jan, >>>> >>>> On 16 April 2018 at 17:02, Jan Lahoda wrote: >>>>> >>>>> Hi Bernard, >>>>> >>>>> [...] >>>>> >>>>> -should there be a method in Symtab managing the map? Something like: >>>>> Symtab.getClassField(TypeSymbol tsym) {/*create the VarSymbol is >>>>> needed*/} >>>> >>>> >>>> I'll take a look if you think it's worth adding a method for this. >>> >>> >>> I think it would be nicer than maintaining the map from another class, if >>> possible/doable. >>> >>> Thanks, >>> Jan >> >> Here it is, javac tests are OK. >> Cheers, >> Bernard >> >> diff -r 8c85a1855e10 >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >> Fri Apr 13 11:14:49 2018 -0700 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >> Mon Apr 16 23:33:02 2018 +0200 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1999, 2017, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -51,6 +51,7 @@ >> import com.sun.tools.javac.code.Type.JCVoidType; >> import com.sun.tools.javac.code.Type.MethodType; >> import com.sun.tools.javac.code.Type.UnknownType; >> +import com.sun.tools.javac.code.Types.UniqueType; >> import com.sun.tools.javac.comp.Modules; >> import com.sun.tools.javac.util.Assert; >> import com.sun.tools.javac.util.Context; >> @@ -247,6 +248,26 @@ >> */ >> private final Map modules = new LinkedHashMap<>(); >> >> + private final Map classFields = new >> HashMap<>(); >> + >> + public VarSymbol getClassField(Type type, Types types) { >> + return classFields.computeIfAbsent( >> + new UniqueType(type, types), k -> { >> + Type arg = null; >> + if (type.getTag() == ARRAY || type.getTag() == CLASS) >> + arg = types.erasure(type); >> + else if (type.isPrimitiveOrVoid()) >> + arg = types.boxedClass(type).type; >> + else >> + throw new AssertionError(type); >> + >> + Type t = new ClassType( >> + classType.getEnclosingType(), List.of(arg), >> classType.tsym); >> + return new VarSymbol( >> + STATIC | PUBLIC | FINAL, names._class, t, type.tsym); >> + }); >> + } >> + >> public void initType(Type type, ClassSymbol c) { >> type.tsym = c; >> typeOfTag[type.getTag().ordinal()] = type; >> diff -r 8c85a1855e10 >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >> Fri Apr 13 11:14:49 2018 -0700 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >> Mon Apr 16 23:33:02 2018 +0200 >> @@ -3731,11 +3731,7 @@ >> } else if (name == names._class) { >> // In this case, we have already made sure in >> // visitSelect that qualifier expression is a type. >> - Type t = syms.classType; >> - List typeargs = List.of(types.erasure(site)); >> - t = new ClassType(t.getEnclosingType(), typeargs, t.tsym); >> - return new VarSymbol( >> - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); >> + return syms.getClassField(site, types); >> } else { >> // We are seeing a plain identifier as selector. >> Symbol sym = rs.findIdentInType(env, site, name, >> resultInfo.pkind); >> @@ -3773,11 +3769,7 @@ >> if (name == names._class) { >> // In this case, we have already made sure in Select that >> // qualifier expression is a type. >> - Type t = syms.classType; >> - Type arg = types.boxedClass(site).type; >> - t = new ClassType(t.getEnclosingType(), >> List.of(arg), t.tsym); >> - return new VarSymbol( >> - STATIC | PUBLIC | FINAL, names._class, t, site.tsym); >> + return syms.getClassField(site, types); >> } else { >> log.error(pos, Errors.CantDeref(site)); >> return syms.errSymbol; >> diff -r 8c85a1855e10 >> test/langtools/tools/javac/lambda/deduplication/Deduplication.java >> --- a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java >> Fri Apr 13 11:14:49 2018 -0700 >> +++ b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java >> Mon Apr 16 23:33:02 2018 +0200 >> @@ -38,6 +38,31 @@ >> (Runnable) () -> { ( (Runnable) () -> {} ).run(); } >> ); >> >> + group( >> + (Runnable) () -> { Deduplication.class.toString(); }, >> + (Runnable) () -> { Deduplication.class.toString(); } >> + ); >> + >> + group( >> + (Runnable) () -> { Integer[].class.toString(); }, >> + (Runnable) () -> { Integer[].class.toString(); } >> + ); >> + >> + group( >> + (Runnable) () -> { char.class.toString(); }, >> + (Runnable) () -> { char.class.toString(); } >> + ); >> + >> + group( >> + (Runnable) () -> { Void.class.toString(); }, >> + (Runnable) () -> { Void.class.toString(); } >> + ); >> + >> + group( >> + (Runnable) () -> { void.class.toString(); }, >> + (Runnable) () -> { void.class.toString(); } >> + ); >> + >> group((Function) x -> x.hashCode()); >> group((Function) x -> x.hashCode()); From vicente.romero at oracle.com Mon Apr 23 14:11:53 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 23 Apr 2018 10:11:53 -0400 Subject: Equivalent .class fields should share the same symbol In-Reply-To: <5ADDD4D5.3070607@oracle.com> References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> <5AD4BB0C.2060402@oracle.com> <5AD4E027.2040605@oracle.com> <5ADDD4D5.3070607@oracle.com> Message-ID: On 04/23/2018 08:43 AM, Jan Lahoda wrote: > I think the patch itself is OK, but I concur with Vicente that we may > want focused testing. I've put the patch here: > http://cr.openjdk.java.net/~jlahoda/8202141/webrev.00/ > > And added a test that does not depend on the lambda deduplication. > > Vicente, what do you think? looks good to me, > > Thanks, > ?? Jan Thanks! Vicente > > On 23.4.2018 10:31, B. Blaser wrote: >> Is there something left to do with this? >> Tier1 seems OK (jdk & langtools are successful and hotspot looks quite >> good modulo some unrelated issues on my system [1]). >> >> Thanks, >> Bernard >> >> [1] >> http://mail.openjdk.java.net/pipermail/amber-dev/2018-April/003031.html >> >> On 17 April 2018 at 00:28, B. Blaser wrote: >>> On 16 April 2018 at 19:40, Jan Lahoda wrote: >>>> On 16.4.2018 19:31, B. Blaser wrote: >>>>> >>>>> Hi Jan, >>>>> >>>>> On 16 April 2018 at 17:02, Jan Lahoda wrote: >>>>>> >>>>>> Hi Bernard, >>>>>> >>>>>> [...] >>>>>> >>>>>> -should there be a method in Symtab managing the map? Something >>>>>> like: >>>>>> Symtab.getClassField(TypeSymbol tsym) {/*create the VarSymbol is >>>>>> needed*/} >>>>> >>>>> >>>>> I'll take a look if you think it's worth adding a method for this. >>>> >>>> >>>> I think it would be nicer than maintaining the map from another >>>> class, if >>>> possible/doable. >>>> >>>> Thanks, >>>> ???? Jan >>> >>> Here it is, javac tests are OK. >>> Cheers, >>> Bernard >>> >>> diff -r 8c85a1855e10 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >>> --- >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >>> Fri Apr 13 11:14:49 2018 -0700 >>> +++ >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java >>> Mon Apr 16 23:33:02 2018 +0200 >>> @@ -1,5 +1,5 @@ >>> ? /* >>> - * Copyright (c) 1999, 2017, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All >>> rights reserved. >>> ?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> ?? * >>> ?? * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -51,6 +51,7 @@ >>> ? import com.sun.tools.javac.code.Type.JCVoidType; >>> ? import com.sun.tools.javac.code.Type.MethodType; >>> ? import com.sun.tools.javac.code.Type.UnknownType; >>> +import com.sun.tools.javac.code.Types.UniqueType; >>> ? import com.sun.tools.javac.comp.Modules; >>> ? import com.sun.tools.javac.util.Assert; >>> ? import com.sun.tools.javac.util.Context; >>> @@ -247,6 +248,26 @@ >>> ?????? */ >>> ????? private final Map modules = new >>> LinkedHashMap<>(); >>> >>> +??? private final Map classFields = new >>> HashMap<>(); >>> + >>> +??? public VarSymbol getClassField(Type type, Types types) { >>> +??????? return classFields.computeIfAbsent( >>> +??????????? new UniqueType(type, types), k -> { >>> +??????????????? Type arg = null; >>> +??????????????? if (type.getTag() == ARRAY || type.getTag() == CLASS) >>> +??????????????????? arg = types.erasure(type); >>> +??????????????? else if (type.isPrimitiveOrVoid()) >>> +??????????????????? arg = types.boxedClass(type).type; >>> +??????????????? else >>> +??????????????????? throw new AssertionError(type); >>> + >>> +??????????????? Type t = new ClassType( >>> +??????????????????? classType.getEnclosingType(), List.of(arg), >>> classType.tsym); >>> +??????????????? return new VarSymbol( >>> +??????????????????? STATIC | PUBLIC | FINAL, names._class, t, >>> type.tsym); >>> +??????????? }); >>> +??? } >>> + >>> ????? public void initType(Type type, ClassSymbol c) { >>> ????????? type.tsym = c; >>> ????????? typeOfTag[type.getTag().ordinal()] = type; >>> diff -r 8c85a1855e10 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >>> Fri Apr 13 11:14:49 2018 -0700 >>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java >>> Mon Apr 16 23:33:02 2018 +0200 >>> @@ -3731,11 +3731,7 @@ >>> ????????????????? } else if (name == names._class) { >>> ????????????????????? // In this case, we have already made sure in >>> ????????????????????? // visitSelect that qualifier expression is a >>> type. >>> -??????????????????? Type t = syms.classType; >>> -??????????????????? List typeargs = >>> List.of(types.erasure(site)); >>> -??????????????????? t = new ClassType(t.getEnclosingType(), >>> typeargs, t.tsym); >>> -??????????????????? return new VarSymbol( >>> -??????????????????????? STATIC | PUBLIC | FINAL, names._class, t, >>> site.tsym); >>> +??????????????????? return syms.getClassField(site, types); >>> ????????????????? } else { >>> ????????????????????? // We are seeing a plain identifier as selector. >>> ????????????????????? Symbol sym = rs.findIdentInType(env, site, name, >>> resultInfo.pkind); >>> @@ -3773,11 +3769,7 @@ >>> ????????????????? if (name == names._class) { >>> ????????????????????? // In this case, we have already made sure in >>> Select that >>> ????????????????????? // qualifier expression is a type. >>> -??????????????????? Type t = syms.classType; >>> -??????????????????? Type arg = types.boxedClass(site).type; >>> -??????????????????? t = new ClassType(t.getEnclosingType(), >>> List.of(arg), t.tsym); >>> -??????????????????? return new VarSymbol( >>> -??????????????????????? STATIC | PUBLIC | FINAL, names._class, t, >>> site.tsym); >>> +??????????????????? return syms.getClassField(site, types); >>> ????????????????? } else { >>> ????????????????????? log.error(pos, Errors.CantDeref(site)); >>> ????????????????????? return syms.errSymbol; >>> diff -r 8c85a1855e10 >>> test/langtools/tools/javac/lambda/deduplication/Deduplication.java >>> --- >>> a/test/langtools/tools/javac/lambda/deduplication/Deduplication.java >>> Fri Apr 13 11:14:49 2018 -0700 >>> +++ >>> b/test/langtools/tools/javac/lambda/deduplication/Deduplication.java >>> Mon Apr 16 23:33:02 2018 +0200 >>> @@ -38,6 +38,31 @@ >>> ????????????????? (Runnable) () -> { ( (Runnable) () -> {} ).run(); } >>> ????????? ); >>> >>> +??????? group( >>> +??????????????? (Runnable) () -> { Deduplication.class.toString(); }, >>> +??????????????? (Runnable) () -> { Deduplication.class.toString(); } >>> +??????? ); >>> + >>> +??????? group( >>> +??????????????? (Runnable) () -> { Integer[].class.toString(); }, >>> +??????????????? (Runnable) () -> { Integer[].class.toString(); } >>> +??????? ); >>> + >>> +??????? group( >>> +??????????????? (Runnable) () -> { char.class.toString(); }, >>> +??????????????? (Runnable) () -> { char.class.toString(); } >>> +??????? ); >>> + >>> +??????? group( >>> +??????????????? (Runnable) () -> { Void.class.toString(); }, >>> +??????????????? (Runnable) () -> { Void.class.toString(); } >>> +??????? ); >>> + >>> +??????? group( >>> +??????????????? (Runnable) () -> { void.class.toString(); }, >>> +??????????????? (Runnable) () -> { void.class.toString(); } >>> +??????? ); >>> + >>> ????????? group((Function) x -> x.hashCode()); >>> ????????? group((Function) x -> x.hashCode()); From bsrbnd at gmail.com Mon Apr 23 16:16:38 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 23 Apr 2018 18:16:38 +0200 Subject: Equivalent .class fields should share the same symbol In-Reply-To: References: <375838908.2693906.1523795518957.JavaMail.zimbra@u-pem.fr> <5AD4BB0C.2060402@oracle.com> <5AD4E027.2040605@oracle.com> <5ADDD4D5.3070607@oracle.com> Message-ID: On 23 April 2018 at 16:11, Vicente Romero wrote: > On 04/23/2018 08:43 AM, Jan Lahoda wrote: >> >> I think the patch itself is OK, but I concur with Vicente that we may want >> focused testing. I've put the patch here: >> http://cr.openjdk.java.net/~jlahoda/8202141/webrev.00/ >> >> And added a test that does not depend on the lambda deduplication. >> >> Vicente, what do you think? > > > looks good to me, looks good to me too! Thanks, Bernard >> Thanks, >> Jan > > > Thanks! > Vicente From daniel.smith at oracle.com Tue Apr 24 20:44:35 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 24 Apr 2018 14:44:35 -0600 Subject: Call for Speakers -- 2018 JVM Language Summit Message-ID: CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, JULY 30-AUGUST 1, 2018 We are pleased to announce the 2018 JVM Language Summit to be held at Oracle?s Santa Clara campus on July 30-August 1, 2018. Registration is now open for speaker submissions and will remain open through May 25. There is no registration fee for speakers. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. The schedule consists of a single track of traditional presentations (about 6 each day) interspersed with less-formal multi-track "workshop" discussion groups (2?4 each day) and, possibly, impromptu "lightning talks." Workshops are open discussions with only a small amount of prepared material. We ask each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. Instructions for Speaker Registration If you?d like give a presentation, please register as "Speaker" or "Speaker (Oracle)" (the latter for Oracle employees) and include a detailed abstract. There is no fee. See below for help preparing your abstract and talk. You will be notified about whether your proposal has been accepted; if not, you will be able to register as a regular attendee. For a successful speaker submission, please note the following: - All talks should be deeply technical, given by designers and implementors to designers and implementors. We all speak bytecode here! - Each talk, we hope and expect, will inform the audience, in detail, about the state of the art of language design or implementation on the JVM, or will explore the present and future capabilities of the JVM itself. (Some will do so indirectly by discussing non-JVM technologies.) - Know your audience: attendees may not be likely to ever use your specific language or tool, but could learn something from your interactions with the JVM. A broad goal of the summit is to inspire collaboration on JVM-based technologies that enable a rich ecosystem at higher layers. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2018 at jvmlangsummit.com From jonathan.gibbons at oracle.com Wed Apr 25 00:53:11 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Apr 2018 17:53:11 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com> Message-ID: <5ADFD177.7050600@oracle.com> On 04/12/2018 10:20 PM, mandy chung wrote: > > > On 4/13/18 4:15 AM, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> * The part to handle the new command-line options is in the native >> Java launcher code. >> * The part to invoke the compiler and subsequently execute the code >> found in the source file is in a new class in the jdk.compiler >> module. >> * There are some minor Makefile changes, to add support for a new >> resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > This looks quite good to me. One small comment on the source launcher > Main class: > > 122 } catch (InvocationTargetException e) { > 123 // leave VM to handle the stacktrace, in the standard manner > 124 throw e.getTargetException(); > 125 } > 387 } catch (InvocationTargetException e) { > 388 // remove stack frames for source launcher > 389 int invocationFrames = e.getStackTrace().length; > 390 Throwable target = e.getTargetException(); > 391 StackTraceElement[] targetTrace = target.getStackTrace(); > 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); > 393 throw e; > 394 } > > This could simply throw target instead of the InvocationTargetException > and then the main method can propagate the target, if thrown. > > Mandy Mandy, Yes, but that would require the execute method and its callers to declare that they throw Throwable, or at least Exception. Since the exception is already wrapped, it seems better to propagate the wrapped exception, and to only unwrap it at the last moment. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Apr 25 03:37:31 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 25 Apr 2018 11:37:31 +0800 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ADFD177.7050600@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com> <5ADFD177.7050600@oracle.com> Message-ID: <5b920f09-11e3-1a95-56d6-7daf66db0a91@oracle.com> On 4/25/18 8:53 AM, Jonathan Gibbons wrote: > > > On 04/12/2018 10:20 PM, mandy chung wrote: > >> >> This looks quite good to me.? One small comment on the source >> launcher Main class: >> >> 122 } catch (InvocationTargetException e) { >> 123 // leave VM to handle the stacktrace, in the standard manner >> 124 throw e.getTargetException(); >> 125 } >> 387 } catch (InvocationTargetException e) { >> 388 // remove stack frames for source launcher >> 389 int invocationFrames = e.getStackTrace().length; >> 390 Throwable target = e.getTargetException(); >> 391 StackTraceElement[] targetTrace = target.getStackTrace(); >> 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); >> 393 throw e; >> 394 } >> >> This could simply throw target instead of the InvocationTargetException >> and then the main method can propagate the target, if thrown. >> >> Mandy > > Mandy, > > Yes, but that would require the execute method and its callers to > declare that they throw Throwable, > or at least Exception. Since the exception is already wrapped, it > seems better to propagate the > wrapped exception, and to only unwrap it at the last moment. > Either way works for me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.x.srinivasan at oracle.com Wed Apr 25 16:38:32 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 25 Apr 2018 09:38:32 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <5AE0AF08.10105@oracle.com> Hi John, I focused mainly on the native side, looks ok, except for a couple of minor issues. java.c 1320 const char *prop = "-Djdk.internal.javac.source="; 1321 size_t size = JLI_StrLen(prop) + JLI_StrLen(value) + 1; 1322 char *propValue = (char *)JLI_MemAlloc(size + 1); I think we are allocating extra byte ^^^^^^^ 1323 JLI_StrCpy(propValue, prop); 1324 JLI_StrCat(propValue, value); I think we can do this, safer and neater, as follows: size_t size = JLI_StrLen(prop) + JLI_StrLen(value); char *propValue = (char *)JLI_MemAlloc(size + 1); JLI_Snprintf(propValue, size, "%s%s", prop, value); 1483 if (mode == LM_SOURCE) { 1484 AddOption("--add-modules=ALL-DEFAULT", NULL); 1485 *pwhat = SOURCE_LAUNCHER_MAIN_ENTRY; 1486 *pargc = argc + 1; 1487 *pargv = argv - 1; A short comment perhaps ? why we are incrementing argc, and decrementing argv, saves some head scratching for a casual reader. I looked at the launcher tests, very nice. Thanks Kumar On 4/12/2018 1:15 PM, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Apr 25 17:58:31 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Apr 2018 10:58:31 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5AE0AF08.10105@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <5AE0AF08.10105@oracle.com> Message-ID: <5AE0C1C7.5010300@oracle.com> Kumar, Thank you for your feedback; I will incorporate it in the next webrev. -- Jon On 04/25/2018 09:38 AM, Kumar Srinivasan wrote: > Hi John, > > I focused mainly on the native side, looks ok, except for a couple of > minor issues. > > java.c > 1320 const char *prop = "-Djdk.internal.javac.source="; > 1321 size_t size = JLI_StrLen(prop) + JLI_StrLen(value) + 1; > 1322 char *propValue = (char *)JLI_MemAlloc(size + 1); > > I think we are allocating extra byte ^^^^^^^ > > 1323 JLI_StrCpy(propValue, prop); > 1324 JLI_StrCat(propValue, value); > > I think we can do this, safer and neater, as follows: > > size_t size = JLI_StrLen(prop) + JLI_StrLen(value); > char *propValue = (char *)JLI_MemAlloc(size + 1); > JLI_Snprintf(propValue, size, "%s%s", prop, value); > 1483 if (mode == LM_SOURCE) { > 1484 AddOption("--add-modules=ALL-DEFAULT", NULL); > 1485 *pwhat = SOURCE_LAUNCHER_MAIN_ENTRY; > 1486 *pargc = argc + 1; > 1487 *pargv = argv - 1; > > A short comment perhaps ? why we are incrementing argc, and > decrementing argv, > saves some head scratching for a casual reader. > > I looked at the launcher tests, very nice. > > > Thanks > Kumar > > > > > > On 4/12/2018 1:15 PM, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> * The part to handle the new command-line options is in the native >> Java launcher code. >> * The part to invoke the compiler and subsequently execute the code >> found in the source file is in a new class in the jdk.compiler >> module. >> * There are some minor Makefile changes, to add support for a new >> resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >> >> -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Apr 26 17:50:16 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 26 Apr 2018 10:50:16 -0700 Subject: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 Message-ID: <4f63e470-be02-0def-e93b-eea8f9f9fe79@oracle.com> Hello, Please review the webrev and CSR for 8202334: "Update javax.lang.model.util visitors for 11": ??? http://cr.openjdk.java.net/~darcy/8202334.0/ ??? https://bugs.openjdk.java.net/browse/JDK-8202335 From the CSR: > The `javax.lang.model` API was added in Java SE 6. In each of Java SE > 7, 8, and 9, new sets of utility visitors were added for each release, > for example starting with `AbstractElementVisitor6`, types > `AbstractElementVisitor7`, `AbstractElementVisitor8`, > `AbstractElementVisitor8` were added in SE 7 and 8, respectively. > Similar patterns were followed for `ElementKindVisitor6`, and the rest > of the utility visitors. > > In Java SE 10, there were no language changes requiring new > operational behavior from the root visitors. Therefore, rather than > introducing yet another slate of visitor classes, the 9-era visitors > were updated to indicate they are appropriate for 10 as well > (CCC-8193194). > > In the absence of language changes in 11 which would require new > operational behavior from the visitors, the 9-era visitors should be > updated to indicate they are appropriate for releases 9 through 11. > > Solution > -------- > Update the specification and `SupportedSourceVersion` annotations on > the 9-era visitor classes to indicate they are appropriate for release 11. Thanks, -Joe From forax at univ-mlv.fr Thu Apr 26 18:13:23 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 26 Apr 2018 20:13:23 +0200 (CEST) Subject: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 In-Reply-To: <4f63e470-be02-0def-e93b-eea8f9f9fe79@oracle.com> References: <4f63e470-be02-0def-e93b-eea8f9f9fe79@oracle.com> Message-ID: <903749401.1665594.1524766403234.JavaMail.zimbra@u-pem.fr> Hi Joe, As a side effect, it means that raw string literal will not appear in 11, which is totally fine given a lot of things are still moving. I've another question, with my ASM hat becaus we have the same issue with ASM API, how do you plan to introduce preview features in the Visitor API ? As a separate interface, as a normal feature, as something else ? R?mi ----- Mail original ----- > De: "joe darcy" > ?: "compiler-dev" > Envoy?: Jeudi 26 Avril 2018 19:50:16 > Objet: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 > Hello, > > Please review the webrev and CSR for 8202334: "Update > javax.lang.model.util visitors for 11": > > ??? http://cr.openjdk.java.net/~darcy/8202334.0/ > ??? https://bugs.openjdk.java.net/browse/JDK-8202335 > > From the CSR: > >> The `javax.lang.model` API was added in Java SE 6. In each of Java SE >> 7, 8, and 9, new sets of utility visitors were added for each release, >> for example starting with `AbstractElementVisitor6`, types >> `AbstractElementVisitor7`, `AbstractElementVisitor8`, >> `AbstractElementVisitor8` were added in SE 7 and 8, respectively. >> Similar patterns were followed for `ElementKindVisitor6`, and the rest >> of the utility visitors. >> >> In Java SE 10, there were no language changes requiring new >> operational behavior from the root visitors. Therefore, rather than >> introducing yet another slate of visitor classes, the 9-era visitors >> were updated to indicate they are appropriate for 10 as well >> (CCC-8193194). >> >> In the absence of language changes in 11 which would require new >> operational behavior from the visitors, the 9-era visitors should be >> updated to indicate they are appropriate for releases 9 through 11. >> >> Solution >> -------- >> Update the specification and `SupportedSourceVersion` annotations on >> the 9-era visitor classes to indicate they are appropriate for release 11. > > Thanks, > > -Joe From joe.darcy at oracle.com Fri Apr 27 00:15:27 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 26 Apr 2018 17:15:27 -0700 Subject: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 In-Reply-To: <903749401.1665594.1524766403234.JavaMail.zimbra@u-pem.fr> References: <4f63e470-be02-0def-e93b-eea8f9f9fe79@oracle.com> <903749401.1665594.1524766403234.JavaMail.zimbra@u-pem.fr> Message-ID: <5802c84e-52eb-78a1-a401-c4fcc364109e@oracle.com> Hi Remi, On 4/26/2018 11:13 AM, Remi Forax wrote: > Hi Joe, > As a side effect, it means that raw string literal will not appear in 11, which is totally fine given a lot of things are still moving. I wouldn't necessary conclude that. The string literals could be able to be supported without changes in the modeling API, which doesn't cover method bodies. Many language changes do not require updates to javax.lang.model. For example Project Coin's binary literals and underscores in literals didn't lead to any language changes and neither did "var". > > I've another question, with my ASM hat becaus we have the same issue with ASM API, how do you plan to introduce preview features in the Visitor API ? As a separate interface, as a normal feature, as something else ? We've discussed this a bit in the context of JEP 12: Preview Language and VM Features. The JEP currently proposes terminal deprecation for API elements added solely to support preview features. HTH, -Joe > > R?mi > > ----- Mail original ----- >> De: "joe darcy" >> ?: "compiler-dev" >> Envoy?: Jeudi 26 Avril 2018 19:50:16 >> Objet: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 >> Hello, >> >> Please review the webrev and CSR for 8202334: "Update >> javax.lang.model.util visitors for 11": >> >> ??? http://cr.openjdk.java.net/~darcy/8202334.0/ >> ??? https://bugs.openjdk.java.net/browse/JDK-8202335 >> >> From the CSR: >> >>> The `javax.lang.model` API was added in Java SE 6. In each of Java SE >>> 7, 8, and 9, new sets of utility visitors were added for each release, >>> for example starting with `AbstractElementVisitor6`, types >>> `AbstractElementVisitor7`, `AbstractElementVisitor8`, >>> `AbstractElementVisitor8` were added in SE 7 and 8, respectively. >>> Similar patterns were followed for `ElementKindVisitor6`, and the rest >>> of the utility visitors. >>> >>> In Java SE 10, there were no language changes requiring new >>> operational behavior from the root visitors. Therefore, rather than >>> introducing yet another slate of visitor classes, the 9-era visitors >>> were updated to indicate they are appropriate for 10 as well >>> (CCC-8193194). >>> >>> In the absence of language changes in 11 which would require new >>> operational behavior from the visitors, the 9-era visitors should be >>> updated to indicate they are appropriate for releases 9 through 11. >>> >>> Solution >>> -------- >>> Update the specification and `SupportedSourceVersion` annotations on >>> the 9-era visitor classes to indicate they are appropriate for release 11. >> Thanks, >> >> -Joe From forax at univ-mlv.fr Fri Apr 27 11:20:03 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 27 Apr 2018 13:20:03 +0200 (CEST) Subject: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 In-Reply-To: <5802c84e-52eb-78a1-a401-c4fcc364109e@oracle.com> References: <4f63e470-be02-0def-e93b-eea8f9f9fe79@oracle.com> <903749401.1665594.1524766403234.JavaMail.zimbra@u-pem.fr> <5802c84e-52eb-78a1-a401-c4fcc364109e@oracle.com> Message-ID: <258250905.1987030.1524828003870.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "joe darcy" > ?: "Remi Forax" > Cc: "compiler-dev" > Envoy?: Vendredi 27 Avril 2018 02:15:27 > Objet: Re: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 > Hi Remi, > > On 4/26/2018 11:13 AM, Remi Forax wrote: >> Hi Joe, >> As a side effect, it means that raw string literal will not appear in 11, which >> is totally fine given a lot of things are still moving. > > I wouldn't necessary conclude that. The string literals could be able to > be supported without changes in the modeling API, which doesn't cover > method bodies. yes, right, forget that > > Many language changes do not require updates to javax.lang.model. For > example Project Coin's binary literals and underscores in literals > didn't lead to any language changes and neither did "var". > >> >> I've another question, with my ASM hat becaus we have the same issue with ASM >> API, how do you plan to introduce preview features in the Visitor API ? As a >> separate interface, as a normal feature, as something else ? > > We've discussed this a bit in the context of JEP 12: Preview Language > and VM Features. > > The JEP currently proposes terminal deprecation for API elements added > solely to support preview features. We doing that, add @Deprecated and we also suffix every method/field name with experimental, thus even if the method is promoted to be a real one in the next release, we allow the semantics to slightly change (because it's not the same method). In term of warning, i think we should have a way to say that this @Deprecated is not exactly the same as the other @Deprecated(forRemoval=true) because you can not take action now and replace with another API, you have to wait the next release to do something. > > HTH, > > -Joe R?mi >> >> ----- Mail original ----- >>> De: "joe darcy" >>> ?: "compiler-dev" >>> Envoy?: Jeudi 26 Avril 2018 19:50:16 >>> Objet: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 >>> Hello, >>> >>> Please review the webrev and CSR for 8202334: "Update >>> javax.lang.model.util visitors for 11": >>> >>> ??? http://cr.openjdk.java.net/~darcy/8202334.0/ >>> ??? https://bugs.openjdk.java.net/browse/JDK-8202335 >>> >>> From the CSR: >>> >>>> The `javax.lang.model` API was added in Java SE 6. In each of Java SE >>>> 7, 8, and 9, new sets of utility visitors were added for each release, >>>> for example starting with `AbstractElementVisitor6`, types >>>> `AbstractElementVisitor7`, `AbstractElementVisitor8`, >>>> `AbstractElementVisitor8` were added in SE 7 and 8, respectively. >>>> Similar patterns were followed for `ElementKindVisitor6`, and the rest >>>> of the utility visitors. >>>> >>>> In Java SE 10, there were no language changes requiring new >>>> operational behavior from the root visitors. Therefore, rather than >>>> introducing yet another slate of visitor classes, the 9-era visitors >>>> were updated to indicate they are appropriate for 10 as well >>>> (CCC-8193194). >>>> >>>> In the absence of language changes in 11 which would require new >>>> operational behavior from the visitors, the 9-era visitors should be >>>> updated to indicate they are appropriate for releases 9 through 11. >>>> >>>> Solution >>>> -------- >>>> Update the specification and `SupportedSourceVersion` annotations on >>>> the 9-era visitor classes to indicate they are appropriate for release 11. >>> Thanks, >>> > >> -Joe From sven.reimers at gmail.com Fri Apr 27 13:01:35 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 27 Apr 2018 15:01:35 +0200 Subject: Misleading compile error - regression Message-ID: Hi all, using a compiler from 9, 10, 11 the following code package issue; public class A { public static interface I { public void m(String s); } public void add (I i) {} public static void main(String[] args) { A a = new A(); a.add(() -> {}); } } results in ... issue/A.java:2: error: incompatible types: incompatible parameter types in lambda expression public class A { Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output 1 error With -Xdiags:verbose the message is correct ... issue/A.java:12: error: method add in class A cannot be applied to given types; a.add(() -> {}); required: I found: ()->{ } reason: argument mismatch; incompatible parameter types in lambda expression 1 error -> Look at the difference in the line number. Using JDK 8 everything works as expected (correct line number without -Xdiags:verbose). I assume this is not the desired behavior. Is this already known? Any issue in JBS already? Thanks Sven -- Sven Reimers * Senior Expert Software Architect * Java Champion -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Apr 27 13:10:01 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 27 Apr 2018 14:10:01 +0100 Subject: Misleading compile error - regression In-Reply-To: References: Message-ID: Thanks for the report - I have not seen this before; I filed this: https://bugs.openjdk.java.net/browse/JDK-8202372 I've noted that if the lambda expression is changed to contain e.g. too many args, the diag position issue is fixed. Maurizio On 27/04/18 14:01, Sven Reimers wrote: > Hi all, > > using a compiler from 9, 10, 11 the following code > > package issue; > public class A { > > ? ? public static interface I { > ? ? ? ? public void m(String s); > ? ? } > ? ? public void add (I i) {} > ? ? public static void main(String[] args) { > ? ? ? ? A a = new A(); > ? ? ? ? a.add(() -> {}); > ? ? } > } > > results in > > ... issue/A.java:2: error: incompatible types: incompatible parameter > types in lambda expression > public class A { > Note: Some messages have been simplified; recompile with > -Xdiags:verbose to get full output > 1 error > > With -Xdiags:verbose the message is correct > > ... issue/A.java:12: error: method add in class A cannot be applied to > given types; > ? ? ? ? a.add(() -> {}); > ? required: I > ? found: ()->{ } > ? reason: argument mismatch; incompatible parameter types in lambda > expression > 1 error > > -> Look at the difference in the line number. > > Using JDK 8 everything works as expected (correct line number without > -Xdiags:verbose). > > I assume this is not the desired behavior. > > Is this already known? Any issue in JBS already? > > Thanks > > Sven > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sun Apr 29 11:55:06 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 29 Apr 2018 13:55:06 +0200 Subject: Misleading compile error - regression In-Reply-To: References: Message-ID: Hi, It looks like a missing 'make.at()' in DeferredAttr::attribSpeculativeLambda, as next. Tier1 seems OK. What do you think? Thanks, Bernard diff -r 1871c5d07caf src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java Fri Apr 27 15:55:29 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java Sun Apr 29 13:34:13 2018 +0200 @@ -441,7 +441,7 @@ } else { stats.add((JCBlock)that.body); } - JCBlock lambdaBlock = make.Block(0, stats.toList()); + JCBlock lambdaBlock = make.at(that).Block(0, stats.toList()); Env localEnv = attr.lambdaEnv(that, env); try { localEnv.info.returnResult = resultInfo; On 27 April 2018 at 15:10, Maurizio Cimadamore wrote: > Thanks for the report - I have not seen this before; I filed this: > > https://bugs.openjdk.java.net/browse/JDK-8202372 > > I've noted that if the lambda expression is changed to contain e.g. too many > args, the diag position issue is fixed. > > Maurizio > > > On 27/04/18 14:01, Sven Reimers wrote: > > Hi all, > > using a compiler from 9, 10, 11 the following code > > package issue; > public class A { > > public static interface I { > public void m(String s); > } > > public void add (I i) {} > > public static void main(String[] args) { > A a = new A(); > a.add(() -> {}); > } > } > > results in > > ... issue/A.java:2: error: incompatible types: incompatible parameter types > in lambda expression > public class A { > Note: Some messages have been simplified; recompile with -Xdiags:verbose to > get full output > 1 error > > With -Xdiags:verbose the message is correct > > ... issue/A.java:12: error: method add in class A cannot be applied to given > types; > a.add(() -> {}); > required: I > found: ()->{ } > reason: argument mismatch; incompatible parameter types in lambda > expression > 1 error > > -> Look at the difference in the line number. > > Using JDK 8 everything works as expected (correct line number without > -Xdiags:verbose). > > I assume this is not the desired behavior. > > Is this already known? Any issue in JBS already? > > Thanks > > Sven > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > > From bsrbnd at gmail.com Sun Apr 29 14:17:54 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 29 Apr 2018 16:17:54 +0200 Subject: Misleading compile error - regression In-Reply-To: References: Message-ID: On 29 April 2018 at 13:55, B. Blaser wrote: > Hi, > > It looks like a missing 'make.at()' in > DeferredAttr::attribSpeculativeLambda, as next. > Tier1 seems OK. > > What do you think? > > Thanks, > Bernard ... with the test. Any comment is welcome, Bernard diff -r 1871c5d07caf src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java Fri Apr 27 15:55:29 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java Sun Apr 29 15:53:09 2018 +0200 @@ -441,7 +441,7 @@ } else { stats.add((JCBlock)that.body); } - JCBlock lambdaBlock = make.Block(0, stats.toList()); + JCBlock lambdaBlock = make.at(that).Block(0, stats.toList()); Env localEnv = attr.lambdaEnv(that, env); try { localEnv.info.returnResult = resultInfo; diff -r 1871c5d07caf test/langtools/tools/javac/Diagnostics/8202372/T8202372.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/langtools/tools/javac/Diagnostics/8202372/T8202372.java Sun Apr 29 15:53:09 2018 +0200 @@ -0,0 +1,16 @@ +/** + * @test + * @bug 8202372 + * @summary Diagnostic with incorrect line info generated when compiling lambda expression. + * @compile/fail/ref=T8202372.out -XDrawDiagnostics -Xdiags:compact T8202372.java + */ +public class T8202372 { + public static interface I { + public void m(String s); + } + public void add (I i) {} + public static void main(String[] args) { + T8202372 a = new T8202372(); + a.add(() -> {}); + } +} diff -r 1871c5d07caf test/langtools/tools/javac/Diagnostics/8202372/T8202372.out --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/langtools/tools/javac/Diagnostics/8202372/T8202372.out Sun Apr 29 15:53:09 2018 +0200 @@ -0,0 +1,3 @@ +T8202372.java:14:15: compiler.err.prob.found.req: (compiler.misc.incompatible.arg.types.in.lambda) +- compiler.note.compressed.diags +1 error > On 27 April 2018 at 15:10, Maurizio Cimadamore > wrote: >> Thanks for the report - I have not seen this before; I filed this: >> >> https://bugs.openjdk.java.net/browse/JDK-8202372 >> >> I've noted that if the lambda expression is changed to contain e.g. too many >> args, the diag position issue is fixed. >> >> Maurizio >> >> >> On 27/04/18 14:01, Sven Reimers wrote: >> >> Hi all, >> >> using a compiler from 9, 10, 11 the following code >> >> package issue; >> public class A { >> >> public static interface I { >> public void m(String s); >> } >> >> public void add (I i) {} >> >> public static void main(String[] args) { >> A a = new A(); >> a.add(() -> {}); >> } >> } >> >> results in >> >> ... issue/A.java:2: error: incompatible types: incompatible parameter types >> in lambda expression >> public class A { >> Note: Some messages have been simplified; recompile with -Xdiags:verbose to >> get full output >> 1 error >> >> With -Xdiags:verbose the message is correct >> >> ... issue/A.java:12: error: method add in class A cannot be applied to given >> types; >> a.add(() -> {}); >> required: I >> found: ()->{ } >> reason: argument mismatch; incompatible parameter types in lambda >> expression >> 1 error >> >> -> Look at the difference in the line number. >> >> Using JDK 8 everything works as expected (correct line number without >> -Xdiags:verbose). >> >> I assume this is not the desired behavior. >> >> Is this already known? Any issue in JBS already? >> >> Thanks >> >> Sven >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * Java Champion >> >> From maurizio.cimadamore at oracle.com Sun Apr 29 19:53:54 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sun, 29 Apr 2018 20:53:54 +0100 Subject: Misleading compile error - regression In-Reply-To: References: Message-ID: <62298386-7ec8-0b16-ce60-de7d20e2d8c4@oracle.com> Thanks - this seems good; I'll take a look for myself, and run some tests; if everything looks good I'll push. Cheers Maurizio On 29/04/18 15:17, B. Blaser wrote: > On 29 April 2018 at 13:55, B. Blaser wrote: >> Hi, >> >> It looks like a missing 'make.at()' in >> DeferredAttr::attribSpeculativeLambda, as next. >> Tier1 seems OK. >> >> What do you think? >> >> Thanks, >> Bernard > ... with the test. > > Any comment is welcome, > Bernard > > diff -r 1871c5d07caf > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > Fri Apr 27 15:55:29 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java > Sun Apr 29 15:53:09 2018 +0200 > @@ -441,7 +441,7 @@ > } else { > stats.add((JCBlock)that.body); > } > - JCBlock lambdaBlock = make.Block(0, stats.toList()); > + JCBlock lambdaBlock = make.at(that).Block(0, stats.toList()); > Env localEnv = attr.lambdaEnv(that, env); > try { > localEnv.info.returnResult = resultInfo; > diff -r 1871c5d07caf > test/langtools/tools/javac/Diagnostics/8202372/T8202372.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/langtools/tools/javac/Diagnostics/8202372/T8202372.java > Sun Apr 29 15:53:09 2018 +0200 > @@ -0,0 +1,16 @@ > +/** > + * @test > + * @bug 8202372 > + * @summary Diagnostic with incorrect line info generated when > compiling lambda expression. > + * @compile/fail/ref=T8202372.out -XDrawDiagnostics -Xdiags:compact > T8202372.java > + */ > +public class T8202372 { > + public static interface I { > + public void m(String s); > + } > + public void add (I i) {} > + public static void main(String[] args) { > + T8202372 a = new T8202372(); > + a.add(() -> {}); > + } > +} > diff -r 1871c5d07caf test/langtools/tools/javac/Diagnostics/8202372/T8202372.out > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/langtools/tools/javac/Diagnostics/8202372/T8202372.out > Sun Apr 29 15:53:09 2018 +0200 > @@ -0,0 +1,3 @@ > +T8202372.java:14:15: compiler.err.prob.found.req: > (compiler.misc.incompatible.arg.types.in.lambda) > +- compiler.note.compressed.diags > +1 error > > >> On 27 April 2018 at 15:10, Maurizio Cimadamore >> wrote: >>> Thanks for the report - I have not seen this before; I filed this: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8202372 >>> >>> I've noted that if the lambda expression is changed to contain e.g. too many >>> args, the diag position issue is fixed. >>> >>> Maurizio >>> >>> >>> On 27/04/18 14:01, Sven Reimers wrote: >>> >>> Hi all, >>> >>> using a compiler from 9, 10, 11 the following code >>> >>> package issue; >>> public class A { >>> >>> public static interface I { >>> public void m(String s); >>> } >>> >>> public void add (I i) {} >>> >>> public static void main(String[] args) { >>> A a = new A(); >>> a.add(() -> {}); >>> } >>> } >>> >>> results in >>> >>> ... issue/A.java:2: error: incompatible types: incompatible parameter types >>> in lambda expression >>> public class A { >>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to >>> get full output >>> 1 error >>> >>> With -Xdiags:verbose the message is correct >>> >>> ... issue/A.java:12: error: method add in class A cannot be applied to given >>> types; >>> a.add(() -> {}); >>> required: I >>> found: ()->{ } >>> reason: argument mismatch; incompatible parameter types in lambda >>> expression >>> 1 error >>> >>> -> Look at the difference in the line number. >>> >>> Using JDK 8 everything works as expected (correct line number without >>> -Xdiags:verbose). >>> >>> I assume this is not the desired behavior. >>> >>> Is this already known? Any issue in JBS already? >>> >>> Thanks >>> >>> Sven >>> >>> -- >>> Sven Reimers >>> >>> * Senior Expert Software Architect >>> * Java Champion >>> >>>