From GROEGES at uk.ibm.com  Fri Mar  1 14:00:24 2019
From: GROEGES at uk.ibm.com (Steve Groeger)
Date: Fri, 1 Mar 2019 14:00:24 +0000
Subject: RFR: [8218152] javac fails and exits with no error if a bad
 annotation processor is on the classpath
In-Reply-To: <5C6432DB.7070208@oracle.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
 <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
 <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>
 <5C616E68.5050103@oracle.com>
 <OF05AD88C8.5056BCAA-ON802583A0.00362FFF-802583A0.0036C19B@notes.na.collabserv.com>
 <5C6432DB.7070208@oracle.com>
Message-ID: <OF9B65D231.51A3D4D7-ON802583B0.004BA69C-802583B0.004CF0F1@notes.na.collabserv.com>

Hi Jan, 

Sorry for the delay in getting back to you on this, but I got dragged onto 
another project which 
delayed me working on this .

Quick question about having binary files in the repository. I had a look 
at the example you mentioned,
test/langtools/tools/javac/processing/rounds/GetElementsAnnotatedWithOnMissing.java
and see that it is using JavacTask() to compile the class. However in my 
tests cases they are using .jar files
and some of the classes included in the jar files are not real classes or 
a classes that have been built with a 
later version of java than is being tested. In these cases it is difficult 
to build these as part of the tests 
(unless you know how this can be done).

I did also notice, although you said binary files should not be in the 
repository, that the existing repository
has lots of binary files, which seem to be jar files. So is it a definite 
that binary files are not allowed or only
in ceratin circumstances. If the latter would it be OK to have the jar 
files in my webrev in the repo?

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From:   Jan Lahoda <jan.lahoda at oracle.com>
To:     Steve Groeger <GROEGES at uk.ibm.com>
Cc:     compiler-dev at openjdk.java.net
Date:   13/02/2019 15:10
Subject:        Re: RFR: [8218152] javac fails and exits with no error if 
a bad annotation processor is on the classpath



On 13.2.2019 10:58, Steve Groeger wrote:
> Hi Jan,
>
> Thanks for the response.
>
> With regards to your comments re:
>
>  >But I guess I'd personally rather kept
>  >it simple. Would there be an issue with simply changing the "catch
>  >(Throwable)" to also report the same error as "catch
>  >(ServiceConfigurationError)"? I.e. something like:
>  >>---
>  >> diff -r 4ef401769c36
> 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >> ---
> 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>      Fri Feb 08 14:06:35 2019 +0100
>  >> +++
> 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>      Mon Feb 11 13:33:50 2019 +0100
>  >> @@ -437,6 +437,7 @@
>  >>
>   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >>                  throw new Abort(sce);
>  >>              } catch (Throwable t) {
>  >> +
>   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >>                  throw new Abort(t);
>  >>              }
>  >>          }
>  >> @@ -453,6 +454,7 @@
>  >>
>   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >>                  throw new Abort(sce);
>  >>              } catch (Throwable t) {
>  >> +
>   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >>                  throw new Abort(t);
>  >>              }
>  >>          }
>  >---
>
> I can do it the waty you sugegsted but I had done it this way because
> Jonathan Gibbons had stated:
>
>  >> There's a `catch (Throwable t)` in the same set of catch blocks that 
you
>  >> did not update. Rather than add yet another message for that case, 
it
>  >> might be better to throw FatalError, to provoke the standard "javac
>  >> crash" output for the unknown exception.
>
> Either way is OK with me. We just need to make a decision on which is
> the preferred way - then I can update the webrevs.

To me personally, FatalError feels a little bit harsh. But I agree we 
should try to avoid adding new error messages for this if possible. I'll 
leave it up to Jon.

(If we wanted to always print a stack trace for these problems, we could 
change to code to simply throw AnnotationProcessingError, which always 
prints the stacktrace - some tweaking to make the errors look good might 
be needed, though.)

Jan

>
>  >Looking at the tests, one thing to note is that binary files are
>  >generally not allowed in the repository. I wonder if a test that would
>  >run javac programmaticaly wouldn't be easier to do
>
> I will take yopur advice on the tests and see if I can do this
> programtically rather than havng the binary files in the repository.
>
> Will post again in the mailing list when I have updated webrevs that are
> suitable for being reviewed.
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>
>
>
> From: Jan Lahoda <jan.lahoda at oracle.com>
> To: Steve Groeger <GROEGES at uk.ibm.com>, compiler-dev at openjdk.java.net
> Date: 11/02/2019 12:45
> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad
> annotation processor is on the classpath
> ------------------------------------------------------------------------
>
>
>
> Hi Steve,
>
> I apologize for a late reply.
>
> One thing to note is that according to the ServiceLoader spec, the
> LinkageErrors shouldn't be thrown out of the Iterator. That is my
> reading at least. Please see:
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8196182&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=mZ1pZsBoFc0zAVmbYwZyhV9R95RKJIpb-Ifm-qYszjs&s=RUvbol5W2cTxYRGp5ab87P-XP9mFbPr6hiCn-YdqFpY&e=

>
> Given there are some issues associated with that, I don't see a problem
> with workarounding that in javac. But I guess I'd personally rather kept
> it simple. Would there be an issue with simply changing the "catch
> (Throwable)" to also report the same error as "catch
> (ServiceConfigurationError)"? I.e. something like:
> ---
>  > diff -r 4ef401769c36
> 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  > ---
> 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>      Fri Feb 08 14:06:35 2019 +0100
>  > +++
> 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>      Mon Feb 11 13:33:50 2019 +0100
>  > @@ -437,6 +437,7 @@
>  >
>   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >                  throw new Abort(sce);
>  >              } catch (Throwable t) {
>  > +
>   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >                  throw new Abort(t);
>  >              }
>  >          }
>  > @@ -453,6 +454,7 @@
>  >
>   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >                  throw new Abort(sce);
>  >              } catch (Throwable t) {
>  > +
>   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >                  throw new Abort(t);
>  >              }
>  >          }
> ---
>
> Looking at the tests, one thing to note is that binary files are
> generally not allowed in the repository. I wonder if a test that would
> run javac programmaticaly wouldn't be easier to do, see e.g.:
> 
test/langtools/tools/javac/processing/rounds/GetElementsAnnotatedWithOnMissing.java
>
> This should allow arbitrary changes to the classfiles, so that binaries
> don't need to be in the repository.
>
> Thanks,
>      Jan
>
> On 11.2.2019 12:30, Steve Groeger wrote:
>  > Hi all,
>  >
>  > Is there anyone out there that would be able to review the webrevs
>  > mentioned in the earlier post.
>  > Jonathan Gibbons has agreed to sponsor these changes but we need 2
>  > reviewers. Anyone?
>  >
>  > Thanks
>  > Steve Groeger
>  > IBM Runtime Technologies
>  > Hursley, Winchester
>  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  > Fax (44) 1962 816800
>  > Lotus Notes: Steve Groeger/UK/IBM
>  > Internet: groeges at uk.ibm.com
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  >
>  > From: Steve Groeger <GROEGES at uk.ibm.com>
>  > To: compiler-dev at openjdk.java.net
>  > Date: 01/02/2019 12:47
>  > Subject: RFR: [8218152] javac fails and exits with no error if a bad
>  > annotation processor is on the classpath
>  > Sent by: "compiler-dev" <compiler-dev-bounces at openjdk.java.net>
>  > 
------------------------------------------------------------------------
>  >
>  >
>  >
>  > Hi all,
>  >
>  > I have made some changes to the code for issue [1] for both jdk8u and
>  > jdk (jdk13)
>  > The latest webrevs have a few extra changes suggested by  Jonathan
>  > Gibbons mentioned in an earlier mailing [2]
>  > The webrevs are for jdk8u [3] and for jdk [4].
>  > Please could someone review these changes and let me know if there 
are
>  > any issues.
>  >
>  > [1]
> 
_https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
>  > [2]
>  >
> 
_https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_compiler-2Ddev_2019-2DJanuary_012920.html-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=AhWE854aM6al5na1Eo9sxF4IoWBZC3jfvLHRo2a2ETo&e=
>  > [3]
> 
_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=OM__1ZIlBCUXiHNLfltEv9c_6a8k8nspR0KnKjRT8II&e=
>  > [4]
> 
_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=HrpL5tvveJrGX0ABN9uGRn0bZV1nsiNxzuLOAVem3Z0&e=
>  >
>  > Thanks
>  > Steve Groeger
>  > IBM Runtime Technologies
>  > Hursley, Winchester
>  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  > Fax (44) 1962 816800
>  > Lotus Notes: Steve Groeger/UK/IBM
>  > Internet: groeges at uk.ibm.com
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  >
>  > From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
>  > To: Steve Groeger <GROEGES at uk.ibm.com>
>  > Cc: compiler-dev at openjdk.java.net
>  > Date: 31/01/2019 16:56
>  > Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
>  > annotation processor is on the classpath
>  > 
------------------------------------------------------------------------
>  >
>  >
>  >
>  > Steve,
>  >
>  > When you post the new webrevs, can I suggest that you change the 
Subject
>  > line of this thread to something like
>  >
>  > RFR: 8218152 [javac] fails and exits with no error if a bad 
annotation
>  > processor provided
>  >
>  > That will help get attention from reviewers, and help any subsequent
>  > bug-archaeology.
>  >
>  > I can sponsor the changes for you once they have been reviewed.
>  >
>  > -- Jon
>  >
>  > On 1/31/19 8:49 AM, Steve Groeger wrote:
>  > Hi Jonathan,
>  >
>  > Thanks for responding.
>  >
>  > I have created a couple of webrevs for jdk8u [1] and jdk [2] which 
also
>  > include some JTReg tests.
>  > I would be grateful if you, or someone else could review these just 
to
>  > ensure I am doing the right thing.
>  > I will update the code with the additional 'throw FatalError' that 
you
>  > mentioned and will then create some new webrevs
>  >
>  > If you are able to sponsor these changes for me I would be very 
grateful.
>  >
>  > PS. As you saw I have created a JBS issue for this here [3]
>  >
>  > [1]
> 
_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=JoEgW12V0tuoZvuG9GDF7g5YmXhjGolWyibAYlifWME&e=
>  > [2]
> 
_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=NeM6uUrEq-vcqXQ5uHonCor_ChwsY20notpASJS4is8&e=
>  >
> 
[3_https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
>  >
>  > Thanks
>  > Steve Groeger
>  > IBM Runtime Technologies
>  > Hursley, Winchester
>  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  > Fax (44) 1962 816800
>  > Lotus Notes: Steve Groeger/UK/IBM
>  > Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  >
>  > From: Jonathan Gibbons _<jonathan.gibbons at oracle.com>_
>  > <mailto:jonathan.gibbons at oracle.com>
>  > To: Steve Groeger _<GROEGES at uk.ibm.com>_ <mailto:GROEGES at uk.ibm.com>,
>  > _compiler-dev at openjdk.java.net_ <mailto:compiler-dev at openjdk.java.net
>
>  > Date: 31/01/2019 16:33
>  > Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
>  > annotation processor is on the classpath
>  >
>  > 
------------------------------------------------------------------------
>  >
>  >
>  >
>  > Steve,
>  >
>  > Your fix is generally good: Abort should only be used after a 
suitable
>  > message has been reported.
>  >
>  > There's a `catch (Throwable t)` in the same set of catch blocks that 
you
>  > did not update. Rather than add yet another message for that case, it
>  > might be better to throw FatalError, to provoke the standard "javac
>  > crash" output for the unknown exception.
>  >
>  > You should provide a test case ... i.e. as a jtreg test.
>  >
>  > -- Jon
>  >
>  > On 1/29/19 3:18 AM, Steve Groeger wrote:
>  > Hi all,
>  >
>  > I have identified a potential issue where javac fails and exits with 
no
>  > error if a bad annotation processor is on the classpath.
>  >
>  > Background: an Annotation Processor class can be packaged in a jar 
file
>  > and is identified by a special text file inside the jar named:
>  > META-INF/services/javax.annotation.processing.Processor. This text 
file
>  > has only one line, specifying the class name of the annotation 
process
>  > class to run. When javac runs, it checks all jars on the classpath 
and
>  > if it finds the special text file in any jar file, then it attempts 
to
>  > run the class listed there.
>  >
>  > The issue here is that when the annotation processor class can't be
>  > executed, javac catches the exception and exits without reporting on 
the
>  > reason for the exit. Examples of reasons why the annotation processor
>  > can't be executed include:
>  >
>  >   * the annotation processor class is compiled for a higher version 
of
>  >     Java than the javac is running, giving 
UnsupportedClassVersionError.
>  >   * the annotation processor class file is corrupt so can't be 
loaded.
>  >
>  >
>  > In either of the above cases javac will swallow the error and exit
>  > without telling the user why it failed to compile the java source 
code
>  > as expected.
>  >
>  > Testcase
>  >    put HelloWorld.java in current directory, edit <path_to_jar> and 
run:
>  >          javac -cp .:<path_to_jar>/bad.annotation.processor.jar
>  > HelloWorld.java
>  >
>  > Instead of producing HelloWorld.class as expected, javac exits 
silently.
>  >
>  > Here, bad.annotation.processor.jar is a file that I created to 
contain:
>  >       META-INF/services/javax.annotation.processing.Processor <<-- 
text
>  > file to list bad class
>  >      bad/notaclass.class <<-- dummy file, can't be loaded as a java 
class
>  >
>  > Does anyone know whether this is a bug and that this should throw an
>  > error in these cases?
>  > If so, I will raise a bug for this.
>  >
>  > I have looked at the code and seen where javac Aborts the processing,
>  > and if I make the following changes the javac detects the issue and
>  > reports an error before Aborting.
>  >
>  > diff -r 5178e4b58b17
>  >
> 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  > ---
>  >
> 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >       Mon Jan 28 09:56:00 2019 +0100
>  > +++
>  >
> 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >       Tue Jan 29 11:14:57 2019 +0000
>  > @@ -1,5 +1,5 @@
>  > /*
>  > - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All 
rights
>  > reserved.
>  > + * Copyright (c) 2005, 2019, 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
>  > @@ -436,6 +436,12 @@
>  >              } catch(ServiceConfigurationError sce) {
>  >
>  > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >                  throw new Abort(sce);
>  > +            } catch (UnsupportedClassVersionError ucve) {
>  > +
>  >   log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage()));
>  > +                throw new Abort(ucve);
>  > +            } catch (ClassFormatError cfe) {
>  > +
>  >   log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage()));
>  > +                throw new Abort(cfe);
>  >              } catch (Throwable t) {
>  >                  throw new Abort(t);
>  >              }
>  >
>  > and to add a new message there is this change
>  >
>  > diff -r 5178e4b58b17
>  >
> 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>  > ---
>  >
> 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>  >       Mon Jan 28 09:56:00 2019 +0100
>  > +++
>  >
> 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>  >       Tue Jan 29 11:16:03 2019 +0000
>  > @@ -1,5 +1,5 @@
>  > #
>  > -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights
>  > reserved.
>  > +# Copyright (c) 1999, 2019, 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
>  > @@ -1051,6 +1051,10 @@
>  > compiler.err.proc.cant.find.class=\
>  >      Could not find class file for ''{0}''.
>  >
>  > +# 0: string
>  > +compiler.err.proc.cant.load.class=\
>  > +    Could not load processor class file due to ''{0}''.
>  > +
>  > # Print a client-generated error message; assumed to be localized, no
>  > translation required
>  > # 0: string
>  > compiler.err.proc.messager=\
>  >
>  >
>  > If this is deemed a bug and the change seems OK, please could someone
>  > sponsor this for me and I will create a proper webrev for the change 
for
>  > a full review.
>  >
>  > Thanks
>  > Steve Groeger
>  > IBM Runtime Technologies
>  > Hursley, Winchester
>  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  > Fax (44) 1962 816800
>  > Lotus Notes: Steve Groeger/UK/IBM
>  > Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190301/4ff0d95a/attachment-0001.html>

From jan.lahoda at oracle.com  Mon Mar  4 11:57:45 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 4 Mar 2019 12:57:45 +0100
Subject: RFR: [8218152] javac fails and exits with no error if a bad
 annotation processor is on the classpath
In-Reply-To: <OF9B65D231.51A3D4D7-ON802583B0.004BA69C-802583B0.004CF0F1@notes.na.collabserv.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
 <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
 <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>
 <5C616E68.5050103@oracle.com>
 <OF05AD88C8.5056BCAA-ON802583A0.00362FFF-802583A0.0036C19B@notes.na.collabserv.com>
 <5C6432DB.7070208@oracle.com>
 <OF9B65D231.51A3D4D7-ON802583B0.004BA69C-802583B0.004CF0F1@notes.na.collabserv.com>
Message-ID: <5C7D12B9.5060801@oracle.com>

Hi Steve,

On 1.3.2019 15:00, Steve Groeger wrote:
> Hi Jan,
>
> Sorry for the delay in getting back to you on this, but I got dragged
> onto another project which
> delayed me working on this .
>
> Quick question about having binary files in the repository. I had a look
> at the example you mentioned,
> test/langtools/tools/javac/processing/rounds/GetElementsAnnotatedWithOnMissing.java
>
> and see that it is using JavacTask() to compile the class. However in my
> tests cases they are using .jar files
> and some of the classes included in the jar files are not real classes
> or a classes that have been built with a
> later version of java than is being tested. In these cases it is
> difficult to build these as part of the tests
> (unless you know how this can be done).

I don't think the tests really need jars - directories should work in 
the same way (but ToolBox allows to create jars as well if needed). 
Also, seems the current tests only test malformed processor classfiles 
and missing processors, which should be easy to do in any case. A 
possible test:
http://cr.openjdk.java.net/~jlahoda/8218152/MalformedAP.java

(It also tests a Processor classfile that has unsupported major version.)

>
> I did also notice, although you said binary files should not be in the
> repository, that the existing repository
> has lots of binary files, which seem to be jar files. So is it a
> definite that binary files are not allowed or only
> in ceratin circumstances. If the latter would it be OK to have the jar
> files in my webrev in the repo?

$ find . -type f -name "*.jar" | grep -v "./build/" | wc -l

in the top-level directory returns 61 for me, and looking at the history 
of some of them, it seems they are very old, so I'd consider them 
legacy. In this case, it seems fairly easy to do without these files 
(and maybe even easier without them), so I personally don't see a reason 
to include them.

Thanks,
     Jan

>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
> From: Jan Lahoda <jan.lahoda at oracle.com>
> To: Steve Groeger <GROEGES at uk.ibm.com>
> Cc: compiler-dev at openjdk.java.net
> Date: 13/02/2019 15:10
> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad
> annotation processor is on the classpath
> ------------------------------------------------------------------------
>
>
>
> On 13.2.2019 10:58, Steve Groeger wrote:
>  > Hi Jan,
>  >
>  > Thanks for the response.
>  >
>  > With regards to your comments re:
>  >
>  >  >But I guess I'd personally rather kept
>  >  >it simple. Would there be an issue with simply changing the "catch
>  >  >(Throwable)" to also report the same error as "catch
>  >  >(ServiceConfigurationError)"? I.e. something like:
>  >  >>---
>  >  >> diff -r 4ef401769c36
>  >
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >  >> ---
>  >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >      Fri Feb 08 14:06:35 2019 +0100
>  >  >> +++
>  >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >      Mon Feb 11 13:33:50 2019 +0100
>  >  >> @@ -437,6 +437,7 @@
>  >  >>
>  >   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >  >>  throw new Abort(sce);
>  >  >>              } catch (Throwable t) {
>  >  >> +
>  >   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >  >>  throw new Abort(t);
>  >  >>              }
>  >  >>          }
>  >  >> @@ -453,6 +454,7 @@
>  >  >>
>  >   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >  >>  throw new Abort(sce);
>  >  >>              } catch (Throwable t) {
>  >  >> +
>  >   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >  >>  throw new Abort(t);
>  >  >>              }
>  >  >>          }
>  >  >---
>  >
>  > I can do it the waty you sugegsted but I had done it this way because
>  > Jonathan Gibbons had stated:
>  >
>  >  >> There's a `catch (Throwable t)` in the same set of catch blocks
> that you
>  >  >> did not update. Rather than add yet another message for that case, it
>  >  >> might be better to throw FatalError, to provoke the standard "javac
>  >  >> crash" output for the unknown exception.
>  >
>  > Either way is OK with me. We just need to make a decision on which is
>  > the preferred way - then I can update the webrevs.
>
> To me personally, FatalError feels a little bit harsh. But I agree we
> should try to avoid adding new error messages for this if possible. I'll
> leave it up to Jon.
>
> (If we wanted to always print a stack trace for these problems, we could
> change to code to simply throw AnnotationProcessingError, which always
> prints the stacktrace - some tweaking to make the errors look good might
> be needed, though.)
>
> Jan
>
>  >
>  >  >Looking at the tests, one thing to note is that binary files are
>  >  >generally not allowed in the repository. I wonder if a test that would
>  >  >run javac programmaticaly wouldn't be easier to do
>  >
>  > I will take yopur advice on the tests and see if I can do this
>  > programtically rather than havng the binary files in the repository.
>  >
>  > Will post again in the mailing list when I have updated webrevs that are
>  > suitable for being reviewed.
>  >
>  > Thanks
>  > Steve Groeger
>  > IBM Runtime Technologies
>  > Hursley, Winchester
>  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  > Fax (44) 1962 816800
>  > Lotus Notes: Steve Groeger/UK/IBM
>  > Internet: groeges at uk.ibm.com
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  >
>  > From: Jan Lahoda <jan.lahoda at oracle.com>
>  > To: Steve Groeger <GROEGES at uk.ibm.com>, compiler-dev at openjdk.java.net
>  > Date: 11/02/2019 12:45
>  > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad
>  > annotation processor is on the classpath
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  > Hi Steve,
>  >
>  > I apologize for a late reply.
>  >
>  > One thing to note is that according to the ServiceLoader spec, the
>  > LinkageErrors shouldn't be thrown out of the Iterator. That is my
>  > reading at least. Please see:
>  > https://bugs.openjdk.java.net/browse/JDK-8196182
>  >
>  > Given there are some issues associated with that, I don't see a problem
>  > with workarounding that in javac. But I guess I'd personally rather kept
>  > it simple. Would there be an issue with simply changing the "catch
>  > (Throwable)" to also report the same error as "catch
>  > (ServiceConfigurationError)"? I.e. something like:
>  > ---
>  >  > diff -r 4ef401769c36
>  >
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >  > ---
>  >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >      Fri Feb 08 14:06:35 2019 +0100
>  >  > +++
>  >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >      Mon Feb 11 13:33:50 2019 +0100
>  >  > @@ -437,6 +437,7 @@
>  >  >
>  >   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >  >  throw new Abort(sce);
>  >  >              } catch (Throwable t) {
>  >  > +
>  >   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >  >  throw new Abort(t);
>  >  >              }
>  >  >          }
>  >  > @@ -453,6 +454,7 @@
>  >  >
>  >   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >  >  throw new Abort(sce);
>  >  >              } catch (Throwable t) {
>  >  > +
>  >   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >  >  throw new Abort(t);
>  >  >              }
>  >  >          }
>  > ---
>  >
>  > Looking at the tests, one thing to note is that binary files are
>  > generally not allowed in the repository. I wonder if a test that would
>  > run javac programmaticaly wouldn't be easier to do, see e.g.:
>  >
> test/langtools/tools/javac/processing/rounds/GetElementsAnnotatedWithOnMissing.java
>  >
>  > This should allow arbitrary changes to the classfiles, so that binaries
>  > don't need to be in the repository.
>  >
>  > Thanks,
>  >      Jan
>  >
>  > On 11.2.2019 12:30, Steve Groeger wrote:
>  >  > Hi all,
>  >  >
>  >  > Is there anyone out there that would be able to review the webrevs
>  >  > mentioned in the earlier post.
>  >  > Jonathan Gibbons has agreed to sponsor these changes but we need 2
>  >  > reviewers. Anyone?
>  >  >
>  >  > Thanks
>  >  > Steve Groeger
>  >  > IBM Runtime Technologies
>  >  > Hursley, Winchester
>  >  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  >  > Fax (44) 1962 816800
>  >  > Lotus Notes: Steve Groeger/UK/IBM
>  >  > Internet: groeges at uk.ibm.com
>  >  >
>  >  > Unless stated otherwise above:
>  >  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  >  > 741598.
>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>  > PO6 3AU
>  >  >
>  >  >
>  >  >
>  >  > From: Steve Groeger <GROEGES at uk.ibm.com>
>  >  > To: compiler-dev at openjdk.java.net
>  >  > Date: 01/02/2019 12:47
>  >  > Subject: RFR: [8218152] javac fails and exits with no error if a bad
>  >  > annotation processor is on the classpath
>  >  > Sent by: "compiler-dev" <compiler-dev-bounces at openjdk.java.net>
>  >  >
> ------------------------------------------------------------------------
>  >  >
>  >  >
>  >  >
>  >  > Hi all,
>  >  >
>  >  > I have made some changes to the code for issue [1] for both jdk8u and
>  >  > jdk (jdk13)
>  >  > The latest webrevs have a few extra changes suggested by  Jonathan
>  >  > Gibbons mentioned in an earlier mailing [2]
>  >  > The webrevs are for jdk8u [3] and for jdk [4].
>  >  > Please could someone review these changes and let me know if there are
>  >  > any issues.
>  >  >
>  >  > [1]
>  >
> _https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
>  >  > [2]
>  >  >
>  >
> _https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_compiler-2Ddev_2019-2DJanuary_012920.html-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=AhWE854aM6al5na1Eo9sxF4IoWBZC3jfvLHRo2a2ETo&e=
>  >  > [3]
>  >
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=OM__1ZIlBCUXiHNLfltEv9c_6a8k8nspR0KnKjRT8II&e=
>  >  > [4]
>  >
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=HrpL5tvveJrGX0ABN9uGRn0bZV1nsiNxzuLOAVem3Z0&e=
>  >  >
>  >  > Thanks
>  >  > Steve Groeger
>  >  > IBM Runtime Technologies
>  >  > Hursley, Winchester
>  >  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  >  > Fax (44) 1962 816800
>  >  > Lotus Notes: Steve Groeger/UK/IBM
>  >  > Internet: groeges at uk.ibm.com
>  >  >
>  >  > Unless stated otherwise above:
>  >  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  >  > 741598.
>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>  > PO6 3AU
>  >  >
>  >  >
>  >  >
>  >  > From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
>  >  > To: Steve Groeger <GROEGES at uk.ibm.com>
>  >  > Cc: compiler-dev at openjdk.java.net
>  >  > Date: 31/01/2019 16:56
>  >  > Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
>  >  > annotation processor is on the classpath
>  >  >
> ------------------------------------------------------------------------
>  >  >
>  >  >
>  >  >
>  >  > Steve,
>  >  >
>  >  > When you post the new webrevs, can I suggest that you change the
> Subject
>  >  > line of this thread to something like
>  >  >
>  >  > RFR: 8218152 [javac] fails and exits with no error if a bad annotation
>  >  > processor provided
>  >  >
>  >  > That will help get attention from reviewers, and help any subsequent
>  >  > bug-archaeology.
>  >  >
>  >  > I can sponsor the changes for you once they have been reviewed.
>  >  >
>  >  > -- Jon
>  >  >
>  >  > On 1/31/19 8:49 AM, Steve Groeger wrote:
>  >  > Hi Jonathan,
>  >  >
>  >  > Thanks for responding.
>  >  >
>  >  > I have created a couple of webrevs for jdk8u [1] and jdk [2] which
> also
>  >  > include some JTReg tests.
>  >  > I would be grateful if you, or someone else could review these just to
>  >  > ensure I am doing the right thing.
>  >  > I will update the code with the additional 'throw FatalError' that you
>  >  > mentioned and will then create some new webrevs
>  >  >
>  >  > If you are able to sponsor these changes for me I would be very
> grateful.
>  >  >
>  >  > PS. As you saw I have created a JBS issue for this here [3]
>  >  >
>  >  > [1]
>  >
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=JoEgW12V0tuoZvuG9GDF7g5YmXhjGolWyibAYlifWME&e=
>  >  > [2]
>  >
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=NeM6uUrEq-vcqXQ5uHonCor_ChwsY20notpASJS4is8&e=
>  >  >
>  >
> [3_https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
>  >  >
>  >  > Thanks
>  >  > Steve Groeger
>  >  > IBM Runtime Technologies
>  >  > Hursley, Winchester
>  >  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  >  > Fax (44) 1962 816800
>  >  > Lotus Notes: Steve Groeger/UK/IBM
>  >  > Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>  >  >
>  >  > Unless stated otherwise above:
>  >  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  >  > 741598.
>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>  > PO6 3AU
>  >  >
>  >  >
>  >  >
>  >  > From: Jonathan Gibbons _<jonathan.gibbons at oracle.com>_
>  >  > <mailto:jonathan.gibbons at oracle.com>
>  >  > To: Steve Groeger _<GROEGES at uk.ibm.com>_ <mailto:GROEGES at uk.ibm.com>,
>  >  > _compiler-dev at openjdk.java.net_ <mailto:compiler-dev at openjdk.java.net>
>  >  > Date: 31/01/2019 16:33
>  >  > Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
>  >  > annotation processor is on the classpath
>  >  >
>  >  >
> ------------------------------------------------------------------------
>  >  >
>  >  >
>  >  >
>  >  > Steve,
>  >  >
>  >  > Your fix is generally good: Abort should only be used after a suitable
>  >  > message has been reported.
>  >  >
>  >  > There's a `catch (Throwable t)` in the same set of catch blocks
> that you
>  >  > did not update. Rather than add yet another message for that case, it
>  >  > might be better to throw FatalError, to provoke the standard "javac
>  >  > crash" output for the unknown exception.
>  >  >
>  >  > You should provide a test case ... i.e. as a jtreg test.
>  >  >
>  >  > -- Jon
>  >  >
>  >  > On 1/29/19 3:18 AM, Steve Groeger wrote:
>  >  > Hi all,
>  >  >
>  >  > I have identified a potential issue where javac fails and exits
> with no
>  >  > error if a bad annotation processor is on the classpath.
>  >  >
>  >  > Background: an Annotation Processor class can be packaged in a jar
> file
>  >  > and is identified by a special text file inside the jar named:
>  >  > META-INF/services/javax.annotation.processing.Processor. This text
> file
>  >  > has only one line, specifying the class name of the annotation process
>  >  > class to run. When javac runs, it checks all jars on the classpath and
>  >  > if it finds the special text file in any jar file, then it attempts to
>  >  > run the class listed there.
>  >  >
>  >  > The issue here is that when the annotation processor class can't be
>  >  > executed, javac catches the exception and exits without reporting
> on the
>  >  > reason for the exit. Examples of reasons why the annotation processor
>  >  > can't be executed include:
>  >  >
>  >  >   * the annotation processor class is compiled for a higher version of
>  >  >     Java than the javac is running, giving
> UnsupportedClassVersionError.
>  >  >   * the annotation processor class file is corrupt so can't be loaded.
>  >  >
>  >  >
>  >  > In either of the above cases javac will swallow the error and exit
>  >  > without telling the user why it failed to compile the java source code
>  >  > as expected.
>  >  >
>  >  > Testcase
>  >  >    put HelloWorld.java in current directory, edit <path_to_jar>
> and run:
>  >  >          javac -cp .:<path_to_jar>/bad.annotation.processor.jar
>  >  > HelloWorld.java
>  >  >
>  >  > Instead of producing HelloWorld.class as expected, javac exits
> silently.
>  >  >
>  >  > Here, bad.annotation.processor.jar is a file that I created to
> contain:
>  >  >       META-INF/services/javax.annotation.processing.Processor <<--
> text
>  >  > file to list bad class
>  >  >      bad/notaclass.class <<-- dummy file, can't be loaded as a
> java class
>  >  >
>  >  > Does anyone know whether this is a bug and that this should throw an
>  >  > error in these cases?
>  >  > If so, I will raise a bug for this.
>  >  >
>  >  > I have looked at the code and seen where javac Aborts the processing,
>  >  > and if I make the following changes the javac detects the issue and
>  >  > reports an error before Aborting.
>  >  >
>  >  > diff -r 5178e4b58b17
>  >  >
>  >
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >  > ---
>  >  >
>  >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >  >       Mon Jan 28 09:56:00 2019 +0100
>  >  > +++
>  >  >
>  >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >  >       Tue Jan 29 11:14:57 2019 +0000
>  >  > @@ -1,5 +1,5 @@
>  >  > /*
>  >  > - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights
>  >  > reserved.
>  >  > + * Copyright (c) 2005, 2019, 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
>  >  > @@ -436,6 +436,12 @@
>  >  >              } catch(ServiceConfigurationError sce) {
>  >  >
>  >  > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >  >  throw new Abort(sce);
>  >  > +            } catch (UnsupportedClassVersionError ucve) {
>  >  > +
>  >  >   log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage()));
>  >  > +                throw new Abort(ucve);
>  >  > +            } catch (ClassFormatError cfe) {
>  >  > +
>  >  >   log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage()));
>  >  > +                throw new Abort(cfe);
>  >  >              } catch (Throwable t) {
>  >  >  throw new Abort(t);
>  >  >              }
>  >  >
>  >  > and to add a new message there is this change
>  >  >
>  >  > diff -r 5178e4b58b17
>  >  >
>  >
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>  >  > ---
>  >  >
>  >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>  >  >       Mon Jan 28 09:56:00 2019 +0100
>  >  > +++
>  >  >
>  >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>  >  >       Tue Jan 29 11:16:03 2019 +0000
>  >  > @@ -1,5 +1,5 @@
>  >  > #
>  >  > -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights
>  >  > reserved.
>  >  > +# Copyright (c) 1999, 2019, 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
>  >  > @@ -1051,6 +1051,10 @@
>  >  > compiler.err.proc.cant.find.class=\
>  >  >      Could not find class file for ''{0}''.
>  >  >
>  >  > +# 0: string
>  >  > +compiler.err.proc.cant.load.class=\
>  >  > +    Could not load processor class file due to ''{0}''.
>  >  > +
>  >  > # Print a client-generated error message; assumed to be localized, no
>  >  > translation required
>  >  > # 0: string
>  >  > compiler.err.proc.messager=\
>  >  >
>  >  >
>  >  > If this is deemed a bug and the change seems OK, please could someone
>  >  > sponsor this for me and I will create a proper webrev for the
> change for
>  >  > a full review.
>  >  >
>  >  > Thanks
>  >  > Steve Groeger
>  >  > IBM Runtime Technologies
>  >  > Hursley, Winchester
>  >  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  >  > Fax (44) 1962 816800
>  >  > Lotus Notes: Steve Groeger/UK/IBM
>  >  > Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>  >  >
>  >  > Unless stated otherwise above:
>  >  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  >  > 741598.
>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>  > PO6 3AU
>  >  > Unless stated otherwise above:
>  >  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  >  > 741598.
>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>  > PO6 3AU
>  >  >
>  >  >
>  >  > Unless stated otherwise above:
>  >  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  >  > 741598.
>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>  > PO6 3AU
>  >  >
>  >  >
>  >  > Unless stated otherwise above:
>  >  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  >  > 741598.
>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>  > PO6 3AU
>  >  >
>  >  >
>  >  > Unless stated otherwise above:
>  >  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  >  > 741598.
>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>  > PO6 3AU
>  >
>  >
>  >
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From jonathan.gibbons at oracle.com  Mon Mar  4 15:41:16 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 4 Mar 2019 07:41:16 -0800
Subject: RFR: [8218152] javac fails and exits with no error if a bad
 annotation processor is on the classpath
In-Reply-To: <OF9B65D231.51A3D4D7-ON802583B0.004BA69C-802583B0.004CF0F1@notes.na.collabserv.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
 <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
 <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>
 <5C616E68.5050103@oracle.com>
 <OF05AD88C8.5056BCAA-ON802583A0.00362FFF-802583A0.0036C19B@notes.na.collabserv.com>
 <5C6432DB.7070208@oracle.com>
 <OF9B65D231.51A3D4D7-ON802583B0.004BA69C-802583B0.004CF0F1@notes.na.collabserv.com>
Message-ID: <78e2a1fd-be45-f9db-33a8-365f7aafd847@oracle.com>


On 3/1/19 6:00 AM, Steve Groeger wrote:
>
> I did also notice, although you said binary files should not be in the 
> repository, that the existing repository
> has lots of binary files, which seem to be jar files. So is it a 
> definite that binary files are not allowed or only
> in ceratin circumstances. If the latter would it be OK to have the jar 
> files in my webrev in the repo?

Steve,

Binary files in the repo are strongly discouraged, especially in the 
cases where the file is either unnecessary
or can be generated on the fly. We have tools like jasm/jcod that can 
make "strange" class files and we have
API like toolbox that make it easy to make jar files.

Some number of binary files came in when OpenJDK was created, but there 
has been an ongoing background
effort to eliminate these files, although admittedly that work has 
slowed of late.? It would be bad to start
adding new binary files at this point.

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190304/bb1bed62/attachment.html>

From GROEGES at uk.ibm.com  Tue Mar  5 09:30:14 2019
From: GROEGES at uk.ibm.com (Steve Groeger)
Date: Tue, 5 Mar 2019 09:30:14 +0000
Subject: RFR: [8218152] javac fails and exits with no error if a bad
 annotation processor is on the classpath
In-Reply-To: <78e2a1fd-be45-f9db-33a8-365f7aafd847@oracle.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
 <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
 <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>
 <5C616E68.5050103@oracle.com>
 <OF05AD88C8.5056BCAA-ON802583A0.00362FFF-802583A0.0036C19B@notes.na.collabserv.com>
 <5C6432DB.7070208@oracle.com>
 <OF9B65D231.51A3D4D7-ON802583B0.004BA69C-802583B0.004CF0F1@notes.na.collabserv.com>
 <78e2a1fd-be45-f9db-33a8-365f7aafd847@oracle.com>
Message-ID: <OF5B6BD9D3.665B158B-ON802583B4.00340018-802583B4.003434C8@notes.na.collabserv.com>

Hi Jonathan & Jan, 

Thanks for your comments. 
I fully understand the reasoning and will endeavor to make changes that 
removes the 
need for these jar files.  Will post again once I have some new webrevs 
for review.

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From:   Jonathan Gibbons <jonathan.gibbons at oracle.com>
To:     compiler-dev at openjdk.java.net
Date:   04/03/2019 15:44
Subject:        Re: RFR: [8218152] javac fails and exits with no error if 
a bad annotation processor is on the classpath
Sent by:        "compiler-dev" <compiler-dev-bounces at openjdk.java.net>




On 3/1/19 6:00 AM, Steve Groeger wrote:

I did also notice, although you said binary files should not be in the 
repository, that the existing repository 
has lots of binary files, which seem to be jar files. So is it a definite 
that binary files are not allowed or only 
in ceratin circumstances. If the latter would it be OK to have the jar 
files in my webrev in the repo?
Steve,
Binary files in the repo are strongly discouraged, especially in the cases 
where the file is either unnecessary
or can be generated on the fly. We have tools like jasm/jcod that can make 
"strange" class files and we have
API like toolbox that make it easy to make jar files.
Some number of binary files came in when OpenJDK was created, but there 
has been an ongoing background
effort to eliminate these files, although admittedly that work has slowed 
of late.  It would be bad to start
adding new binary files at this point.
-- Jon


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190305/6e4045e4/attachment.html>

From jan.lahoda at oracle.com  Tue Mar  5 15:55:03 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 5 Mar 2019 16:55:03 +0100
Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException:
 String index out of range: -2
Message-ID: <5C7E9BD7.1070607@oracle.com>

Hi,

Seems that some classfiles have a weird EnclosingMethod attribute - for 
(local/anonymous) class A, the EnclosingMethod attribute states the 
enclosing class is C, but the name of C is not a prefix of the name of 
A. This appears to be contradictory to JLS 13.1., so the proposal is to 
reject such classfiles.

Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8215407

How does this look?

Thanks,
     Jan

From joe.darcy at oracle.com  Tue Mar  5 16:33:25 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 5 Mar 2019 08:33:25 -0800
Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException:
 String index out of range: -2
In-Reply-To: <5C7E9BD7.1070607@oracle.com>
References: <5C7E9BD7.1070607@oracle.com>
Message-ID: <df3a5947-ee18-3584-c00e-7fa7abc43943@oracle.com>

Hi Jan,

Do you think this issue merits a CSR for the behavioral change?

Thanks,

-Joe

On 3/5/2019 7:55 AM, Jan Lahoda wrote:
> Hi,
>
> Seems that some classfiles have a weird EnclosingMethod attribute - 
> for (local/anonymous) class A, the EnclosingMethod attribute states 
> the enclosing class is C, but the name of C is not a prefix of the 
> name of A. This appears to be contradictory to JLS 13.1., so the 
> proposal is to reject such classfiles.
>
> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407
>
> How does this look?
>
> Thanks,
> ??? Jan

From jan.lahoda at oracle.com  Tue Mar  5 17:00:47 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 5 Mar 2019 18:00:47 +0100
Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException:
 String index out of range: -2
In-Reply-To: <df3a5947-ee18-3584-c00e-7fa7abc43943@oracle.com>
References: <5C7E9BD7.1070607@oracle.com>
 <df3a5947-ee18-3584-c00e-7fa7abc43943@oracle.com>
Message-ID: <5C7EAB3F.4050402@oracle.com>

On 5.3.2019 17:33, Joe Darcy wrote:
> Hi Jan,
>
> Do you think this issue merits a CSR for the behavioral change?

Good question! It is true that javac may now refuse to load classfiles 
that didn't lead to the exception before, so I guess a CSR may be in 
order. I've started with it here:
https://bugs.openjdk.java.net/browse/JDK-8220167

Feedback on the CSR is very welcome as well!

Thanks,
     Jan

>
> Thanks,
>
> -Joe
>
> On 3/5/2019 7:55 AM, Jan Lahoda wrote:
>> Hi,
>>
>> Seems that some classfiles have a weird EnclosingMethod attribute -
>> for (local/anonymous) class A, the EnclosingMethod attribute states
>> the enclosing class is C, but the name of C is not a prefix of the
>> name of A. This appears to be contradictory to JLS 13.1., so the
>> proposal is to reject such classfiles.
>>
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407
>>
>> How does this look?
>>
>> Thanks,
>>     Jan

From cushon at google.com  Tue Mar  5 20:06:27 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 5 Mar 2019 15:06:27 -0500
Subject: RFR: 8193277: SimpleFileObject inconsistency between getName and
 getShortName
Message-ID: <CAL4QsguBXzc_kQ0ZUofMvQzpoGT8nbkGNZGWiqY=SL+343sLhw@mail.gmail.com>

Hi,

Please consider this small fix to make symlink handling consistent between
SimpleFileObject#getName and SimpleFileObject#getShortName.

webrev: http://cr.openjdk.java.net/~cushon/8193277/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8193277
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190305/1668006c/attachment.html>

From jonathan.gibbons at oracle.com  Tue Mar  5 20:16:29 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 5 Mar 2019 12:16:29 -0800
Subject: RFR: 8193277: SimpleFileObject inconsistency between getName and
 getShortName
In-Reply-To: <CAL4QsguBXzc_kQ0ZUofMvQzpoGT8nbkGNZGWiqY=SL+343sLhw@mail.gmail.com>
References: <CAL4QsguBXzc_kQ0ZUofMvQzpoGT8nbkGNZGWiqY=SL+343sLhw@mail.gmail.com>
Message-ID: <8a5259e3-e050-f942-7713-1b79eff82bfc@oracle.com>

Liam,

There can be problems with symbolic links on Windows. Have you tried the 
test on a Windows system?

-- Jon

On 3/5/19 12:06 PM, Liam Miller-Cushon wrote:
> Hi,
>
> Please consider this small fix to make symlink handling consistent 
> between SimpleFileObject#getName and SimpleFileObject#getShortName.
>
> webrev: http://cr.openjdk.java.net/~cushon/8193277/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8193277

From jonathan.gibbons at oracle.com  Tue Mar  5 20:20:01 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 5 Mar 2019 12:20:01 -0800
Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException:
 String index out of range: -2
In-Reply-To: <5C7EAB3F.4050402@oracle.com>
References: <5C7E9BD7.1070607@oracle.com>
 <df3a5947-ee18-3584-c00e-7fa7abc43943@oracle.com>
 <5C7EAB3F.4050402@oracle.com>
Message-ID: <44fb40ef-6f77-a389-7559-cbe04ae4e1f1@oracle.com>

Jan,

Is checking for a prefix good enough??? It seems like that would be 
necessary but not sufficient.

-- Jon

On 3/5/19 9:00 AM, Jan Lahoda wrote:
> On 5.3.2019 17:33, Joe Darcy wrote:
>> Hi Jan,
>>
>> Do you think this issue merits a CSR for the behavioral change?
>
> Good question! It is true that javac may now refuse to load classfiles 
> that didn't lead to the exception before, so I guess a CSR may be in 
> order. I've started with it here:
> https://bugs.openjdk.java.net/browse/JDK-8220167
>
> Feedback on the CSR is very welcome as well!
>
> Thanks,
> ??? Jan
>
>>
>> Thanks,
>>
>> -Joe
>>
>> On 3/5/2019 7:55 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Seems that some classfiles have a weird EnclosingMethod attribute -
>>> for (local/anonymous) class A, the EnclosingMethod attribute states
>>> the enclosing class is C, but the name of C is not a prefix of the
>>> name of A. This appears to be contradictory to JLS 13.1., so the
>>> proposal is to reject such classfiles.
>>>
>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407
>>>
>>> How does this look?
>>>
>>> Thanks,
>>> ??? Jan

From cushon at google.com  Tue Mar  5 20:30:55 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 5 Mar 2019 15:30:55 -0500
Subject: RFR: 8193277: SimpleFileObject inconsistency between getName and
 getShortName
In-Reply-To: <8a5259e3-e050-f942-7713-1b79eff82bfc@oracle.com>
References: <CAL4QsguBXzc_kQ0ZUofMvQzpoGT8nbkGNZGWiqY=SL+343sLhw@mail.gmail.com>
 <8a5259e3-e050-f942-7713-1b79eff82bfc@oracle.com>
Message-ID: <CAL4QsgtzSrj9Ep1NfPMPXNhsCy4-VbnbnLfi3BjHWduArThFgg@mail.gmail.com>

On Tue, Mar 5, 2019 at 3:16 PM Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:

> There can be problems with symbolic links on Windows. Have you tried the
> test on a Windows system?
>

Not yet, I just sent it to the submit repo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190305/09a7c32d/attachment-0001.html>

From cushon at google.com  Tue Mar  5 22:36:30 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 5 Mar 2019 17:36:30 -0500
Subject: RFR: 8193277: SimpleFileObject inconsistency between getName and
 getShortName
In-Reply-To: <CAL4QsgtzSrj9Ep1NfPMPXNhsCy4-VbnbnLfi3BjHWduArThFgg@mail.gmail.com>
References: <CAL4QsguBXzc_kQ0ZUofMvQzpoGT8nbkGNZGWiqY=SL+343sLhw@mail.gmail.com>
 <8a5259e3-e050-f942-7713-1b79eff82bfc@oracle.com>
 <CAL4QsgtzSrj9Ep1NfPMPXNhsCy4-VbnbnLfi3BjHWduArThFgg@mail.gmail.com>
Message-ID: <CAL4QsgtpyO7Ge=KAEBc-QKQbZthFjoJmcj5yiRBNbf-uGVVVqg@mail.gmail.com>

The submit repo build is clean.

On Tue, Mar 5, 2019 at 3:30 PM Liam Miller-Cushon <cushon at google.com> wrote:

> On Tue, Mar 5, 2019 at 3:16 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> There can be problems with symbolic links on Windows. Have you tried the
>> test on a Windows system?
>>
>
> Not yet, I just sent it to the submit repo.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190305/795d5826/attachment.html>

From jan.lahoda at oracle.com  Wed Mar  6 10:31:15 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 6 Mar 2019 11:31:15 +0100
Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException:
 String index out of range: -2
In-Reply-To: <44fb40ef-6f77-a389-7559-cbe04ae4e1f1@oracle.com>
References: <5C7E9BD7.1070607@oracle.com>
 <df3a5947-ee18-3584-c00e-7fa7abc43943@oracle.com>
 <5C7EAB3F.4050402@oracle.com>
 <44fb40ef-6f77-a389-7559-cbe04ae4e1f1@oracle.com>
Message-ID: <5C7FA173.5000707@oracle.com>

Hi Jon,

On 5.3.2019 21:20, Jonathan Gibbons wrote:
> Jan,
>
> Is checking for a prefix good enough?   It seems like that would be
> necessary but not sufficient.

What specific additional checks do you foresee? The 
ClassReader.simpleBinaryName method does some additional checks, like 
that the class suffix is non-empty and starts with '$'.

Thanks,
     Jan

>
> -- Jon
>
> On 3/5/19 9:00 AM, Jan Lahoda wrote:
>> On 5.3.2019 17:33, Joe Darcy wrote:
>>> Hi Jan,
>>>
>>> Do you think this issue merits a CSR for the behavioral change?
>>
>> Good question! It is true that javac may now refuse to load classfiles
>> that didn't lead to the exception before, so I guess a CSR may be in
>> order. I've started with it here:
>> https://bugs.openjdk.java.net/browse/JDK-8220167
>>
>> Feedback on the CSR is very welcome as well!
>>
>> Thanks,
>>     Jan
>>
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 3/5/2019 7:55 AM, Jan Lahoda wrote:
>>>> Hi,
>>>>
>>>> Seems that some classfiles have a weird EnclosingMethod attribute -
>>>> for (local/anonymous) class A, the EnclosingMethod attribute states
>>>> the enclosing class is C, but the name of C is not a prefix of the
>>>> name of A. This appears to be contradictory to JLS 13.1., so the
>>>> proposal is to reject such classfiles.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407
>>>>
>>>> How does this look?
>>>>
>>>> Thanks,
>>>>     Jan

From GROEGES at uk.ibm.com  Thu Mar  7 09:56:26 2019
From: GROEGES at uk.ibm.com (Steve Groeger)
Date: Thu, 7 Mar 2019 09:56:26 +0000
Subject: RFR: [8218152] javac fails and exits with no error if a bad
 annotation processor is on the classpath
In-Reply-To: <5C7D12B9.5060801@oracle.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
 <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
 <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>
 <5C616E68.5050103@oracle.com>
 <OF05AD88C8.5056BCAA-ON802583A0.00362FFF-802583A0.0036C19B@notes.na.collabserv.com>
 <5C6432DB.7070208@oracle.com>
 <OF9B65D231.51A3D4D7-ON802583B0.004BA69C-802583B0.004CF0F1@notes.na.collabserv.com>
 <5C7D12B9.5060801@oracle.com>
Message-ID: <OF7DBC92C7.D5E92FCB-ON802583B6.0035CF34-802583B6.00369B39@notes.na.collabserv.com>

Hi Jan, 

Thanks for providing a possible test for the malformed Annotation 
Processor.
I have taken the code you provided and tweaked it a bit (for jdk) and had 
to 
write a similar thing for jdk8u as some of the functionality in the test 
is not 
available in the same form in jdk8u (well, not that I could find!!!)

I would be grateful if you could review to code in the new webrevs.

http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.02/
http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.02/

Any issues pelase let me know.

PS. I left the FatalErorr in JavacProcessingEnvironment.java as we
wanted Jon to comment on whether this is what is required or whether
we go with your previous suggestion.

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190307/d4571b8a/attachment.html>

From jonathan.gibbons at oracle.com  Thu Mar  7 20:37:56 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 7 Mar 2019 12:37:56 -0800
Subject: RFR:[13] XS: JDK-8220249: fix headings in java.compiler
Message-ID: <613b7450-ada8-2493-8461-b45bfef0b6ec@oracle.com>

Please review a trivial doc fix to adjust a heading in the java.compiler 
module.? The heading is changed from <h3> to <h2>.

-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8220249

$ hg diff -R open
diff -r fb9541185457 
src/java.compiler/share/classes/javax/annotation/processing/Generated.java
--- 
a/src/java.compiler/share/classes/javax/annotation/processing/Generated.java 
Tue Mar 05 10:35:29 2019 -0800
+++ 
b/src/java.compiler/share/classes/javax/annotation/processing/Generated.java 
Thu Mar 07 12:31:38 2019 -0800
@@ -33,7 +33,7 @@
 ? * It can also be used to differentiate user written code from 
generated code in
 ? * a single file.
 ? *
- * <h3>Examples:</h3>
+ * <h2>Examples:</h2>
 ? * <pre>
 ? *?? &#064;Generated("com.example.Generator")
 ? * </pre>




From joe.darcy at oracle.com  Thu Mar  7 23:34:53 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 7 Mar 2019 15:34:53 -0800
Subject: RFR:[13] XS: JDK-8220249: fix headings in java.compiler
In-Reply-To: <613b7450-ada8-2493-8461-b45bfef0b6ec@oracle.com>
References: <613b7450-ada8-2493-8461-b45bfef0b6ec@oracle.com>
Message-ID: <6becbba7-6aaf-1242-1efd-67377c36bbbb@oracle.com>

+1

Cheers,

-Joe

On 3/7/2019 12:37 PM, Jonathan Gibbons wrote:
> Please review a trivial doc fix to adjust a heading in the 
> java.compiler module.? The heading is changed from <h3> to <h2>.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220249
>
> $ hg diff -R open
> diff -r fb9541185457 
> src/java.compiler/share/classes/javax/annotation/processing/Generated.java
> --- 
> a/src/java.compiler/share/classes/javax/annotation/processing/Generated.java 
> Tue Mar 05 10:35:29 2019 -0800
> +++ 
> b/src/java.compiler/share/classes/javax/annotation/processing/Generated.java 
> Thu Mar 07 12:31:38 2019 -0800
> @@ -33,7 +33,7 @@
> ? * It can also be used to differentiate user written code from 
> generated code in
> ? * a single file.
> ? *
> - * <h3>Examples:</h3>
> + * <h2>Examples:</h2>
> ? * <pre>
> ? *?? &#064;Generated("com.example.Generator")
> ? * </pre>
>
>
>

From cushon at google.com  Fri Mar  8 17:44:46 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 8 Mar 2019 12:44:46 -0500
Subject: RFR: 8220377: Unused field SourceFileObject.flatname
Message-ID: <CAL4QsgtQdSAmFxL0BbeXRDqnP0fN7bM4URB8UiX=kb7HOf2aLQ@mail.gmail.com>

Hi,

Please review this cleanup to remove an unused field
in SourceFileObject.flatname.

bug: https://bugs.openjdk.java.net/browse/JDK-8220377
webrev: http://cr.openjdk.java.net/~cushon/8220377/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190308/db308548/attachment.html>

From jonathan.gibbons at oracle.com  Fri Mar  8 18:22:53 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 8 Mar 2019 10:22:53 -0800
Subject: RFR: 8220377: Unused field SourceFileObject.flatname
In-Reply-To: <CAL4QsgtQdSAmFxL0BbeXRDqnP0fN7bM4URB8UiX=kb7HOf2aLQ@mail.gmail.com>
References: <CAL4QsgtQdSAmFxL0BbeXRDqnP0fN7bM4URB8UiX=kb7HOf2aLQ@mail.gmail.com>
Message-ID: <6df0ced7-84a9-b82a-0802-1b55eaa885e6@oracle.com>

+1


On 03/08/2019 09:44 AM, Liam Miller-Cushon wrote:
> Hi,
>
> Please review this cleanup to remove an unused field 
> in?SourceFileObject.flatname.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220377
> webrev: http://cr.openjdk.java.net/~cushon/8220377/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220377/webrev.00/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190308/9f8837e2/attachment.html>

From cushon at google.com  Fri Mar  8 19:56:12 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 8 Mar 2019 14:56:12 -0500
Subject: RFR: 8220377: Unused field SourceFileObject.flatname
In-Reply-To: <6df0ced7-84a9-b82a-0802-1b55eaa885e6@oracle.com>
References: <CAL4QsgtQdSAmFxL0BbeXRDqnP0fN7bM4URB8UiX=kb7HOf2aLQ@mail.gmail.com>
 <6df0ced7-84a9-b82a-0802-1b55eaa885e6@oracle.com>
Message-ID: <CAL4QsguPZaOJ8UTtLHuQv901jFa6iVV6VJFTGaNw4+YEv2M6ZA@mail.gmail.com>

Thanks for the review.

Merged as http://hg.openjdk.java.net/jdk/jdk/rev/fd6c13481231.

On Fri, Mar 8, 2019 at 1:23 PM Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:

> +1
>
> On 03/08/2019 09:44 AM, Liam Miller-Cushon wrote:
>
> Hi,
>
> Please review this cleanup to remove an unused field
> in SourceFileObject.flatname.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220377
> webrev: http://cr.openjdk.java.net/~cushon/8220377/webrev.00/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190308/7fc3be25/attachment.html>

From eaftan at google.com  Sat Mar  9 01:41:07 2019
From: eaftan at google.com (Eddie Aftandilian)
Date: Fri, 8 Mar 2019 17:41:07 -0800
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <ad46feee-82ed-eedc-89cd-e1671a5bc27f@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
 <b45c4699-1490-dd6a-bdb3-751355e90027@oracle.com>
 <a25683a4-a0d6-a60c-de9c-5ebf98c6d23d@oracle.com>
 <CAL4QsgtW6xjj8vSYgRi0Aj_xgd7NNTXS59jog45FqWiVvgt=RA@mail.gmail.com>
 <ad46feee-82ed-eedc-89cd-e1671a5bc27f@oracle.com>
Message-ID: <CA+7OGVoF5jUXQQCsQmCsBkS2sZxOY-CGv79imPw2mFYVSSVLqw@mail.gmail.com>

Sorry for the delay, I got pulled off onto other tasks for a while.

Vicente said:
> I'm not opposed to adding more lines to the LNT if that's what you are
proposing, but I wonder about the benefit. I mean how bad it is to miss for
one, two lines vs having bigger class files. Actually, this is an
interesting experiment @Eddie could you please run an experiment to see how
bigger would the class files for the whole JDK be with your patch? I'm also
interested in redundant lines, it could be that this code adds redundant
lines to the LNT and we should avoid that

I ran the experiment on the class file sizes for the JDK:

Without patch:
eaftan at eaftan:~/openjdk-source/jdk/build/linux-x86_64-server-release/jdk$
find -name *.class -type f | xargs du -cb
2929167 total

With patch:
eaftan at eaftan:~/openjdk-source/jdk/build/linux-x86_64-server-release/jdk$
find -name *.class -type f | xargs du -cb
2929631 total

Difference: +0.0158407%

This seems suspiciously small, but I confirmed by inspection that the javac
patch had the expected effect.  For example, when looking at the LNT for
com.sun.crypto.provider.AESCipher#getEngineKeySize, in the patched version
I see a new LNT entry `line 510: 32`, where the relevant source lines are

```
509             throw new InvalidKeyException("Invalid AES key length: " +
510                                           encoded.length + " bytes");
```

So it seems the impact on class file size is minimal.

Re: redundant lines in the LNT -- my (poor) understanding of the javac code
that emits LNT entries is that it tries to prevent this.  Any suggestions
on how to determine whether there are redundant LNT entries being emitted?

-Eddie

On Thu, Feb 21, 2019 at 3:37 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 21/02/2019 19:27, Liam Miller-Cushon wrote:
>
> For what it's worth I filed JDK-8218650 after a real debugging session
> where I spent a while trying to understand an 'impossible' NPE before
> realizing it was actually happening on the next line. So anecdotally at
> leave one moderately savvy consumer of debug info would have benefited from
> the extra LNT entries :)
>
> The approach in JDK-8218628 sounds very promising, though. That
> information would have been sufficient in the example that motivated
> JDK-8218650.
>
> > e.g. access to fields in different classes with same name :-)
>
> Won't that be an issue even if javac starts emitting LNT entries for field
> accesses *and* the NPE messages get more detailed?
>
> i.e. you could also have `b.b.b` and even if we know the line and that `b`
> was involved it's ambiguous which dereference failed. (If the NPE message
> included a qualified name of `b` that would be sufficient except for some
> really pathological cases.)
>
> Yes - in that case not much can be done - unless we add column info too :-)
>
> Another option for improving the message for `b.b.b` would be to include a
> column number, which was discussed in JDK-8020204.
>
> Ah :-)
>
> Maurizio
>
>
> On Thu, Feb 21, 2019 at 10:59 AM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> Yeah - I was afraid that will be the case.
>>
>> And I'm wondering what happens in cases where you have stuff like
>>
>> b.
>>    b.
>>       b.
>>
>> e.g. access to fields in different classes with same name :-)
>>
>> Of course a corner case, but...
>>
>> Maurizio
>>
>>
>> On 21/02/2019 17:38, Vicente Romero wrote:
>> > but it still refers to line 13, so it doesn't seem like it will
>> > produce an exact reference to the actual line where the NPE happened
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190308/56e5e4ea/attachment-0001.html>

From ronshapiro at google.com  Sun Mar 10 20:41:24 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Sun, 10 Mar 2019 16:41:24 -0400
Subject: RFR 8220378: Unused Names fields
In-Reply-To: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
References: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
Message-ID: <CACA6h9vSxAe_EYgCakeSBfjy7go5knk=UbrOmsKZHoOxPstm6w@mail.gmail.com>

(and thanks to Liam for uploading the webrev+filing the bug for me.)

On Sun, Mar 10, 2019 at 4:40 PM Ron Shapiro <ronshapiro at google.com> wrote:

> Hi,
>
> Please review this cleanup to remove unused fields in Names.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220378
> webrev: http://cr.openjdk.java.net/~cushon/8220378/webrev.00/
>
> Thanks,
> Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190310/ff2d32b6/attachment.html>

From ronshapiro at google.com  Sun Mar 10 20:40:54 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Sun, 10 Mar 2019 16:40:54 -0400
Subject: RFR 8220378: Unused Names fields
Message-ID: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>

Hi,

Please review this cleanup to remove unused fields in Names.

bug: https://bugs.openjdk.java.net/browse/JDK-8220378
webrev: http://cr.openjdk.java.net/~cushon/8220378/webrev.00/

Thanks,
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190310/2108967e/attachment.html>

From cushon at google.com  Sun Mar 10 22:02:10 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Sun, 10 Mar 2019 18:02:10 -0400
Subject: RFR 8220378: Unused Names fields
In-Reply-To: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
References: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
Message-ID: <CAL4Qsgsr6qCG-qLbMr_TmzzXBxf2_Q0EYfxZgMiPOTLMf2hXig@mail.gmail.com>

I'm not a Reviewer, but this LGTM.

On Sun, Mar 10, 2019 at 4:41 PM Ron Shapiro <ronshapiro at google.com> wrote:

> Hi,
>
> Please review this cleanup to remove unused fields in Names.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220378
> webrev: http://cr.openjdk.java.net/~cushon/8220378/webrev.00/
>
> Thanks,
> Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190310/9fb2da2b/attachment.html>

From jonathan.gibbons at oracle.com  Mon Mar 11 00:59:49 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 10 Mar 2019 17:59:49 -0700
Subject: RFR 8220378: Unused Names fields
In-Reply-To: <CAL4Qsgsr6qCG-qLbMr_TmzzXBxf2_Q0EYfxZgMiPOTLMf2hXig@mail.gmail.com>
References: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
 <CAL4Qsgsr6qCG-qLbMr_TmzzXBxf2_Q0EYfxZgMiPOTLMf2hXig@mail.gmail.com>
Message-ID: <a99c9018-2cbc-15f4-ea6a-14a3be1c7cf6@oracle.com>

That's a bigger list than I was expecting, with some surprising entries 
as well.

It will be interesting to spot-check a few to go back and see why the 
name was
introduced in the first place, to understand why it is no longer required.

-- Jon

On 3/10/19 3:02 PM, Liam Miller-Cushon wrote:
> I'm not a Reviewer, but this LGTM.
>
> On Sun, Mar 10, 2019 at 4:41 PM Ron Shapiro <ronshapiro at google.com 
> <mailto:ronshapiro at google.com>> wrote:
>
>     Hi,
>
>     Please review this cleanup to remove unused fields in Names.
>
>     bug: https://bugs.openjdk.java.net/browse/JDK-8220378
>     webrev: http://cr.openjdk.java.net/~cushon/8220378/webrev.00/
>
>     Thanks,
>     Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190310/ae77d287/attachment.html>

From vicente.romero at oracle.com  Mon Mar 11 14:02:30 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 11 Mar 2019 10:02:30 -0400
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <CA+7OGVoF5jUXQQCsQmCsBkS2sZxOY-CGv79imPw2mFYVSSVLqw@mail.gmail.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
 <b45c4699-1490-dd6a-bdb3-751355e90027@oracle.com>
 <a25683a4-a0d6-a60c-de9c-5ebf98c6d23d@oracle.com>
 <CAL4QsgtW6xjj8vSYgRi0Aj_xgd7NNTXS59jog45FqWiVvgt=RA@mail.gmail.com>
 <ad46feee-82ed-eedc-89cd-e1671a5bc27f@oracle.com>
 <CA+7OGVoF5jUXQQCsQmCsBkS2sZxOY-CGv79imPw2mFYVSSVLqw@mail.gmail.com>
Message-ID: <f07336ee-8e05-608f-97f2-b570d51a6a3d@oracle.com>

Hi Eddie,

Thanks for the additional experiments, it is good to know that there is 
not too much increase in the class file size after the patch

On 3/8/19 8:41 PM, Eddie Aftandilian wrote:
> Sorry for the delay, I got pulled off onto other tasks for a while.
>
> Vicente said:
> > I'm not opposed to adding more lines to the LNT if that's what you 
> are proposing, but I wonder about the benefit. I mean how bad it is to 
> miss for one, two lines vs having bigger class files. Actually, this 
> is an interesting experiment @Eddie could you please run an experiment 
> to see how bigger would the class files for the whole JDK be with your 
> patch? I'm also interested in redundant lines, it could be that this 
> code adds redundant lines to the LNT and we should avoid that
>
> I ran the experiment on the class file sizes for the JDK:
>
> Without patch:
> eaftan at eaftan:~/openjdk-source/jdk/build/linux-x86_64-server-release/jdk$ 
> find -name *.class -type f | xargs du -cb
> 2929167total
>
> With patch:
> eaftan at eaftan:~/openjdk-source/jdk/build/linux-x86_64-server-release/jdk$ 
> find -name *.class -type f | xargs du -cb
> 2929631total
>
> Difference: +0.0158407%
>
> This seems suspiciously small, but I confirmed by inspection that the 
> javac patch had the expected effect.? For example, when looking at the 
> LNT for com.sun.crypto.provider.AESCipher#getEngineKeySize, in the 
> patched version I see a new LNT entry `line 510: 32`, where the 
> relevant source lines are
>
> ```
> 509? ? ? ? ? ? ?throw new InvalidKeyException("Invalid AES key length: " +
> 510 ?encoded.length + " bytes");
> ```
>
> So it seems the impact on class file size is minimal.
>
> Re: redundant lines in the LNT -- my (poor) understanding of the javac 
> code that emits LNT entries is that it tries to prevent this.? Any 
> suggestions on how to determine whether there are redundant LNT 
> entries being emitted?

regarding this I think that the easiest way could be to determine what 
class files have different size, and get a set of them, produce the 
javap output and compare them. You should see the changes in the LNT and 
if there are redundant entries.

>
> -Eddie

Vicente

>
> On Thu, Feb 21, 2019 at 3:37 PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>
>     On 21/02/2019 19:27, Liam Miller-Cushon wrote:
>>     For what it's worth I filed?JDK-8218650 after a real debugging
>>     session where I spent a while trying to understand an
>>     'impossible' NPE before realizing it was actually happening on
>>     the next line. So anecdotally at leave one moderately savvy
>>     consumer of debug info would have benefited from the extra LNT
>>     entries :)
>>
>>     The approach in JDK-8218628 sounds very promising, though. That
>>     information would have been sufficient in the example that
>>     motivated JDK-8218650.
>>
>>     > e.g. access to fields in different classes with same name :-)
>>
>>     Won't that be an issue even if javac starts emitting LNT entries
>>     for field accesses *and* the NPE messages get more detailed?
>>
>>     i.e. you could also have `b.b.b` and even if we know the line and
>>     that `b` was involved it's ambiguous which dereference failed.
>>     (If the NPE message included a qualified name of `b` that would
>>     be sufficient except for some really pathological cases.)
>>
>     Yes - in that case not much can be done - unless we add column
>     info too :-)
>>     Another option for improving the message for `b.b.b` would be to
>>     include a column number, which was discussed in JDK-8020204.
>
>     Ah :-)
>
>     Maurizio
>
>>
>>     On Thu, Feb 21, 2019 at 10:59 AM Maurizio Cimadamore
>>     <maurizio.cimadamore at oracle.com
>>     <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>         Yeah - I was afraid that will be the case.
>>
>>         And I'm wondering what happens in cases where you have stuff like
>>
>>         b.
>>         ?? b.
>>         ????? b.
>>
>>         e.g. access to fields in different classes with same name :-)
>>
>>         Of course a corner case, but...
>>
>>         Maurizio
>>
>>
>>         On 21/02/2019 17:38, Vicente Romero wrote:
>>         > but it still refers to line 13, so it doesn't seem like it
>>         will
>>         > produce an exact reference to the actual line where the NPE
>>         happened
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190311/351be979/attachment.html>

From brian.goetz at oracle.com  Mon Mar 11 14:28:59 2019
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 11 Mar 2019 10:28:59 -0400
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <5e645555-a300-11ab-dd67-abc8a58c8b92@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
 <5e645555-a300-11ab-dd67-abc8a58c8b92@oracle.com>
Message-ID: <9917AB51-A1BD-400B-9B27-91B229961F5F@oracle.com>

I agree. Without a clear target for what LNT should and should not be used for, the current situation is not obviously optimal, so its not really fair to use loaded terms like ?bloat? or ?throw away information? for adding to / removing from the LNT.  

This is a good example of a situation that comes up often, which is: we start discussing a solution before we?ve got a shared understanding of the problem.  So I agree with the path of: let?s step back for a moment, discuss the problem, convince ourselves it is a problem, explore solutions, and then, assuming there?s consensus, drive towards implementing the best of the solutions explored.  

> On Feb 21, 2019, at 12:02 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 21/02/2019 16:49, Maurizio Cimadamore wrote:
>> 
>> I guess what I'm arguing is not that we should add LNT - but that I see no solid basis for doing this for methods, but not for field access. If 8218628 will cure us from all sins :-) then the same argument surely could be applied to method access?
>> 
> Where I'm truly going with this is - we never really collected a list of use cases as to when it would be nice to have a LNT generated; there are many use cases out there, from debuggers to static analysis tools (code coverage, findbugs...) and each of these might be affected in subtle ways. Heck, once we've even stumbled upon a bug where missing LNT entry was causing the JRockit VM to crash ;-)
> 
> So, I think that, stepping back from this specific issue, we should try (with the help of the community :-)) to identify the conditions under which it would be desirable to have a LNT entry, and come up with some sort of informal javac spec for that.
> 
> Maurizio
> 
> 


From cushon at google.com  Mon Mar 11 16:40:40 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 11 Mar 2019 09:40:40 -0700
Subject: RFR 8220378: Unused Names fields
In-Reply-To: <a99c9018-2cbc-15f4-ea6a-14a3be1c7cf6@oracle.com>
References: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
 <CAL4Qsgsr6qCG-qLbMr_TmzzXBxf2_Q0EYfxZgMiPOTLMf2hXig@mail.gmail.com>
 <a99c9018-2cbc-15f4-ea6a-14a3be1c7cf6@oracle.com>
Message-ID: <CAL4Qsgs=O-6LZ+P5TE2DdBUiyqCnVZDhxUZCqpmY6_GFnUrWOA@mail.gmail.com>

On Sun, Mar 10, 2019 at 6:00 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> It will be interesting to spot-check a few to go back and see why the name
> was
> introduced in the first place, to understand why it is no longer required.
>
Two of the more recent unused entries are:
* java.lang.invoke.MethodHandle added in
http://hg.openjdk.java.net/jdk/jdk/rev/4161b56e0d20, and
* java.lang.AutoCloseable added in
http://hg.openjdk.java.net/jdk/jdk/rev/3a8158299c51

Both of those were unused at the time they were added, perhaps they were
left over from earlier iterations of the change that was eventually
submitted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190311/6ab9f1d2/attachment-0001.html>

From jonathan.gibbons at oracle.com  Mon Mar 11 17:10:30 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 11 Mar 2019 10:10:30 -0700
Subject: RFR 8220378: Unused Names fields
In-Reply-To: <CAL4Qsgs=O-6LZ+P5TE2DdBUiyqCnVZDhxUZCqpmY6_GFnUrWOA@mail.gmail.com>
References: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
 <CAL4Qsgsr6qCG-qLbMr_TmzzXBxf2_Q0EYfxZgMiPOTLMf2hXig@mail.gmail.com>
 <a99c9018-2cbc-15f4-ea6a-14a3be1c7cf6@oracle.com>
 <CAL4Qsgs=O-6LZ+P5TE2DdBUiyqCnVZDhxUZCqpmY6_GFnUrWOA@mail.gmail.com>
Message-ID: <4b73761a-f1b2-5150-fb13-7234fc9c216b@oracle.com>


On 3/11/19 9:40 AM, Liam Miller-Cushon wrote:
> On Sun, Mar 10, 2019 at 6:00 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     It will be interesting to spot-check a few to go back and see why
>     the name was
>     introduced in the first place, to understand why it is no longer
>     required.
>
> Two of the more recent unused entries are:
> * java.lang.invoke.MethodHandle added in 
> http://hg.openjdk.java.net/jdk/jdk/rev/4161b56e0d20, and
> * java.lang.AutoCloseable added in 
> http://hg.openjdk.java.net/jdk/jdk/rev/3a8158299c51
>
> Both of those were unused at the time they were added, perhaps they 
> were left over from earlier iterations of the change that was 
> eventually submitted.


Yes, I see that the names are created and used indirectly via Symtab and Symbol/Type.

+ autoCloseableType = enterClass("java.lang.AutoCloseable");

+ methodHandleType = enterClass("java.lang.invoke.MethodHandle");

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190311/33483670/attachment.html>

From maurizio.cimadamore at oracle.com  Mon Mar 11 21:23:14 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 11 Mar 2019 21:23:14 +0000
Subject: RFR 8220378: Unused Names fields
In-Reply-To: <4b73761a-f1b2-5150-fb13-7234fc9c216b@oracle.com>
References: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
 <CAL4Qsgsr6qCG-qLbMr_TmzzXBxf2_Q0EYfxZgMiPOTLMf2hXig@mail.gmail.com>
 <a99c9018-2cbc-15f4-ea6a-14a3be1c7cf6@oracle.com>
 <CAL4Qsgs=O-6LZ+P5TE2DdBUiyqCnVZDhxUZCqpmY6_GFnUrWOA@mail.gmail.com>
 <4b73761a-f1b2-5150-fb13-7234fc9c216b@oracle.com>
Message-ID: <34905019-aa3c-0bf1-b727-55f51ba5e805@oracle.com>

Since I had my hands in both patches, I can confirm these usages were 
leftover of things that previous support for both features used to do, 
but which we forgot to remove after cleaning up.

I believe in the case of AutoCloseable, the name was used to trigger 
some diagnostic generation (which I then replaced to be based on 
symbols, as with rest of javac); in the case of MethodHandle, the 292 
support initially had some support for recognizing classfiles using 
polysig methods using something other than java.lang.invoke - and at the 
classfile level, working with names was easier and that's what the logic 
used to do.

Both are unnecessary at this stage (and have been for quite some time 
--- blush).

Thanks
Maurizio

On 11/03/2019 17:10, Jonathan Gibbons wrote:
>
>
> On 3/11/19 9:40 AM, Liam Miller-Cushon wrote:
>> On Sun, Mar 10, 2019 at 6:00 PM Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>     It will be interesting to spot-check a few to go back and see why
>>     the name was
>>     introduced in the first place, to understand why it is no longer
>>     required.
>>
>> Two of the more recent unused entries are:
>> * java.lang.invoke.MethodHandle added in 
>> http://hg.openjdk.java.net/jdk/jdk/rev/4161b56e0d20, and
>> * java.lang.AutoCloseable added in 
>> http://hg.openjdk.java.net/jdk/jdk/rev/3a8158299c51
>>
>> Both of those were unused at the time they were added, perhaps they 
>> were left over from earlier iterations of the change that was 
>> eventually submitted.
>
>
> Yes, I see that the names are created and used indirectly via Symtab and Symbol/Type.
>
> + autoCloseableType = enterClass("java.lang.AutoCloseable");
>
> + methodHandleType = enterClass("java.lang.invoke.MethodHandle");
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190311/f09ef5ca/attachment.html>

From cushon at google.com  Wed Mar 13 22:46:59 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Mar 2019 15:46:59 -0700
Subject: RFR: 8193277: SimpleFileObject inconsistency between getName and
 getShortName
In-Reply-To: <CAL4QsgtpyO7Ge=KAEBc-QKQbZthFjoJmcj5yiRBNbf-uGVVVqg@mail.gmail.com>
References: <CAL4QsguBXzc_kQ0ZUofMvQzpoGT8nbkGNZGWiqY=SL+343sLhw@mail.gmail.com>
 <8a5259e3-e050-f942-7713-1b79eff82bfc@oracle.com>
 <CAL4QsgtzSrj9Ep1NfPMPXNhsCy4-VbnbnLfi3BjHWduArThFgg@mail.gmail.com>
 <CAL4QsgtpyO7Ge=KAEBc-QKQbZthFjoJmcj5yiRBNbf-uGVVVqg@mail.gmail.com>
Message-ID: <CAL4Qsgu__zBfSJyYnz=3CF4MrOb6W__1O5t8sHk4teXmRurVwg@mail.gmail.com>

Any concerns with this, as long as the tests pass on all platforms?

On Tue, Mar 5, 2019 at 2:36 PM Liam Miller-Cushon <cushon at google.com> wrote:

> The submit repo build is clean.
>
> On Tue, Mar 5, 2019 at 3:30 PM Liam Miller-Cushon <cushon at google.com>
> wrote:
>
>> On Tue, Mar 5, 2019 at 3:16 PM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> There can be problems with symbolic links on Windows. Have you tried the
>>> test on a Windows system?
>>>
>>
>> Not yet, I just sent it to the submit repo.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/cc937b16/attachment.html>

From jonathan.gibbons at oracle.com  Wed Mar 13 23:40:10 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Mar 2019 16:40:10 -0700
Subject: RFR: 8193277: SimpleFileObject inconsistency between getName and
 getShortName
In-Reply-To: <CAL4Qsgu__zBfSJyYnz=3CF4MrOb6W__1O5t8sHk4teXmRurVwg@mail.gmail.com>
References: <CAL4QsguBXzc_kQ0ZUofMvQzpoGT8nbkGNZGWiqY=SL+343sLhw@mail.gmail.com>
 <8a5259e3-e050-f942-7713-1b79eff82bfc@oracle.com>
 <CAL4QsgtzSrj9Ep1NfPMPXNhsCy4-VbnbnLfi3BjHWduArThFgg@mail.gmail.com>
 <CAL4QsgtpyO7Ge=KAEBc-QKQbZthFjoJmcj5yiRBNbf-uGVVVqg@mail.gmail.com>
 <CAL4Qsgu__zBfSJyYnz=3CF4MrOb6W__1O5t8sHk4teXmRurVwg@mail.gmail.com>
Message-ID: <90203184-688c-9fe9-58d7-5fb71eea84d3@oracle.com>

Hmmm, curious,

The src/ change is OK; all the concern is about the test, on Windows, 
and this text in the spec:

https://docs.oracle.com/javase/9/docs/api/java/nio/file/Files.html#createSymbolicLink-java.nio.file.Path-java.nio.file.Path-java.nio.file.attribute.FileAttribute...-

> Where symbolic links are supported, but the underlying |FileStore| 
> <https://docs.oracle.com/javase/9/docs/api/java/nio/file/FileStore.html> 
> does not support symbolic links, then this may fail with an 
> |IOException| 
> <https://docs.oracle.com/javase/9/docs/api/java/io/IOException.html>. 
> Additionally, some operating systems may require that the Java virtual 
> machine be started with implementation specific privileges to create 
> symbolic links, in which case this method may throw |IOException|.

That's spec-speak to cover the case that the historical perception has 
been that (IIRC) you require admin privileges on Windows to create 
symbolic links.

Taking a quick survey of existing tests ...

$ grep -rl Files.createSym open/test/langtools/
open/test/langtools/tools/javac/modules/SourceInSymlinkTest.java
open/test/langtools/tools/javac/file/SymLinkTest.java
open/test/langtools/tools/javac/file/SymLinkArchiveTest.java
open/test/langtools/tools/javac/links/LinksTest.java

... I see that 3 of the 4 use something like this idiom:

> ??????? try {
> ??????????? Files.createSymbolicLink(lsrc, Paths.get("src"));
> ??????? } catch (FileSystemException fse) {
> ??????????? System.err.println("warning: test passes vacuously, 
> sym-link could not be created");
> ??????????? System.err.println(fse.getMessage());
> ??????????? return;
> ??????? }

But SymLinkArchiveTest.java does not -- it just does a plain call of 
Files.createSymbolicLink, and the test is not excluded (i.e. listed on 
the ProblemList)

So, given your assertion that you get a clean build/test run, and given 
the existence of a separate test that appears to be able to create 
symbolic links on all platforms, I guess the test is good to go.? But if 
any problems arise with this test, we may need to wrap the call as 
illustrated above. Or you can proactively wrap it, to be on the safe side.

-- jon



On 03/13/2019 03:46 PM, Liam Miller-Cushon wrote:
> Any concerns with this, as long as the tests pass on all platforms?
>
> On Tue, Mar 5, 2019 at 2:36 PM Liam Miller-Cushon <cushon at google.com 
> <mailto:cushon at google.com>> wrote:
>
>     The submit repo build is clean.
>
>     On Tue, Mar 5, 2019 at 3:30 PM Liam Miller-Cushon
>     <cushon at google.com <mailto:cushon at google.com>> wrote:
>
>         On Tue, Mar 5, 2019 at 3:16 PM Jonathan Gibbons
>         <jonathan.gibbons at oracle.com
>         <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>             There can be problems with symbolic links on Windows. Have
>             you tried the
>             test on a Windows system?
>
>
>         Not yet, I just sent it to the submit repo.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/10b62b04/attachment.html>

From cushon at google.com  Wed Mar 13 23:55:08 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Mar 2019 16:55:08 -0700
Subject: RFR: 8220633: Optimize CacheFSInfo
Message-ID: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>

Hi,

Please consider the following optimization to CacheFSInfo, which makes the
caching finer-grained and reduces the number of filesystem calls.

bug: https://bugs.openjdk.java.net/browse/JDK-8220633
webrev: http://cr.openjdk.java.net/~cushon/8220633/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/756f4513/attachment.html>

From jonathan.gibbons at oracle.com  Thu Mar 14 00:12:34 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Mar 2019 17:12:34 -0700
Subject: RFR: 8220633: Optimize CacheFSInfo
In-Reply-To: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>
References: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>
Message-ID: <4d1e769d-51ce-276d-868b-7fb840466df0@oracle.com>

Liam,

Please don't reformat the scary comment ;-)? You'll frighten away any 
scripts
that might check for the comment.

Is there a reason you don't use computeIfAbsent in getJarClassPath?

-- Jon


On 03/13/2019 04:55 PM, Liam Miller-Cushon wrote:
> Hi,
>
> Please consider the following optimization to CacheFSInfo, which makes 
> the caching finer-grained and reduces the number of filesystem calls.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220633
> webrev: http://cr.openjdk.java.net/~cushon/8220633/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220633/webrev.00/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/714abb0e/attachment-0001.html>

From cushon at google.com  Thu Mar 14 00:23:51 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Mar 2019 17:23:51 -0700
Subject: RFR: 8193277: SimpleFileObject inconsistency between getName and
 getShortName
In-Reply-To: <90203184-688c-9fe9-58d7-5fb71eea84d3@oracle.com>
References: <CAL4QsguBXzc_kQ0ZUofMvQzpoGT8nbkGNZGWiqY=SL+343sLhw@mail.gmail.com>
 <8a5259e3-e050-f942-7713-1b79eff82bfc@oracle.com>
 <CAL4QsgtzSrj9Ep1NfPMPXNhsCy4-VbnbnLfi3BjHWduArThFgg@mail.gmail.com>
 <CAL4QsgtpyO7Ge=KAEBc-QKQbZthFjoJmcj5yiRBNbf-uGVVVqg@mail.gmail.com>
 <CAL4Qsgu__zBfSJyYnz=3CF4MrOb6W__1O5t8sHk4teXmRurVwg@mail.gmail.com>
 <90203184-688c-9fe9-58d7-5fb71eea84d3@oracle.com>
Message-ID: <CAL4QsgtM1+FjAp=hc=O6uE-cLA8vZfzMuX9TE_vww5bOyGDc7Q@mail.gmail.com>

Thanks for the context. Proactively wrapping it sounds like a good idea, I
updated the change to do that:

http://cr.openjdk.java.net/~cushon/8193277/webrev.01/

(I also filed JDK-8220634 for SymLinkArchiveTest)

On Wed, Mar 13, 2019 at 4:40 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Hmmm, curious,
>
> The src/ change is OK; all the concern is about the test, on Windows, and
> this text in the spec:
>
>
> https://docs.oracle.com/javase/9/docs/api/java/nio/file/Files.html#createSymbolicLink-java.nio.file.Path-java.nio.file.Path-java.nio.file.attribute.FileAttribute
> ...-
>
> Where symbolic links are supported, but the underlying FileStore
> <https://docs.oracle.com/javase/9/docs/api/java/nio/file/FileStore.html>
> does not support symbolic links, then this may fail with an IOException
> <https://docs.oracle.com/javase/9/docs/api/java/io/IOException.html>.
> Additionally, some operating systems may require that the Java virtual
> machine be started with implementation specific privileges to create
> symbolic links, in which case this method may throw IOException.
>
>
> That's spec-speak to cover the case that the historical perception has
> been that (IIRC) you require admin privileges on Windows to create symbolic
> links.
>
> Taking a quick survey of existing tests ...
>
> $ grep -rl Files.createSym open/test/langtools/
> open/test/langtools/tools/javac/modules/SourceInSymlinkTest.java
> open/test/langtools/tools/javac/file/SymLinkTest.java
> open/test/langtools/tools/javac/file/SymLinkArchiveTest.java
> open/test/langtools/tools/javac/links/LinksTest.java
>
> ... I see that 3 of the 4 use something like this idiom:
>
>         try {
>             Files.createSymbolicLink(lsrc, Paths.get("src"));
>         } catch (FileSystemException fse) {
>             System.err.println("warning: test passes vacuously, sym-link
> could not be created");
>             System.err.println(fse.getMessage());
>             return;
>         }
>
>
> But SymLinkArchiveTest.java does not -- it just does a plain call of
> Files.createSymbolicLink, and the test is not excluded (i.e. listed on the
> ProblemList)
>
> So, given your assertion that you get a clean build/test run, and given
> the existence of a separate test that appears to be able to create symbolic
> links on all platforms, I guess the test is good to go.  But if any
> problems arise with this test, we may need to wrap the call as illustrated
> above. Or you can proactively wrap it, to be on the safe side.
>
> -- jon
>
>
>
> On 03/13/2019 03:46 PM, Liam Miller-Cushon wrote:
>
> Any concerns with this, as long as the tests pass on all platforms?
>
> On Tue, Mar 5, 2019 at 2:36 PM Liam Miller-Cushon <cushon at google.com>
> wrote:
>
>> The submit repo build is clean.
>>
>> On Tue, Mar 5, 2019 at 3:30 PM Liam Miller-Cushon <cushon at google.com>
>> wrote:
>>
>>> On Tue, Mar 5, 2019 at 3:16 PM Jonathan Gibbons <
>>> jonathan.gibbons at oracle.com> wrote:
>>>
>>>> There can be problems with symbolic links on Windows. Have you tried
>>>> the
>>>> test on a Windows system?
>>>>
>>>
>>> Not yet, I just sent it to the submit repo.
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/0437a5b1/attachment.html>

From cushon at google.com  Thu Mar 14 00:28:14 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Mar 2019 17:28:14 -0700
Subject: RFR: 8220634: SymLinkArchiveTest should handle not being able to
 create symlinks
Message-ID: <CAL4Qsgt_E-kvUsObdYvNerue40yPMoY-JhyRG9hh08rRSS+G0A@mail.gmail.com>

This change fixes SymLinkArchiveTest to be consistent with the guidance
from
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013031.html.

bug: https://bugs.openjdk.java.net/browse/JDK-8220634
webrev: http://cr.openjdk.java.net/~cushon/8220634/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/3f30ac97/attachment.html>

From cushon at google.com  Thu Mar 14 00:39:43 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Mar 2019 17:39:43 -0700
Subject: RFR: 8220633: Optimize CacheFSInfo
In-Reply-To: <4d1e769d-51ce-276d-868b-7fb840466df0@oracle.com>
References: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>
 <4d1e769d-51ce-276d-868b-7fb840466df0@oracle.com>
Message-ID: <CAL4Qsgu-vQakwfHz4MhAeY3X14+ajQYrsfCCPg8Z-b_uU9dkcQ@mail.gmail.com>

On Wed, Mar 13, 2019 at 5:12 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Please don't reformat the scary comment ;-)  You'll frighten away any
> scripts
> that might check for the comment.
>
Thanks--the reformatting of unchanged lines was accidental, I reverted
those parts.

> Is there a reason you don't use computeIfAbsent in getJarClassPath?
>
I switched to use computeIfAbsent there too.

It does requires wrapping/unwrapping the IOException, but I think it's
probably still a better choice. Mostly I was focused on the other other
methods.

Here's the updated webrev:
http://cr.openjdk.java.net/~cushon/8220633/webrev.01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/50fa2155/attachment.html>

From jonathan.gibbons at oracle.com  Thu Mar 14 00:53:58 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Mar 2019 17:53:58 -0700
Subject: RFR: 8220634: SymLinkArchiveTest should handle not being able to
 create symlinks
In-Reply-To: <CAL4Qsgt_E-kvUsObdYvNerue40yPMoY-JhyRG9hh08rRSS+G0A@mail.gmail.com>
References: <CAL4Qsgt_E-kvUsObdYvNerue40yPMoY-JhyRG9hh08rRSS+G0A@mail.gmail.com>
Message-ID: <a626edab-7d2a-7e99-624a-533f233a8f46@oracle.com>

+1 :-)

-- Jon


On 03/13/2019 05:28 PM, Liam Miller-Cushon wrote:
> This change fixes?SymLinkArchiveTest to be consistent with the 
> guidance from 
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013031.html.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220634
> webrev: http://cr.openjdk.java.net/~cushon/8220634/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220634/webrev.00/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/7fe92d23/attachment-0001.html>

From jonathan.gibbons at oracle.com  Thu Mar 14 00:58:27 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Mar 2019 17:58:27 -0700
Subject: RFR: 8193277: SimpleFileObject inconsistency between getName and
 getShortName
In-Reply-To: <CAL4QsgtM1+FjAp=hc=O6uE-cLA8vZfzMuX9TE_vww5bOyGDc7Q@mail.gmail.com>
References: <CAL4QsguBXzc_kQ0ZUofMvQzpoGT8nbkGNZGWiqY=SL+343sLhw@mail.gmail.com>
 <8a5259e3-e050-f942-7713-1b79eff82bfc@oracle.com>
 <CAL4QsgtzSrj9Ep1NfPMPXNhsCy4-VbnbnLfi3BjHWduArThFgg@mail.gmail.com>
 <CAL4QsgtpyO7Ge=KAEBc-QKQbZthFjoJmcj5yiRBNbf-uGVVVqg@mail.gmail.com>
 <CAL4Qsgu__zBfSJyYnz=3CF4MrOb6W__1O5t8sHk4teXmRurVwg@mail.gmail.com>
 <90203184-688c-9fe9-58d7-5fb71eea84d3@oracle.com>
 <CAL4QsgtM1+FjAp=hc=O6uE-cLA8vZfzMuX9TE_vww5bOyGDc7Q@mail.gmail.com>
Message-ID: <f2d6cb3d-f323-b689-3ff4-5bb7e3bbe0fe@oracle.com>

+1


On 03/13/2019 05:23 PM, Liam Miller-Cushon wrote:
> Thanks for the context. Proactively wrapping it sounds like a good 
> idea, I updated the change to do that:
>
> http://cr.openjdk.java.net/~cushon/8193277/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ecushon/8193277/webrev.01/>
>
> (I also filed JDK-8220634 for SymLinkArchiveTest)
>
> On Wed, Mar 13, 2019 at 4:40 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Hmmm, curious,
>
>     The src/ change is OK; all the concern is about the test, on
>     Windows, and this text in the spec:
>
>     https://docs.oracle.com/javase/9/docs/api/java/nio/file/Files.html#createSymbolicLink-java.nio.file.Path-java.nio.file.Path-java.nio.file.attribute.FileAttribute...-
>
>>     Where symbolic links are supported, but the underlying
>>     |FileStore|
>>     <https://docs.oracle.com/javase/9/docs/api/java/nio/file/FileStore.html>
>>     does not support symbolic links, then this may fail with an
>>     |IOException|
>>     <https://docs.oracle.com/javase/9/docs/api/java/io/IOException.html>.
>>     Additionally, some operating systems may require that the Java
>>     virtual machine be started with implementation specific
>>     privileges to create symbolic links, in which case this method
>>     may throw |IOException|.
>
>     That's spec-speak to cover the case that the historical perception
>     has been that (IIRC) you require admin privileges on Windows to
>     create symbolic links.
>
>     Taking a quick survey of existing tests ...
>
>     $ grep -rl Files.createSym open/test/langtools/
>     open/test/langtools/tools/javac/modules/SourceInSymlinkTest.java
>     open/test/langtools/tools/javac/file/SymLinkTest.java
>     open/test/langtools/tools/javac/file/SymLinkArchiveTest.java
>     open/test/langtools/tools/javac/links/LinksTest.java
>
>     ... I see that 3 of the 4 use something like this idiom:
>
>>     ??????? try {
>>     ??????????? Files.createSymbolicLink(lsrc, Paths.get("src"));
>>     ??????? } catch (FileSystemException fse) {
>>     ??????????? System.err.println("warning: test passes vacuously,
>>     sym-link could not be created");
>>     ??????????? System.err.println(fse.getMessage());
>>     ??????????? return;
>>     ??????? }
>
>     But SymLinkArchiveTest.java does not -- it just does a plain call
>     of Files.createSymbolicLink, and the test is not excluded (i.e.
>     listed on the ProblemList)
>
>     So, given your assertion that you get a clean build/test run, and
>     given the existence of a separate test that appears to be able to
>     create symbolic links on all platforms, I guess the test is good
>     to go.? But if any problems arise with this test, we may need to
>     wrap the call as illustrated above. Or you can proactively wrap
>     it, to be on the safe side.
>
>     -- jon
>
>
>
>     On 03/13/2019 03:46 PM, Liam Miller-Cushon wrote:
>>     Any concerns with this, as long as the tests pass on all platforms?
>>
>>     On Tue, Mar 5, 2019 at 2:36 PM Liam Miller-Cushon
>>     <cushon at google.com <mailto:cushon at google.com>> wrote:
>>
>>         The submit repo build is clean.
>>
>>         On Tue, Mar 5, 2019 at 3:30 PM Liam Miller-Cushon
>>         <cushon at google.com <mailto:cushon at google.com>> wrote:
>>
>>             On Tue, Mar 5, 2019 at 3:16 PM Jonathan Gibbons
>>             <jonathan.gibbons at oracle.com
>>             <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>                 There can be problems with symbolic links on Windows.
>>                 Have you tried the
>>                 test on a Windows system?
>>
>>
>>             Not yet, I just sent it to the submit repo.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/8c741682/attachment.html>

From jonathan.gibbons at oracle.com  Thu Mar 14 00:59:25 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Mar 2019 17:59:25 -0700
Subject: RFR: 8220633: Optimize CacheFSInfo
In-Reply-To: <CAL4Qsgu-vQakwfHz4MhAeY3X14+ajQYrsfCCPg8Z-b_uU9dkcQ@mail.gmail.com>
References: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>
 <4d1e769d-51ce-276d-868b-7fb840466df0@oracle.com>
 <CAL4Qsgu-vQakwfHz4MhAeY3X14+ajQYrsfCCPg8Z-b_uU9dkcQ@mail.gmail.com>
Message-ID: <f6244901-2dfa-faea-6955-b1193f1406a5@oracle.com>

OK.

I could go either way on getJarClassPath.? The initial version in 
webrev.00 was definitely shorter.

-- Jon


On 03/13/2019 05:39 PM, Liam Miller-Cushon wrote:
> On Wed, Mar 13, 2019 at 5:12 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Please don't reformat the scary comment ;-)? You'll frighten away
>     any scripts
>     that might check for the comment.
>
> Thanks--the reformatting of unchanged lines was accidental, I reverted 
> those parts.
>
>     Is there a reason you don't use computeIfAbsent in getJarClassPath?
>
> I switched to use computeIfAbsent there too.
>
> It does requires wrapping/unwrapping the IOException, but I think it's 
> probably still a better choice. Mostly I was focused on the other 
> other methods.
>
> Here's the updated webrev: 
> http://cr.openjdk.java.net/~cushon/8220633/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220633/webrev.01/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/e0492921/attachment.html>

From cushon at google.com  Thu Mar 14 04:29:52 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Mar 2019 21:29:52 -0700
Subject: RFR: 8220633: Optimize CacheFSInfo
In-Reply-To: <f6244901-2dfa-faea-6955-b1193f1406a5@oracle.com>
References: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>
 <4d1e769d-51ce-276d-868b-7fb840466df0@oracle.com>
 <CAL4Qsgu-vQakwfHz4MhAeY3X14+ajQYrsfCCPg8Z-b_uU9dkcQ@mail.gmail.com>
 <f6244901-2dfa-faea-6955-b1193f1406a5@oracle.com>
Message-ID: <CAL4QsgvM5QKFifdbGpmHJyze149JXRDcLWX8bWouKohc6vG8yQ@mail.gmail.com>

On Wed, Mar 13, 2019 at 5:59 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> I could go either way on getJarClassPath.  The initial version in
> webrev.00 was definitely shorter.
>
computeIfAbsent feels a little more idiomatic to me than the intentional
race (and the comment to explain why it's safe), but I don't really have a
preference.

I'm happy to revert to webrev.00 if you prefer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/b5b610d8/attachment-0001.html>

From cushon at google.com  Thu Mar 14 04:59:12 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Mar 2019 21:59:12 -0700
Subject: RFR 8220378: Unused Names fields
In-Reply-To: <34905019-aa3c-0bf1-b727-55f51ba5e805@oracle.com>
References: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
 <CAL4Qsgsr6qCG-qLbMr_TmzzXBxf2_Q0EYfxZgMiPOTLMf2hXig@mail.gmail.com>
 <a99c9018-2cbc-15f4-ea6a-14a3be1c7cf6@oracle.com>
 <CAL4Qsgs=O-6LZ+P5TE2DdBUiyqCnVZDhxUZCqpmY6_GFnUrWOA@mail.gmail.com>
 <4b73761a-f1b2-5150-fb13-7234fc9c216b@oracle.com>
 <34905019-aa3c-0bf1-b727-55f51ba5e805@oracle.com>
Message-ID: <CAL4QsgvVaY6VtQABNxg97LGph_KeDEe8r7Wg_PTqKtnNCrFajg@mail.gmail.com>

Thanks for confirming, Maurizio.

(Does that count as a review, or should I wait for more discussion?)

On Mon, Mar 11, 2019 at 2:23 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Since I had my hands in both patches, I can confirm these usages were
> leftover of things that previous support for both features used to do, but
> which we forgot to remove after cleaning up.
>
> I believe in the case of AutoCloseable, the name was used to trigger some
> diagnostic generation (which I then replaced to be based on symbols, as
> with rest of javac); in the case of MethodHandle, the 292 support initially
> had some support for recognizing classfiles using polysig methods using
> something other than java.lang.invoke - and at the classfile level, working
> with names was easier and that's what the logic used to do.
>
> Both are unnecessary at this stage (and have been for quite some time ---
> blush).
>
> Thanks
> Maurizio
> On 11/03/2019 17:10, Jonathan Gibbons wrote:
>
>
> On 3/11/19 9:40 AM, Liam Miller-Cushon wrote:
>
> On Sun, Mar 10, 2019 at 6:00 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> It will be interesting to spot-check a few to go back and see why the
>> name was
>> introduced in the first place, to understand why it is no longer required.
>>
> Two of the more recent unused entries are:
> * java.lang.invoke.MethodHandle added in
> http://hg.openjdk.java.net/jdk/jdk/rev/4161b56e0d20, and
> * java.lang.AutoCloseable added in
> http://hg.openjdk.java.net/jdk/jdk/rev/3a8158299c51
>
> Both of those were unused at the time they were added, perhaps they were
> left over from earlier iterations of the change that was eventually
> submitted.
>
>
> Yes, I see that the names are created and used indirectly via Symtab and Symbol/Type.
> +        autoCloseableType = enterClass("java.lang.AutoCloseable");
> +        methodHandleType = enterClass("java.lang.invoke.MethodHandle");
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/7eef11a2/attachment.html>

From cushon at google.com  Thu Mar 14 05:10:50 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Mar 2019 22:10:50 -0700
Subject: RFR: 8220644: Align required/found pairs in diagnostics
Message-ID: <CAL4Qsgu6VxZSGnhqckY+WOWWjh8ffz0eNE8eFd59=j=6A2z3+Q@mail.gmail.com>

This is a small whitespace adjustment to diagnostics that report a mismatch
between required/found arguments, which makes them a little easier to read.

webrev: http://cr.openjdk.java.net/~cushon/8220644/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8220644
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190313/32617415/attachment.html>

From jonathan.gibbons at oracle.com  Thu Mar 14 14:29:02 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 14 Mar 2019 07:29:02 -0700
Subject: RFR 8220378: Unused Names fields
In-Reply-To: <CAL4QsgvVaY6VtQABNxg97LGph_KeDEe8r7Wg_PTqKtnNCrFajg@mail.gmail.com>
References: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
 <CAL4Qsgsr6qCG-qLbMr_TmzzXBxf2_Q0EYfxZgMiPOTLMf2hXig@mail.gmail.com>
 <a99c9018-2cbc-15f4-ea6a-14a3be1c7cf6@oracle.com>
 <CAL4Qsgs=O-6LZ+P5TE2DdBUiyqCnVZDhxUZCqpmY6_GFnUrWOA@mail.gmail.com>
 <4b73761a-f1b2-5150-fb13-7234fc9c216b@oracle.com>
 <34905019-aa3c-0bf1-b727-55f51ba5e805@oracle.com>
 <CAL4QsgvVaY6VtQABNxg97LGph_KeDEe8r7Wg_PTqKtnNCrFajg@mail.gmail.com>
Message-ID: <ada4974a-dbb4-2879-c77e-2aea512aa835@oracle.com>

Liam,

Thanks, Liam, Maurizio, for helping to understand how we got here.

Looks good to me.

-- Jon

On 3/13/19 9:59 PM, Liam Miller-Cushon wrote:
> Thanks for confirming, Maurizio.
>
> (Does that count as a review, or should I wait for more discussion?)
>
> On Mon, Mar 11, 2019 at 2:23 PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Since I had my hands in both patches, I can confirm these usages
>     were leftover of things that previous support for both features
>     used to do, but which we forgot to remove after cleaning up.
>
>     I believe in the case of AutoCloseable, the name was used to
>     trigger some diagnostic generation (which I then replaced to be
>     based on symbols, as with rest of javac); in the case of
>     MethodHandle, the 292 support initially had some support for
>     recognizing classfiles using polysig methods using something other
>     than java.lang.invoke - and at the classfile level, working with
>     names was easier and that's what the logic used to do.
>
>     Both are unnecessary at this stage (and have been for quite some
>     time --- blush).
>
>     Thanks
>     Maurizio
>
>     On 11/03/2019 17:10, Jonathan Gibbons wrote:
>>
>>
>>     On 3/11/19 9:40 AM, Liam Miller-Cushon wrote:
>>>     On Sun, Mar 10, 2019 at 6:00 PM Jonathan Gibbons
>>>     <jonathan.gibbons at oracle.com
>>>     <mailto:jonathan.gibbons at oracle.com>> wrote:
>>>
>>>         It will be interesting to spot-check a few to go back and
>>>         see why the name was
>>>         introduced in the first place, to understand why it is no
>>>         longer required.
>>>
>>>     Two of the more recent unused entries are:
>>>     * java.lang.invoke.MethodHandle added in
>>>     http://hg.openjdk.java.net/jdk/jdk/rev/4161b56e0d20, and
>>>     * java.lang.AutoCloseable added in
>>>     http://hg.openjdk.java.net/jdk/jdk/rev/3a8158299c51
>>>
>>>     Both of those were unused at the time they were added, perhaps
>>>     they were left over from earlier iterations of the change that
>>>     was eventually submitted.
>>
>>
>>     Yes, I see that the names are created and used indirectly via Symtab and Symbol/Type.
>>
>>     + autoCloseableType = enterClass("java.lang.AutoCloseable");
>>
>>     + methodHandleType = enterClass("java.lang.invoke.MethodHandle");
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190314/ef4f73f1/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Mar 14 15:04:36 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 14 Mar 2019 15:04:36 +0000
Subject: RFR 8220378: Unused Names fields
In-Reply-To: <CAL4QsgvVaY6VtQABNxg97LGph_KeDEe8r7Wg_PTqKtnNCrFajg@mail.gmail.com>
References: <CACA6h9uui0XObAZMQsiM5yOXKkWAR2oAbxH=5+Eua+v1iGGbpg@mail.gmail.com>
 <CAL4Qsgsr6qCG-qLbMr_TmzzXBxf2_Q0EYfxZgMiPOTLMf2hXig@mail.gmail.com>
 <a99c9018-2cbc-15f4-ea6a-14a3be1c7cf6@oracle.com>
 <CAL4Qsgs=O-6LZ+P5TE2DdBUiyqCnVZDhxUZCqpmY6_GFnUrWOA@mail.gmail.com>
 <4b73761a-f1b2-5150-fb13-7234fc9c216b@oracle.com>
 <34905019-aa3c-0bf1-b727-55f51ba5e805@oracle.com>
 <CAL4QsgvVaY6VtQABNxg97LGph_KeDEe8r7Wg_PTqKtnNCrFajg@mail.gmail.com>
Message-ID: <b9b9a7a8-50b5-5430-1514-7c72a4324d4d@oracle.com>


On 14/03/2019 04:59, Liam Miller-Cushon wrote:
> Thanks for confirming, Maurizio.
>
> (Does that count as a review, or should I wait for more discussion?)

Sorry for not having been clear - yes, this looks good to me.

Maurizio

>
> On Mon, Mar 11, 2019 at 2:23 PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Since I had my hands in both patches, I can confirm these usages
>     were leftover of things that previous support for both features
>     used to do, but which we forgot to remove after cleaning up.
>
>     I believe in the case of AutoCloseable, the name was used to
>     trigger some diagnostic generation (which I then replaced to be
>     based on symbols, as with rest of javac); in the case of
>     MethodHandle, the 292 support initially had some support for
>     recognizing classfiles using polysig methods using something other
>     than java.lang.invoke - and at the classfile level, working with
>     names was easier and that's what the logic used to do.
>
>     Both are unnecessary at this stage (and have been for quite some
>     time --- blush).
>
>     Thanks
>     Maurizio
>
>     On 11/03/2019 17:10, Jonathan Gibbons wrote:
>>
>>
>>     On 3/11/19 9:40 AM, Liam Miller-Cushon wrote:
>>>     On Sun, Mar 10, 2019 at 6:00 PM Jonathan Gibbons
>>>     <jonathan.gibbons at oracle.com
>>>     <mailto:jonathan.gibbons at oracle.com>> wrote:
>>>
>>>         It will be interesting to spot-check a few to go back and
>>>         see why the name was
>>>         introduced in the first place, to understand why it is no
>>>         longer required.
>>>
>>>     Two of the more recent unused entries are:
>>>     * java.lang.invoke.MethodHandle added in
>>>     http://hg.openjdk.java.net/jdk/jdk/rev/4161b56e0d20, and
>>>     * java.lang.AutoCloseable added in
>>>     http://hg.openjdk.java.net/jdk/jdk/rev/3a8158299c51
>>>
>>>     Both of those were unused at the time they were added, perhaps
>>>     they were left over from earlier iterations of the change that
>>>     was eventually submitted.
>>
>>
>>     Yes, I see that the names are created and used indirectly via Symtab and Symbol/Type.
>>
>>     + autoCloseableType = enterClass("java.lang.AutoCloseable");
>>
>>     + methodHandleType = enterClass("java.lang.invoke.MethodHandle");
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190314/cba56d15/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Mar 14 15:07:34 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 14 Mar 2019 15:07:34 +0000
Subject: RFR: 8220644: Align required/found pairs in diagnostics
In-Reply-To: <CAL4Qsgu6VxZSGnhqckY+WOWWjh8ffz0eNE8eFd59=j=6A2z3+Q@mail.gmail.com>
References: <CAL4Qsgu6VxZSGnhqckY+WOWWjh8ffz0eNE8eFd59=j=6A2z3+Q@mail.gmail.com>
Message-ID: <1ea6340b-abcb-c836-eb2c-f54f079412b8@oracle.com>

Looks good!

Maurizio

On 14/03/2019 05:10, Liam Miller-Cushon wrote:
> This is a small whitespace adjustment to diagnostics that report a 
> mismatch between required/found arguments, which makes them a little 
> easier to read.
>
> webrev: http://cr.openjdk.java.net/~cushon/8220644/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8220644

From jonathan.gibbons at oracle.com  Thu Mar 14 17:25:38 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 14 Mar 2019 10:25:38 -0700
Subject: RFR: 8220644: Align required/found pairs in diagnostics
In-Reply-To: <CAL4Qsgu6VxZSGnhqckY+WOWWjh8ffz0eNE8eFd59=j=6A2z3+Q@mail.gmail.com>
References: <CAL4Qsgu6VxZSGnhqckY+WOWWjh8ffz0eNE8eFd59=j=6A2z3+Q@mail.gmail.com>
Message-ID: <e1b7a6f7-7250-935e-880a-7315a828bd6e@oracle.com>

Looks good to me.

-- Jon


On 03/13/2019 10:10 PM, Liam Miller-Cushon wrote:
> This is a small whitespace adjustment to diagnostics that report a 
> mismatch between required/found arguments, which makes them a little 
> easier to read.
>
> webrev: http://cr.openjdk.java.net/~cushon/8220644/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220644/webrev.00/>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220644

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190314/3f60195b/attachment.html>

From jonathan.gibbons at oracle.com  Thu Mar 14 21:15:38 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 14 Mar 2019 14:15:38 -0700
Subject: RFR:[13] XS: JDK-8220249: fix headings in java.compiler
In-Reply-To: <6becbba7-6aaf-1242-1efd-67377c36bbbb@oracle.com>
References: <613b7450-ada8-2493-8461-b45bfef0b6ec@oracle.com>
 <6becbba7-6aaf-1242-1efd-67377c36bbbb@oracle.com>
Message-ID: <e43f8371-48a1-e808-38d4-f5dc60c9df90@oracle.com>

Build folk,

Joe previously approved the fix for the single use of a heading in the 
java.compiler module.? Now that doclint has been fixed, we can re-enable 
doclint accessibility checking for this module as well.

-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8220249
Webrev: http://cr.openjdk.java.net/~jjg/8220249/webrev.00


On 03/07/2019 03:34 PM, Joe Darcy wrote:
> +1
>
> Cheers,
>
> -Joe
>
> On 3/7/2019 12:37 PM, Jonathan Gibbons wrote:
>> Please review a trivial doc fix to adjust a heading in the 
>> java.compiler module.? The heading is changed from <h3> to <h2>.
>>
>> -- Jon
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8220249
>>
>> $ hg diff -R open
>> diff -r fb9541185457 
>> src/java.compiler/share/classes/javax/annotation/processing/Generated.java
>> --- 
>> a/src/java.compiler/share/classes/javax/annotation/processing/Generated.java 
>> Tue Mar 05 10:35:29 2019 -0800
>> +++ 
>> b/src/java.compiler/share/classes/javax/annotation/processing/Generated.java 
>> Thu Mar 07 12:31:38 2019 -0800
>> @@ -33,7 +33,7 @@
>> ? * It can also be used to differentiate user written code from 
>> generated code in
>> ? * a single file.
>> ? *
>> - * <h3>Examples:</h3>
>> + * <h2>Examples:</h2>
>> ? * <pre>
>> ? *?? &#064;Generated("com.example.Generator")
>> ? * </pre>
>>
>>
>>


From erik.joelsson at oracle.com  Thu Mar 14 22:08:45 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 14 Mar 2019 15:08:45 -0700
Subject: RFR:[13] XS: JDK-8220249: fix headings in java.compiler
In-Reply-To: <e43f8371-48a1-e808-38d4-f5dc60c9df90@oracle.com>
References: <613b7450-ada8-2493-8461-b45bfef0b6ec@oracle.com>
 <6becbba7-6aaf-1242-1efd-67377c36bbbb@oracle.com>
 <e43f8371-48a1-e808-38d4-f5dc60c9df90@oracle.com>
Message-ID: <0eb92c16-e63a-c267-0ccf-ab5eac745691@oracle.com>

Looks good.

/Erik

On 2019-03-14 14:15, Jonathan Gibbons wrote:
> Build folk,
>
> Joe previously approved the fix for the single use of a heading in the 
> java.compiler module.? Now that doclint has been fixed, we can 
> re-enable doclint accessibility checking for this module as well.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220249
> Webrev: http://cr.openjdk.java.net/~jjg/8220249/webrev.00
>
>
> On 03/07/2019 03:34 PM, Joe Darcy wrote:
>> +1
>>
>> Cheers,
>>
>> -Joe
>>
>> On 3/7/2019 12:37 PM, Jonathan Gibbons wrote:
>>> Please review a trivial doc fix to adjust a heading in the 
>>> java.compiler module.? The heading is changed from <h3> to <h2>.
>>>
>>> -- Jon
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8220249
>>>
>>> $ hg diff -R open
>>> diff -r fb9541185457 
>>> src/java.compiler/share/classes/javax/annotation/processing/Generated.java
>>> --- 
>>> a/src/java.compiler/share/classes/javax/annotation/processing/Generated.java 
>>> Tue Mar 05 10:35:29 2019 -0800
>>> +++ 
>>> b/src/java.compiler/share/classes/javax/annotation/processing/Generated.java 
>>> Thu Mar 07 12:31:38 2019 -0800
>>> @@ -33,7 +33,7 @@
>>> ? * It can also be used to differentiate user written code from 
>>> generated code in
>>> ? * a single file.
>>> ? *
>>> - * <h3>Examples:</h3>
>>> + * <h2>Examples:</h2>
>>> ? * <pre>
>>> ? *?? &#064;Generated("com.example.Generator")
>>> ? * </pre>
>>>
>>>
>>>
>

From cushon at google.com  Fri Mar 15 01:19:34 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 14 Mar 2019 18:19:34 -0700
Subject: RFR: 8220687: Change signature of
 StandardJavaFileManager.getJavaFileObjectsFromPaths
Message-ID: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>

Hi,

This change adds a getJavaFileObjectsFromPaths(Collection<Path>) method,
and deprecates the existing getJavaFileObjectsFromPaths(Iterable<Path>).
The motivation is the same as JDK-8150111, which made a similar change to
setLocationFromPaths: methods that take Iterable<Path> are error-prone
since Path itself implements Iterable<Path>.

I have two initial questions: do you think this is worthwhile, and if so
what's the correct process (should I file a CSR?).

bug: https://bugs.openjdk.java.net/browse/JDK-8220687
webrev: http://cr.openjdk.java.net/~cushon/8220687/webrev.00/

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190314/c9182344/attachment.html>

From cushon at google.com  Fri Mar 15 01:53:01 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 14 Mar 2019 18:53:01 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
Message-ID: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>

This change adds notes if diagnostics were suppressed due to the current
value of -Xmaxerrs/-Xmaxwarns, e.g.:

```
3 more warnings not shown; consider recompiling with -Xmaxwarns 100 to see
them
```

bug: https://bugs.openjdk.java.net/browse/JDK-8220632
webrev: http://cr.openjdk.java.net/~cushon/8220632/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190314/4354a869/attachment.html>

From joe.darcy at oracle.com  Fri Mar 15 02:14:58 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 14 Mar 2019 19:14:58 -0700
Subject: RFR: 8220687: Change signature of
 StandardJavaFileManager.getJavaFileObjectsFromPaths
In-Reply-To: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>
References: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>
Message-ID: <5C8B0AA2.7050908@oracle.com>

Hello Liam,

On 3/14/2019 6:19 PM, Liam Miller-Cushon wrote:
> Hi,
>
> This change adds a getJavaFileObjectsFromPaths(Collection<Path>) 
> method, and deprecates the existing 
> getJavaFileObjectsFromPaths(Iterable<Path>). The motivation is the 
> same as JDK-8150111, which made a similar change to 
> setLocationFromPaths: methods that take Iterable<Path> are error-prone 
> since Path itself implements Iterable<Path>.
>
> I have two initial questions: do you think this is worthwhile, and if 
> so what's the correct process (should I file a CSR?).
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220687
> webrev: http://cr.openjdk.java.net/~cushon/8220687/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220687/webrev.00/>
>

On the process question, if this change goes forward it will need a CSR 
since it is change to a Java SE API.

For an overview of the CSR process, see the CSR wiki 
(https://wiki.openjdk.java.net/display/csr/Main) and a recent 
presentation about the CSR given at the OCW 
(http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-CSR-2019-02.pdf).

HTH,

-Joe


From cushon at google.com  Fri Mar 15 02:54:25 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 14 Mar 2019 19:54:25 -0700
Subject: RFR: 8220687: Change signature of
 StandardJavaFileManager.getJavaFileObjectsFromPaths
In-Reply-To: <5C8B0AA2.7050908@oracle.com>
References: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>
 <5C8B0AA2.7050908@oracle.com>
Message-ID: <CAL4Qsgua9GQArVbHaXkVS=knM3xP+Pr45fv9Xw-AM-A4ieP09w@mail.gmail.com>

On Thu, Mar 14, 2019 at 7:15 PM Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> On the process question, if this change goes forward it will need a CSR
> since it is change to a Java SE API.
>
> For an overview of the CSR process, see the CSR wiki
> (https://wiki.openjdk.java.net/display/csr/Main) and a recent
> presentation about the CSR given at the OCW
> (http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-CSR-2019-02.pdf).
>

Thanks! I started a draft of the CSR:
https://bugs.openjdk.java.net/browse/JDK-8220695
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190314/93b04762/attachment.html>

From christoph.langer at sap.com  Fri Mar 15 13:24:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Mar 2019 13:24:34 +0000
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with
 java.lang.AssertionError: Classfiles too old!
Message-ID: <HE1PR0201MB22667FACECA75BBD09D1FB568A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

please review a fix proposal for an intermittent error in test/langtools/tools/javac/modules/MOptionTest.java.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200286
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8200286.0/

The issue has been reported already a while ago but was closed as not reproducible/won't fix. However, we've encountered this issue quite often on a linuxppc64 test machine in our ci infrastructure. Here are links to failed test jobs:

jdk11u:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/
  ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

jdk12:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
jdk:
https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/
    ->jtr: https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

The analysis done in the bug by Jiangli seems to be true. There is some imprecision in time resolution (maybe rounding issue, maybe os inaccuracy) where it can happen that the class file created by the java compiler has an earlier timestamp than the original source file.

What I did to overcome this is to date back the .java file to be compiled by one second before doing the compilation which will create a class file with the current time stamp. This should make sure that the .java file doesn't have a newer timestamp than the .class file.
I can do that because the test thread had waited for 2 seconds before doing the compilation. In fact, I have removed another 2 second wait because I don't think it is needed at that place since the test had already waited 2 seconds before testing a noop compilation due to unchanged timestamps.

I guess this is certainly not perfect but it should stabilize this test and to me it seems pragmatic.

I have already added this fix to our (SapMachine) code base and have not observed this error after that and didn't run into regressions either.

Thanks
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/994e9ca3/attachment.html>

From christoph.langer at sap.com  Fri Mar 15 14:48:36 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Mar 2019 14:48:36 +0000
Subject: OpenJDK source code not compiling with Eclipse compiler
Message-ID: <HE1PR0201MB2266C9EFE47098C55FBC94D38A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi there,

I?m using Eclipse for OpenJDK development. For quite a long time, I?ve been stumbling over a few issues where the Eclipse compiler is not able to compile some code while javac is. It?s all related to generics and handling of capture vars.

There are open bugs, both at Eclipse [0] and OpenJDK[1] for this type of issues. The Eclipse bug refers to the OpenJDK bug and states that it just conforms to JLS. In the OpenJDK bug, the statement is that there are unspecified widening of captures which should be added to spec/JLS.

For the OpenJDK I have created the following webrev that shows how the problematic code places could be modified to be compilable with Eclipse ECJ: http://cr.openjdk.java.net/~clanger/webrevs/ecjcompile/

Can someone give me a status on JDK-8016207? Or are there arguments to convince Stephan (the ECJ compiler maintainer) to modify ECJ?

I?ll probably propose my webrev for OpenJDK, in case we can?t find a solution for the compilers ??

Thanks & Best regards
Christoph

[0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530236
[1] https://bugs.openjdk.java.net/browse/JDK-8016207

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/cbe8c318/attachment-0001.html>

From jonathan.gibbons at oracle.com  Fri Mar 15 17:19:09 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 15 Mar 2019 10:19:09 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
Message-ID: <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>

For discussion ...

Rather than giving a specific number, how about something more like:

"consider using the -Xmaxwarns option to increase the number of messages 
displayed"

-- Jon

On 3/14/19 6:53 PM, Liam Miller-Cushon wrote:
> This change adds notes if diagnostics were suppressed due to the 
> current value of?-Xmaxerrs/-Xmaxwarns, e.g.:
>
> ```
> 3 more warnings not shown; consider recompiling with -Xmaxwarns 100 to 
> see them
> ```
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220632
> webrev: http://cr.openjdk.java.net/~cushon/8220632/webrev.00/

From cushon at google.com  Fri Mar 15 17:28:01 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 15 Mar 2019 10:28:01 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
Message-ID: <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>

On Fri, Mar 15, 2019 at 10:19 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> For discussion ...
>
> Rather than giving a specific number, how about something more like:
>
> "consider using the -Xmaxwarns option to increase the number of messages
> displayed"
>

Choosing a specific number modulo 100 was somewhat arbitrary, but I was
trying to anticipate the question of what the current value of -Xmaxwarns
is, especially if the user isn't already setting it and is relying on the
default.

Another way to approach that would be for the note to also mention the
total number of diagnostics, so -Xmaxwarns could be raised past that number
if the user wanted to see all diagnostics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/d28cae93/attachment.html>

From jonathan.gibbons at oracle.com  Fri Mar 15 17:31:21 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 15 Mar 2019 10:31:21 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
Message-ID: <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>


On 3/15/19 10:28 AM, Liam Miller-Cushon wrote:
> On Fri, Mar 15, 2019 at 10:19 AM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     For discussion ...
>
>     Rather than giving a specific number, how about something more like:
>
>     "consider using the -Xmaxwarns option to increase the number of
>     messages
>     displayed"
>
>
> Choosing a specific number modulo 100 was somewhat arbitrary, but I 
> was trying to anticipate the question of what the current value of 
> -Xmaxwarns is, especially if the user isn't already setting it and is 
> relying on the default.
>
> Another way to approach that would be for the note to also mention the 
> total number of diagnostics, so -Xmaxwarns could be raised past that 
> number if the user wanted to see all diagnostics.

You could report the current limit and the total number.

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/b481e51f/attachment.html>

From cushon at google.com  Fri Mar 15 18:04:33 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 15 Mar 2019 11:04:33 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
Message-ID: <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>

On Fri, Mar 15, 2019 at 10:31 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> You could report the current limit and the total number.
>
That sounds good to me.

Perhaps:

only showing the first 100 warnings (of 142 total); consider recompiling
with a higher value of -Xmaxwarns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/06bc7489/attachment.html>

From jonathan.gibbons at oracle.com  Fri Mar 15 18:10:07 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 15 Mar 2019 11:10:07 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
 <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
Message-ID: <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>


On 3/15/19 11:04 AM, Liam Miller-Cushon wrote:
> On Fri, Mar 15, 2019 at 10:31 AM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     You could report the current limit and the total number.
>
> That sounds good to me.
>
> Perhaps:
>
> only showing the first 100 warnings (of 142 total); consider 
> recompiling with a higher value of -Xmaxwarns

Sounds good to me!

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/bd4260d2/attachment.html>

From ronshapiro at google.com  Fri Mar 15 18:11:31 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Fri, 15 Mar 2019 14:11:31 -0400
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
 <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
 <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>
Message-ID: <CACA6h9t2k73yLPVaG+0A1eAmiLAkq8r=MaA4tov6XD81wjjArw@mail.gmail.com>

Regarding Jonathan's comments in the bug, would it be helpful/possible to
categorize the types of diagnostics not shown? For built-in diagnostics we
could try to group (maybe just the popular ones?) by their key?

42 symbols could not be found
15 errors from com.example.proc.ExampleProcessor
etc

?

On Fri, Mar 15, 2019 at 2:11 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
> On 3/15/19 11:04 AM, Liam Miller-Cushon wrote:
>
> On Fri, Mar 15, 2019 at 10:31 AM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> You could report the current limit and the total number.
>>
> That sounds good to me.
>
> Perhaps:
>
> only showing the first 100 warnings (of 142 total); consider recompiling
> with a higher value of -Xmaxwarns
>
> Sounds good to me!
>
> -- Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/5b801a91/attachment-0001.html>

From cushon at google.com  Fri Mar 15 18:21:50 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 15 Mar 2019 11:21:50 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <CACA6h9t2k73yLPVaG+0A1eAmiLAkq8r=MaA4tov6XD81wjjArw@mail.gmail.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
 <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
 <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>
 <CACA6h9t2k73yLPVaG+0A1eAmiLAkq8r=MaA4tov6XD81wjjArw@mail.gmail.com>
Message-ID: <CAL4Qsgu5U_GMwtpddhz5_7DAyVep8qPvJFNman2E88BqmBb-WQ@mail.gmail.com>

On Fri, Mar 15, 2019 at 11:11 AM Ron Shapiro <ronshapiro at google.com> wrote:

> Regarding Jonathan's comments in the bug, would it be helpful/possible to
> categorize the types of diagnostics not shown? For built-in diagnostics we
> could try to group (maybe just the popular ones?) by their key?
>
> 42 symbols could not be found
> 15 errors from com.example.proc.ExampleProcessor
> etc
>
> ?
>

It's certainly possible. I think we want to strike a balance between
providing enough information to help avoid users getting stuck when
diagnostics are suppressed, but not so much information that it's
distracting (since hopefully in the common case the suppressed diagnostics
are not necessary to understand the problem).

In that specific example, Jon's suggestion to sort the non-recoverable
diagnostics first (which I intend to follow up on JDK-8220691) would avoid
suppressing the com.example.proc.ExampleProcessor diagnostics entirely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/f4e2ebf8/attachment.html>

From jonathan.gibbons at oracle.com  Fri Mar 15 18:26:39 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 15 Mar 2019 11:26:39 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <CAL4Qsgu5U_GMwtpddhz5_7DAyVep8qPvJFNman2E88BqmBb-WQ@mail.gmail.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
 <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
 <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>
 <CACA6h9t2k73yLPVaG+0A1eAmiLAkq8r=MaA4tov6XD81wjjArw@mail.gmail.com>
 <CAL4Qsgu5U_GMwtpddhz5_7DAyVep8qPvJFNman2E88BqmBb-WQ@mail.gmail.com>
Message-ID: <bcceef10-12c0-307a-56f7-332c4b97552f@oracle.com>


On 3/15/19 11:21 AM, Liam Miller-Cushon wrote:
> On Fri, Mar 15, 2019 at 11:11 AM Ron Shapiro <ronshapiro at google.com 
> <mailto:ronshapiro at google.com>> wrote:
>
>     Regarding Jonathan's comments in the bug, would it be
>     helpful/possible to categorize the types of diagnostics not shown?
>     For built-in diagnostics we could try to group (maybe just the
>     popular ones?) by their key?
>
>     42 symbols could not be found
>     15 errors from com.example.proc.ExampleProcessor
>     etc
>
>     ?
>
>
> It's certainly possible. I think we want to strike a balance between 
> providing enough information to help avoid users getting stuck when 
> diagnostics are suppressed, but not so much information that it's 
> distracting (since hopefully in the common case the suppressed 
> diagnostics are not necessary to understand the problem).
>
> In that specific example, Jon's suggestion to sort the non-recoverable 
> diagnostics first (which I intend to follow up on JDK-8220691) would 
> avoid suppressing the com.example.proc.ExampleProcessor diagnostics 
> entirely.


If we were to provide this extra info, maybe it could/should be opt-in.? 
But, I think it is a better use of resources to make javac more friendly 
"out of the box" and to print the more-likely-important messages first, 
so that users don't have to wade through too much info.

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/c4398b8e/attachment.html>

From cushon at google.com  Fri Mar 15 18:31:11 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 15 Mar 2019 11:31:11 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <bcceef10-12c0-307a-56f7-332c4b97552f@oracle.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
 <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
 <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>
 <CACA6h9t2k73yLPVaG+0A1eAmiLAkq8r=MaA4tov6XD81wjjArw@mail.gmail.com>
 <CAL4Qsgu5U_GMwtpddhz5_7DAyVep8qPvJFNman2E88BqmBb-WQ@mail.gmail.com>
 <bcceef10-12c0-307a-56f7-332c4b97552f@oracle.com>
Message-ID: <CAL4Qsgv5Qk=61BY7=Zhtp-CXepu8mqHK-N+GMr_rk-_SEwQtZw@mail.gmail.com>

I updated the webrev with the suggested changes to the diagnostic text:

http://cr.openjdk.java.net/~cushon/8220632/webrev.01/

On Fri, Mar 15, 2019 at 11:26 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
> On 3/15/19 11:21 AM, Liam Miller-Cushon wrote:
>
> On Fri, Mar 15, 2019 at 11:11 AM Ron Shapiro <ronshapiro at google.com>
> wrote:
>
>> Regarding Jonathan's comments in the bug, would it be helpful/possible to
>> categorize the types of diagnostics not shown? For built-in diagnostics we
>> could try to group (maybe just the popular ones?) by their key?
>>
>> 42 symbols could not be found
>> 15 errors from com.example.proc.ExampleProcessor
>> etc
>>
>> ?
>>
>
> It's certainly possible. I think we want to strike a balance between
> providing enough information to help avoid users getting stuck when
> diagnostics are suppressed, but not so much information that it's
> distracting (since hopefully in the common case the suppressed diagnostics
> are not necessary to understand the problem).
>
> In that specific example, Jon's suggestion to sort the non-recoverable
> diagnostics first (which I intend to follow up on JDK-8220691) would avoid
> suppressing the com.example.proc.ExampleProcessor diagnostics entirely.
>
>
> If we were to provide this extra info, maybe it could/should be opt-in.
> But, I think it is a better use of resources to make javac more friendly
> "out of the box" and to print the more-likely-important messages first, so
> that users don't have to wade through too much info.
>
> -- Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/278e4e68/attachment.html>

From dkwakkel at gmail.com  Fri Mar 15 23:06:59 2019
From: dkwakkel at gmail.com (Donald Kwakkel)
Date: Sat, 16 Mar 2019 00:06:59 +0100
Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as
 Paths instead of URLs
Message-ID: <CAO7qondOY=0ZPzBQx92KvSma7qH_e70O8f3o3CxxR4ci-6ex6w@mail.gmail.com>

After discussion and conclusion on core-libs-dev the spec is changed
that manifest classpath must be handled the same in java as javac. And
Jonathan told me to continue now on this list.

I created a fix + tests for
https://bugs.openjdk.java.net/browse/JDK-8218268. Now the manifest
classpath is behaving the same in javac and java for file paths as it
was in java 8. See attached first patch.

Now I would like to reuse the code of URLClassLoader (see second
attached patch), but it seems I can not use SharedSecrets from
FSInfo.java:

* For target buildtools_interim_langtools_modules_jdk.compiler.interim__the.BUILD_jdk.compiler.interim_batch:
jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java:51:
error: package jdk.internal.access does not exist
import jdk.internal.access.SharedSecrets;

Where should I locate the common code and how can it be called both
from URLClassLoader and FSInfo?

Kind Regards,

Donald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: first.patch
Type: text/x-patch
Size: 8402 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190316/5f74dcd4/first-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: second.patch
Type: text/x-patch
Size: 23644 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190316/5f74dcd4/second-0001.patch>

From jonathan.gibbons at oracle.com  Fri Mar 15 23:44:40 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 15 Mar 2019 16:44:40 -0700
Subject: [PATCH] 8218268: Javac treats Manifest Class-Path entries as
 Paths instead of URLs
In-Reply-To: <CAO7qondOY=0ZPzBQx92KvSma7qH_e70O8f3o3CxxR4ci-6ex6w@mail.gmail.com>
References: <CAO7qondOY=0ZPzBQx92KvSma7qH_e70O8f3o3CxxR4ci-6ex6w@mail.gmail.com>
Message-ID: <1c7ca6d3-33a8-f330-8a69-32236a4b5c7a@oracle.com>


On 3/15/19 4:06 PM, Donald Kwakkel wrote:
> After discussion and conclusion on core-libs-dev the spec is changed
> that manifest classpath must be handled the same in java as javac. And
> Jonathan told me to continue now on this list.
>
> I created a fix + tests for
> https://bugs.openjdk.java.net/browse/JDK-8218268. Now the manifest
> classpath is behaving the same in javac and java for file paths as it
> was in java 8. See attached first patch.
>
> Now I would like to reuse the code of URLClassLoader (see second
> attached patch), but it seems I can not use SharedSecrets from
> FSInfo.java:

That's right, you can't.


>
> * For target buildtools_interim_langtools_modules_jdk.compiler.interim__the.BUILD_jdk.compiler.interim_batch:
> jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java:51:
> error: package jdk.internal.access does not exist
> import jdk.internal.access.SharedSecrets;
>
> Where should I locate the common code and how can it be called both
> from URLClassLoader and FSInfo?

As bad as it sounds, you should probably not try and share the code in 
this case.


> Kind Regards,
>
> Donald

From jonathan.gibbons at oracle.com  Sat Mar 16 00:10:16 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 15 Mar 2019 17:10:16 -0700
Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException:
 String index out of range: -2
In-Reply-To: <5C7FA173.5000707@oracle.com>
References: <5C7E9BD7.1070607@oracle.com>
 <df3a5947-ee18-3584-c00e-7fa7abc43943@oracle.com>
 <5C7EAB3F.4050402@oracle.com>
 <44fb40ef-6f77-a389-7559-cbe04ae4e1f1@oracle.com>
 <5C7FA173.5000707@oracle.com>
Message-ID: <a4e3cc8b-f2a8-faf2-e8d8-c711af8188da@oracle.com>

OK, I see the additional checks in simpleBinaryName, which is the sort 
of check I was expecting.

I'm a bit surprised you didn't put the check inside simpleBinaryName, 
but that would trigger a subsequent question as to why we have

1478 throw badEnclosingMethod(self);

and ClassReader.simpleBinaryName:1507

     throw badClassFile("bad.enclosing.method", self);

I'm OK with either webrev as is or with the check moved into 
simpleBinaryName,

-- Jon

On 03/06/2019 02:31 AM, Jan Lahoda wrote:
> Hi Jon,
>
> On 5.3.2019 21:20, Jonathan Gibbons wrote:
>> Jan,
>>
>> Is checking for a prefix good enough??? It seems like that would be
>> necessary but not sufficient.
>
> What specific additional checks do you foresee? The 
> ClassReader.simpleBinaryName method does some additional checks, like 
> that the class suffix is non-empty and starts with '$'.
>
> Thanks,
> ??? Jan
>
>>
>> -- Jon
>>
>> On 3/5/19 9:00 AM, Jan Lahoda wrote:
>>> On 5.3.2019 17:33, Joe Darcy wrote:
>>>> Hi Jan,
>>>>
>>>> Do you think this issue merits a CSR for the behavioral change?
>>>
>>> Good question! It is true that javac may now refuse to load classfiles
>>> that didn't lead to the exception before, so I guess a CSR may be in
>>> order. I've started with it here:
>>> https://bugs.openjdk.java.net/browse/JDK-8220167
>>>
>>> Feedback on the CSR is very welcome as well!
>>>
>>> Thanks,
>>> ??? Jan
>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> On 3/5/2019 7:55 AM, Jan Lahoda wrote:
>>>>> Hi,
>>>>>
>>>>> Seems that some classfiles have a weird EnclosingMethod attribute -
>>>>> for (local/anonymous) class A, the EnclosingMethod attribute states
>>>>> the enclosing class is C, but the name of C is not a prefix of the
>>>>> name of A. This appears to be contradictory to JLS 13.1., so the
>>>>> proposal is to reject such classfiles.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407
>>>>>
>>>>> How does this look?
>>>>>
>>>>> Thanks,
>>>>> ??? Jan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/01ab0528/attachment.html>

From jonathan.gibbons at oracle.com  Sat Mar 16 00:32:33 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 15 Mar 2019 17:32:33 -0700
Subject: RFR(13): JDK-8217047: Provide a way to inject missing parameter
 names
In-Reply-To: <5C45BBE5.6030007@oracle.com>
References: <5C45BBE5.6030007@oracle.com>
Message-ID: <61878d42-a401-a5a2-3331-d0fa4dd0e77f@oracle.com>

Nice.? Minor comments...

The {@linkplain}don't seem to be working as expected;? I suspect you 
need to import the type names. Also, you should use parens and arg types 
on links to methods; if you don't want the `(arg-types)` to show up in 
the docs, use the form of {@linkplain} that allows you to specify the 
text to be linked.

The new method in JavacTask should have an implNote that says, "This 
Implementation does nothing." or words to that effect.

(Aside: we have a more general problem with implNotes, that we have 
places where the default is to do nothing or throw UOE, but the reality 
is that the real-world impl of these methods does something useful. I 
don't know how/where we should document that behavior. But that's a 
bigger question for another time and another review.)

Flags.java

typo: friedly

ClassReader ... just curious, you always create a new ParamSymbol, even 
when you could use a VarSymbol (because you have already filled in the 
name).? I guess the code is neater/more consistent the way you have it.

MissingInfoHandler ... no class-level doc comment. I realize it's an 
internal class but even so ...

-- Jon


On 01/21/2019 04:32 AM, Jan Lahoda wrote:
> Hi,
>
> When a type is load from a classfile, and some or all of its methods 
> have neither the MethodParameters or LocalVariableTable attributes, 
> then the parameters of the methods have an artificial synthesized 
> name, which is visible through VariableElement.getSimpleName().
>
> The proposal here is to allow to plug in an external provider that 
> could provide more user-friendly names lazily/on demand. These could 
> originate e.g. in adjacent sources.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8217437
> Webrev: http://cr.openjdk.java.net/~jlahoda/8217047/webrev.01/
> Specdiff: 
> http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.01/overview-summary.html
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8217437
>
> What do you think?
>
> Thanks,
> ??? Jan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/773ce969/attachment.html>

From jan.lahoda at oracle.com  Mon Mar 18 16:20:55 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 18 Mar 2019 17:20:55 +0100
Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException:
 String index out of range: -2
In-Reply-To: <a4e3cc8b-f2a8-faf2-e8d8-c711af8188da@oracle.com>
References: <5C7E9BD7.1070607@oracle.com>
 <df3a5947-ee18-3584-c00e-7fa7abc43943@oracle.com>
 <5C7EAB3F.4050402@oracle.com>
 <44fb40ef-6f77-a389-7559-cbe04ae4e1f1@oracle.com>
 <5C7FA173.5000707@oracle.com>
 <a4e3cc8b-f2a8-faf2-e8d8-c711af8188da@oracle.com>
Message-ID: <5C8FC567.6040407@oracle.com>

On 16.3.2019 01:10, Jonathan Gibbons wrote:
> OK, I see the additional checks in simpleBinaryName, which is the sort
> of check I was expecting.
>
> I'm a bit surprised you didn't put the check inside simpleBinaryName,
> but that would trigger a subsequent question as to why we have

I started with the check inside the simpleBinaryName method, but then 
moved it outside, as the check seemed like a "general" check, not 
something related to the simple name as such. I don't have a very strong 
opinion on this, I can move the check inside simpleBinaryName if preferred.

Thanks,
     Jan

>
> 1478 throw badEnclosingMethod(self);
>
> and ClassReader.simpleBinaryName:1507
>
>      throw badClassFile("bad.enclosing.method", self);
>
> I'm OK with either webrev as is or with the check moved into
> simpleBinaryName,
>
> -- Jon
>
> On 03/06/2019 02:31 AM, Jan Lahoda wrote:
>> Hi Jon,
>>
>> On 5.3.2019 21:20, Jonathan Gibbons wrote:
>>> Jan,
>>>
>>> Is checking for a prefix good enough?   It seems like that would be
>>> necessary but not sufficient.
>>
>> What specific additional checks do you foresee? The
>> ClassReader.simpleBinaryName method does some additional checks, like
>> that the class suffix is non-empty and starts with '$'.
>>
>> Thanks,
>>     Jan
>>
>>>
>>> -- Jon
>>>
>>> On 3/5/19 9:00 AM, Jan Lahoda wrote:
>>>> On 5.3.2019 17:33, Joe Darcy wrote:
>>>>> Hi Jan,
>>>>>
>>>>> Do you think this issue merits a CSR for the behavioral change?
>>>>
>>>> Good question! It is true that javac may now refuse to load classfiles
>>>> that didn't lead to the exception before, so I guess a CSR may be in
>>>> order. I've started with it here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8220167
>>>>
>>>> Feedback on the CSR is very welcome as well!
>>>>
>>>> Thanks,
>>>>     Jan
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 3/5/2019 7:55 AM, Jan Lahoda wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Seems that some classfiles have a weird EnclosingMethod attribute -
>>>>>> for (local/anonymous) class A, the EnclosingMethod attribute states
>>>>>> the enclosing class is C, but the name of C is not a prefix of the
>>>>>> name of A. This appears to be contradictory to JLS 13.1., so the
>>>>>> proposal is to reject such classfiles.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407
>>>>>>
>>>>>> How does this look?
>>>>>>
>>>>>> Thanks,
>>>>>>     Jan
>

From ronshapiro at google.com  Mon Mar 18 18:14:23 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Mon, 18 Mar 2019 14:14:23 -0400
Subject: RFR 8220792: JavacFileManager.list() performance
Message-ID: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>

Hi,

Please review this change to improve the performance of
JavacFileManager.list().

bug: https://bugs.openjdk.java.net/browse/JDK-8220792
webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.00/

Thanks,
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190318/9e1eba89/attachment.html>

From jonathan.gibbons at oracle.com  Mon Mar 18 22:17:52 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 18 Mar 2019 15:17:52 -0700
Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException:
 String index out of range: -2
In-Reply-To: <5C8FC567.6040407@oracle.com>
References: <5C7E9BD7.1070607@oracle.com>
 <df3a5947-ee18-3584-c00e-7fa7abc43943@oracle.com>
 <5C7EAB3F.4050402@oracle.com>
 <44fb40ef-6f77-a389-7559-cbe04ae4e1f1@oracle.com>
 <5C7FA173.5000707@oracle.com>
 <a4e3cc8b-f2a8-faf2-e8d8-c711af8188da@oracle.com>
 <5C8FC567.6040407@oracle.com>
Message-ID: <7db01736-0cf2-2f99-9afe-fae976155d77@oracle.com>

I think it would be better to put all the name checking together, in 
simpleBinaryName.

-- Jon

On 3/18/19 9:20 AM, Jan Lahoda wrote:
> On 16.3.2019 01:10, Jonathan Gibbons wrote:
>> OK, I see the additional checks in simpleBinaryName, which is the sort
>> of check I was expecting.
>>
>> I'm a bit surprised you didn't put the check inside simpleBinaryName,
>> but that would trigger a subsequent question as to why we have
>
> I started with the check inside the simpleBinaryName method, but then 
> moved it outside, as the check seemed like a "general" check, not 
> something related to the simple name as such. I don't have a very 
> strong opinion on this, I can move the check inside simpleBinaryName 
> if preferred.
>
> Thanks,
> ??? Jan
>
>>
>> 1478 throw badEnclosingMethod(self);
>>
>> and ClassReader.simpleBinaryName:1507
>>
>> ???? throw badClassFile("bad.enclosing.method", self);
>>
>> I'm OK with either webrev as is or with the check moved into
>> simpleBinaryName,
>>
>> -- Jon
>>
>> On 03/06/2019 02:31 AM, Jan Lahoda wrote:
>>> Hi Jon,
>>>
>>> On 5.3.2019 21:20, Jonathan Gibbons wrote:
>>>> Jan,
>>>>
>>>> Is checking for a prefix good enough??? It seems like that would be
>>>> necessary but not sufficient.
>>>
>>> What specific additional checks do you foresee? The
>>> ClassReader.simpleBinaryName method does some additional checks, like
>>> that the class suffix is non-empty and starts with '$'.
>>>
>>> Thanks,
>>> ??? Jan
>>>
>>>>
>>>> -- Jon
>>>>
>>>> On 3/5/19 9:00 AM, Jan Lahoda wrote:
>>>>> On 5.3.2019 17:33, Joe Darcy wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> Do you think this issue merits a CSR for the behavioral change?
>>>>>
>>>>> Good question! It is true that javac may now refuse to load 
>>>>> classfiles
>>>>> that didn't lead to the exception before, so I guess a CSR may be in
>>>>> order. I've started with it here:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8220167
>>>>>
>>>>> Feedback on the CSR is very welcome as well!
>>>>>
>>>>> Thanks,
>>>>> ??? Jan
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>> On 3/5/2019 7:55 AM, Jan Lahoda wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Seems that some classfiles have a weird EnclosingMethod attribute -
>>>>>>> for (local/anonymous) class A, the EnclosingMethod attribute states
>>>>>>> the enclosing class is C, but the name of C is not a prefix of the
>>>>>>> name of A. This appears to be contradictory to JLS 13.1., so the
>>>>>>> proposal is to reject such classfiles.
>>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407
>>>>>>>
>>>>>>> How does this look?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> ??? Jan
>>

From ronshapiro at google.com  Tue Mar 19 18:25:07 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Tue, 19 Mar 2019 14:25:07 -0400
Subject: RFR 8220792: Performance bottleneck in JavacFileManager.list()
In-Reply-To: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
Message-ID: <CACA6h9sAEMTKj8RLNRvCgWq9a33vYUkGEC87bvS3UYuXs=wagg@mail.gmail.com>

(fixing the subject to align with the bug title)

On Mon, Mar 18, 2019 at 2:14 PM Ron Shapiro <ronshapiro at google.com> wrote:

> Hi,
>
> Please review this change to improve the performance of
> JavacFileManager.list().
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220792
> webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.00/
>
> Thanks,
> Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190319/521638e1/attachment.html>

From ronshapiro at google.com  Tue Mar 19 22:37:14 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Tue, 19 Mar 2019 18:37:14 -0400
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
Message-ID: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>

Hi,

This is a small change that avoids eagerly creating JCDiagnostic for
CompletionFailures.

webrev: http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8221118

Thanks,
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190319/cb9826b7/attachment.html>

From amaembo at gmail.com  Wed Mar 20 04:10:13 2019
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 20 Mar 2019 11:10:13 +0700
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
Message-ID: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>

Hello!

I just wanted to draw your attention to the issue JDK-8220018. I
reported it several weeks ago, but saw no reaction. Probably I failed
to fill all the necessary fields. The problem is still actual in java
12 GA:

// SwTest.java
public class SwTest {
    public static void main(String[] args) {
        System.out.println(switch (0) {
           default -> {
               try {
                   break 1;
               }
               catch (Exception ex) {
                   break 2;
               }
               finally {
                   break 3;
               }
           }
        });
    }
}

C:\Program Files\Java\jdk-12\bin>java.exe -version
openjdk version "12" 2019-03-19
OpenJDK Runtime Environment (build 12+33)
OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)

"C:\Program Files\Java\jdk-12\bin\javac.exe" --enable-preview
--release=12 SwTest.java
Note: SwTest.java uses preview language features.
Note: Recompile with -Xlint:preview for details.
An exception has occurred in the compiler (12). Please file a bug
against the Java compiler via the Java bug reporting page
(http://bugreport.java.com) after checking the Bug Database
(http://bugs.java.com) for duplicates. Include your program and the
following diagnostic in your report. Thank you.
java.lang.AssertionError
at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBreak(Gen.java:1707)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBreak.accept(JCTree.java:1561)
at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:595)
at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:630)
at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:616)
at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:667)
at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1067)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1026)
at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:595)
at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:630)
at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:616)
at jdk.compiler/com.sun.tools.javac.jvm.Gen$3.genLast(Gen.java:1450)

Also similar failure when try-with-resources is used:

import java.util.stream.*;

public class SwTest {
    public static void main(String[] args) {
        System.out.println(switch (0) {
           default -> {
               try(Stream<?> s = Stream.empty()) {
                   break 1;
               }
           }
        });
    }
}

With best regards,
Tagir Valeev.

From jan.lahoda at oracle.com  Wed Mar 20 07:22:15 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 20 Mar 2019 08:22:15 +0100
Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException:
 String index out of range: -2
In-Reply-To: <7db01736-0cf2-2f99-9afe-fae976155d77@oracle.com>
References: <5C7E9BD7.1070607@oracle.com>
 <df3a5947-ee18-3584-c00e-7fa7abc43943@oracle.com>
 <5C7EAB3F.4050402@oracle.com>
 <44fb40ef-6f77-a389-7559-cbe04ae4e1f1@oracle.com>
 <5C7FA173.5000707@oracle.com>
 <a4e3cc8b-f2a8-faf2-e8d8-c711af8188da@oracle.com>
 <5C8FC567.6040407@oracle.com>
 <7db01736-0cf2-2f99-9afe-fae976155d77@oracle.com>
Message-ID: <5C91EA27.5000209@oracle.com>

On 18.3.2019 23:17, Jonathan Gibbons wrote:
> I think it would be better to put all the name checking together, in
> simpleBinaryName.

Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8215407/webrev.01/

(The only difference compared to the .00 should be in ClassReader.java.)

Does that look OK?

Thanks,
     Jan

>
> -- Jon
>
> On 3/18/19 9:20 AM, Jan Lahoda wrote:
>> On 16.3.2019 01:10, Jonathan Gibbons wrote:
>>> OK, I see the additional checks in simpleBinaryName, which is the sort
>>> of check I was expecting.
>>>
>>> I'm a bit surprised you didn't put the check inside simpleBinaryName,
>>> but that would trigger a subsequent question as to why we have
>>
>> I started with the check inside the simpleBinaryName method, but then
>> moved it outside, as the check seemed like a "general" check, not
>> something related to the simple name as such. I don't have a very
>> strong opinion on this, I can move the check inside simpleBinaryName
>> if preferred.
>>
>> Thanks,
>>     Jan
>>
>>>
>>> 1478 throw badEnclosingMethod(self);
>>>
>>> and ClassReader.simpleBinaryName:1507
>>>
>>>      throw badClassFile("bad.enclosing.method", self);
>>>
>>> I'm OK with either webrev as is or with the check moved into
>>> simpleBinaryName,
>>>
>>> -- Jon
>>>
>>> On 03/06/2019 02:31 AM, Jan Lahoda wrote:
>>>> Hi Jon,
>>>>
>>>> On 5.3.2019 21:20, Jonathan Gibbons wrote:
>>>>> Jan,
>>>>>
>>>>> Is checking for a prefix good enough?   It seems like that would be
>>>>> necessary but not sufficient.
>>>>
>>>> What specific additional checks do you foresee? The
>>>> ClassReader.simpleBinaryName method does some additional checks, like
>>>> that the class suffix is non-empty and starts with '$'.
>>>>
>>>> Thanks,
>>>>     Jan
>>>>
>>>>>
>>>>> -- Jon
>>>>>
>>>>> On 3/5/19 9:00 AM, Jan Lahoda wrote:
>>>>>> On 5.3.2019 17:33, Joe Darcy wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> Do you think this issue merits a CSR for the behavioral change?
>>>>>>
>>>>>> Good question! It is true that javac may now refuse to load
>>>>>> classfiles
>>>>>> that didn't lead to the exception before, so I guess a CSR may be in
>>>>>> order. I've started with it here:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220167
>>>>>>
>>>>>> Feedback on the CSR is very welcome as well!
>>>>>>
>>>>>> Thanks,
>>>>>>     Jan
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Joe
>>>>>>>
>>>>>>> On 3/5/2019 7:55 AM, Jan Lahoda wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Seems that some classfiles have a weird EnclosingMethod attribute -
>>>>>>>> for (local/anonymous) class A, the EnclosingMethod attribute states
>>>>>>>> the enclosing class is C, but the name of C is not a prefix of the
>>>>>>>> name of A. This appears to be contradictory to JLS 13.1., so the
>>>>>>>> proposal is to reject such classfiles.
>>>>>>>>
>>>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407
>>>>>>>>
>>>>>>>> How does this look?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>     Jan
>>>

From christoph.langer at sap.com  Wed Mar 20 08:40:45 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Mar 2019 08:40:45 +0000
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with
 java.lang.AssertionError: Classfiles too old!
In-Reply-To: <HE1PR0201MB22667FACECA75BBD09D1FB568A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22667FACECA75BBD09D1FB568A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0201MB226629263387C525D9D7D6EF8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

Ping...

Any comments/reviews on this test fix?

Thanks
Christoph

From: Langer, Christoph
Sent: Freitag, 15. M?rz 2019 14:25
To: 'compiler-dev at openjdk.java.net' <compiler-dev at openjdk.java.net>
Cc: Zeller, Arno <arno.zeller at sap.com>
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with java.lang.AssertionError: Classfiles too old!

Hi,

please review a fix proposal for an intermittent error in test/langtools/tools/javac/modules/MOptionTest.java.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200286
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8200286.0/

The issue has been reported already a while ago but was closed as not reproducible/won't fix. However, we've encountered this issue quite often on a linuxppc64 test machine in our ci infrastructure. Here are links to failed test jobs:

jdk11u:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/
  ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

jdk12:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
jdk:
https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/
    ->jtr: https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

The analysis done in the bug by Jiangli seems to be true. There is some imprecision in time resolution (maybe rounding issue, maybe os inaccuracy) where it can happen that the class file created by the java compiler has an earlier timestamp than the original source file.

What I did to overcome this is to date back the .java file to be compiled by one second before doing the compilation which will create a class file with the current time stamp. This should make sure that the .java file doesn't have a newer timestamp than the .class file.
I can do that because the test thread had waited for 2 seconds before doing the compilation. In fact, I have removed another 2 second wait because I don't think it is needed at that place since the test had already waited 2 seconds before testing a noop compilation due to unchanged timestamps.

I guess this is certainly not perfect but it should stabilize this test and to me it seems pragmatic.

I have already added this fix to our (SapMachine) code base and have not observed this error after that and didn't run into regressions either.

Thanks
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190320/dee7be26/attachment-0001.html>

From jan.lahoda at oracle.com  Wed Mar 20 19:02:11 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 20 Mar 2019 20:02:11 +0100
Subject: RFR(13): JDK-8217047: Provide a way to inject missing parameter
 names
In-Reply-To: <61878d42-a401-a5a2-3331-d0fa4dd0e77f@oracle.com>
References: <5C45BBE5.6030007@oracle.com>
 <61878d42-a401-a5a2-3331-d0fa4dd0e77f@oracle.com>
Message-ID: <5C928E33.6030508@oracle.com>

Hi Jon,

Thanks for the comments. I tried to improve the javadoc, added implNote, 
and fixed Flags and MissingInfoHandler.

Regarding ClassReader always creating ParamSymbols, as the ParamSymbol 
is not bigger than VarSymbol, I opted for simplicity and a more uniform 
representation. But I can change that to use VarSymbol when the name is 
known, should be simple.

Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8217047/webrev.03/

Updated specdiff:
http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.03/overview-summary.html

How does this look?

Thanks,
     Jan

On 16.3.2019 01:32, Jonathan Gibbons wrote:
> Nice.  Minor comments...
>
> The {@linkplain}don't seem to be working as expected;  I suspect you
> need to import the type names. Also, you should use parens and arg types
> on links to methods; if you don't want the `(arg-types)` to show up in
> the docs, use the form of {@linkplain} that allows you to specify the
> text to be linked.
>
> The new method in JavacTask should have an implNote that says, "This
> Implementation does nothing." or words to that effect.
>
> (Aside: we have a more general problem with implNotes, that we have
> places where the default is to do nothing or throw UOE, but the reality
> is that the real-world impl of these methods does something useful. I
> don't know how/where we should document that behavior. But that's a
> bigger question for another time and another review.)
>
> Flags.java
>
> typo: friedly
>
> ClassReader ... just curious, you always create a new ParamSymbol, even
> when you could use a VarSymbol (because you have already filled in the
> name).  I guess the code is neater/more consistent the way you have it.
>
> MissingInfoHandler ... no class-level doc comment. I realize it's an
> internal class but even so ...
>
> -- Jon
>
>
> On 01/21/2019 04:32 AM, Jan Lahoda wrote:
>> Hi,
>>
>> When a type is load from a classfile, and some or all of its methods
>> have neither the MethodParameters or LocalVariableTable attributes,
>> then the parameters of the methods have an artificial synthesized
>> name, which is visible through VariableElement.getSimpleName().
>>
>> The proposal here is to allow to plug in an external provider that
>> could provide more user-friendly names lazily/on demand. These could
>> originate e.g. in adjacent sources.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217437
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8217047/webrev.01/
>> Specdiff:
>> http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.01/overview-summary.html
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8217437
>>
>> What do you think?
>>
>> Thanks,
>>     Jan
>

From thomas.stuefe at gmail.com  Thu Mar 21 10:31:39 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 21 Mar 2019 11:31:39 +0100
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with
 java.lang.AssertionError: Classfiles too old!
In-Reply-To: <HE1PR0201MB226629263387C525D9D7D6EF8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22667FACECA75BBD09D1FB568A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <HE1PR0201MB226629263387C525D9D7D6EF8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUxFpgJ1dJokaq-AW+Cj7-qa20DkYOeL2wACtBR1N_98Lw@mail.gmail.com>

Looks reasonable. I am not sure I understand the purpose of the 2 second
waits so I cannot comment what their removal does.

Comment: please loose the commas and the trailing "otherwise"

Thanks! Thomas

On Wed, Mar 20, 2019 at 9:41 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi,
>
>
>
> Ping?
>
>
>
> Any comments/reviews on this test fix?
>
>
>
> Thanks
>
> Christoph
>
>
>
> *From:* Langer, Christoph
> *Sent:* Freitag, 15. M?rz 2019 14:25
> *To:* 'compiler-dev at openjdk.java.net' <compiler-dev at openjdk.java.net>
> *Cc:* Zeller, Arno <arno.zeller at sap.com>
> *Subject:* RFR(S): 8200286: (testbug) MOptionTest test fails with
> java.lang.AssertionError: Classfiles too old!
>
>
>
> Hi,
>
>
>
> please review a fix proposal for an intermittent error in
> test/langtools/tools/javac/modules/MOptionTest.java.
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200286
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8200286.0/
>
>
>
> The issue has been reported already a while ago but was closed as not
> reproducible/won?t fix. However, we?ve encountered this issue quite often
> on a linuxppc64 test machine in our ci infrastructure. Here are links to
> failed test jobs:
>
>
>
> jdk11u:
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/
>
>   ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
>
> jdk12:
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
> jdk:
>
>
> https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
>
> The analysis done in the bug by Jiangli seems to be true. There is some
> imprecision in time resolution (maybe rounding issue, maybe os inaccuracy)
> where it can happen that the class file created by the java compiler has an
> earlier timestamp than the original source file.
>
>
>
> What I did to overcome this is to date back the .java file to be compiled
> by one second before doing the compilation which will create a class file
> with the current time stamp. This should make sure that the .java file
> doesn?t have a newer timestamp than the .class file.
>
> I can do that because the test thread had waited for 2 seconds before
> doing the compilation. In fact, I have removed another 2 second wait
> because I don?t think it is needed at that place since the test had already
> waited 2 seconds before testing a noop compilation due to unchanged
> timestamps.
>
>
>
> I guess this is certainly not perfect but it should stabilize this test
> and to me it seems pragmatic.
>
>
>
> I have already added this fix to our (SapMachine) code base and have not
> observed this error after that and didn?t run into regressions either.
>
>
>
> Thanks
>
> Christoph
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190321/d5a06ed0/attachment.html>

From bsrbnd at gmail.com  Thu Mar 21 15:37:04 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Thu, 21 Mar 2019 16:37:04 +0100
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
Message-ID: <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>

Hi,

On Wed, 20 Mar 2019 at 05:11, Tagir Valeev <amaembo at gmail.com> wrote:
>
> Hello!
>
> I just wanted to draw your attention to the issue JDK-8220018. I
> reported it several weeks ago, but saw no reaction. Probably I failed
> to fill all the necessary fields. The problem is still actual in java
> 12 GA:
>
> // SwTest.java
> public class SwTest {
>     public static void main(String[] args) {
>         System.out.println(switch (0) {
>            default -> {
>                try {
>                    break 1;
>                }
>                catch (Exception ex) {
>                    break 2;
>                }
>                finally {
>                    break 3;
>                }
>            }
>         });
>     }
> }

Is somebody already looking at this?

This is an interesting issue because when generating the final 'break
3', an operand stack size mismatch occurs due to the other already
emitted breaks.
I tried the following tweak to pop the unnecessary operands before
generating the last break, does this look reasonable (langtools:tier1
being OK)?

Thanks,
Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
@@ -1223,6 +1223,15 @@
         return !alive || state.stacksize == letExprStackPos;
     }

+    public void makeStatementStart() {
+        if (state.stacksize > letExprStackPos) {
+            int toPop = state.stacksize - letExprStackPos;
+            for (int i=0; i<toPop; i++) {
+                emitop0(pop);
+            }
+        }
+    }
+
 /**************************************************************************
  * Stack map generation
  *************************************************************************/
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
@@ -1704,7 +1704,7 @@
     }

     public void visitBreak(JCBreak tree) {
-        Assert.check(code.isStatementStart());
+        code.makeStatementStart();
         final Env<GenContext> targetEnv;
         if (tree.isValueBreak()) {
             //restore stack as it was before the switch expression:

From forax at univ-mlv.fr  Thu Mar 21 16:02:35 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 21 Mar 2019 17:02:35 +0100 (CET)
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
 <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
Message-ID: <247243880.1647872.1553184155000.JavaMail.zimbra@u-pem.fr>

That's interesting,
it means that the sequence
  switch(0) { default -> { ... }}
can transform any statement syntax into an expression.
  
so
  let x = init in expression
can be written
  switch(0) { default -> { try(var x = init) { break expression; } }}

so instead of point.getX() * point.getX() which is clearly not effective,
one can now write
  switch(0) { default -> { try(var x = point.getX()) { break x * x; } }}
which is obviously far better

R?mi

----- Mail original -----
> De: "B. Blaser" <bsrbnd at gmail.com>
> ?: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoy?: Jeudi 21 Mars 2019 16:37:04
> Objet: Re: Java 12: javac crash with switch expression containing try-catch-finally

> Hi,
> 
> On Wed, 20 Mar 2019 at 05:11, Tagir Valeev <amaembo at gmail.com> wrote:
>>
>> Hello!
>>
>> I just wanted to draw your attention to the issue JDK-8220018. I
>> reported it several weeks ago, but saw no reaction. Probably I failed
>> to fill all the necessary fields. The problem is still actual in java
>> 12 GA:
>>
>> // SwTest.java
>> public class SwTest {
>>     public static void main(String[] args) {
>>         System.out.println(switch (0) {
>>            default -> {
>>                try {
>>                    break 1;
>>                }
>>                catch (Exception ex) {
>>                    break 2;
>>                }
>>                finally {
>>                    break 3;
>>                }
>>            }
>>         });
>>     }
>> }
> 
> Is somebody already looking at this?
> 
> This is an interesting issue because when generating the final 'break
> 3', an operand stack size mismatch occurs due to the other already
> emitted breaks.
> I tried the following tweak to pop the unnecessary operands before
> generating the last break, does this look reasonable (langtools:tier1
> being OK)?
> 
> Thanks,
> Bernard
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> @@ -1223,6 +1223,15 @@
>         return !alive || state.stacksize == letExprStackPos;
>     }
> 
> +    public void makeStatementStart() {
> +        if (state.stacksize > letExprStackPos) {
> +            int toPop = state.stacksize - letExprStackPos;
> +            for (int i=0; i<toPop; i++) {
> +                emitop0(pop);
> +            }
> +        }
> +    }
> +
> /**************************************************************************
>  * Stack map generation
>  *************************************************************************/
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> @@ -1704,7 +1704,7 @@
>     }
> 
>     public void visitBreak(JCBreak tree) {
> -        Assert.check(code.isStatementStart());
> +        code.makeStatementStart();
>         final Env<GenContext> targetEnv;
>         if (tree.isValueBreak()) {
>              //restore stack as it was before the switch expression:

From christoph.langer at sap.com  Thu Mar 21 16:14:46 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Mar 2019 16:14:46 +0000
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with
 java.lang.AssertionError: Classfiles too old!
In-Reply-To: <CAA-vtUxFpgJ1dJokaq-AW+Cj7-qa20DkYOeL2wACtBR1N_98Lw@mail.gmail.com>
References: <HE1PR0201MB22667FACECA75BBD09D1FB568A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <HE1PR0201MB226629263387C525D9D7D6EF8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <CAA-vtUxFpgJ1dJokaq-AW+Cj7-qa20DkYOeL2wACtBR1N_98Lw@mail.gmail.com>
Message-ID: <HE1PR0201MB22669A0E4D384AC08BDDA4E48A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Thomas,

thanks for your review. I updated the comment lines: http://cr.openjdk.java.net/~clanger/webrevs/8200286.1/

Best regards
Christoph

From: Thomas St?fe <thomas.stuefe at gmail.com>
Sent: Donnerstag, 21. M?rz 2019 11:32
To: Langer, Christoph <christoph.langer at sap.com>
Cc: compiler-dev at openjdk.java.net
Subject: Re: RFR(S): 8200286: (testbug) MOptionTest test fails with java.lang.AssertionError: Classfiles too old!

Looks reasonable. I am not sure I understand the purpose of the 2 second waits so I cannot comment what their removal does.

Comment: please loose the commas and the trailing "otherwise"

Thanks! Thomas

On Wed, Mar 20, 2019 at 9:41 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi,

Ping?

Any comments/reviews on this test fix?

Thanks
Christoph

From: Langer, Christoph
Sent: Freitag, 15. M?rz 2019 14:25
To: 'compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>' <compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>>
Cc: Zeller, Arno <arno.zeller at sap.com<mailto:arno.zeller at sap.com>>
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with java.lang.AssertionError: Classfiles too old!

Hi,

please review a fix proposal for an intermittent error in test/langtools/tools/javac/modules/MOptionTest.java.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200286
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8200286.0/

The issue has been reported already a while ago but was closed as not reproducible/won?t fix. However, we?ve encountered this issue quite often on a linuxppc64 test machine in our ci infrastructure. Here are links to failed test jobs:

jdk11u:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/
  ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

jdk12:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
jdk:
https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/
    ->jtr: https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

The analysis done in the bug by Jiangli seems to be true. There is some imprecision in time resolution (maybe rounding issue, maybe os inaccuracy) where it can happen that the class file created by the java compiler has an earlier timestamp than the original source file.

What I did to overcome this is to date back the .java file to be compiled by one second before doing the compilation which will create a class file with the current time stamp. This should make sure that the .java file doesn?t have a newer timestamp than the .class file.
I can do that because the test thread had waited for 2 seconds before doing the compilation. In fact, I have removed another 2 second wait because I don?t think it is needed at that place since the test had already waited 2 seconds before testing a noop compilation due to unchanged timestamps.

I guess this is certainly not perfect but it should stabilize this test and to me it seems pragmatic.

I have already added this fix to our (SapMachine) code base and have not observed this error after that and didn?t run into regressions either.

Thanks
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190321/ff6430d4/attachment-0001.html>

From jan.lahoda at oracle.com  Thu Mar 21 17:24:32 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 21 Mar 2019 18:24:32 +0100
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
 <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
Message-ID: <5C93C8D0.1070707@oracle.com>

Hi Bernard,

I was peeking at this, and expected to start to work on this.

I do agree we will need to strip the extra values from the stack, but we 
may also need to set the letExprStackPos at some point.

Jan

On 21.3.2019 16:37, B. Blaser wrote:
> Hi,
>
> On Wed, 20 Mar 2019 at 05:11, Tagir Valeev <amaembo at gmail.com> wrote:
>>
>> Hello!
>>
>> I just wanted to draw your attention to the issue JDK-8220018. I
>> reported it several weeks ago, but saw no reaction. Probably I failed
>> to fill all the necessary fields. The problem is still actual in java
>> 12 GA:
>>
>> // SwTest.java
>> public class SwTest {
>>      public static void main(String[] args) {
>>          System.out.println(switch (0) {
>>             default -> {
>>                 try {
>>                     break 1;
>>                 }
>>                 catch (Exception ex) {
>>                     break 2;
>>                 }
>>                 finally {
>>                     break 3;
>>                 }
>>             }
>>          });
>>      }
>> }
>
> Is somebody already looking at this?
>
> This is an interesting issue because when generating the final 'break
> 3', an operand stack size mismatch occurs due to the other already
> emitted breaks.
> I tried the following tweak to pop the unnecessary operands before
> generating the last break, does this look reasonable (langtools:tier1
> being OK)?
>
> Thanks,
> Bernard
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> @@ -1223,6 +1223,15 @@
>           return !alive || state.stacksize == letExprStackPos;
>       }
>
> +    public void makeStatementStart() {
> +        if (state.stacksize > letExprStackPos) {
> +            int toPop = state.stacksize - letExprStackPos;
> +            for (int i=0; i<toPop; i++) {
> +                emitop0(pop);
> +            }
> +        }
> +    }
> +
>   /**************************************************************************
>    * Stack map generation
>    *************************************************************************/
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> @@ -1704,7 +1704,7 @@
>       }
>
>       public void visitBreak(JCBreak tree) {
> -        Assert.check(code.isStatementStart());
> +        code.makeStatementStart();
>           final Env<GenContext> targetEnv;
>           if (tree.isValueBreak()) {
>               //restore stack as it was before the switch expression:
>

From thomas.stuefe at gmail.com  Thu Mar 21 18:53:45 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 21 Mar 2019 19:53:45 +0100
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with
 java.lang.AssertionError: Classfiles too old!
In-Reply-To: <HE1PR0201MB22669A0E4D384AC08BDDA4E48A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB22667FACECA75BBD09D1FB568A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <HE1PR0201MB226629263387C525D9D7D6EF8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <CAA-vtUxFpgJ1dJokaq-AW+Cj7-qa20DkYOeL2wACtBR1N_98Lw@mail.gmail.com>
 <HE1PR0201MB22669A0E4D384AC08BDDA4E48A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUwxfvgo8kaqVWw7vFYCwPiuh5BAskrT9PANqiFUHOQXmA@mail.gmail.com>

Looks good now.

..Thomas

On Thu, Mar 21, 2019 at 5:15 PM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Thomas,
>
>
>
> thanks for your review. I updated the comment lines:
> http://cr.openjdk.java.net/~clanger/webrevs/8200286.1/
>
>
>
> Best regards
>
> Christoph
>
>
>
> *From:* Thomas St?fe <thomas.stuefe at gmail.com>
> *Sent:* Donnerstag, 21. M?rz 2019 11:32
> *To:* Langer, Christoph <christoph.langer at sap.com>
> *Cc:* compiler-dev at openjdk.java.net
> *Subject:* Re: RFR(S): 8200286: (testbug) MOptionTest test fails with
> java.lang.AssertionError: Classfiles too old!
>
>
>
> Looks reasonable. I am not sure I understand the purpose of the 2 second
> waits so I cannot comment what their removal does.
>
>
>
> Comment: please loose the commas and the trailing "otherwise"
>
> Thanks! Thomas
>
>
>
> On Wed, Mar 20, 2019 at 9:41 AM Langer, Christoph <
> christoph.langer at sap.com> wrote:
>
> Hi,
>
>
>
> Ping?
>
>
>
> Any comments/reviews on this test fix?
>
>
>
> Thanks
>
> Christoph
>
>
>
> *From:* Langer, Christoph
> *Sent:* Freitag, 15. M?rz 2019 14:25
> *To:* 'compiler-dev at openjdk.java.net' <compiler-dev at openjdk.java.net>
> *Cc:* Zeller, Arno <arno.zeller at sap.com>
> *Subject:* RFR(S): 8200286: (testbug) MOptionTest test fails with
> java.lang.AssertionError: Classfiles too old!
>
>
>
> Hi,
>
>
>
> please review a fix proposal for an intermittent error in
> test/langtools/tools/javac/modules/MOptionTest.java.
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200286
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8200286.0/
>
>
>
> The issue has been reported already a while ago but was closed as not
> reproducible/won?t fix. However, we?ve encountered this issue quite often
> on a linuxppc64 test machine in our ci infrastructure. Here are links to
> failed test jobs:
>
>
>
> jdk11u:
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/
>
>   ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
>
> jdk12:
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
> jdk:
>
>
> https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
>
> The analysis done in the bug by Jiangli seems to be true. There is some
> imprecision in time resolution (maybe rounding issue, maybe os inaccuracy)
> where it can happen that the class file created by the java compiler has an
> earlier timestamp than the original source file.
>
>
>
> What I did to overcome this is to date back the .java file to be compiled
> by one second before doing the compilation which will create a class file
> with the current time stamp. This should make sure that the .java file
> doesn?t have a newer timestamp than the .class file.
>
> I can do that because the test thread had waited for 2 seconds before
> doing the compilation. In fact, I have removed another 2 second wait
> because I don?t think it is needed at that place since the test had already
> waited 2 seconds before testing a noop compilation due to unchanged
> timestamps.
>
>
>
> I guess this is certainly not perfect but it should stabilize this test
> and to me it seems pragmatic.
>
>
>
> I have already added this fix to our (SapMachine) code base and have not
> observed this error after that and didn?t run into regressions either.
>
>
>
> Thanks
>
> Christoph
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190321/505104bb/attachment.html>

From jonathan.gibbons at oracle.com  Thu Mar 21 19:12:28 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 21 Mar 2019 12:12:28 -0700
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with
 java.lang.AssertionError: Classfiles too old!
In-Reply-To: <CAA-vtUwxfvgo8kaqVWw7vFYCwPiuh5BAskrT9PANqiFUHOQXmA@mail.gmail.com>
References: <HE1PR0201MB22667FACECA75BBD09D1FB568A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <HE1PR0201MB226629263387C525D9D7D6EF8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <CAA-vtUxFpgJ1dJokaq-AW+Cj7-qa20DkYOeL2wACtBR1N_98Lw@mail.gmail.com>
 <HE1PR0201MB22669A0E4D384AC08BDDA4E48A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <CAA-vtUwxfvgo8kaqVWw7vFYCwPiuh5BAskrT9PANqiFUHOQXmA@mail.gmail.com>
Message-ID: <f3643ed1-3103-fd9c-d03b-198a08b2cf8a@oracle.com>

Looks good, and better than the earlier sleep calls.

An alternative strategy, in case there is ever any issue setting the 
time of the file, would be a conditional/iterative sleep until the time 
to write a second file is observably different from the time to write an 
initial file.

-- Jon


On 03/21/2019 11:53 AM, Thomas St?fe wrote:
> Looks good now.
>
> ..Thomas
>
> On Thu, Mar 21, 2019 at 5:15 PM Langer, Christoph 
> <christoph.langer at sap.com <mailto:christoph.langer at sap.com>> wrote:
>
>     Hi Thomas,
>
>     thanks for your review. I updated the comment lines:
>     http://cr.openjdk.java.net/~clanger/webrevs/8200286.1/
>     <http://cr.openjdk.java.net/%7Eclanger/webrevs/8200286.1/>
>
>     Best regards
>
>     Christoph
>
>     *From:*Thomas St?fe <thomas.stuefe at gmail.com
>     <mailto:thomas.stuefe at gmail.com>>
>     *Sent:* Donnerstag, 21. M?rz 2019 11:32
>     *To:* Langer, Christoph <christoph.langer at sap.com
>     <mailto:christoph.langer at sap.com>>
>     *Cc:* compiler-dev at openjdk.java.net
>     <mailto:compiler-dev at openjdk.java.net>
>     *Subject:* Re: RFR(S): 8200286: (testbug) MOptionTest test fails
>     with java.lang.AssertionError: Classfiles too old!
>
>     Looks reasonable. I am not sure I understand the purpose of the 2
>     second waits so I cannot comment what their removal does.
>
>     Comment: please loose the commas and the trailing "otherwise"
>
>     Thanks! Thomas
>
>     On Wed, Mar 20, 2019 at 9:41 AM Langer, Christoph
>     <christoph.langer at sap.com <mailto:christoph.langer at sap.com>> wrote:
>
>         Hi,
>
>         Ping?
>
>         Any comments/reviews on this test fix?
>
>         Thanks
>
>         Christoph
>
>         *From:*Langer, Christoph
>         *Sent:* Freitag, 15. M?rz 2019 14:25
>         *To:* 'compiler-dev at openjdk.java.net
>         <mailto:compiler-dev at openjdk.java.net>'
>         <compiler-dev at openjdk.java.net
>         <mailto:compiler-dev at openjdk.java.net>>
>         *Cc:* Zeller, Arno <arno.zeller at sap.com
>         <mailto:arno.zeller at sap.com>>
>         *Subject:* RFR(S): 8200286: (testbug) MOptionTest test fails
>         with java.lang.AssertionError: Classfiles too old!
>
>         Hi,
>
>         please review a fix proposal for an intermittent error in
>         test/langtools/tools/javac/modules/MOptionTest.java.
>
>         Bug: https://bugs.openjdk.java.net/browse/JDK-8200286
>
>         Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8200286.0/
>         <http://cr.openjdk.java.net/%7Eclanger/webrevs/8200286.0/>
>
>         The issue has been reported already a while ago but was closed
>         as not reproducible/won?t fix. However, we?ve encountered this
>         issue quite often on a linuxppc64 test machine in our ci
>         infrastructure. Here are links to failed test jobs:
>
>         jdk11u:
>
>         https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/
>
>         ??->jtr:
>         https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>         https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/
>
>         ->jtr:
>         https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>         jdk12:
>
>         https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/
>
>         ->jtr:
>         https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
>         https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/
>
>         ->jtr:
>         https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
>         jdk:
>
>         https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/
>
>         ->jtr:
>         https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>         The analysis done in the bug by Jiangli seems to be true.
>         There is some imprecision in time resolution (maybe rounding
>         issue, maybe os inaccuracy) where it can happen that the class
>         file created by the java compiler has an earlier timestamp
>         than the original source file.
>
>         What I did to overcome this is to date back the .java file to
>         be compiled by one second before doing the compilation which
>         will create a class file with the current time stamp. This
>         should make sure that the .java file doesn?t have a newer
>         timestamp than the .class file.
>
>         I can do that because the test thread had waited for 2 seconds
>         before doing the compilation. In fact, I have removed another
>         2 second wait because I don?t think it is needed at that place
>         since the test had already waited 2 seconds before testing a
>         noop compilation due to unchanged timestamps.
>
>         I guess this is certainly not perfect but it should stabilize
>         this test and to me it seems pragmatic.
>
>         I have already added this fix to our (SapMachine) code base
>         and have not observed this error after that and didn?t run
>         into regressions either.
>
>         Thanks
>
>         Christoph
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190321/0921c930/attachment-0001.html>

From christoph.langer at sap.com  Fri Mar 22 07:58:42 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Mar 2019 07:58:42 +0000
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with
 java.lang.AssertionError: Classfiles too old!
In-Reply-To: <f3643ed1-3103-fd9c-d03b-198a08b2cf8a@oracle.com>
References: <HE1PR0201MB22667FACECA75BBD09D1FB568A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <HE1PR0201MB226629263387C525D9D7D6EF8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <CAA-vtUxFpgJ1dJokaq-AW+Cj7-qa20DkYOeL2wACtBR1N_98Lw@mail.gmail.com>
 <HE1PR0201MB22669A0E4D384AC08BDDA4E48A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <CAA-vtUwxfvgo8kaqVWw7vFYCwPiuh5BAskrT9PANqiFUHOQXmA@mail.gmail.com>
 <f3643ed1-3103-fd9c-d03b-198a08b2cf8a@oracle.com>
Message-ID: <HE1PR0201MB226605B111920CE3A0BACBD78A430@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Thanks, Jon and Thomas for the reviews. I pushed this now.

From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
Sent: Donnerstag, 21. M?rz 2019 20:12
To: Thomas St?fe <thomas.stuefe at gmail.com>; Langer, Christoph <christoph.langer at sap.com>
Cc: compiler-dev at openjdk.java.net
Subject: Re: RFR(S): 8200286: (testbug) MOptionTest test fails with java.lang.AssertionError: Classfiles too old!


Looks good, and better than the earlier sleep calls.

An alternative strategy, in case there is ever any issue setting the time of the file, would be a conditional/iterative sleep until the time to write a second file is observably different from the time to write an initial file.

-- Jon

On 03/21/2019 11:53 AM, Thomas St?fe wrote:
Looks good now.

..Thomas

On Thu, Mar 21, 2019 at 5:15 PM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi Thomas,

thanks for your review. I updated the comment lines: http://cr.openjdk.java.net/~clanger/webrevs/8200286.1/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8200286.1/>

Best regards
Christoph

From: Thomas St?fe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>>
Sent: Donnerstag, 21. M?rz 2019 11:32
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>
Subject: Re: RFR(S): 8200286: (testbug) MOptionTest test fails with java.lang.AssertionError: Classfiles too old!

Looks reasonable. I am not sure I understand the purpose of the 2 second waits so I cannot comment what their removal does.

Comment: please loose the commas and the trailing "otherwise"

Thanks! Thomas

On Wed, Mar 20, 2019 at 9:41 AM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi,

Ping?

Any comments/reviews on this test fix?

Thanks
Christoph

From: Langer, Christoph
Sent: Freitag, 15. M?rz 2019 14:25
To: 'compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>' <compiler-dev at openjdk.java.net<mailto:compiler-dev at openjdk.java.net>>
Cc: Zeller, Arno <arno.zeller at sap.com<mailto:arno.zeller at sap.com>>
Subject: RFR(S): 8200286: (testbug) MOptionTest test fails with java.lang.AssertionError: Classfiles too old!

Hi,

please review a fix proposal for an intermittent error in test/langtools/tools/javac/modules/MOptionTest.java.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200286
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8200286.0/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8200286.0/>

The issue has been reported already a while ago but was closed as not reproducible/won?t fix. However, we?ve encountered this issue quite often on a linuxppc64 test machine in our ci infrastructure. Here are links to failed test jobs:

jdk11u:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/
  ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

jdk12:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
jdk:
https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/
    ->jtr: https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

The analysis done in the bug by Jiangli seems to be true. There is some imprecision in time resolution (maybe rounding issue, maybe os inaccuracy) where it can happen that the class file created by the java compiler has an earlier timestamp than the original source file.

What I did to overcome this is to date back the .java file to be compiled by one second before doing the compilation which will create a class file with the current time stamp. This should make sure that the .java file doesn?t have a newer timestamp than the .class file.
I can do that because the test thread had waited for 2 seconds before doing the compilation. In fact, I have removed another 2 second wait because I don?t think it is needed at that place since the test had already waited 2 seconds before testing a noop compilation due to unchanged timestamps.

I guess this is certainly not perfect but it should stabilize this test and to me it seems pragmatic.

I have already added this fix to our (SapMachine) code base and have not observed this error after that and didn?t run into regressions either.

Thanks
Christoph


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190322/f5be769d/attachment-0001.html>

From joe.darcy at oracle.com  Fri Mar 22 17:34:48 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 22 Mar 2019 10:34:48 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
Message-ID: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>

Hello,

Responding to an rfe filed by Liam, please review a refactoring of the 
SourceVersion.latestSupported method:

 ??? JDK-8221264: Refactor SourceVersion#latestSupported
 ??? http://cr.openjdk.java.net/~darcy/8221264.0/

Patch below.

With this version, when it comes time to rev a release for 14, the line

+??????????? return valueOf("RELEASE_" + Math.min(13, intVersion));

will need to be changed to

+??????????? return valueOf("RELEASE_" + Math.min(14, intVersion));

In general the JSR 269 packages, javax.lang.model and 
javax.annotation.processing, are constrained by bootstrapping issue to 
be runnable on JDK (N-1); in other words, they cannot only run on JDK N. 
It may or may not be possible to compile the code to run on JDK (N-2) or 
earlier. For example, since JDK 9, the JSR 269 API has used default 
methods so the API certainly cannot be compiled and run earlier than JDK 8.

The Runtime.Version type was introduced in JDK 9; its feature() method 
in 10.

The proposed implementation is simple, even if it is not completely 
accurate in a current lower bound for running the API; I don't think 
being more accurate on this lower bound is necessary.

Thanks,

-Joe

--- 
old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
2019-03-22 10:09:33.870668998 -0700
+++ 
new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
2019-03-22 10:09:33.526668998 -0700
@@ -209,30 +209,13 @@
 ???? private static final SourceVersion latestSupported = 
getLatestSupported();

 ???? private static SourceVersion getLatestSupported() {
-??????? try {
-??????????? String specVersion = 
System.getProperty("java.specification.version");
+??????? int intVersion = Runtime.version().feature();

-??????????? switch (specVersion) {
-??????????????? case "13":
-??????????????????? return RELEASE_13;
-??????????????? case "12":
-??????????????????? return RELEASE_12;
-??????????????? case "11":
-??????????????????? return RELEASE_11;
-??????????????? case "10":
-??????????????????? return RELEASE_10;
-??????????????? case "9":
-??????????????????? return RELEASE_9;
-??????????????? case "1.8":
-??????????????????? return RELEASE_8;
-??????????????? case "1.7":
-??????????????????? return RELEASE_7;
-??????????????? case "1.6":
-??????????????????? return RELEASE_6;
-??????????? }
-??????? } catch (SecurityException se) {}
-
-??????? return RELEASE_5;
+??????? if (intVersion >= 10) {
+??????????? return valueOf("RELEASE_" + Math.min(13, intVersion));
+??????? } else {
+??????????? return RELEASE_9;
+??????? }
 ???? }

 ???? /**


From cushon at google.com  Fri Mar 22 18:14:24 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 22 Mar 2019 11:14:24 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
Message-ID: <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>

Thanks Joe,

This looks good to me overall, for what it's worth.

Some minor notes:

* I think it might still be helpful to capture some of your explanation
from the bug in the javadoc for latestSupported(), to help users understand
when the use of that method is appropriate.

* Your explanation of the lower bound might make a good implementation
comment to explain the use of RELEASE_9.

* Also, have you considered including the numeric feature version in the
enum constants in SourceVersion? It might avoid some of the hard-coded
version numbers in getLatestSupported. I'm imagining something along the
lines of:
http://cr.openjdk.java.net/~cushon/8221264/webrev.00/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java.sdiff.html

On Fri, Mar 22, 2019 at 10:34 AM Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello,
>
> Responding to an rfe filed by Liam, please review a refactoring of the
> SourceVersion.latestSupported method:
>
>      JDK-8221264: Refactor SourceVersion#latestSupported
>      http://cr.openjdk.java.net/~darcy/8221264.0/
>
> Patch below.
>
> With this version, when it comes time to rev a release for 14, the line
>
> +            return valueOf("RELEASE_" + Math.min(13, intVersion));
>
> will need to be changed to
>
> +            return valueOf("RELEASE_" + Math.min(14, intVersion));
>
> In general the JSR 269 packages, javax.lang.model and
> javax.annotation.processing, are constrained by bootstrapping issue to
> be runnable on JDK (N-1); in other words, they cannot only run on JDK N.
> It may or may not be possible to compile the code to run on JDK (N-2) or
> earlier. For example, since JDK 9, the JSR 269 API has used default
> methods so the API certainly cannot be compiled and run earlier than JDK 8.
>
> The Runtime.Version type was introduced in JDK 9; its feature() method
> in 10.
>
> The proposed implementation is simple, even if it is not completely
> accurate in a current lower bound for running the API; I don't think
> being more accurate on this lower bound is necessary.
>
> Thanks,
>
> -Joe
>
> ---
> old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
> 2019-03-22 10:09:33.870668998 -0700
> +++
> new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
> 2019-03-22 10:09:33.526668998 -0700
> @@ -209,30 +209,13 @@
>       private static final SourceVersion latestSupported =
> getLatestSupported();
>
>       private static SourceVersion getLatestSupported() {
> -        try {
> -            String specVersion =
> System.getProperty("java.specification.version");
> +        int intVersion = Runtime.version().feature();
>
> -            switch (specVersion) {
> -                case "13":
> -                    return RELEASE_13;
> -                case "12":
> -                    return RELEASE_12;
> -                case "11":
> -                    return RELEASE_11;
> -                case "10":
> -                    return RELEASE_10;
> -                case "9":
> -                    return RELEASE_9;
> -                case "1.8":
> -                    return RELEASE_8;
> -                case "1.7":
> -                    return RELEASE_7;
> -                case "1.6":
> -                    return RELEASE_6;
> -            }
> -        } catch (SecurityException se) {}
> -
> -        return RELEASE_5;
> +        if (intVersion >= 10) {
> +            return valueOf("RELEASE_" + Math.min(13, intVersion));
> +        } else {
> +            return RELEASE_9;
> +        }
>       }
>
>       /**
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190322/68eb2978/attachment.html>

From jonathan.gibbons at oracle.com  Fri Mar 22 18:46:24 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 22 Mar 2019 11:46:24 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
Message-ID: <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>

+1 on an RFE to get a numeric version from a source version, either now 
or in a follow-up RFE ... and potentially the reverse as well, to get a 
SourceVersion from a numeric argument.? Both would help with analyzing 
and creating command-line arguments, without excessive string-bashing or 
side-maps.

-- Jon


On 03/22/2019 11:14 AM, Liam Miller-Cushon wrote:
> Thanks Joe,
>
> This looks good to me overall, for what it's worth.
>
> Some minor notes:
>
> * I think it might still be helpful to capture some of your 
> explanation from the bug in the javadoc for latestSupported(), to help 
> users understand when the use of that method is appropriate.
>
> * Your explanation of the lower bound might make a good implementation 
> comment to explain the use of RELEASE_9.
>
> * Also, have you considered including the numeric feature version in 
> the enum constants in SourceVersion? It might avoid some of the 
> hard-coded version numbers in getLatestSupported. I'm imagining 
> something along the lines of:
> http://cr.openjdk.java.net/~cushon/8221264/webrev.00/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java.sdiff.html 
> <http://cr.openjdk.java.net/%7Ecushon/8221264/webrev.00/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java.sdiff.html>
>
> On Fri, Mar 22, 2019 at 10:34 AM Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Hello,
>
>     Responding to an rfe filed by Liam, please review a refactoring of
>     the
>     SourceVersion.latestSupported method:
>
>     ???? JDK-8221264: Refactor SourceVersion#latestSupported
>     http://cr.openjdk.java.net/~darcy/8221264.0/
>     <http://cr.openjdk.java.net/%7Edarcy/8221264.0/>
>
>     Patch below.
>
>     With this version, when it comes time to rev a release for 14, the
>     line
>
>     +??????????? return valueOf("RELEASE_" + Math.min(13, intVersion));
>
>     will need to be changed to
>
>     +??????????? return valueOf("RELEASE_" + Math.min(14, intVersion));
>
>     In general the JSR 269 packages, javax.lang.model and
>     javax.annotation.processing, are constrained by bootstrapping
>     issue to
>     be runnable on JDK (N-1); in other words, they cannot only run on
>     JDK N.
>     It may or may not be possible to compile the code to run on JDK
>     (N-2) or
>     earlier. For example, since JDK 9, the JSR 269 API has used default
>     methods so the API certainly cannot be compiled and run earlier
>     than JDK 8.
>
>     The Runtime.Version type was introduced in JDK 9; its feature()
>     method
>     in 10.
>
>     The proposed implementation is simple, even if it is not completely
>     accurate in a current lower bound for running the API; I don't think
>     being more accurate on this lower bound is necessary.
>
>     Thanks,
>
>     -Joe
>
>     ---
>     old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>
>     2019-03-22 10:09:33.870668998 -0700
>     +++
>     new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>
>     2019-03-22 10:09:33.526668998 -0700
>     @@ -209,30 +209,13 @@
>     ????? private static final SourceVersion latestSupported =
>     getLatestSupported();
>
>     ????? private static SourceVersion getLatestSupported() {
>     -??????? try {
>     -??????????? String specVersion =
>     System.getProperty("java.specification.version");
>     +??????? int intVersion = Runtime.version().feature();
>
>     -??????????? switch (specVersion) {
>     -??????????????? case "13":
>     -??????????????????? return RELEASE_13;
>     -??????????????? case "12":
>     -??????????????????? return RELEASE_12;
>     -??????????????? case "11":
>     -??????????????????? return RELEASE_11;
>     -??????????????? case "10":
>     -??????????????????? return RELEASE_10;
>     -??????????????? case "9":
>     -??????????????????? return RELEASE_9;
>     -??????????????? case "1.8":
>     -??????????????????? return RELEASE_8;
>     -??????????????? case "1.7":
>     -??????????????????? return RELEASE_7;
>     -??????????????? case "1.6":
>     -??????????????????? return RELEASE_6;
>     -??????????? }
>     -??????? } catch (SecurityException se) {}
>     -
>     -??????? return RELEASE_5;
>     +??????? if (intVersion >= 10) {
>     +??????????? return valueOf("RELEASE_" + Math.min(13, intVersion));
>     +??????? } else {
>     +??????????? return RELEASE_9;
>     +??????? }
>     ????? }
>
>     ????? /**
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190322/b89a353c/attachment-0001.html>

From bsrbnd at gmail.com  Sat Mar 23 17:24:38 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Sat, 23 Mar 2019 18:24:38 +0100
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <5C93C8D0.1070707@oracle.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
 <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
 <5C93C8D0.1070707@oracle.com>
Message-ID: <CAEgw74D7mtviUY=yJyF4bXdS5KoBbGq8_799HCy55BMHUQXeVw@mail.gmail.com>

Hi Jan,

On Thu, 21 Mar 2019 at 18:24, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
> Hi Bernard,
>
> I was peeking at this, and expected to start to work on this.
>
> I do agree we will need to strip the extra values from the stack, but we
> may also need to set the letExprStackPos at some point.
>
> Jan

Right, this refers to Tagir's second example:

    public static void test2() {
        System.out.println(switch (0) {
            default -> {
                try(Stream<?> s = Stream.empty()) {
                    break 1;
                }
            }
        });
    }

The following patch fixes both cases, does this look more reasonable?

Thanks,
Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
@@ -1223,6 +1223,18 @@
         return !alive || state.stacksize == letExprStackPos;
     }

+    private boolean valueBreak = false;
+
+    public boolean setValueBreak(boolean set) {
+        boolean b = valueBreak;
+        valueBreak = set;
+        return b;
+    }
+
+    public boolean isValueBreak() {
+        return valueBreak;
+    }
+
 /**************************************************************************
  * Stack map generation
  *************************************************************************/
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
@@ -1201,10 +1201,12 @@
                 }
             }
             int prevLetExprStart =
code.setLetExprStackPos(code.state.stacksize);
+            boolean prevValueBreak = code.setValueBreak(false);
             try {
                 handleSwitch(tree, tree.selector, tree.cases);
             } finally {
                 code.setLetExprStackPos(prevLetExprStart);
+                code.setValueBreak(prevValueBreak);
             }
         } finally {
             stackBeforeSwitchExpression = prevStackBeforeSwitchExpression;
@@ -1707,9 +1709,14 @@
         Assert.check(code.isStatementStart());
         final Env<GenContext> targetEnv;
         if (tree.isValueBreak()) {
-            //restore stack as it was before the switch expression:
-            for (LocalItem li : stackBeforeSwitchExpression) {
-                li.load();
+            if (code.isValueBreak()) {
+                code.emitop0(pop);
+            }
+            else {
+                //restore stack as it was before the switch expression:
+                for (LocalItem li : stackBeforeSwitchExpression) {
+                    li.load();
+                }
             }
             if (inCondSwitchExpression) {
                 CondItem value = genCond(tree.value, CRT_FLOW_TARGET);
@@ -1732,7 +1739,17 @@
             } else {
                 genExpr(tree.value, pt).load();
                 code.state.forceStackTop(tree.target.type);
-                targetEnv = unwindBreak(tree);
+
+                int prevLetStackPos =
code.setLetExprStackPos(code.state.stacksize);
+                boolean prevValueBreak = code.setValueBreak(true);
+                try {
+                    targetEnv = unwindBreak(tree);
+                }
+                finally {
+                    code.setLetExprStackPos(prevLetStackPos);
+                    code.setValueBreak(prevValueBreak);
+                }
+
                 targetEnv.info.addExit(code.branch(goto_));
             }
         } else {

From joe.darcy at oracle.com  Sat Mar 23 18:11:03 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 23 Mar 2019 11:11:03 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
Message-ID: <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>

Hello,

New version of the patch uploaded to

 ???? http://cr.openjdk.java.net/~darcy/8221264.1/

and in-line below.

I did consider adding a numeric version to the enum constants as one way 
to address the issue, but considered that as excessive for the issue at 
hand. I'm will to consider such field for other purposes, as Jon alludes to.

New API note added to latestSupported:

"This method is included alongside latest() to allow situations where 
the language model API is running on a platform version different than 
the latest version modeled by the API to be identified. One way that 
sort of situation can occur is if a IDE or similar tool is using the API 
to model source version N while running on platform version (N - 1). 
Running in this configuration is supported by the API. Running an API on 
platform versions earlier than (N - 1) or later than N may or may not 
work as an implementation detail."

I wouldn't endorse any overt steps to prevent the language model API 
from being able to be compiled and run on JDK versions other than N and 
(N - 1) and it would most likely work on (N + 1) and later, but I want 
to set expectations that there are no guarantees for a larger range.

Also, since the feature method was added in JDK 10, I tightened the 
returned range to be JDK 10 or later.

I didn't do so in this patch, but it would be reasonable to bump

 ??? {@code RELEASE_5} or later must be returned.

to RELEASE_8 or later since the API using JDK 8 language features.

Thanks,

-Joe

--- 
old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
2019-03-23 10:57:50.719498000 -0700
+++ 
new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
2019-03-23 10:57:50.383330000 -0700
@@ -209,30 +209,10 @@
 ???? private static final SourceVersion latestSupported = 
getLatestSupported();

 ???? private static SourceVersion getLatestSupported() {
-??????? try {
-??????????? String specVersion = 
System.getProperty("java.specification.version");
-
-??????????? switch (specVersion) {
-??????????????? case "13":
-??????????????????? return RELEASE_13;
-??????????????? case "12":
-??????????????????? return RELEASE_12;
-??????????????? case "11":
-??????????????????? return RELEASE_11;
-??????????????? case "10":
-??????????????????? return RELEASE_10;
-??????????????? case "9":
-??????????????????? return RELEASE_9;
-??????????????? case "1.8":
-??????????????????? return RELEASE_8;
-??????????????? case "1.7":
-??????????????????? return RELEASE_7;
-??????????????? case "1.6":
-??????????????????? return RELEASE_6;
-??????????? }
-??????? } catch (SecurityException se) {}
-
-??????? return RELEASE_5;
+??????? int intVersion = Runtime.version().feature();
+??????? return (intVersion >= 11) ?
+??????????? valueOf("RELEASE_" + Math.min(13, intVersion)):
+??????????? RELEASE_10;
 ???? }

 ???? /**
@@ -240,6 +220,17 @@
 ????? * current execution environment.? {@code RELEASE_5} or later must
 ????? * be returned.
 ????? *
+???? * @apiNote This method is included alongside {@link latest} to
+???? * allow situations where the language model API is running on a
+???? * platform version different than the latest version modeled by
+???? * the API to be identified. One way that sort of situation can
+???? * occur is if a IDE or similar tool is using the API to model
+???? * source version <i>N</i> while running on platform version
+???? * (<i>N</i>&nbsp;-&nbsp;1). Running in this configuration is
+???? * supported by the API. Running an API on platform versions
+???? * earlier than (<i>N</i>&nbsp;-&nbsp;1) or later than <i>N</i>
+???? * may or may not work as an implementation detail.
+???? *
 ????? * @return the latest source version that is fully supported
 ????? */
 ???? public static SourceVersion latestSupported() {

On 3/22/2019 11:46 AM, Jonathan Gibbons wrote:
>
> +1 on an RFE to get a numeric version from a source version, either 
> now or in a follow-up RFE ... and potentially the reverse as well, to 
> get a SourceVersion from a numeric argument.? Both would help with 
> analyzing and creating command-line arguments, without excessive 
> string-bashing or side-maps.
>
> -- Jon
>
>
> On 03/22/2019 11:14 AM, Liam Miller-Cushon wrote:
>> Thanks Joe,
>>
>> This looks good to me overall, for what it's worth.
>>
>> Some minor notes:
>>
>> * I think it might still be helpful to capture some of your 
>> explanation from the bug in the javadoc for latestSupported(), to 
>> help users understand when the use of that method is appropriate.
>>
>> * Your explanation of the lower bound might make a good 
>> implementation comment to explain the use of RELEASE_9.
>>
>> * Also, have you considered including the numeric feature version in 
>> the enum constants in SourceVersion? It might avoid some of the 
>> hard-coded version numbers in getLatestSupported. I'm imagining 
>> something along the lines of:
>> http://cr.openjdk.java.net/~cushon/8221264/webrev.00/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java.sdiff.html 
>> <http://cr.openjdk.java.net/%7Ecushon/8221264/webrev.00/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java.sdiff.html>
>>
>> On Fri, Mar 22, 2019 at 10:34 AM Joe Darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>>     Hello,
>>
>>     Responding to an rfe filed by Liam, please review a refactoring
>>     of the
>>     SourceVersion.latestSupported method:
>>
>>     ???? JDK-8221264: Refactor SourceVersion#latestSupported
>>     http://cr.openjdk.java.net/~darcy/8221264.0/
>>     <http://cr.openjdk.java.net/%7Edarcy/8221264.0/>
>>
>>     Patch below.
>>
>>     With this version, when it comes time to rev a release for 14,
>>     the line
>>
>>     +??????????? return valueOf("RELEASE_" + Math.min(13, intVersion));
>>
>>     will need to be changed to
>>
>>     +??????????? return valueOf("RELEASE_" + Math.min(14, intVersion));
>>
>>     In general the JSR 269 packages, javax.lang.model and
>>     javax.annotation.processing, are constrained by bootstrapping
>>     issue to
>>     be runnable on JDK (N-1); in other words, they cannot only run on
>>     JDK N.
>>     It may or may not be possible to compile the code to run on JDK
>>     (N-2) or
>>     earlier. For example, since JDK 9, the JSR 269 API has used default
>>     methods so the API certainly cannot be compiled and run earlier
>>     than JDK 8.
>>
>>     The Runtime.Version type was introduced in JDK 9; its feature()
>>     method
>>     in 10.
>>
>>     The proposed implementation is simple, even if it is not completely
>>     accurate in a current lower bound for running the API; I don't think
>>     being more accurate on this lower bound is necessary.
>>
>>     Thanks,
>>
>>     -Joe
>>
>>     ---
>>     old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>>
>>     2019-03-22 10:09:33.870668998 -0700
>>     +++
>>     new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>>
>>     2019-03-22 10:09:33.526668998 -0700
>>     @@ -209,30 +209,13 @@
>>     ????? private static final SourceVersion latestSupported =
>>     getLatestSupported();
>>
>>     ????? private static SourceVersion getLatestSupported() {
>>     -??????? try {
>>     -??????????? String specVersion =
>>     System.getProperty("java.specification.version");
>>     +??????? int intVersion = Runtime.version().feature();
>>
>>     -??????????? switch (specVersion) {
>>     -??????????????? case "13":
>>     -??????????????????? return RELEASE_13;
>>     -??????????????? case "12":
>>     -??????????????????? return RELEASE_12;
>>     -??????????????? case "11":
>>     -??????????????????? return RELEASE_11;
>>     -??????????????? case "10":
>>     -??????????????????? return RELEASE_10;
>>     -??????????????? case "9":
>>     -??????????????????? return RELEASE_9;
>>     -??????????????? case "1.8":
>>     -??????????????????? return RELEASE_8;
>>     -??????????????? case "1.7":
>>     -??????????????????? return RELEASE_7;
>>     -??????????????? case "1.6":
>>     -??????????????????? return RELEASE_6;
>>     -??????????? }
>>     -??????? } catch (SecurityException se) {}
>>     -
>>     -??????? return RELEASE_5;
>>     +??????? if (intVersion >= 10) {
>>     +??????????? return valueOf("RELEASE_" + Math.min(13, intVersion));
>>     +??????? } else {
>>     +??????????? return RELEASE_9;
>>     +??????? }
>>     ????? }
>>
>>     ????? /**
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190323/56d55501/attachment-0001.html>

From martinrb at google.com  Sat Mar 23 18:54:16 2019
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 23 Mar 2019 11:54:16 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
Message-ID: <CA+kOe08=jm9+Y7MDfO46DJ--G4x2izTOGjqkfkfu6tdwg9329A@mail.gmail.com>

I'm confused about how an IDE would access the jdk(N+1) API inside a JDK(N).

Of course, the jdk build needs to use this API while bootstrapping the
JDK(N+1), but this seems to involve a lot of build magic and "interim"
modules, e.g. I see java.compiler.interim in my build tree.  But isn't that
all implementation detail of the build system?  Users can't simply take a
java.compiler module out of a JDK(N+1) and use it with a JDK(N) can they?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190323/27a6849c/attachment.html>

From joe.darcy at oracle.com  Sat Mar 23 19:16:18 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 23 Mar 2019 12:16:18 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <CA+kOe08=jm9+Y7MDfO46DJ--G4x2izTOGjqkfkfu6tdwg9329A@mail.gmail.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
 <CA+kOe08=jm9+Y7MDfO46DJ--G4x2izTOGjqkfkfu6tdwg9329A@mail.gmail.com>
Message-ID: <558857cf-3e2c-9557-2989-13bcd360ba20@oracle.com>

Hi Martin,

On 3/23/2019 11:54 AM, Martin Buchholz wrote:
> I'm confused about how an IDE would access the jdk(N+1) API inside a 
> JDK(N).
>
> Of course, the jdk build needs to use this API while bootstrapping the 
> JDK(N+1), but this seems to involve a lot of build magic and "interim" 
> modules, e.g. I see?java.compiler.interim in my build tree.? But isn't 
> that all implementation detail of the build system?? Users can't 
> simply take a java.compiler module out of a JDK(N+1) and use it with a 
> JDK(N) can they?

An IDE would need to have a distinct copy of the JDK N version of the 
JSR 269 API as a jar file (or similar artifact) to run against JDK (N 
-1). The java.compiler module is upgradable and we run a maintenance 
review of JSR 269 each feature release to keep this possible.

This use-case has been with JDK 269 since its beginning.

HTH,

-Joe


From joe.darcy at oracle.com  Sat Mar 23 19:31:14 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 23 Mar 2019 12:31:14 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
Message-ID: <e94c8c0b-ef1d-b59b-0e61-08ab91b4b579@oracle.com>

PS

On 3/23/2019 11:11 AM, Joe Darcy wrote:

[snip]

> Also, since the feature method was added in JDK 10, I tightened the 
> returned range to be JDK 10 or later.
>
> I didn't do so in this patch, but it would be reasonable to bump
>
> ??? {@code RELEASE_5} or later must be returned.
>
> to RELEASE_8 or later since the API using JDK 8 language features.
>
And with defining a module, the API is using 9-level language features 
so might as well do

-???? * current execution environment.? {@code RELEASE_5} or later must
+???? * current execution environment.? {@code RELEASE_9} or later must

at this time and run a CSR for the change once all the wording has been 
agreed to.

 From a quick check, the java.compiler API will compile down to JDK 9 
other than the Runtime.Version.feature() method which as added in JDK 
10. (A different implementation could use a now deprecated 
Runtime.Version method to compile on JDK 9, but I don't think this is 
necessary or desirable in the implementation.)

Thanks,

-Joe



From jonathan.gibbons at oracle.com  Sun Mar 24 14:49:14 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 24 Mar 2019 07:49:14 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <CA+kOe08=jm9+Y7MDfO46DJ--G4x2izTOGjqkfkfu6tdwg9329A@mail.gmail.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
 <CA+kOe08=jm9+Y7MDfO46DJ--G4x2izTOGjqkfkfu6tdwg9329A@mail.gmail.com>
Message-ID: <6a4ae71e-3f03-e544-6a48-dbedc36a00d4@oracle.com>


On 3/23/19 11:54 AM, Martin Buchholz wrote:
> I'm confused about how an IDE would access the jdk(N+1) API inside a 
> JDK(N).
>
> Of course, the jdk build needs to use this API while bootstrapping the 
> JDK(N+1), but this seems to involve a lot of build magic and "interim" 
> modules, e.g. I see?java.compiler.interim in my build tree.? But isn't 
> that all implementation detail of the build system?? Users can't 
> simply take a java.compiler module out of a JDK(N+1) and use it with a 
> JDK(N) can they?

The build magic is related to this issue but not an inherent part of the 
issue.

The javac classes in JDK N, i.e. the classes in the java.compiler and 
jdk.compiler modules) are guaranteed to be executable on JDK N-1 [*], 
and able to compile source code for `--source N` provided that a 
suitable copy of the API for JDK N is available.? In the build magic, 
that copy of the API comes from the source code in the repo. In other 
deployments, the copy of the API can be provided in any suitable 
compiled form.

-- Jon

[*] Note that as generally used in this sort of context, "N-1" means the 
previous GA release, which may be numerically 2 less than N if the 
following release is not yet final.


From martinrb at google.com  Sun Mar 24 16:20:22 2019
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 24 Mar 2019 09:20:22 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <6a4ae71e-3f03-e544-6a48-dbedc36a00d4@oracle.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
 <CA+kOe08=jm9+Y7MDfO46DJ--G4x2izTOGjqkfkfu6tdwg9329A@mail.gmail.com>
 <6a4ae71e-3f03-e544-6a48-dbedc36a00d4@oracle.com>
Message-ID: <CA+kOe0_NCr-M0jMsC9=_Nwfds=cfu=VjFL_UpN7TS=QfuO0t+g@mail.gmail.com>

Here's a naive user journey into upgradeable module land:

I knew about upgradeable modules from reading JEP 261 but I had trouble
figuring out which modules in a particular JDK were upgradeable.  How does
one tell that java.compiler is upgradeable in a particular JDK?  Eventually
I came up with the non-obvious hack:

#!/bin/bash

set -eu -o pipefail
die() { printf "%s: $1\n" "$0" "${@:2}" >&2; exit 1; }

(( "$#" == 1 )) && [[ -d ${JAVA_HOME=$(jver "$1")} ]] \
  || die "Usage: %s JDK-SPEC" "$0"

readonly JMODS_DIR="$JAVA_HOME/jmods"
[[ -d "$JMODS_DIR" ]] \
  || die "%s: no such directory" "$JMODS_DIR"

cd "$JMODS_DIR"

declare -A hashed
hashed[java.base]=1
for mod in $("$JAVA_HOME/bin/jmod" describe java.base.jmod \
  | perl -ne 'print "$1\n" if /^hashes (\S+)/'); do
  hashed[$mod]=1
done

for file in *.jmod; do
  [[ -n "${hashed[${file%.jmod}]-}" ]] || echo "${file%.jmod}"
done
---

list-upgradeable-modules ~/jdk/jdk13
java.compiler
jdk.aot
jdk.internal.vm.compiler
jdk.internal.vm.compiler.management

That looks right - java.compiler is upgradeable.  I'm an IDE and now I want
to actually do an upgrade.  For that I need a module.  There doesn't seem
to be any such artifact on Maven Central. There's a java.compiler.jmod file
in my jdk13, BUT:
 - a jmod file looks a lot like a modular jar, but it isn't one
 - the .class files contained therein are the wrong class file version

If the class files for upgradeable modules were built to target an older
JDK version, they could be used unchanged in JDK(N) or JDK(N-1).
If additionally there was a way to turn a .jmod file into a modular jar,
that artifact could be used directly in JDK(N-1)

Many people in the industry are migrating across LTS releases jdk8 -> jdk11
-> jdk17.
They will want to use jdk17 java.compiler in an IDE running on jdk11.

 $ jver 11 jmod describe java.compiler.jmod
Error: Unsupported major.minor version 57.0



On Sun, Mar 24, 2019 at 7:49 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
> On 3/23/19 11:54 AM, Martin Buchholz wrote:
> > I'm confused about how an IDE would access the jdk(N+1) API inside a
> > JDK(N).
> >
> > Of course, the jdk build needs to use this API while bootstrapping the
> > JDK(N+1), but this seems to involve a lot of build magic and "interim"
> > modules, e.g. I see java.compiler.interim in my build tree.  But isn't
> > that all implementation detail of the build system?  Users can't
> > simply take a java.compiler module out of a JDK(N+1) and use it with a
> > JDK(N) can they?
>
> The build magic is related to this issue but not an inherent part of the
> issue.
>
> The javac classes in JDK N, i.e. the classes in the java.compiler and
> jdk.compiler modules) are guaranteed to be executable on JDK N-1 [*],
> and able to compile source code for `--source N` provided that a
> suitable copy of the API for JDK N is available.  In the build magic,
> that copy of the API comes from the source code in the repo. In other
> deployments, the copy of the API can be provided in any suitable
> compiled form.
>
> -- Jon
>
> [*] Note that as generally used in this sort of context, "N-1" means the
> previous GA release, which may be numerically 2 less than N if the
> following release is not yet final.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190324/4b231b32/attachment.html>

From Alan.Bateman at oracle.com  Sun Mar 24 19:40:05 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 24 Mar 2019 19:40:05 +0000
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <CA+kOe0_NCr-M0jMsC9=_Nwfds=cfu=VjFL_UpN7TS=QfuO0t+g@mail.gmail.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
 <CA+kOe08=jm9+Y7MDfO46DJ--G4x2izTOGjqkfkfu6tdwg9329A@mail.gmail.com>
 <6a4ae71e-3f03-e544-6a48-dbedc36a00d4@oracle.com>
 <CA+kOe0_NCr-M0jMsC9=_Nwfds=cfu=VjFL_UpN7TS=QfuO0t+g@mail.gmail.com>
Message-ID: <89f0a236-25de-8b47-d2df-5b53eac472d6@oracle.com>

On 24/03/2019 16:20, Martin Buchholz wrote:
> Here's a naive user journey into upgradeable module land:
>
> I knew about upgradeable modules from reading JEP 261 but I had 
> trouble figuring out which modules in a particular JDK were 
> upgradeable.? How does one tell that java.compiler is upgradeable in a 
> particular JDK?
The modules for the standalone technologies are upgradable. Prior to 
Java SE 9 the list was documented on the "Endorsed standards override 
mechanism" page, From Java SE 9 on, the standard modules document it 
themselves in their module description. As of Java SE 11, the only 
standard module that is upgradeable is java.compiler, upgradeable 
because it exports the APIs defined by JSR 199 and 269.

There hasn't been a need to date to have one place list the modules in 
the JDK that are upgradeable but the output from your script looks right 
(you can check it against the value of UPGRADEABLE_MODULES in 
make/common/Modules.gmk). The reason that the modules containing the 
Graal bits are upgradable is so that builds from the upstream Graal 
project can be used with a JDK build.

One other thing to know is that the non-upgradable modules are strongly 
tied to java.base, essentially a SHA-256 hash of each of non-upgradable 
modules is stored in java.base to prevent accidental mixing of modules 
from different builds. This enforcement is mostly applicable at 
link-time, as in jlink.

> :
>
> If the class files for upgradeable modules were built to target an 
> older JDK version, they could be used unchanged in JDK(N) or JDK(N-1).
> If additionally there was a way to turn a .jmod file into a modular 
> jar, that artifact could be used directly in JDK(N-1)
>
> Many people in the industry are migrating across LTS releases jdk8 -> 
> jdk11 -> jdk17.
> They will want to use jdk17 java.compiler in an IDE running on jdk11.
>
> ?$ jver 11 jmod describe java.compiler.jmod
> Error: Unsupported major.minor version 57.0
>
If an IDE maker wants to upgrade the java.compiler module then they will 
be building the javax.tools and javax.lang.model APIs for the JDK 
release that the IDE uses. They will need a compiler implementation too, 
maybe loading it into a module layer as jdk.compiler is not upgradeable. 
There should be no expectation that they can take the contents of 
java.compiler.jmod from a newer release.

-Alan

From jan.lahoda at oracle.com  Mon Mar 25 13:27:12 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 25 Mar 2019 14:27:12 +0100
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <CAEgw74D7mtviUY=yJyF4bXdS5KoBbGq8_799HCy55BMHUQXeVw@mail.gmail.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
 <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
 <5C93C8D0.1070707@oracle.com>
 <CAEgw74D7mtviUY=yJyF4bXdS5KoBbGq8_799HCy55BMHUQXeVw@mail.gmail.com>
Message-ID: <5C98D730.5070803@oracle.com>

Hi Bernard,

My current thinking is that we will need to restore the stack right 
before the final goto for the given break (which can be skipped if 
code.isAlive() == false).

I've put my current patch here (incl. test) (I wasn't running other 
tests on this patch yet, though):
http://cr.openjdk.java.net/~jlahoda/8220018/8220018

This does not cover the switch expressions over booleans yet, that is 
something I am looking at right now.

Jan

On 23.3.2019 18:24, B. Blaser wrote:
> Hi Jan,
>
> On Thu, 21 Mar 2019 at 18:24, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>
>> Hi Bernard,
>>
>> I was peeking at this, and expected to start to work on this.
>>
>> I do agree we will need to strip the extra values from the stack, but we
>> may also need to set the letExprStackPos at some point.
>>
>> Jan
>
> Right, this refers to Tagir's second example:
>
>      public static void test2() {
>          System.out.println(switch (0) {
>              default -> {
>                  try(Stream<?> s = Stream.empty()) {
>                      break 1;
>                  }
>              }
>          });
>      }
>
> The following patch fixes both cases, does this look more reasonable?
>
> Thanks,
> Bernard
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java
> @@ -1223,6 +1223,18 @@
>           return !alive || state.stacksize == letExprStackPos;
>       }
>
> +    private boolean valueBreak = false;
> +
> +    public boolean setValueBreak(boolean set) {
> +        boolean b = valueBreak;
> +        valueBreak = set;
> +        return b;
> +    }
> +
> +    public boolean isValueBreak() {
> +        return valueBreak;
> +    }
> +
>   /**************************************************************************
>    * Stack map generation
>    *************************************************************************/
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> @@ -1201,10 +1201,12 @@
>                   }
>               }
>               int prevLetExprStart =
> code.setLetExprStackPos(code.state.stacksize);
> +            boolean prevValueBreak = code.setValueBreak(false);
>               try {
>                   handleSwitch(tree, tree.selector, tree.cases);
>               } finally {
>                   code.setLetExprStackPos(prevLetExprStart);
> +                code.setValueBreak(prevValueBreak);
>               }
>           } finally {
>               stackBeforeSwitchExpression = prevStackBeforeSwitchExpression;
> @@ -1707,9 +1709,14 @@
>           Assert.check(code.isStatementStart());
>           final Env<GenContext> targetEnv;
>           if (tree.isValueBreak()) {
> -            //restore stack as it was before the switch expression:
> -            for (LocalItem li : stackBeforeSwitchExpression) {
> -                li.load();
> +            if (code.isValueBreak()) {
> +                code.emitop0(pop);
> +            }
> +            else {
> +                //restore stack as it was before the switch expression:
> +                for (LocalItem li : stackBeforeSwitchExpression) {
> +                    li.load();
> +                }
>               }
>               if (inCondSwitchExpression) {
>                   CondItem value = genCond(tree.value, CRT_FLOW_TARGET);
> @@ -1732,7 +1739,17 @@
>               } else {
>                   genExpr(tree.value, pt).load();
>                   code.state.forceStackTop(tree.target.type);
> -                targetEnv = unwindBreak(tree);
> +
> +                int prevLetStackPos =
> code.setLetExprStackPos(code.state.stacksize);
> +                boolean prevValueBreak = code.setValueBreak(true);
> +                try {
> +                    targetEnv = unwindBreak(tree);
> +                }
> +                finally {
> +                    code.setLetExprStackPos(prevLetStackPos);
> +                    code.setValueBreak(prevValueBreak);
> +                }
> +
>                   targetEnv.info.addExit(code.branch(goto_));
>               }
>           } else {
>

From ronshapiro at google.com  Mon Mar 25 14:26:01 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Mon, 25 Mar 2019 09:26:01 -0500
Subject: RFR 8220792: Performance bottleneck in JavacFileManager.list()
In-Reply-To: <CACA6h9sAEMTKj8RLNRvCgWq9a33vYUkGEC87bvS3UYuXs=wagg@mail.gmail.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
 <CACA6h9sAEMTKj8RLNRvCgWq9a33vYUkGEC87bvS3UYuXs=wagg@mail.gmail.com>
Message-ID: <CACA6h9tx41jw9ZsNd0vdozX7Z7aBsSBvdm_KfhTHNhxL9wddoA@mail.gmail.com>

Hi -

Wanted to follow up here to see if anyone had comments. This patch has some
really great improvements for large builds w/ annotation processing that
I've been profiling, so I'd love to do what's necessary to get this into
the hands of real users.

Thanks!
Ron

On Tue, Mar 19, 2019 at 1:25 PM Ron Shapiro <ronshapiro at google.com> wrote:

> (fixing the subject to align with the bug title)
>
> On Mon, Mar 18, 2019 at 2:14 PM Ron Shapiro <ronshapiro at google.com> wrote:
>
>> Hi,
>>
>> Please review this change to improve the performance of
>> JavacFileManager.list().
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8220792
>> webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.00/
>>
>> Thanks,
>> Ron
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190325/d4349780/attachment.html>

From jonathan.gibbons at oracle.com  Mon Mar 25 15:00:35 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 25 Mar 2019 08:00:35 -0700
Subject: RFR 8220792: Performance bottleneck in JavacFileManager.list()
In-Reply-To: <CACA6h9tx41jw9ZsNd0vdozX7Z7aBsSBvdm_KfhTHNhxL9wddoA@mail.gmail.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
 <CACA6h9sAEMTKj8RLNRvCgWq9a33vYUkGEC87bvS3UYuXs=wagg@mail.gmail.com>
 <CACA6h9tx41jw9ZsNd0vdozX7Z7aBsSBvdm_KfhTHNhxL9wddoA@mail.gmail.com>
Message-ID: <3673f8c5-220f-59ae-728a-f9c48f650bc6@oracle.com>

Ron,

I'll take a detailed look.

-- Jon

On 3/25/19 7:26 AM, Ron Shapiro wrote:
> Hi -
>
> Wanted to follow up here to see if anyone had comments. This patch has 
> some really great improvements for large builds w/ annotation 
> processing that I've been profiling, so I'd love to do what's 
> necessary to get this into the hands of real users.
>
> Thanks!
> Ron
>
> On Tue, Mar 19, 2019 at 1:25 PM Ron Shapiro <ronshapiro at google.com 
> <mailto:ronshapiro at google.com>> wrote:
>
>     (fixing the subject to align with the bug title)
>
>     On Mon, Mar 18, 2019 at 2:14 PM Ron Shapiro <ronshapiro at google.com
>     <mailto:ronshapiro at google.com>> wrote:
>
>         Hi,
>
>         Please review this change to improve the performance of
>         JavacFileManager.list().
>
>         bug: https://bugs.openjdk.java.net/browse/JDK-8220792
>         webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.00/
>
>         Thanks,
>         Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190325/038b3abf/attachment.html>

From bsrbnd at gmail.com  Mon Mar 25 14:59:48 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Mon, 25 Mar 2019 15:59:48 +0100
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <5C98D730.5070803@oracle.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
 <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
 <5C93C8D0.1070707@oracle.com>
 <CAEgw74D7mtviUY=yJyF4bXdS5KoBbGq8_799HCy55BMHUQXeVw@mail.gmail.com>
 <5C98D730.5070803@oracle.com>
Message-ID: <CAEgw74Cn67DtXoY7GR8JA4SLJL5b2ZF2q1pLuw67e_noFfz0Xw@mail.gmail.com>

Hi Jan,

On Mon, 25 Mar 2019 at 14:27, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
> Hi Bernard,
>
> My current thinking is that we will need to restore the stack right
> before the final goto for the given break (which can be skipped if
> code.isAlive() == false).
>
> I've put my current patch here (incl. test) (I wasn't running other
> tests on this patch yet, though):
> http://cr.openjdk.java.net/~jlahoda/8220018/8220018
>
> This does not cover the switch expressions over booleans yet, that is
> something I am looking at right now.
>
> Jan

I was working on a similar solution as I found that my previous patch
wasn't working with 'try' within 'finally'. The solution, very close
to yours, was also handling conditional expressions which currently
doesn't seem to execute the 'finally' clause.
However, I still have a couple of failing tests... does your solution
pass all langtools:tier1?
Please, share it when covering conditional expressions too.

Bernard

From joe.darcy at oracle.com  Mon Mar 25 16:41:37 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 25 Mar 2019 09:41:37 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <e94c8c0b-ef1d-b59b-0e61-08ab91b4b579@oracle.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
 <e94c8c0b-ef1d-b59b-0e61-08ab91b4b579@oracle.com>
Message-ID: <55c76921-eef1-2649-063c-eeca9deb1dc9@oracle.com>

Hello,

Hopefully the final iteration of this patch; updated materials:

 ??? 8221264 Refactor and update SourceVersion.latestSupported
 ??? http://cr.openjdk.java.net/~darcy/8221264.2/
 ??? NEW! CSR https://bugs.openjdk.java.net/browse/JDK-8221415

I added a comment citing JEP 322: "Time-Based Release Versioning" to 
justify the new implementation.

A CSR is needed because of the update to the minimum version returned, 
just an @apiNote would not necessarily need a CSR as the changes would 
be informative rather than normative.

The particular implementation below would only work on JDK 10 and higher 
as it uses a method added in JDK 10. However, the lower-bound of latest 
supported is raised to JDK *9* rather than JDK 10 since an independent 
implementation of the API could be written to run and compile against 9.

A few additional comments. The most common way of using the 
javax.lang.model API is expected to be the version bundled in the JDK. 
There is one particular other use case that has always intended to be 
supported by JSR 269, namely running the API from JDK N on JDK (N-1) 
assuming the user had their own compilation of the API. If other 
mix-and-match use cases work that is fine - and the new implementation 
should accurately support a larger number of reasonable combinations - 
but it is a non-goal to impose any additional engineering constraints on 
the evolution of the API to maximize the range of JDKs it can be run on.

Patch below.

Thanks,

-Joe

--- 
old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
2019-03-25 08:53:35.544735632 -0700
+++ 
new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
2019-03-25 08:53:35.220573632 -0700
@@ -58,7 +58,7 @@
 ????? *?? 9: modules, small cleanups to 1.7 and 1.8 changes
 ????? *? 10: local-variable type inference (var)
 ????? *? 11: local-variable syntax for lambda parameters
-???? *? 12: TBD
+???? *? 12: no changes (switch expressions in preview)
 ????? *? 13: TBD
 ????? */

@@ -208,38 +208,36 @@

 ???? private static final SourceVersion latestSupported = 
getLatestSupported();

+??? /*
+???? * The integer to release enum constant implemented by this method
+???? * assumes the JEP 322: "Time-Based Release Versioning" scheme is
+???? * in effect. This scheme began in JDK 10. If the JDK versioning
+???? * scheme is revised, this method may need to be updated
+???? * accordingly.
+???? */
 ???? private static SourceVersion getLatestSupported() {
-??????? try {
-??????????? String specVersion = 
System.getProperty("java.specification.version");
-
-??????????? switch (specVersion) {
-??????????????? case "13":
-??????????????????? return RELEASE_13;
-??????????????? case "12":
-??????????????????? return RELEASE_12;
-??????????????? case "11":
-??????????????????? return RELEASE_11;
-??????????????? case "10":
-??????????????????? return RELEASE_10;
-??????????????? case "9":
-??????????????????? return RELEASE_9;
-??????????????? case "1.8":
-??????????????????? return RELEASE_8;
-??????????????? case "1.7":
-??????????????????? return RELEASE_7;
-??????????????? case "1.6":
-??????????????????? return RELEASE_6;
-??????????? }
-??????? } catch (SecurityException se) {}
-
-??????? return RELEASE_5;
+??????? int intVersion = Runtime.version().feature();
+??????? return (intVersion >= 11) ?
+??????????? valueOf("RELEASE_" + Math.min(13, intVersion)):
+??????????? RELEASE_10;
 ???? }

 ???? /**
 ????? * Returns the latest source version fully supported by the
-???? * current execution environment.? {@code RELEASE_5} or later must
+???? * current execution environment.? {@code RELEASE_9} or later must
 ????? * be returned.
 ????? *
+???? * @apiNote This method is included alongside {@link latest} to
+???? * allow situations where the language model API is running on a
+???? * platform version different than the latest version modeled by
+???? * the API to be identified. One way that sort of situation can
+???? * occur is if a IDE or similar tool is using the API to model
+???? * source version <i>N</i> while running on platform version
+???? * (<i>N</i>&nbsp;-&nbsp;1). Running in this configuration is
+???? * supported by the API. Running an API on platform versions
+???? * earlier than (<i>N</i>&nbsp;-&nbsp;1) or later than <i>N</i>
+???? * may or may not work as an implementation detail.
+???? *
 ????? * @return the latest source version that is fully supported
 ????? */
 ???? public static SourceVersion latestSupported() {



From jan.lahoda at oracle.com  Mon Mar 25 18:33:28 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 25 Mar 2019 19:33:28 +0100
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <CAEgw74Cn67DtXoY7GR8JA4SLJL5b2ZF2q1pLuw67e_noFfz0Xw@mail.gmail.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
 <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
 <5C93C8D0.1070707@oracle.com>
 <CAEgw74D7mtviUY=yJyF4bXdS5KoBbGq8_799HCy55BMHUQXeVw@mail.gmail.com>
 <5C98D730.5070803@oracle.com>
 <CAEgw74Cn67DtXoY7GR8JA4SLJL5b2ZF2q1pLuw67e_noFfz0Xw@mail.gmail.com>
Message-ID: <5C991EF8.4050702@oracle.com>

On 25.3.2019 15:59, B. Blaser wrote:
> Hi Jan,
>
> On Mon, 25 Mar 2019 at 14:27, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>
>> Hi Bernard,
>>
>> My current thinking is that we will need to restore the stack right
>> before the final goto for the given break (which can be skipped if
>> code.isAlive() == false).
>>
>> I've put my current patch here (incl. test) (I wasn't running other
>> tests on this patch yet, though):
>> http://cr.openjdk.java.net/~jlahoda/8220018/8220018
>>
>> This does not cover the switch expressions over booleans yet, that is
>> something I am looking at right now.
>>
>> Jan
>
> I was working on a similar solution as I found that my previous patch
> wasn't working with 'try' within 'finally'. The solution, very close
> to yours, was also handling conditional expressions which currently
> doesn't seem to execute the 'finally' clause.
> However, I still have a couple of failing tests... does your solution
> pass all langtools:tier1?
> Please, share it when covering conditional expressions too.

I've updated the patch with a version that strives to handle the boolean 
switch expressions. Passes all tests except 
tools/javac/switchexpr/CRT.java, which depends on the exact structure of 
the generated code. Among other things, I'd like to see if we could 
generate the current bytecode when there is no try-finally, which should 
help with the CRT.java test. More testing still needed, though.

Jan

>
> Bernard
>

From jonathan.gibbons at oracle.com  Mon Mar 25 23:34:20 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 25 Mar 2019 16:34:20 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <55c76921-eef1-2649-063c-eeca9deb1dc9@oracle.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
 <e94c8c0b-ef1d-b59b-0e61-08ab91b4b579@oracle.com>
 <55c76921-eef1-2649-063c-eeca9deb1dc9@oracle.com>
Message-ID: <6a3038db-6485-95a4-84f6-c2a9ee672267@oracle.com>

Looks good to me.

-- Jon


On 03/25/2019 09:41 AM, Joe Darcy wrote:
> Hello,
>
> Hopefully the final iteration of this patch; updated materials:
>
> ??? 8221264 Refactor and update SourceVersion.latestSupported
> ??? http://cr.openjdk.java.net/~darcy/8221264.2/
> ??? NEW! CSR https://bugs.openjdk.java.net/browse/JDK-8221415
>
> I added a comment citing JEP 322: "Time-Based Release Versioning" to 
> justify the new implementation.
>
> A CSR is needed because of the update to the minimum version returned, 
> just an @apiNote would not necessarily need a CSR as the changes would 
> be informative rather than normative.
>
> The particular implementation below would only work on JDK 10 and 
> higher as it uses a method added in JDK 10. However, the lower-bound 
> of latest supported is raised to JDK *9* rather than JDK 10 since an 
> independent implementation of the API could be written to run and 
> compile against 9.
>
> A few additional comments. The most common way of using the 
> javax.lang.model API is expected to be the version bundled in the JDK. 
> There is one particular other use case that has always intended to be 
> supported by JSR 269, namely running the API from JDK N on JDK (N-1) 
> assuming the user had their own compilation of the API. If other 
> mix-and-match use cases work that is fine - and the new implementation 
> should accurately support a larger number of reasonable combinations - 
> but it is a non-goal to impose any additional engineering constraints 
> on the evolution of the API to maximize the range of JDKs it can be 
> run on.
>
> Patch below.
>
> Thanks,
>
> -Joe
>
> --- 
> old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
> 2019-03-25 08:53:35.544735632 -0700
> +++ 
> new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
> 2019-03-25 08:53:35.220573632 -0700
> @@ -58,7 +58,7 @@
> ????? *?? 9: modules, small cleanups to 1.7 and 1.8 changes
> ????? *? 10: local-variable type inference (var)
> ????? *? 11: local-variable syntax for lambda parameters
> -???? *? 12: TBD
> +???? *? 12: no changes (switch expressions in preview)
> ????? *? 13: TBD
> ????? */
>
> @@ -208,38 +208,36 @@
>
> ???? private static final SourceVersion latestSupported = 
> getLatestSupported();
>
> +??? /*
> +???? * The integer to release enum constant implemented by this method
> +???? * assumes the JEP 322: "Time-Based Release Versioning" scheme is
> +???? * in effect. This scheme began in JDK 10. If the JDK versioning
> +???? * scheme is revised, this method may need to be updated
> +???? * accordingly.
> +???? */
> ???? private static SourceVersion getLatestSupported() {
> -??????? try {
> -??????????? String specVersion = 
> System.getProperty("java.specification.version");
> -
> -??????????? switch (specVersion) {
> -??????????????? case "13":
> -??????????????????? return RELEASE_13;
> -??????????????? case "12":
> -??????????????????? return RELEASE_12;
> -??????????????? case "11":
> -??????????????????? return RELEASE_11;
> -??????????????? case "10":
> -??????????????????? return RELEASE_10;
> -??????????????? case "9":
> -??????????????????? return RELEASE_9;
> -??????????????? case "1.8":
> -??????????????????? return RELEASE_8;
> -??????????????? case "1.7":
> -??????????????????? return RELEASE_7;
> -??????????????? case "1.6":
> -??????????????????? return RELEASE_6;
> -??????????? }
> -??????? } catch (SecurityException se) {}
> -
> -??????? return RELEASE_5;
> +??????? int intVersion = Runtime.version().feature();
> +??????? return (intVersion >= 11) ?
> +??????????? valueOf("RELEASE_" + Math.min(13, intVersion)):
> +??????????? RELEASE_10;
> ???? }
>
> ???? /**
> ????? * Returns the latest source version fully supported by the
> -???? * current execution environment.? {@code RELEASE_5} or later must
> +???? * current execution environment.? {@code RELEASE_9} or later must
> ????? * be returned.
> ????? *
> +???? * @apiNote This method is included alongside {@link latest} to
> +???? * allow situations where the language model API is running on a
> +???? * platform version different than the latest version modeled by
> +???? * the API to be identified. One way that sort of situation can
> +???? * occur is if a IDE or similar tool is using the API to model
> +???? * source version <i>N</i> while running on platform version
> +???? * (<i>N</i>&nbsp;-&nbsp;1). Running in this configuration is
> +???? * supported by the API. Running an API on platform versions
> +???? * earlier than (<i>N</i>&nbsp;-&nbsp;1) or later than <i>N</i>
> +???? * may or may not work as an implementation detail.
> +???? *
> ????? * @return the latest source version that is fully supported
> ????? */
> ???? public static SourceVersion latestSupported() {
>
>


From cushon at google.com  Mon Mar 25 23:41:54 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 25 Mar 2019 16:41:54 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <6a3038db-6485-95a4-84f6-c2a9ee672267@oracle.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
 <e94c8c0b-ef1d-b59b-0e61-08ab91b4b579@oracle.com>
 <55c76921-eef1-2649-063c-eeca9deb1dc9@oracle.com>
 <6a3038db-6485-95a4-84f6-c2a9ee672267@oracle.com>
Message-ID: <CAL4QsgvMyrJ4fLMqhiOpKk2WC6eR2w9kmPubnMnV9UKeWzJKyg@mail.gmail.com>

+1, thanks!

On Mon, Mar 25, 2019 at 4:34 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Looks good to me.
>
> -- Jon
>
>
> On 03/25/2019 09:41 AM, Joe Darcy wrote:
> > Hello,
> >
> > Hopefully the final iteration of this patch; updated materials:
> >
> >     8221264 Refactor and update SourceVersion.latestSupported
> >     http://cr.openjdk.java.net/~darcy/8221264.2/
> >     NEW! CSR https://bugs.openjdk.java.net/browse/JDK-8221415
> >
> > I added a comment citing JEP 322: "Time-Based Release Versioning" to
> > justify the new implementation.
> >
> > A CSR is needed because of the update to the minimum version returned,
> > just an @apiNote would not necessarily need a CSR as the changes would
> > be informative rather than normative.
> >
> > The particular implementation below would only work on JDK 10 and
> > higher as it uses a method added in JDK 10. However, the lower-bound
> > of latest supported is raised to JDK *9* rather than JDK 10 since an
> > independent implementation of the API could be written to run and
> > compile against 9.
> >
> > A few additional comments. The most common way of using the
> > javax.lang.model API is expected to be the version bundled in the JDK.
> > There is one particular other use case that has always intended to be
> > supported by JSR 269, namely running the API from JDK N on JDK (N-1)
> > assuming the user had their own compilation of the API. If other
> > mix-and-match use cases work that is fine - and the new implementation
> > should accurately support a larger number of reasonable combinations -
> > but it is a non-goal to impose any additional engineering constraints
> > on the evolution of the API to maximize the range of JDKs it can be
> > run on.
> >
> > Patch below.
> >
> > Thanks,
> >
> > -Joe
> >
> > ---
> > old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
> > 2019-03-25 08:53:35.544735632 -0700
> > +++
> > new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
> > 2019-03-25 08:53:35.220573632 -0700
> > @@ -58,7 +58,7 @@
> >       *   9: modules, small cleanups to 1.7 and 1.8 changes
> >       *  10: local-variable type inference (var)
> >       *  11: local-variable syntax for lambda parameters
> > -     *  12: TBD
> > +     *  12: no changes (switch expressions in preview)
> >       *  13: TBD
> >       */
> >
> > @@ -208,38 +208,36 @@
> >
> >      private static final SourceVersion latestSupported =
> > getLatestSupported();
> >
> > +    /*
> > +     * The integer to release enum constant implemented by this method
> > +     * assumes the JEP 322: "Time-Based Release Versioning" scheme is
> > +     * in effect. This scheme began in JDK 10. If the JDK versioning
> > +     * scheme is revised, this method may need to be updated
> > +     * accordingly.
> > +     */
> >      private static SourceVersion getLatestSupported() {
> > -        try {
> > -            String specVersion =
> > System.getProperty("java.specification.version");
> > -
> > -            switch (specVersion) {
> > -                case "13":
> > -                    return RELEASE_13;
> > -                case "12":
> > -                    return RELEASE_12;
> > -                case "11":
> > -                    return RELEASE_11;
> > -                case "10":
> > -                    return RELEASE_10;
> > -                case "9":
> > -                    return RELEASE_9;
> > -                case "1.8":
> > -                    return RELEASE_8;
> > -                case "1.7":
> > -                    return RELEASE_7;
> > -                case "1.6":
> > -                    return RELEASE_6;
> > -            }
> > -        } catch (SecurityException se) {}
> > -
> > -        return RELEASE_5;
> > +        int intVersion = Runtime.version().feature();
> > +        return (intVersion >= 11) ?
> > +            valueOf("RELEASE_" + Math.min(13, intVersion)):
> > +            RELEASE_10;
> >      }
> >
> >      /**
> >       * Returns the latest source version fully supported by the
> > -     * current execution environment.  {@code RELEASE_5} or later must
> > +     * current execution environment.  {@code RELEASE_9} or later must
> >       * be returned.
> >       *
> > +     * @apiNote This method is included alongside {@link latest} to
> > +     * allow situations where the language model API is running on a
> > +     * platform version different than the latest version modeled by
> > +     * the API to be identified. One way that sort of situation can
> > +     * occur is if a IDE or similar tool is using the API to model
> > +     * source version <i>N</i> while running on platform version
> > +     * (<i>N</i>&nbsp;-&nbsp;1). Running in this configuration is
> > +     * supported by the API. Running an API on platform versions
> > +     * earlier than (<i>N</i>&nbsp;-&nbsp;1) or later than <i>N</i>
> > +     * may or may not work as an implementation detail.
> > +     *
> >       * @return the latest source version that is fully supported
> >       */
> >      public static SourceVersion latestSupported() {
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190325/d43cc055/attachment-0001.html>

From bsrbnd at gmail.com  Mon Mar 25 23:42:56 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Tue, 26 Mar 2019 00:42:56 +0100
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <5C991EF8.4050702@oracle.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
 <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
 <5C93C8D0.1070707@oracle.com>
 <CAEgw74D7mtviUY=yJyF4bXdS5KoBbGq8_799HCy55BMHUQXeVw@mail.gmail.com>
 <5C98D730.5070803@oracle.com>
 <CAEgw74Cn67DtXoY7GR8JA4SLJL5b2ZF2q1pLuw67e_noFfz0Xw@mail.gmail.com>
 <5C991EF8.4050702@oracle.com>
Message-ID: <CAEgw74AidE1709yHUcS+30vS6JZiENnXau1qAqxT9rJ6Fjn7AA@mail.gmail.com>

On Mon, 25 Mar 2019 at 19:33, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
> I've updated the patch with a version that strives to handle the boolean
> switch expressions. Passes all tests except
> tools/javac/switchexpr/CRT.java, which depends on the exact structure of
> the generated code. Among other things, I'd like to see if we could
> generate the current bytecode when there is no try-finally, which should
> help with the CRT.java test. More testing still needed, though.
>
> Jan

It seems we had the same problem with tests like
'switchexpr/ExpressionSwitchEmbedding.java'. You solved it with
'code.newRegSegment()' but you still allocate one temporary variable
per 'break'.

The following patch based on yours create only one temporary variable
per switch expression and preserves roughly the same byte-code without
'try-finally' making tests like 'switchexpr/CRT.java' succeed.

So, maybe you'll have an even better solution but 'langtools:tier1'
along with the test you provided are OK.

What do you think?

Thanks,
Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
@@ -165,6 +165,7 @@
     Chain switchExpressionTrueChain;
     Chain switchExpressionFalseChain;
     List<LocalItem> stackBeforeSwitchExpression;
+    LocalItem switchResult;

     /** Generate code to load an integer constant.
      *  @param n     The integer to be loaded.
@@ -1178,9 +1179,11 @@

     private void doHandleSwitchExpression(JCSwitchExpression tree) {
         List<LocalItem> prevStackBeforeSwitchExpression =
stackBeforeSwitchExpression;
+        LocalItem prevSwitchResult = switchResult;
         int limit = code.nextreg;
         try {
             stackBeforeSwitchExpression = List.nil();
+            switchResult = null;
             if (hasTry(tree)) {
                 //if the switch expression contains try-catch, the
catch handlers need to have
                 //an empty stack. So stash whole stack to local
variables, and restore it before
@@ -1199,6 +1202,7 @@
                     stackBeforeSwitchExpression =
stackBeforeSwitchExpression.prepend(item);
                     item.store();
                 }
+                switchResult = makeTemp(tree.type);
             }
             int prevLetExprStart =
code.setLetExprStackPos(code.state.stacksize);
             try {
@@ -1208,6 +1212,7 @@
             }
         } finally {
             stackBeforeSwitchExpression = prevStackBeforeSwitchExpression;
+            switchResult = prevSwitchResult;
             code.endScopes(limit);
         }
     }
@@ -1707,16 +1712,22 @@
         Assert.check(code.isStatementStart());
         final Env<GenContext> targetEnv;
         if (tree.isValueBreak()) {
-            //restore stack as it was before the switch expression:
-            for (LocalItem li : stackBeforeSwitchExpression) {
-                li.load();
-            }
             if (inCondSwitchExpression) {
                 CondItem value = genCond(tree.value, CRT_FLOW_TARGET);
                 Chain falseJumps = value.jumpFalse();
-                targetEnv = unwindBreak(tree);
+                Env<GenContext> localEnv = unwindBreak(tree);
                 code.resolve(value.trueJumps);
+                for (LocalItem li : stackBeforeSwitchExpression) {
+                   li.load();
+                }
                 Chain trueJumps = code.branch(goto_);
+                endFinalizerGaps(env, localEnv);
+                code.resolve(falseJumps);
+                targetEnv = unwindBreak(tree);
+                for (LocalItem li : stackBeforeSwitchExpression) {
+                    li.load();
+                }
+                falseJumps = code.branch(goto_);
                 if (switchExpressionTrueChain == null) {
                     switchExpressionTrueChain = trueJumps;
                 } else {
@@ -1731,9 +1742,17 @@
                 }
             } else {
                 genExpr(tree.value, pt).load();
-                code.state.forceStackTop(tree.target.type);
+                if (switchResult != null) switchResult.store();
                 targetEnv = unwindBreak(tree);
-                targetEnv.info.addExit(code.branch(goto_));
+                if (code.isAlive()) {
+                    for (LocalItem li : stackBeforeSwitchExpression) {
+                        li.load();
+                    }
+                    if (switchResult != null) switchResult.load();
+                    code.state.forceStackTop(tree.target.type);
+                    targetEnv.info.addExit(code.branch(goto_));
+                    code.markDead();
+                }
             }
         } else {
             targetEnv = unwindBreak(tree);

From joe.darcy at oracle.com  Tue Mar 26 02:45:42 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 25 Mar 2019 19:45:42 -0700
Subject: JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
In-Reply-To: <CAL4QsgvMyrJ4fLMqhiOpKk2WC6eR2w9kmPubnMnV9UKeWzJKyg@mail.gmail.com>
References: <aa5801a5-4f79-6b24-0739-205120d6f487@oracle.com>
 <CAL4Qsgv-fQ8Mu2X=03xeekdqgNSg2tYO3PvGd5TRHHcC6N6=8Q@mail.gmail.com>
 <d68b32c6-9b7e-ed45-cd79-351d72143419@oracle.com>
 <bc44dfc4-b92c-7128-1a21-f3731838929f@oracle.com>
 <e94c8c0b-ef1d-b59b-0e61-08ab91b4b579@oracle.com>
 <55c76921-eef1-2649-063c-eeca9deb1dc9@oracle.com>
 <6a3038db-6485-95a4-84f6-c2a9ee672267@oracle.com>
 <CAL4QsgvMyrJ4fLMqhiOpKk2WC6eR2w9kmPubnMnV9UKeWzJKyg@mail.gmail.com>
Message-ID: <5C999256.8090106@oracle.com>

Pushed with some additional clarifications discussed with Jon off-list:

     http://hg.openjdk.java.net/jdk/jdk/rev/44edf64cb206

Thanks,

-Joe

On 3/25/2019 4:41 PM, Liam Miller-Cushon wrote:
> +1, thanks!
>
> On Mon, Mar 25, 2019 at 4:34 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Looks good to me.
>
>     -- Jon
>
>
>     On 03/25/2019 09:41 AM, Joe Darcy wrote:
>     > Hello,
>     >
>     > Hopefully the final iteration of this patch; updated materials:
>     >
>     >     8221264 Refactor and update SourceVersion.latestSupported
>     > http://cr.openjdk.java.net/~darcy/8221264.2/
>     <http://cr.openjdk.java.net/%7Edarcy/8221264.2/>
>     >     NEW! CSR https://bugs.openjdk.java.net/browse/JDK-8221415
>     >
>     > I added a comment citing JEP 322: "Time-Based Release
>     Versioning" to
>     > justify the new implementation.
>     >
>     > A CSR is needed because of the update to the minimum version
>     returned,
>     > just an @apiNote would not necessarily need a CSR as the changes
>     would
>     > be informative rather than normative.
>     >
>     > The particular implementation below would only work on JDK 10 and
>     > higher as it uses a method added in JDK 10. However, the
>     lower-bound
>     > of latest supported is raised to JDK *9* rather than JDK 10
>     since an
>     > independent implementation of the API could be written to run and
>     > compile against 9.
>     >
>     > A few additional comments. The most common way of using the
>     > javax.lang.model API is expected to be the version bundled in
>     the JDK.
>     > There is one particular other use case that has always intended
>     to be
>     > supported by JSR 269, namely running the API from JDK N on JDK
>     (N-1)
>     > assuming the user had their own compilation of the API. If other
>     > mix-and-match use cases work that is fine - and the new
>     implementation
>     > should accurately support a larger number of reasonable
>     combinations -
>     > but it is a non-goal to impose any additional engineering
>     constraints
>     > on the evolution of the API to maximize the range of JDKs it can be
>     > run on.
>     >
>     > Patch below.
>     >
>     > Thanks,
>     >
>     > -Joe
>     >
>     > ---
>     >
>     old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>
>     > 2019-03-25 08:53:35.544735632 -0700
>     > +++
>     >
>     new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>
>     > 2019-03-25 08:53:35.220573632 -0700
>     > @@ -58,7 +58,7 @@
>     >       *   9: modules, small cleanups to 1.7 and 1.8 changes
>     >       *  10: local-variable type inference (var)
>     >       *  11: local-variable syntax for lambda parameters
>     > -     *  12: TBD
>     > +     *  12: no changes (switch expressions in preview)
>     >       *  13: TBD
>     >       */
>     >
>     > @@ -208,38 +208,36 @@
>     >
>     >      private static final SourceVersion latestSupported =
>     > getLatestSupported();
>     >
>     > +    /*
>     > +     * The integer to release enum constant implemented by this
>     method
>     > +     * assumes the JEP 322: "Time-Based Release Versioning"
>     scheme is
>     > +     * in effect. This scheme began in JDK 10. If the JDK
>     versioning
>     > +     * scheme is revised, this method may need to be updated
>     > +     * accordingly.
>     > +     */
>     >      private static SourceVersion getLatestSupported() {
>     > -        try {
>     > -            String specVersion =
>     > System.getProperty("java.specification.version");
>     > -
>     > -            switch (specVersion) {
>     > -                case "13":
>     > -                    return RELEASE_13;
>     > -                case "12":
>     > -                    return RELEASE_12;
>     > -                case "11":
>     > -                    return RELEASE_11;
>     > -                case "10":
>     > -                    return RELEASE_10;
>     > -                case "9":
>     > -                    return RELEASE_9;
>     > -                case "1.8":
>     > -                    return RELEASE_8;
>     > -                case "1.7":
>     > -                    return RELEASE_7;
>     > -                case "1.6":
>     > -                    return RELEASE_6;
>     > -            }
>     > -        } catch (SecurityException se) {}
>     > -
>     > -        return RELEASE_5;
>     > +        int intVersion = Runtime.version().feature();
>     > +        return (intVersion >= 11) ?
>     > +            valueOf("RELEASE_" + Math.min(13, intVersion)):
>     > +            RELEASE_10;
>     >      }
>     >
>     >      /**
>     >       * Returns the latest source version fully supported by the
>     > -     * current execution environment.  {@code RELEASE_5} or
>     later must
>     > +     * current execution environment.  {@code RELEASE_9} or
>     later must
>     >       * be returned.
>     >       *
>     > +     * @apiNote This method is included alongside {@link latest} to
>     > +     * allow situations where the language model API is running
>     on a
>     > +     * platform version different than the latest version
>     modeled by
>     > +     * the API to be identified. One way that sort of situation can
>     > +     * occur is if a IDE or similar tool is using the API to model
>     > +     * source version <i>N</i> while running on platform version
>     > +     * (<i>N</i>&nbsp;-&nbsp;1). Running in this configuration is
>     > +     * supported by the API. Running an API on platform versions
>     > +     * earlier than (<i>N</i>&nbsp;-&nbsp;1) or later than <i>N</i>
>     > +     * may or may not work as an implementation detail.
>     > +     *
>     >       * @return the latest source version that is fully supported
>     >       */
>     >      public static SourceVersion latestSupported() {
>     >
>     >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190325/5ae7c43b/attachment-0001.html>

From jan.lahoda at oracle.com  Tue Mar 26 13:42:35 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 26 Mar 2019 14:42:35 +0100
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <CAEgw74AidE1709yHUcS+30vS6JZiENnXau1qAqxT9rJ6Fjn7AA@mail.gmail.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
 <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
 <5C93C8D0.1070707@oracle.com>
 <CAEgw74D7mtviUY=yJyF4bXdS5KoBbGq8_799HCy55BMHUQXeVw@mail.gmail.com>
 <5C98D730.5070803@oracle.com>
 <CAEgw74Cn67DtXoY7GR8JA4SLJL5b2ZF2q1pLuw67e_noFfz0Xw@mail.gmail.com>
 <5C991EF8.4050702@oracle.com>
 <CAEgw74AidE1709yHUcS+30vS6JZiENnXau1qAqxT9rJ6Fjn7AA@mail.gmail.com>
Message-ID: <5C9A2C4B.4090201@oracle.com>

Hi Bernard,

I think I like this approach (possibly, it should also be used in the 
condition switch expr. branch). Do you want to take the patch to completion?

Thanks,
     Jan

On 26.3.2019 00:42, B. Blaser wrote:
> On Mon, 25 Mar 2019 at 19:33, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>
>> I've updated the patch with a version that strives to handle the boolean
>> switch expressions. Passes all tests except
>> tools/javac/switchexpr/CRT.java, which depends on the exact structure of
>> the generated code. Among other things, I'd like to see if we could
>> generate the current bytecode when there is no try-finally, which should
>> help with the CRT.java test. More testing still needed, though.
>>
>> Jan
>
> It seems we had the same problem with tests like
> 'switchexpr/ExpressionSwitchEmbedding.java'. You solved it with
> 'code.newRegSegment()' but you still allocate one temporary variable
> per 'break'.
>
> The following patch based on yours create only one temporary variable
> per switch expression and preserves roughly the same byte-code without
> 'try-finally' making tests like 'switchexpr/CRT.java' succeed.
>
> So, maybe you'll have an even better solution but 'langtools:tier1'
> along with the test you provided are OK.
>
> What do you think?
>
> Thanks,
> Bernard
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
> @@ -165,6 +165,7 @@
>       Chain switchExpressionTrueChain;
>       Chain switchExpressionFalseChain;
>       List<LocalItem> stackBeforeSwitchExpression;
> +    LocalItem switchResult;
>
>       /** Generate code to load an integer constant.
>        *  @param n     The integer to be loaded.
> @@ -1178,9 +1179,11 @@
>
>       private void doHandleSwitchExpression(JCSwitchExpression tree) {
>           List<LocalItem> prevStackBeforeSwitchExpression =
> stackBeforeSwitchExpression;
> +        LocalItem prevSwitchResult = switchResult;
>           int limit = code.nextreg;
>           try {
>               stackBeforeSwitchExpression = List.nil();
> +            switchResult = null;
>               if (hasTry(tree)) {
>                   //if the switch expression contains try-catch, the
> catch handlers need to have
>                   //an empty stack. So stash whole stack to local
> variables, and restore it before
> @@ -1199,6 +1202,7 @@
>                       stackBeforeSwitchExpression =
> stackBeforeSwitchExpression.prepend(item);
>                       item.store();
>                   }
> +                switchResult = makeTemp(tree.type);
>               }
>               int prevLetExprStart =
> code.setLetExprStackPos(code.state.stacksize);
>               try {
> @@ -1208,6 +1212,7 @@
>               }
>           } finally {
>               stackBeforeSwitchExpression = prevStackBeforeSwitchExpression;
> +            switchResult = prevSwitchResult;
>               code.endScopes(limit);
>           }
>       }
> @@ -1707,16 +1712,22 @@
>           Assert.check(code.isStatementStart());
>           final Env<GenContext> targetEnv;
>           if (tree.isValueBreak()) {
> -            //restore stack as it was before the switch expression:
> -            for (LocalItem li : stackBeforeSwitchExpression) {
> -                li.load();
> -            }
>               if (inCondSwitchExpression) {
>                   CondItem value = genCond(tree.value, CRT_FLOW_TARGET);
>                   Chain falseJumps = value.jumpFalse();
> -                targetEnv = unwindBreak(tree);
> +                Env<GenContext> localEnv = unwindBreak(tree);
>                   code.resolve(value.trueJumps);
> +                for (LocalItem li : stackBeforeSwitchExpression) {
> +                   li.load();
> +                }
>                   Chain trueJumps = code.branch(goto_);
> +                endFinalizerGaps(env, localEnv);
> +                code.resolve(falseJumps);
> +                targetEnv = unwindBreak(tree);
> +                for (LocalItem li : stackBeforeSwitchExpression) {
> +                    li.load();
> +                }
> +                falseJumps = code.branch(goto_);
>                   if (switchExpressionTrueChain == null) {
>                       switchExpressionTrueChain = trueJumps;
>                   } else {
> @@ -1731,9 +1742,17 @@
>                   }
>               } else {
>                   genExpr(tree.value, pt).load();
> -                code.state.forceStackTop(tree.target.type);
> +                if (switchResult != null) switchResult.store();
>                   targetEnv = unwindBreak(tree);
> -                targetEnv.info.addExit(code.branch(goto_));
> +                if (code.isAlive()) {
> +                    for (LocalItem li : stackBeforeSwitchExpression) {
> +                        li.load();
> +                    }
> +                    if (switchResult != null) switchResult.load();
> +                    code.state.forceStackTop(tree.target.type);
> +                    targetEnv.info.addExit(code.branch(goto_));
> +                    code.markDead();
> +                }
>               }
>           } else {
>               targetEnv = unwindBreak(tree);
>

From jan.lahoda at oracle.com  Tue Mar 26 13:54:52 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 26 Mar 2019 14:54:52 +0100
Subject: RFR: JDK-8221413: javac does not recognize variable assigned in
 switch expression as DA
Message-ID: <5C9A2F2C.5050805@oracle.com>

Hi,

javac does not correctly infer definitely assigned variables for switch 
expressions with implicit default clause (where the default clause is 
added automatically for exhaustive switch over enums).

Proposed patch: http://cr.openjdk.java.net/~jlahoda/8221413/webrev.00/

JBS: https://bugs.openjdk.java.net/browse/JDK-8221413

How does this look?

Thanks,
     Jan

From bsrbnd at gmail.com  Tue Mar 26 15:14:58 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Tue, 26 Mar 2019 16:14:58 +0100
Subject: Java 12: javac crash with switch expression containing
 try-catch-finally
In-Reply-To: <5C9A2C4B.4090201@oracle.com>
References: <CAE+3fjYsbAVHnOvFErXyvsPWcH_m64-yf8MxhXFPo9iBB=aBOg@mail.gmail.com>
 <CAEgw74ANTsFD7VxDHKWQY5xySo-k+=Z6MY51io_Z--SqCQSsdw@mail.gmail.com>
 <5C93C8D0.1070707@oracle.com>
 <CAEgw74D7mtviUY=yJyF4bXdS5KoBbGq8_799HCy55BMHUQXeVw@mail.gmail.com>
 <5C98D730.5070803@oracle.com>
 <CAEgw74Cn67DtXoY7GR8JA4SLJL5b2ZF2q1pLuw67e_noFfz0Xw@mail.gmail.com>
 <5C991EF8.4050702@oracle.com>
 <CAEgw74AidE1709yHUcS+30vS6JZiENnXau1qAqxT9rJ6Fjn7AA@mail.gmail.com>
 <5C9A2C4B.4090201@oracle.com>
Message-ID: <CAEgw74Cu5MGjtw_W8UZkwcM+esVLLH0Ruti9zCpUQo-NWFAn8A@mail.gmail.com>

Hi Jan,

On Tue, 26 Mar 2019 at 14:42, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
> Hi Bernard,
>
> I think I like this approach (possibly, it should also be used in the
> condition switch expr. branch). Do you want to take the patch to completion?
>
> Thanks,
>      Jan

Thanks for your feedback.

I tried the same approach for conditional switch some days ago but I
had one failing test if I remember well, that's why I kept your
solution for this part in the latest patch.
I'll try again and send out a RFR soon either with your solution for
conditional switch or with the same approach if I can make it work...

Thanks!
Bernard

From cushon at google.com  Tue Mar 26 15:50:37 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 26 Mar 2019 08:50:37 -0700
Subject: RFR: 8220633: Optimize CacheFSInfo
In-Reply-To: <CAL4QsgvM5QKFifdbGpmHJyze149JXRDcLWX8bWouKohc6vG8yQ@mail.gmail.com>
References: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>
 <4d1e769d-51ce-276d-868b-7fb840466df0@oracle.com>
 <CAL4Qsgu-vQakwfHz4MhAeY3X14+ajQYrsfCCPg8Z-b_uU9dkcQ@mail.gmail.com>
 <f6244901-2dfa-faea-6955-b1193f1406a5@oracle.com>
 <CAL4QsgvM5QKFifdbGpmHJyze149JXRDcLWX8bWouKohc6vG8yQ@mail.gmail.com>
Message-ID: <CAL4QsgskXLHaoa+CF0doWxp9gHdZ8EGnh3H+rMsFs+o18tPcNQ@mail.gmail.com>

Is there any other feedback on the change?

On Wed, Mar 13, 2019 at 9:29 PM Liam Miller-Cushon <cushon at google.com>
wrote:

> On Wed, Mar 13, 2019 at 5:59 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> I could go either way on getJarClassPath.  The initial version in
>> webrev.00 was definitely shorter.
>>
> computeIfAbsent feels a little more idiomatic to me than the intentional
> race (and the comment to explain why it's safe), but I don't really have a
> preference.
>
> I'm happy to revert to webrev.00 if you prefer.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/9e17191b/attachment.html>

From jonathan.gibbons at oracle.com  Tue Mar 26 18:21:52 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 26 Mar 2019 11:21:52 -0700
Subject: RFR: 8220633: Optimize CacheFSInfo
In-Reply-To: <CAL4QsgskXLHaoa+CF0doWxp9gHdZ8EGnh3H+rMsFs+o18tPcNQ@mail.gmail.com>
References: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>
 <4d1e769d-51ce-276d-868b-7fb840466df0@oracle.com>
 <CAL4Qsgu-vQakwfHz4MhAeY3X14+ajQYrsfCCPg8Z-b_uU9dkcQ@mail.gmail.com>
 <f6244901-2dfa-faea-6955-b1193f1406a5@oracle.com>
 <CAL4QsgvM5QKFifdbGpmHJyze149JXRDcLWX8bWouKohc6vG8yQ@mail.gmail.com>
 <CAL4QsgskXLHaoa+CF0doWxp9gHdZ8EGnh3H+rMsFs+o18tPcNQ@mail.gmail.com>
Message-ID: <863e757e-668e-b05f-b861-a9c4638a00a9@oracle.com>

Liam,

I looked again at both webrev.00 and webrev.01.? I think there is a 
better solution than both.

The original code has the explanatory comment; for webrev.01, "form 
follows function" comes to mind: while being more idiomatic, using 
computeIfAbsent, it is also more verbose and thus less clear.

How about a variant of webrev.00 in which you do lock the newly-added 
specific cache, and thus do away with the comment.

   91     @Override
   92     public List<Path> getJarClassPath(Path file) throws IOException {
              synchronized (jarClassPathCache) {
96 List<Path> jarClassPath = jarClassPathCache.get(file);
97 if (jarClassPath == null) {
98 jarClassPath = super.getJarClassPath(file);
99 jarClassPathCache.put(file, jarClassPath);
100 }
101 return jarClassPath; }
 ?102     }

The reformatting on lines 55-57 seems a bit gratuitous, especially 
putting the cast on a line by itself.

The rest seems OK.

- Jon


On 03/26/2019 08:50 AM, Liam Miller-Cushon wrote:
> Is there any other feedback on the change?
>
> On Wed, Mar 13, 2019 at 9:29 PM Liam Miller-Cushon <cushon at google.com 
> <mailto:cushon at google.com>> wrote:
>
>     On Wed, Mar 13, 2019 at 5:59 PM Jonathan Gibbons
>     <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>>
>     wrote:
>
>         I could go either way on getJarClassPath.? The initial version
>         in webrev.00 was definitely shorter.
>
>     computeIfAbsent feels a little more idiomatic to me than the
>     intentional race (and the comment to explain why it's safe), but I
>     don't really have a preference.
>
>     I'm happy to revert to webrev.00 if you prefer.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/6a478b45/attachment-0001.html>

From jonathan.gibbons at oracle.com  Tue Mar 26 18:40:13 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 26 Mar 2019 11:40:13 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <CAL4Qsgv5Qk=61BY7=Zhtp-CXepu8mqHK-N+GMr_rk-_SEwQtZw@mail.gmail.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
 <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
 <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>
 <CACA6h9t2k73yLPVaG+0A1eAmiLAkq8r=MaA4tov6XD81wjjArw@mail.gmail.com>
 <CAL4Qsgu5U_GMwtpddhz5_7DAyVep8qPvJFNman2E88BqmBb-WQ@mail.gmail.com>
 <bcceef10-12c0-307a-56f7-332c4b97552f@oracle.com>
 <CAL4Qsgv5Qk=61BY7=Zhtp-CXepu8mqHK-N+GMr_rk-_SEwQtZw@mail.gmail.com>
Message-ID: <09b9ebcf-cb6e-416f-44f7-deb0b0659541@oracle.com>

OK, with a suggestion.

The basic update is OK.? Seeing the messages in context, I would suggest 
to tweak the messages as follows:

1640 compiler.misc.count.error.recompile=\
1641 only showing the first {0} errors, of {1} total; use -Xmaxerrs if 
you would like to see more

I like the text for explicitly hinting at why you might want to use the 
option, as compared to just telling people to consider using the option, 
without saying why.

No need to re-review if you keep the webrev as is, or change to the 
suggested text, for both messages

-- Jon

On 03/15/2019 11:31 AM, Liam Miller-Cushon wrote:
> I updated the webrev with the suggested changes to the diagnostic text:
>
> http://cr.openjdk.java.net/~cushon/8220632/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220632/webrev.01/>
>
> On Fri, Mar 15, 2019 at 11:26 AM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>
>     On 3/15/19 11:21 AM, Liam Miller-Cushon wrote:
>>     On Fri, Mar 15, 2019 at 11:11 AM Ron Shapiro
>>     <ronshapiro at google.com <mailto:ronshapiro at google.com>> wrote:
>>
>>         Regarding Jonathan's comments in the bug, would it be
>>         helpful/possible to categorize the types of diagnostics not
>>         shown? For built-in diagnostics we could try to group (maybe
>>         just the popular ones?) by their key?
>>
>>         42 symbols could not be found
>>         15 errors from com.example.proc.ExampleProcessor
>>         etc
>>
>>         ?
>>
>>
>>     It's certainly possible. I think we want to strike a balance
>>     between providing enough information to help avoid users getting
>>     stuck when diagnostics are suppressed, but not so much
>>     information that it's distracting (since hopefully in the common
>>     case the suppressed diagnostics are not necessary to understand
>>     the problem).
>>
>>     In that specific example, Jon's suggestion to sort the
>>     non-recoverable diagnostics first (which I intend to follow up on
>>     JDK-8220691) would avoid suppressing the
>>     com.example.proc.ExampleProcessor diagnostics entirely.
>
>
>     If we were to provide this extra info, maybe it could/should be
>     opt-in.? But, I think it is a better use of resources to make
>     javac more friendly "out of the box" and to print the
>     more-likely-important messages first, so that users don't have to
>     wade through too much info.
>
>     -- Jon
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/d6bf1984/attachment.html>

From jonathan.gibbons at oracle.com  Tue Mar 26 18:57:26 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 26 Mar 2019 11:57:26 -0700
Subject: RFR: 8220687: Change signature of
 StandardJavaFileManager.getJavaFileObjectsFromPaths
In-Reply-To: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>
References: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>
Message-ID: <6c95320f-aafb-5156-bc4b-aed61b0f7499@oracle.com>

Liam,

ClientCodeWrapper and DelegatingJavaFileManager should both add 
overrides for the new method, instead of repurposing the old existing 
override.? The code should not rely on implementations choosing to use 
the now-default implementations defined in the interface.

-- Jon


On 03/14/2019 06:19 PM, Liam Miller-Cushon wrote:
> Hi,
>
> This change adds a?getJavaFileObjectsFromPaths(Collection<Path>) 
> method, and deprecates the?existing 
> getJavaFileObjectsFromPaths(Iterable<Path>). The motivation is the 
> same as JDK-8150111, which made a similar change to 
> setLocationFromPaths: methods that take Iterable<Path> are error-prone 
> since Path itself implements Iterable<Path>.
>
> I have two initial questions: do you think this is worthwhile, and if 
> so what's the correct process (should I file a CSR?).
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220687
> webrev: http://cr.openjdk.java.net/~cushon/8220687/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220687/webrev.00/>
>
> Thanks,
> Liam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/9a90ab59/attachment.html>

From jonathan.gibbons at oracle.com  Tue Mar 26 19:06:01 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 26 Mar 2019 12:06:01 -0700
Subject: RFR: 8220687: Change signature of
 StandardJavaFileManager.getJavaFileObjectsFromPaths
In-Reply-To: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>
References: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>
Message-ID: <e7518dac-ff91-55a0-71e2-33fe3d882163@oracle.com>

Liam,

Make sure the proposed new code passes all the standard langtools tests, 
including (in particular) TestClientCodeWrapper.java.

As a general process point, a changeset should always either have a 
test, or the JBS issue should have a "noreg-*" label, where the label is 
chosen from the list here [1].? In other words, write a test, or justify 
why one is not required.? Internally, we have infrastructure that checks 
this condition.? If you create a new test, or edit an existing one, make 
sure the jtreg test-description lists the JBS issue number in the `@bug` 
line.

-- Jon

[1] https://openjdk.java.net/guide/changePlanning.html#bug? (See section 6.)


On 03/14/2019 06:19 PM, Liam Miller-Cushon wrote:
> Hi,
>
> This change adds a?getJavaFileObjectsFromPaths(Collection<Path>) 
> method, and deprecates the?existing 
> getJavaFileObjectsFromPaths(Iterable<Path>). The motivation is the 
> same as JDK-8150111, which made a similar change to 
> setLocationFromPaths: methods that take Iterable<Path> are error-prone 
> since Path itself implements Iterable<Path>.
>
> I have two initial questions: do you think this is worthwhile, and if 
> so what's the correct process (should I file a CSR?).
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220687
> webrev: http://cr.openjdk.java.net/~cushon/8220687/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220687/webrev.00/>
>
> Thanks,
> Liam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/4958d16b/attachment.html>

From cushon at google.com  Tue Mar 26 19:48:50 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 26 Mar 2019 12:48:50 -0700
Subject: RFR: 8220633: Optimize CacheFSInfo
In-Reply-To: <863e757e-668e-b05f-b861-a9c4638a00a9@oracle.com>
References: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>
 <4d1e769d-51ce-276d-868b-7fb840466df0@oracle.com>
 <CAL4Qsgu-vQakwfHz4MhAeY3X14+ajQYrsfCCPg8Z-b_uU9dkcQ@mail.gmail.com>
 <f6244901-2dfa-faea-6955-b1193f1406a5@oracle.com>
 <CAL4QsgvM5QKFifdbGpmHJyze149JXRDcLWX8bWouKohc6vG8yQ@mail.gmail.com>
 <CAL4QsgskXLHaoa+CF0doWxp9gHdZ8EGnh3H+rMsFs+o18tPcNQ@mail.gmail.com>
 <863e757e-668e-b05f-b861-a9c4638a00a9@oracle.com>
Message-ID: <CAL4QsgvX7giQBZerQ3XHoDH6xhcBTtQ-32AkJBX0_XVVVzCF5Q@mail.gmail.com>

On Tue, Mar 26, 2019 at 11:21 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> How about a variant of webrev.00 in which you do lock the newly-added
> specific cache, and thus do away with the comment.
>
Sounds good to me, thanks. Done.

> The reformatting on lines 55-57 seems a bit gratuitous, especially putting
> the cast on a line by itself.
>
(That was another automated reformatting error, fixed.)

Here's the updated webrev:
http://cr.openjdk.java.net/~cushon/8220633/webrev.02/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/502a2507/attachment-0001.html>

From jonathan.gibbons at oracle.com  Tue Mar 26 19:51:26 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 26 Mar 2019 12:51:26 -0700
Subject: RFR: 8220633: Optimize CacheFSInfo
In-Reply-To: <863e757e-668e-b05f-b861-a9c4638a00a9@oracle.com>
References: <CAL4Qsguo8hkh0H-zcXtvtDZ=Xy-gzacF1+jda95tK-7Zmk18pg@mail.gmail.com>
 <4d1e769d-51ce-276d-868b-7fb840466df0@oracle.com>
 <CAL4Qsgu-vQakwfHz4MhAeY3X14+ajQYrsfCCPg8Z-b_uU9dkcQ@mail.gmail.com>
 <f6244901-2dfa-faea-6955-b1193f1406a5@oracle.com>
 <CAL4QsgvM5QKFifdbGpmHJyze149JXRDcLWX8bWouKohc6vG8yQ@mail.gmail.com>
 <CAL4QsgskXLHaoa+CF0doWxp9gHdZ8EGnh3H+rMsFs+o18tPcNQ@mail.gmail.com>
 <863e757e-668e-b05f-b861-a9c4638a00a9@oracle.com>
Message-ID: <f720cf6e-1040-b8d3-55ba-f327e4077e00@oracle.com>

Looks good to me.

-- Jon


On 03/26/2019 11:21 AM, Jonathan Gibbons wrote:
>
> Liam,
>
> I looked again at both webrev.00 and webrev.01.? I think there is a 
> better solution than both.
>
> The original code has the explanatory comment; for webrev.01, "form 
> follows function" comes to mind: while being more idiomatic, using 
> computeIfAbsent, it is also more verbose and thus less clear.
>
> How about a variant of webrev.00 in which you do lock the newly-added 
> specific cache, and thus do away with the comment.
>
>    91     @Override
>    92     public List<Path> getJarClassPath(Path file) throws IOException {
>               synchronized (jarClassPathCache) {
> 96 List<Path> jarClassPath = jarClassPathCache.get(file);
> 97 if (jarClassPath == null) {
> 98 jarClassPath = super.getJarClassPath(file);
> 99 jarClassPathCache.put(file, jarClassPath);
> 100 }
> 101 return jarClassPath; }
>  ?102     }
>
> The reformatting on lines 55-57 seems a bit gratuitous, especially 
> putting the cast on a line by itself.
>
> The rest seems OK.
>
> - Jon
>
>
> On 03/26/2019 08:50 AM, Liam Miller-Cushon wrote:
>> Is there any other feedback on the change?
>>
>> On Wed, Mar 13, 2019 at 9:29 PM Liam Miller-Cushon <cushon at google.com 
>> <mailto:cushon at google.com>> wrote:
>>
>>     On Wed, Mar 13, 2019 at 5:59 PM Jonathan Gibbons
>>     <jonathan.gibbons at oracle.com
>>     <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>         I could go either way on getJarClassPath.? The initial
>>         version in webrev.00 was definitely shorter.
>>
>>     computeIfAbsent feels a little more idiomatic to me than the
>>     intentional race (and the comment to explain why it's safe), but
>>     I don't really have a preference.
>>
>>     I'm happy to revert to webrev.00 if you prefer.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/0d6def72/attachment.html>

From jonathan.gibbons at oracle.com  Tue Mar 26 20:33:20 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 26 Mar 2019 13:33:20 -0700
Subject: RFR 8220792: JavacFileManager.list() performance
In-Reply-To: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
Message-ID: <7f656e83-b2e3-2a8d-cb41-afee8da88c8a@oracle.com>



On 03/18/2019 11:14 AM, Ron Shapiro wrote:
> Hi,
>
> Please review this change to improve the performance of 
> JavacFileManager.list().
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220792
> webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eronsh/8220792/webrev.00/>
>
> Thanks,
> Ron

Ron,

The idea seems reasonable, but there are some issues with your proposed 
implementation.

Something of a red flag is the need to import Main.Option, when it was 
not needed before. Following that thread, the new maps appear to be 
general, and apply to each Location, but down at the end of the file, 
you reset all the caches if only the CLASS_PATH option is set.? 
Moreover, even if the class path is deemed to be special, you only 
interpose when the option is set, and not if the location is set 
directly with any of the setLocation methods are called.

class PathAndContainer implements compareTo but not equals and hashCode,

It's not clear to me why you maintain the list of PathAndContainer as a 
sorted list, and hence why you need to use java.util.List instead of 
javac's List.

-- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/198220f6/attachment.html>

From cushon at google.com  Tue Mar 26 20:46:44 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 26 Mar 2019 13:46:44 -0700
Subject: RFR: 8220687: Change signature of
 StandardJavaFileManager.getJavaFileObjectsFromPaths
In-Reply-To: <e7518dac-ff91-55a0-71e2-33fe3d882163@oracle.com>
References: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>
 <e7518dac-ff91-55a0-71e2-33fe3d882163@oracle.com>
Message-ID: <CAL4Qsgt6wLN2sUo=kuDxKoiL3twk-nc6Fq1HDiFZtyF-TJBU5Q@mail.gmail.com>

Jon,

Thanks, I updated ClientCodeWrapper and DelegatingJavaFileManager, and
verified the tier1 langtools tests are passing.

I also adapted one of the existing tests to exercise to deprecated Iterable
overload.

Here's the updated webrev:
http://cr.openjdk.java.net/~cushon/8220687/webrev.03/

On Tue, Mar 26, 2019 at 12:06 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Liam,
>
> Make sure the proposed new code passes all the standard langtools tests,
> including (in particular) TestClientCodeWrapper.java.
>
> As a general process point, a changeset should always either have a test,
> or the JBS issue should have a "noreg-*" label, where the label is chosen
> from the list here [1].  In other words, write a test, or justify why one
> is not required.  Internally, we have infrastructure that checks this
> condition.  If you create a new test, or edit an existing one, make sure
> the jtreg test-description lists the JBS issue number in the `@bug` line.
>
> -- Jon
>
> [1] https://openjdk.java.net/guide/changePlanning.html#bug  (See section
> 6.)
>
> On 03/14/2019 06:19 PM, Liam Miller-Cushon wrote:
>
> Hi,
>
> This change adds a getJavaFileObjectsFromPaths(Collection<Path>) method,
> and deprecates the existing getJavaFileObjectsFromPaths(Iterable<Path>).
> The motivation is the same as JDK-8150111, which made a similar change to
> setLocationFromPaths: methods that take Iterable<Path> are error-prone
> since Path itself implements Iterable<Path>.
>
> I have two initial questions: do you think this is worthwhile, and if so
> what's the correct process (should I file a CSR?).
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220687
> webrev: http://cr.openjdk.java.net/~cushon/8220687/webrev.00/
>
> Thanks,
> Liam
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/367fce61/attachment.html>

From jonathan.gibbons at oracle.com  Tue Mar 26 20:52:23 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 26 Mar 2019 13:52:23 -0700
Subject: RFR 8220792: JavacFileManager.list() performance
In-Reply-To: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
Message-ID: <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com>



On 03/18/2019 11:14 AM, Ron Shapiro wrote:
> Hi,
>
> Please review this change to improve the performance of 
> JavacFileManager.list().
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220792
> webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eronsh/8220792/webrev.00/>
>
> Thanks,
> Ron

Ron,

Look at these lines:


984 // First collect all of the containers that don't maintain their own 
index on
985 // RelativeDirectory. These need to always be included for all mappings
986 java.util.List<PathAndContainer> nonIndexingContainers = new 
ArrayList<>();
987 for (PathAndContainer pathAndContainer : allPathsAndContainers) {
988 if (!(pathAndContainer.container instanceof ArchiveContainer)) {
989 nonIndexingContainers.add(pathAndContainer);
990 }
991 }

The "instanceof" on line 988 does not generally match the comment about 
"all of the
containers that don't maintain their own index".

Digging into the Mercurial histroy a bit, I see that the package index 
was added as a
performance update in JDK-8150461. What if we were to do similar fixes 
on other
subtypes of Container?? Your code would be more future-proof if the 
instanceof was
replaced by a new method on the Container interface, indicating if the 
container
maintained its own map.

That being said, it would be even better if the "master index" was 
automatically updated
whenever any directory was found in any container. That way, the master 
index would lazily
learn about the contents of the JRTImageContainer and DirectoryContainer 
as well.

-- Jon



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/e09cb6d2/attachment-0001.html>

From jonathan.gibbons at oracle.com  Tue Mar 26 21:10:43 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 26 Mar 2019 14:10:43 -0700
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
Message-ID: <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>

Looks OK to me, especially the similarity to JDK-8215368

-- Jon


On 03/19/2019 03:37 PM, Ron Shapiro wrote:
> Hi,
>
> This is a small change that avoids eagerly creating JCDiagnostic for 
> CompletionFailures.
>
> webrev: http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eronsh/8221118/webrev.00/>
> bug: https://bugs.openjdk.java.net/browse/JDK-8221118
>
> Thanks,
> Ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/4d135cc2/attachment.html>

From jonathan.gibbons at oracle.com  Tue Mar 26 21:13:20 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 26 Mar 2019 14:13:20 -0700
Subject: RFR: 8220687: Change signature of
 StandardJavaFileManager.getJavaFileObjectsFromPaths
In-Reply-To: <CAL4Qsgt6wLN2sUo=kuDxKoiL3twk-nc6Fq1HDiFZtyF-TJBU5Q@mail.gmail.com>
References: <CAL4QsguZwSktapV2fBKGY91VSjUoK0_=b1+N956gqTbUazO16Q@mail.gmail.com>
 <e7518dac-ff91-55a0-71e2-33fe3d882163@oracle.com>
 <CAL4Qsgt6wLN2sUo=kuDxKoiL3twk-nc6Fq1HDiFZtyF-TJBU5Q@mail.gmail.com>
Message-ID: <ee8e7d2c-ba2e-0b88-a775-3c06c715b01a@oracle.com>

+1

-- Jon


On 03/26/2019 01:46 PM, Liam Miller-Cushon wrote:
> Jon,
>
> Thanks, I updated ClientCodeWrapper and DelegatingJavaFileManager, and 
> verified the tier1 langtools tests are passing.
>
> I also adapted one of the existing tests to?exercise to deprecated 
> Iterable overload.
>
> Here's the updated webrev:
> http://cr.openjdk.java.net/~cushon/8220687/webrev.03/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220687/webrev.03/>
>
> On Tue, Mar 26, 2019 at 12:06 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Liam,
>
>     Make sure the proposed new code passes all the standard langtools
>     tests, including (in particular) TestClientCodeWrapper.java.
>
>     As a general process point, a changeset should always either have
>     a test, or the JBS issue should have a "noreg-*" label, where the
>     label is chosen from the list here [1].? In other words, write a
>     test, or justify why one is not required.? Internally, we have
>     infrastructure that checks this condition.? If you create a new
>     test, or edit an existing one, make sure the jtreg
>     test-description lists the JBS issue number in the `@bug` line.
>
>     -- Jon
>
>     [1] https://openjdk.java.net/guide/changePlanning.html#bug (See
>     section 6.)
>
>
>     On 03/14/2019 06:19 PM, Liam Miller-Cushon wrote:
>>     Hi,
>>
>>     This change adds a?getJavaFileObjectsFromPaths(Collection<Path>)
>>     method, and deprecates the?existing
>>     getJavaFileObjectsFromPaths(Iterable<Path>). The motivation is
>>     the same as JDK-8150111, which made a similar change to
>>     setLocationFromPaths: methods that take Iterable<Path> are
>>     error-prone since Path itself implements Iterable<Path>.
>>
>>     I have two initial questions: do you think this is worthwhile,
>>     and if so what's the correct process (should I file a CSR?).
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8220687
>>     webrev: http://cr.openjdk.java.net/~cushon/8220687/webrev.00/
>>     <http://cr.openjdk.java.net/%7Ecushon/8220687/webrev.00/>
>>
>>     Thanks,
>>     Liam
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/8f13a90c/attachment.html>

From christoph.langer at sap.com  Tue Mar 26 22:01:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Mar 2019 22:01:34 +0000
Subject: OpenJDK source code not compiling with Eclipse compiler
In-Reply-To: <HE1PR0201MB2266C9EFE47098C55FBC94D38A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB2266C9EFE47098C55FBC94D38A440@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0201MB2266DD325A92EEBEC46C0E808A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

ping: Are there any comments on my findings (see webrev)?

Especially, can anybody comment on the status of JDK-8016207?

Thanks
Christoph


From: Langer, Christoph
Sent: Freitag, 15. M?rz 2019 15:49
To: 'compiler-dev at openjdk.java.net' <compiler-dev at openjdk.java.net>; Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Cc: Schmelter, Ralf <ralf.schmelter at sap.com>; 'Stephan Herrmann' <stephan.herrmann at berlin.de>
Subject: OpenJDK source code not compiling with Eclipse compiler

Hi there,

I?m using Eclipse for OpenJDK development. For quite a long time, I?ve been stumbling over a few issues where the Eclipse compiler is not able to compile some code while javac is. It?s all related to generics and handling of capture vars.

There are open bugs, both at Eclipse [0] and OpenJDK[1] for this type of issues. The Eclipse bug refers to the OpenJDK bug and states that it just conforms to JLS. In the OpenJDK bug, the statement is that there are unspecified widening of captures which should be added to spec/JLS.

For the OpenJDK I have created the following webrev that shows how the problematic code places could be modified to be compilable with Eclipse ECJ: http://cr.openjdk.java.net/~clanger/webrevs/ecjcompile/

Can someone give me a status on JDK-8016207? Or are there arguments to convince Stephan (the ECJ compiler maintainer) to modify ECJ?

I?ll probably propose my webrev for OpenJDK, in case we can?t find a solution for the compilers ??

Thanks & Best regards
Christoph

[0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=530236
[1] https://bugs.openjdk.java.net/browse/JDK-8016207

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/7aefee90/attachment-0001.html>

From cushon at google.com  Wed Mar 27 00:47:22 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 26 Mar 2019 17:47:22 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <09b9ebcf-cb6e-416f-44f7-deb0b0659541@oracle.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
 <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
 <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>
 <CACA6h9t2k73yLPVaG+0A1eAmiLAkq8r=MaA4tov6XD81wjjArw@mail.gmail.com>
 <CAL4Qsgu5U_GMwtpddhz5_7DAyVep8qPvJFNman2E88BqmBb-WQ@mail.gmail.com>
 <bcceef10-12c0-307a-56f7-332c4b97552f@oracle.com>
 <CAL4Qsgv5Qk=61BY7=Zhtp-CXepu8mqHK-N+GMr_rk-_SEwQtZw@mail.gmail.com>
 <09b9ebcf-cb6e-416f-44f7-deb0b0659541@oracle.com>
Message-ID: <CAL4Qsgs6zwBYy5x76yfXUHcz+4mTc3Z3-zJx_-ZWiTJg6Ph4aw@mail.gmail.com>

Thanks, I updated the patch to use your text.

I also remembered to update CheckExamples, and fixed a bug I introduced
moving this patch around earlier:

diff -r 491d5bc43f86
src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java  Tue
Mar 26 16:09:33 2019 -0700
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java  Tue
Mar 26 16:57:37 2019 -0700
@@ -723,13 +723,14 @@
                 break;

             case ERROR:
-                if (nerrors < MaxErrors &&
-                    (diagnostic.isFlagSet(DiagnosticFlag.API) ||
-                     shouldReport(diagnostic))) {
-                    writeDiagnostic(diagnostic);
-                    nerrors++;
-                } else {
-                    nsuppressederrors++;
+                if (diagnostic.isFlagSet(DiagnosticFlag.API) ||
+                     shouldReport(diagnostic)) {
+                    if (nerrors < MaxErrors) {
+                        writeDiagnostic(diagnostic);
+                        nerrors++;
+                    } else {
+                        nsuppressederrors++;
+                    }
                 }
                 break;
             }

The (hopefully final) version of the webrev is here:
http://cr.openjdk.java.net/~cushon/8220632/webrev.02/

On Tue, Mar 26, 2019 at 11:40 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> OK, with a suggestion.
>
> The basic update is OK.  Seeing the messages in context, I would suggest
> to tweak the messages as follows:
>
> 1640 compiler.misc.count.error.recompile=\1641     only showing the first {0} errors, of {1} total; use -Xmaxerrs if you would like to see more
>
> I like the text for explicitly hinting at why you might want to use the
> option, as compared to just telling people to consider using the option,
> without saying why.
>
> No need to re-review if you keep the webrev as is, or change to the
> suggested text, for both messages
>
> -- Jon
>
> On 03/15/2019 11:31 AM, Liam Miller-Cushon wrote:
>
> I updated the webrev with the suggested changes to the diagnostic text:
>
> http://cr.openjdk.java.net/~cushon/8220632/webrev.01/
>
> On Fri, Mar 15, 2019 at 11:26 AM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>>
>> On 3/15/19 11:21 AM, Liam Miller-Cushon wrote:
>>
>> On Fri, Mar 15, 2019 at 11:11 AM Ron Shapiro <ronshapiro at google.com>
>> wrote:
>>
>>> Regarding Jonathan's comments in the bug, would it be helpful/possible
>>> to categorize the types of diagnostics not shown? For built-in diagnostics
>>> we could try to group (maybe just the popular ones?) by their key?
>>>
>>> 42 symbols could not be found
>>> 15 errors from com.example.proc.ExampleProcessor
>>> etc
>>>
>>> ?
>>>
>>
>> It's certainly possible. I think we want to strike a balance between
>> providing enough information to help avoid users getting stuck when
>> diagnostics are suppressed, but not so much information that it's
>> distracting (since hopefully in the common case the suppressed diagnostics
>> are not necessary to understand the problem).
>>
>> In that specific example, Jon's suggestion to sort the non-recoverable
>> diagnostics first (which I intend to follow up on JDK-8220691) would avoid
>> suppressing the com.example.proc.ExampleProcessor diagnostics entirely.
>>
>>
>> If we were to provide this extra info, maybe it could/should be opt-in.
>> But, I think it is a better use of resources to make javac more friendly
>> "out of the box" and to print the more-likely-important messages first, so
>> that users don't have to wade through too much info.
>>
>> -- Jon
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/be4ddb9c/attachment.html>

From ronshapiro at google.com  Wed Mar 27 16:06:51 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Wed, 27 Mar 2019 11:06:51 -0500
Subject: RFR 8220792: JavacFileManager.list() performance
In-Reply-To: <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
 <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com>
Message-ID: <CACA6h9uNhmzqAf=tN33Y-WL9fK-oqmwRDDykP3iZB5WRm88aJg@mail.gmail.com>

Thanks for the comments!

I'm not able to see JDK-8150461 in JBS or in the mercurial history, but I
do like your suggestion on adding a method on Container instead of the
instanceof.

I think the tracking you discuss at the end may be challenging given that
JRTImageContainer and DirectoryContainer don't create an index right away.
I'm not sure exactly how to achieve what you're suggesting without some
heavy lifting.

As for the importing of Main.Option - I needed to do that to have the
jshell tests pass, since they continually update the classpath. I'm open to
other suggestions as I wasn't 100% sure how that works. I've updated the
other setLocation*() methods to also clear the caches as you mentioned.
Thanks for pointing that out.

> class PathAndContainer implements compareTo but not equals and hashCode
Good point. I'll add those for consistency.

> It's not clear to me why you maintain the list of PathAndContainer as a
sorted list, and hence why you need to use java.util.List instead of
javac's List.
There are some tests that ensure that the classpath that javac sees is
equivalent to the classpath the JVM sees vis-a-vis ordering. Without
sorting, javac was seeing a different order, and I presume that is because
the JRTImageContainer and DirectoryContainers could appear anywhere.
Sorting solved that issue. Additionally, I was seeing javac's List.append()
calls take up lots of time in profiling, but using ArrayList made that
disappear.

I have an updated webrev here:
http://cr.openjdk.java.net/~ronsh/8220792/webrev.01/

On Tue, Mar 26, 2019 at 3:52 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
>
> On 03/18/2019 11:14 AM, Ron Shapiro wrote:
>
> Hi,
>
> Please review this change to improve the performance of
> JavacFileManager.list().
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220792
> webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.00/
>
> Thanks,
> Ron
>
>
> Ron,
>
> Look at these lines:
>
>  984         // First collect all of the containers that don't maintain their own index on 985         // RelativeDirectory. These need to always be included for all mappings 986         java.util.List<PathAndContainer> nonIndexingContainers = new ArrayList<>(); 987         for (PathAndContainer pathAndContainer : allPathsAndContainers) { 988             if (!(pathAndContainer.container instanceof ArchiveContainer)) { 989                 nonIndexingContainers.add(pathAndContainer); 990             } 991         }
>
> The "instanceof" on line 988 does not generally match the comment about
> "all of the
> containers that don't maintain their own index".
>
> Digging into the Mercurial histroy a bit, I see that the package index was
> added as a
> performance update in JDK-8150461. What if we were to do similar fixes on
> other
> subtypes of Container?  Your code would be more future-proof if the
> instanceof was
> replaced by a new method on the Container interface, indicating if the
> container
> maintained its own map.
>
> That being said, it would be even better if the "master index" was
> automatically updated
> whenever any directory was found in any container. That way, the master
> index would lazily
> learn about the contents of the JRTImageContainer and DirectoryContainer
> as well.
>
> -- Jon
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190327/20287bd3/attachment.html>

From vicente.romero at oracle.com  Wed Mar 27 16:34:52 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 27 Mar 2019 12:34:52 -0400
Subject: RFR: JDK-8221413: javac does not recognize variable assigned in
 switch expression as DA
In-Reply-To: <5C9A2F2C.5050805@oracle.com>
References: <5C9A2F2C.5050805@oracle.com>
Message-ID: <ba81fb45-27db-8656-e78d-1379301f8d48@oracle.com>

looks good to me,
Vicente

On 3/26/19 9:54 AM, Jan Lahoda wrote:
> Hi,
>
> javac does not correctly infer definitely assigned variables for 
> switch expressions with implicit default clause (where the default 
> clause is added automatically for exhaustive switch over enums).
>
> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8221413/webrev.00/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8221413
>
> How does this look?
>
> Thanks,
> ??? Jan


From jonathan.gibbons at oracle.com  Wed Mar 27 17:21:31 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 27 Mar 2019 10:21:31 -0700
Subject: RFR 8220792: JavacFileManager.list() performance
In-Reply-To: <CACA6h9uNhmzqAf=tN33Y-WL9fK-oqmwRDDykP3iZB5WRm88aJg@mail.gmail.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
 <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com>
 <CACA6h9uNhmzqAf=tN33Y-WL9fK-oqmwRDDykP3iZB5WRm88aJg@mail.gmail.com>
Message-ID: <2f139056-0e39-dd5c-da47-10eb1da13c67@oracle.com>

Responses inline, but there is one additional comment that occurred to 
me after my responses yesterday.

I guess I'm mildly concerned about the double caching caused by the 
proposed new cache in front of the cache built inside ArchiveContainer. 
I guess the point is that the ArchiveContainer should be stable (unless 
the jar file is mutated) but the locations are more easily mutable, 
either via options or setLocation* methods.

---

I'll read and comment on the new webrev separately.

-- Jon


On 3/27/19 9:06 AM, Ron Shapiro wrote:
> Thanks for the comments!
>
> I'm not able to see JDK-8150461 in JBS or in the mercurial history, 
> but I do like your suggestion on adding a method on Container instead 
> of the instanceof.
Mea culpa; transposition typo; I meant JDK-8150641, 
https://bugs.openjdk.java.net/browse/JDK-8150641 which was the work done 
by Jan to add the caching for ArchiveContainer.
>
> I think the tracking you discuss at the end may be challenging given 
> that JRTImageContainer and DirectoryContainer don't create an index 
> right away. I'm not sure exactly how to achieve what you're suggesting 
> without some heavy lifting.

There were two ideas in my head when I was writing the note.

1. If it is worth indexing ArchiveContainer when it is opened, would it 
be worth indexing other containers as well?

2. Given that the answer to #1 may be "maybe, maybe not", the thought 
was that after you list any package for the first time, you know what 
containers the package is found in, so it (theoretically) ought to be 
easy to update a method like JavacFileManager.list so that it updates 
the main index for that package.? That being said, I guess the contents 
of a DirectoryContainer are "easily mutable", e.g. by annotation 
processing and so we should not prematurely cache info about its 
contents. But JRTImageContainer should not be mutable, and so may be 
worth indexing.


>
> As for the importing of Main.Option - I needed to do that to have the 
> jshell tests pass, since they continually update the classpath. I'm 
> open to other suggestions as I wasn't 100% sure how that works. I've 
> updated the other setLocation*() methods to also clear the caches as 
> you mentioned. Thanks for pointing that out.
Look for and use "javacFileManagerOptions", which gives all the file 
manager options. If any option is modified, I think it appropriate to 
clear the cache.
>
> > class PathAndContainer implements compareTo but not equals and hashCode
> Good point. I'll add those for consistency.
>
> > It's not clear to me why you maintain the list of PathAndContainer 
> as a sorted list, and hence why you need to use java.util.List instead 
> of javac's List.
> There are some tests that ensure that the classpath that javac sees is 
> equivalent to the classpath the JVM sees vis-a-vis ordering. Without 
> sorting, javac was seeing a different order, and I presume that is 
> because the JRTImageContainer and DirectoryContainers could appear 
> anywhere. Sorting solved that issue. Additionally, I was seeing 
> javac's List.append() calls take up lots of time in profiling, but 
> using ArrayList made that disappear.

I agree with preserving the order expected by tests ;-)

I don't have an immediate explanation for the ordering issue.? If you 
need mutable lists, with the ability to append any time, then yes, use 
ArrayList. If you just need to build immutable lists, use ListBuffer, 
which has a fast append, and then call .toList()

>
> I have an updated webrev here: 
> http://cr.openjdk.java.net/~ronsh/8220792/webrev.01/
>
> On Tue, Mar 26, 2019 at 3:52 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>
>
>     On 03/18/2019 11:14 AM, Ron Shapiro wrote:
>>     Hi,
>>
>>     Please review this change to improve the performance of
>>     JavacFileManager.list().
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8220792
>>     webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.00/
>>     <http://cr.openjdk.java.net/%7Eronsh/8220792/webrev.00/>
>>
>>     Thanks,
>>     Ron
>
>     Ron,
>
>     Look at these lines:
>
>
>     984 // First collect all of the containers that don't maintain
>     their own index on
>     985 // RelativeDirectory. These need to always be included for all
>     mappings
>     986 java.util.List<PathAndContainer> nonIndexingContainers = new
>     ArrayList<>();
>     987 for (PathAndContainer pathAndContainer : allPathsAndContainers) {
>     988 if (!(pathAndContainer.container instanceof ArchiveContainer)) {
>     989 nonIndexingContainers.add(pathAndContainer);
>     990 }
>     991 }
>
>     The "instanceof" on line 988 does not generally match the comment
>     about "all of the
>     containers that don't maintain their own index".
>
>     Digging into the Mercurial histroy a bit, I see that the package
>     index was added as a
>     performance update in JDK-8150461. What if we were to do similar
>     fixes on other
>     subtypes of Container?? Your code would be more future-proof if
>     the instanceof was
>     replaced by a new method on the Container interface, indicating if
>     the container
>     maintained its own map.
>
>     That being said, it would be even better if the "master index" was
>     automatically updated
>     whenever any directory was found in any container. That way, the
>     master index would lazily
>     learn about the contents of the JRTImageContainer and
>     DirectoryContainer as well.
>
>     -- Jon
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190327/18ef55d0/attachment-0001.html>

From ronshapiro at google.com  Wed Mar 27 17:46:09 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Wed, 27 Mar 2019 12:46:09 -0500
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
Message-ID: <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>

I missed a few cases earlier - see this updated webrev:
http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/

On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Looks OK to me, especially the similarity to JDK-8215368
>
> -- Jon
>
> On 03/19/2019 03:37 PM, Ron Shapiro wrote:
>
> Hi,
>
> This is a small change that avoids eagerly creating JCDiagnostic for
> CompletionFailures.
>
> webrev: http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8221118
>
> Thanks,
> Ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190327/65ea6d64/attachment.html>

From jonathan.gibbons at oracle.com  Wed Mar 27 17:46:56 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 27 Mar 2019 10:46:56 -0700
Subject: RFR 8220792: JavacFileManager.list() performance
In-Reply-To: <CACA6h9uNhmzqAf=tN33Y-WL9fK-oqmwRDDykP3iZB5WRm88aJg@mail.gmail.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
 <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com>
 <CACA6h9uNhmzqAf=tN33Y-WL9fK-oqmwRDDykP3iZB5WRm88aJg@mail.gmail.com>
Message-ID: <86018eba-aecb-0005-390d-0ce2b662a4df@oracle.com>


On 3/27/19 9:06 AM, Ron Shapiro wrote:
>
> > It's not clear to me why you maintain the list of PathAndContainer 
> as a sorted list, and hence why you need to use java.util.List instead 
> of javac's List.
> There are some tests that ensure that the classpath that javac sees is 
> equivalent to the classpath the JVM sees vis-a-vis ordering. Without 
> sorting, javac was seeing a different order, and I presume that is 
> because the JRTImageContainer and DirectoryContainers could appear 
> anywhere. Sorting solved that issue.

OK, I think I understand the issue and why sorting fixes it.

While some tests may check that "the classpath that javac sees is 
equivalent to the classpath the JVM sees vis-a-vis ordering", that's not 
the primary issue. The primary issue is that the new cache must preserve 
the order in which containers are searched on the classpath (i.e just 
within javac, separate from any part set by the JVM). While this is not 
so important when looking up classes in "well-behaved" packages, it is 
important when handling split packages and resources, where the contents 
in one container may hide the contents in another container.

I think this is subtle enough that it is worth a comment in the code, 
explaining that it is important to preserve the search order used in the 
uncached Location path.

-- Jon


From bsrbnd at gmail.com  Wed Mar 27 18:20:07 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 27 Mar 2019 19:20:07 +0100
Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside
 switch expression
Message-ID: <CAEgw74Ct-+DsXM+Ti+Lc2p86r1HhTTU8NYXY_HH8tJQm3+DDQg@mail.gmail.com>

Hi,

Please review the following fix for [1] which has already been
discussed in the corresponding thread [2]:

http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.00/

It includes the variant I suggested to store the switch expression
result in a single temporary variable along with Jan's solution for
switch expressions used as conditions. Note that I had to do a tiny
correction to the latter (see 'code.resolve(value.trueJumps)') to make
the following example succeed:

    public static void test4() {
        if (!switch (0) {
            default -> {
                try {
                    break switch(0) { default -> true; };
                }
                finally {
                    break false;
                }
            }
        }) {
            System.out.println("OK!");
        }
    }

It also includes Jan's test case.

Any feedback is welcome (tier1 is OK).

Thanks,
Bernard

[1] https://bugs.openjdk.java.net/browse/JDK-8220018
[2] http://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013073.html

From cushon at google.com  Wed Mar 27 20:05:16 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 27 Mar 2019 13:05:16 -0700
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
Message-ID: <CAL4QsgsoLAi-NQqE5K7JUYp1bD=oAFWs_nfjbe+Ljsoim-64cQ@mail.gmail.com>

It still looks good to me, FWIW.

On Wed, Mar 27, 2019 at 10:47 AM Ron Shapiro <ronshapiro at google.com> wrote:

> I missed a few cases earlier - see this updated webrev:
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/
>
> On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> Looks OK to me, especially the similarity to JDK-8215368
>>
>> -- Jon
>>
>> On 03/19/2019 03:37 PM, Ron Shapiro wrote:
>>
>> Hi,
>>
>> This is a small change that avoids eagerly creating JCDiagnostic for
>> CompletionFailures.
>>
>> webrev: http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8221118
>>
>> Thanks,
>> Ron
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190327/6c690228/attachment.html>

From david.holmes at oracle.com  Thu Mar 28 05:47:06 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 28 Mar 2019 15:47:06 +1000
Subject: RFC: Make test failed because of the locale LANG
In-Reply-To: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn>
References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn>
Message-ID: <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com>

Hi Jing,

On 28/03/2019 3:22 pm, Jing Tian wrote:
> Hi,
> 
> When I am doing the 'make test'.If the local LANG is set as 
> 'zh_CN.UTF-8', Test cases will have a lot of error messages.
> 
> ==============================
> Test summary
> ==============================
>  ?? TEST????????????????????????????????????????????? TOTAL? PASS FAIL 
> ERROR
>  >> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2???? 0 <<
>  >> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7???? 0 <<
>  >> jtreg:test/langtools:tier1???????????????????????? 3922 2470 
> 1450???? 2 <<
>  ?? jtreg:test/nashorn:tier1????????????????????????????? 0 0???? 0???? 0
>  ?? jtreg:test/jaxp:tier1???????????????????????????????? 0 0???? 0???? 0
>  >> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 29     
> 0 <<
>  >> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 <<
>  ?? jtreg:test/nashorn:tier2???????????????????????????? 35 35???? 0???? 0
>  >> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1???? 0 <<
>  >> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 36     
> 0 <<
>  ?? jtreg:test/langtools:tier3??????????????????????????? 0 0???? 0???? 0
>  ?? jtreg:test/nashorn:tier3????????????????????????????? 0 0???? 0???? 0
>  ?? jtreg:test/jaxp:tier3???????????????????????????????? 0 0???? 0???? 0
> ==============================

Given most of these are not hotspot issues and given the number of 
failures, I think this is something that would need to be discussed much 
more broadly. So I've cc'd core-libs-dev and compiler-dev. I recall 
there was a very recent discussion regarding some tests failing for the 
same reason, but don't recall the outcome.

David
-----

> On the same machine,when i set LANG=en_US.UTF-8.
> 
> ==============================
> Test summary
> ==============================
>  ?? TEST????????????????????????????????????????????? TOTAL? PASS FAIL 
> ERROR
>  >> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2???? 0 <<
>  >> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 19     
> 5 <<
>  ?? jtreg:test/langtools:tier1???????????????????????? 3920 3920 0???? 0
>  ?? jtreg:test/nashorn:tier1????????????????????????????? 0 0???? 0???? 0
>  ?? jtreg:test/jaxp:tier1???????????????????????????????? 0 0???? 0???? 0
>  >> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 31     
> 7 <<
>  ?? jtreg:test/langtools:tier2?????????????????????????? 11 11???? 0???? 0
>  ?? jtreg:test/nashorn:tier2???????????????????????????? 35 35???? 0???? 0
>  ?? jtreg:test/jaxp:tier2?????????????????????????????? 438 438???? 0???? 0
>  >> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 37     
> 0 <<
>  ?? jtreg:test/langtools:tier3??????????????????????????? 0 0???? 0???? 0
>  ?? jtreg:test/nashorn:tier3????????????????????????????? 0 0???? 0???? 0
>  ?? jtreg:test/jaxp:tier3???????????????????????????????? 0 0???? 0???? 0
> 
> 
> By comparison we can find, lots of(1000+) langtools tests will get fail, 
> and other(about 30+, exclude some X11 and sanity that
> 
> result problem) test cases will also fail because of local LANG.
> 
> 
> such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java,
> 
> shouldContain("Error: Could not find or load main class " + CLASSNAME)
> 
> 
> When in the zh_CN.UTF-8 environment, because some of the output 
> information is changed to Chinese by some properties file,
> 
> the English cannot be matched, which will result in an fail.
> 
> When I set? LANG=en_US/LC_ALL=C, this test will pass.
> 
> 
> I think there are some possible solutions.
> 
> 
> 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this modification 
> is more violent because he will affect all test cases.
> 
> 
> 2.We modify each individual test?E.g 
> test/hotspot/jtreg/compiler/c2/Test8062950.java
> 
> diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java
>  ?package compiler.c2;
>  ?import jdk.test.lib.process.ProcessTools;
> +import java.util.Map;
> +import jdk.test.lib.process.OutputAnalyzer;
> 
>  ?public class Test8062950 {
>  ???? private static final String CLASSNAME = "DoesNotExist";
>  ???? public static void main(String[] args) throws Exception {
> - ProcessTools.executeTestJvm("-Xcomp",
> - "-XX:-TieredCompilation",
> - "-XX:-UseOptoBiasInlining",
> - CLASSNAME)
> - .shouldHaveExitValue(1)
> -??????????????????? .shouldContain("Error: Could not find or load main 
> class " + CLASSNAME)
> -??????????????????? .shouldNotContain("A fatal error has been detected")
> -??????????????????? .shouldNotContain("Internal Error")
> -??????????????????? .shouldNotContain("HotSpot Virtual Machine Error");
> +??????? final ProcessBuilder pb = 
> ProcessTools.createJavaProcessBuilder(true,
> + "-Xcomp",
> + "-XX:-TieredCompilation",
> + "-XX:-UseOptoBiasInlining",
> + CLASSNAME);
> +??????? final Map<String, String> env = pb.environment();
> +??????? env.put("LC_ALL", "en_US.UTF-8");
> +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start());
> + output.shouldHaveExitValue(1);
> +??????? output.shouldContain("Error: Could not find or load main class 
> " + CLASSNAME);
> +??????? output.shouldNotContain("A fatal error has been detected");
> +??????? output.shouldNotContain("Internal Error");
> +??????? output.shouldNotContain("HotSpot Virtual Machine Error");
> }
>  ?}
> 
> But I don't know if this will change the test program too much, because 
> the related problems are a lot in langtools tests.
> 
> 
> 3.And i find that there is a function can judge the locale
> 
>  ?if (!isEnglishLocale()) { // only english version
> return;
>  ?}
> 
> But in this case, I think in many test cases, we may not be able to 
> return so directly, because some test cases may have other test purposes.
> 
> 
> So I don't know if you have any ideas or some suggestions to solve the 
> problem that the output information and English do not match in this
> 
> non-English environment.
> 
> 
> Cheers,
> 
> Jing Tian
> 
> 
> 
> 

From maurizio.cimadamore at oracle.com  Thu Mar 28 11:23:19 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Mar 2019 11:23:19 +0000
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
Message-ID: <46bffe45-b263-5fc6-b291-2a56c0d289de@oracle.com>

Looks mostly good - as Jon mentioned, eager diagnostic generation 
sometimes bites back. In the cases we have seen in the past, the main 
issue was related to the fact that, in order to create the diagnostic, 
the client had to call expensive methods (such as 
TreeInfo::diagnosticPositionFor, as per JDK-8215368). In this case, I 
see two somewhat potentially expensive operations:

* ex.getLocalizedMessage()

and

* createBadClassFileDiagnostic

Although neither seem to be too bad (e.g. requiring visitors, loops, or 
whatever). So, while in principle I agree with the change, I'm somewhat 
skeptical that it buys much in terms of performances. I've seen your bug 
report mentioned 700ms up to 3s spent in diagnostic creation... out of 
what total execution time?

Also, the () -> null looks a tad suspicious. If we don't care about the 
diagnostic, do we really want to create a new lambda for it? (I would 
normally not care much about this kind of micro optimization, but since 
that seems the whole point of this webrev, I thought it was worth 
pointing out).

Maurizio

On 27/03/2019 17:46, Ron Shapiro wrote:
> I missed a few cases earlier - see this updated webrev: 
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/
>
> On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Looks OK to me, especially the similarity to JDK-8215368
>
>     -- Jon
>
>
>     On 03/19/2019 03:37 PM, Ron Shapiro wrote:
>>     Hi,
>>
>>     This is a small change that avoids eagerly creating JCDiagnostic
>>     for CompletionFailures.
>>
>>     webrev: http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/
>>     <http://cr.openjdk.java.net/%7Eronsh/8221118/webrev.00/>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8221118
>>
>>     Thanks,
>>     Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/f9fd57c9/attachment.html>

From ronshapiro at google.com  Thu Mar 28 13:43:06 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Thu, 28 Mar 2019 09:43:06 -0400
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <46bffe45-b263-5fc6-b291-2a56c0d289de@oracle.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <46bffe45-b263-5fc6-b291-2a56c0d289de@oracle.com>
Message-ID: <CACA6h9uhTe2Q7sdiWYP_CYH_skbtxu6jr-P_S0SE4t9TOTNcMA@mail.gmail.com>

>From what I saw, JCDiagnostic.normalize() was taking the bulk of the time
(I think ~80%). That was all spent in Arrays.stream()....toArray(), which I
presume was creating a lot of garbage. Inserting a loop to first check if
any normalization was necessary removed that chunk, but I was still seeing
a sizeable remainder from other things (perhaps the two methods you listed).

I can try to dig up the initial profiles, but most of these builds tend to
be in the 100s-120s range.

>From what the code is currently doing, `() -> null` could be made into just
`null`. On my own, I didn't feel comfortable introducing that and preferred
to remain consistent, but if you think I should make the change I defer to
you.



On Thu, Mar 28, 2019 at 7:23 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Looks mostly good - as Jon mentioned, eager diagnostic generation
> sometimes bites back. In the cases we have seen in the past, the main issue
> was related to the fact that, in order to create the diagnostic, the client
> had to call expensive methods (such as TreeInfo::diagnosticPositionFor, as
> per JDK-8215368). In this case, I see two somewhat potentially expensive
> operations:
>
> * ex.getLocalizedMessage()
>
> and
>
> * createBadClassFileDiagnostic
>
> Although neither seem to be too bad (e.g. requiring visitors, loops, or
> whatever). So, while in principle I agree with the change, I'm somewhat
> skeptical that it buys much in terms of performances. I've seen your bug
> report mentioned 700ms up to 3s spent in diagnostic creation... out of what
> total execution time?
>
> Also, the () -> null looks a tad suspicious. If we don't care about the
> diagnostic, do we really want to create a new lambda for it? (I would
> normally not care much about this kind of micro optimization, but since
> that seems the whole point of this webrev, I thought it was worth pointing
> out).
>
> Maurizio
> On 27/03/2019 17:46, Ron Shapiro wrote:
>
> I missed a few cases earlier - see this updated webrev:
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/
>
> On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> Looks OK to me, especially the similarity to JDK-8215368
>>
>> -- Jon
>>
>> On 03/19/2019 03:37 PM, Ron Shapiro wrote:
>>
>> Hi,
>>
>> This is a small change that avoids eagerly creating JCDiagnostic for
>> CompletionFailures.
>>
>> webrev: http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8221118
>>
>> Thanks,
>> Ron
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/c58889e5/attachment.html>

From naoto.sato at oracle.com  Thu Mar 28 15:59:28 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 28 Mar 2019 08:59:28 -0700
Subject: RFC: Make test failed because of the locale LANG
In-Reply-To: <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com>
References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn>
 <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com>
Message-ID: <f3415f7c-224a-3abd-a3b5-dc912b60fbac@oracle.com>

Hi,

I don't think there is any *official* rule for the regression tests to 
succeed in any locale, but if the test case is locale sensitive such as 
in this case, I'd suggest it should correctly specify the locale 
beforehand, or quit gracefully in general.

For this specific case, I'd suggest not set the environment variable (as 
it won't work with Windows), using runtime system properties 
(user.language/user.country) would help.

Naoto

On 3/27/19 10:47 PM, David Holmes wrote:
> Hi Jing,
> 
> On 28/03/2019 3:22 pm, Jing Tian wrote:
>> Hi,
>>
>> When I am doing the 'make test'.If the local LANG is set as 
>> 'zh_CN.UTF-8', Test cases will have a lot of error messages.
>>
>> ==============================
>> Test summary
>> ==============================
>> ??? TEST????????????????????????????????????????????? TOTAL? PASS FAIL 
>> ERROR
>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2     
>> 0 <<
>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7     
>> 0 <<
>> ?>> jtreg:test/langtools:tier1???????????????????????? 3922 2470 
>> 1450???? 2 <<
>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0???? 0???? 0
>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0???? 0???? 0
>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 29 0 <<
>> ?>> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 <<
>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35     
>> 0???? 0
>> ?>> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1     
>> 0 <<
>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 36 0 <<
>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0???? 0???? 0
>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0???? 0???? 0
>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0???? 0???? 0
>> ==============================
> 
> Given most of these are not hotspot issues and given the number of 
> failures, I think this is something that would need to be discussed much 
> more broadly. So I've cc'd core-libs-dev and compiler-dev. I recall 
> there was a very recent discussion regarding some tests failing for the 
> same reason, but don't recall the outcome.
> 
> David
> -----
> 
>> On the same machine,when i set LANG=en_US.UTF-8.
>>
>> ==============================
>> Test summary
>> ==============================
>> ??? TEST????????????????????????????????????????????? TOTAL? PASS FAIL 
>> ERROR
>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2     
>> 0 <<
>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 19 5 <<
>> ??? jtreg:test/langtools:tier1???????????????????????? 3920 3920 0???? 0
>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0???? 0???? 0
>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0???? 0???? 0
>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 31 7 <<
>> ??? jtreg:test/langtools:tier2?????????????????????????? 11 11     
>> 0???? 0
>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35     
>> 0???? 0
>> ??? jtreg:test/jaxp:tier2?????????????????????????????? 438 438     
>> 0???? 0
>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 37 0 <<
>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0???? 0???? 0
>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0???? 0???? 0
>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0???? 0???? 0
>>
>>
>> By comparison we can find, lots of(1000+) langtools tests will get 
>> fail, and other(about 30+, exclude some X11 and sanity that
>>
>> result problem) test cases will also fail because of local LANG.
>>
>>
>> such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java,
>>
>> shouldContain("Error: Could not find or load main class " + CLASSNAME)
>>
>>
>> When in the zh_CN.UTF-8 environment, because some of the output 
>> information is changed to Chinese by some properties file,
>>
>> the English cannot be matched, which will result in an fail.
>>
>> When I set? LANG=en_US/LC_ALL=C, this test will pass.
>>
>>
>> I think there are some possible solutions.
>>
>>
>> 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this 
>> modification is more violent because he will affect all test cases.
>>
>>
>> 2.We modify each individual test?E.g 
>> test/hotspot/jtreg/compiler/c2/Test8062950.java
>>
>> diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java
>> ??package compiler.c2;
>> ??import jdk.test.lib.process.ProcessTools;
>> +import java.util.Map;
>> +import jdk.test.lib.process.OutputAnalyzer;
>>
>> ??public class Test8062950 {
>> ????? private static final String CLASSNAME = "DoesNotExist";
>> ????? public static void main(String[] args) throws Exception {
>> - ProcessTools.executeTestJvm("-Xcomp",
>> - "-XX:-TieredCompilation",
>> - "-XX:-UseOptoBiasInlining",
>> - CLASSNAME)
>> - .shouldHaveExitValue(1)
>> -??????????????????? .shouldContain("Error: Could not find or load 
>> main class " + CLASSNAME)
>> -??????????????????? .shouldNotContain("A fatal error has been detected")
>> -??????????????????? .shouldNotContain("Internal Error")
>> -??????????????????? .shouldNotContain("HotSpot Virtual Machine Error");
>> +??????? final ProcessBuilder pb = 
>> ProcessTools.createJavaProcessBuilder(true,
>> + "-Xcomp",
>> + "-XX:-TieredCompilation",
>> + "-XX:-UseOptoBiasInlining",
>> + CLASSNAME);
>> +??????? final Map<String, String> env = pb.environment();
>> +??????? env.put("LC_ALL", "en_US.UTF-8");
>> +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start());
>> + output.shouldHaveExitValue(1);
>> +??????? output.shouldContain("Error: Could not find or load main 
>> class " + CLASSNAME);
>> +??????? output.shouldNotContain("A fatal error has been detected");
>> +??????? output.shouldNotContain("Internal Error");
>> +??????? output.shouldNotContain("HotSpot Virtual Machine Error");
>> }
>> ??}
>>
>> But I don't know if this will change the test program too much, 
>> because the related problems are a lot in langtools tests.
>>
>>
>> 3.And i find that there is a function can judge the locale
>>
>> ??if (!isEnglishLocale()) { // only english version
>> return;
>> ??}
>>
>> But in this case, I think in many test cases, we may not be able to 
>> return so directly, because some test cases may have other test purposes.
>>
>>
>> So I don't know if you have any ideas or some suggestions to solve the 
>> problem that the output information and English do not match in this
>>
>> non-English environment.
>>
>>
>> Cheers,
>>
>> Jing Tian
>>
>>
>>
>>

From maurizio.cimadamore at oracle.com  Thu Mar 28 21:08:42 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Mar 2019 21:08:42 +0000
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <CACA6h9uhTe2Q7sdiWYP_CYH_skbtxu6jr-P_S0SE4t9TOTNcMA@mail.gmail.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <46bffe45-b263-5fc6-b291-2a56c0d289de@oracle.com>
 <CACA6h9uhTe2Q7sdiWYP_CYH_skbtxu6jr-P_S0SE4t9TOTNcMA@mail.gmail.com>
Message-ID: <e437a3da-8aee-c2e6-f076-895a914f2305@oracle.com>


On 28/03/2019 13:43, Ron Shapiro wrote:
> From what the code is currently doing, `() -> null` could be made into 
> just `null`. On my own, I didn't feel comfortable introducing that and 
> preferred to remain consistent, but if you think I should make the 
> change I defer to you.

Maybe we could have an override that takes no 'supplier', and instead 
uses a predefined () -> null supplier defined somewhere, so that it 
doesn't get created all the time.

Thanks for the additional data points.

Maurizio


From ronshapiro at google.com  Thu Mar 28 21:33:56 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Thu, 28 Mar 2019 17:33:56 -0400
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <e437a3da-8aee-c2e6-f076-895a914f2305@oracle.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <46bffe45-b263-5fc6-b291-2a56c0d289de@oracle.com>
 <CACA6h9uhTe2Q7sdiWYP_CYH_skbtxu6jr-P_S0SE4t9TOTNcMA@mail.gmail.com>
 <e437a3da-8aee-c2e6-f076-895a914f2305@oracle.com>
Message-ID: <CACA6h9vf=yuNydOQjM5w=unB29YvWx3M6uWzZrjEsx6TF-zPNA@mail.gmail.com>

If your concern is performance of creating the () -> null supplier, that's
created only once in the ClassFinder constructor. I don't think it's worth
adding an overload + constant just for that.

On Thu, Mar 28, 2019 at 5:08 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 28/03/2019 13:43, Ron Shapiro wrote:
> > From what the code is currently doing, `() -> null` could be made into
> > just `null`. On my own, I didn't feel comfortable introducing that and
> > preferred to remain consistent, but if you think I should make the
> > change I defer to you.
>
> Maybe we could have an override that takes no 'supplier', and instead
> uses a predefined () -> null supplier defined somewhere, so that it
> doesn't get created all the time.
>
> Thanks for the additional data points.
>
> Maurizio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/be6d7725/attachment.html>

From forax at univ-mlv.fr  Thu Mar 28 21:51:31 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 28 Mar 2019 22:51:31 +0100 (CET)
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
Message-ID: <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>

Hi Ron, 
In Symbol.java, having the field 'diag' being public means that you can access to the object without calling the getter so without calling the supplier. 
I also think that the supplier should not be public too. 

regards, 
R?mi 

> De: "Ron Shapiro" <ronshapiro at google.com>
> ?: "jonathan gibbons" <jonathan.gibbons at oracle.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoy?: Mercredi 27 Mars 2019 18:46:09
> Objet: Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
> CompletionFailures

> I missed a few cases earlier - see this updated webrev: [
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/ |
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/ ]

> On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons < [
> mailto:jonathan.gibbons at oracle.com | jonathan.gibbons at oracle.com ] > wrote:

>> Looks OK to me, especially the similarity to JDK-8215368

>> -- Jon

>> On 03/19/2019 03:37 PM, Ron Shapiro wrote:

>>> Hi,

>>> This is a small change that avoids eagerly creating JCDiagnostic for
>>> CompletionFailures.

>>> webrev: [ http://cr.openjdk.java.net/%7Eronsh/8221118/webrev.00/ |
>>> http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/ ]
>>> bug: [ https://bugs.openjdk.java.net/browse/JDK-8221118 |
>>> https://bugs.openjdk.java.net/browse/JDK-8221118 ]

>>> Thanks,
>>> Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/d467587f/attachment.html>

From ronshapiro at google.com  Thu Mar 28 21:58:00 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Thu, 28 Mar 2019 17:58:00 -0400
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>
Message-ID: <CACA6h9toQu5=bKqkHV4U1=yY6-qDtwCrfR86NbJiAdf=AWwiMQ@mail.gmail.com>

It's currently being reset by the cached CompletionFailure in ClassFinder -
I can replace that with a method call that resets the supplier and then
nulls the diagnostic. Suggestions on a method name for this? Does this
complicate the API of this type?

On Thu, Mar 28, 2019 at 5:51 PM Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Ron,
> In Symbol.java, having the field 'diag' being public means that you can
> access to the object without calling the getter so without calling the
> supplier.
> I also think that the supplier should not be public too.
>
> regards,
> R?mi
>
> ------------------------------
>
> *De: *"Ron Shapiro" <ronshapiro at google.com>
> *?: *"jonathan gibbons" <jonathan.gibbons at oracle.com>
> *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
> *Envoy?: *Mercredi 27 Mars 2019 18:46:09
> *Objet: *Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
> CompletionFailures
>
> I missed a few cases earlier - see this updated webrev:
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/
>
> On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> Looks OK to me, especially the similarity to JDK-8215368
>>
>> -- Jon
>>
>> On 03/19/2019 03:37 PM, Ron Shapiro wrote:
>>
>> Hi,
>>
>> This is a small change that avoids eagerly creating JCDiagnostic for
>> CompletionFailures.
>>
>> webrev: http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8221118
>>
>> Thanks,
>> Ron
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/6adb2d51/attachment.html>

From jonathan.gibbons at oracle.com  Thu Mar 28 21:58:44 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 28 Mar 2019 14:58:44 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <CAL4Qsgs6zwBYy5x76yfXUHcz+4mTc3Z3-zJx_-ZWiTJg6Ph4aw@mail.gmail.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
 <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
 <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>
 <CACA6h9t2k73yLPVaG+0A1eAmiLAkq8r=MaA4tov6XD81wjjArw@mail.gmail.com>
 <CAL4Qsgu5U_GMwtpddhz5_7DAyVep8qPvJFNman2E88BqmBb-WQ@mail.gmail.com>
 <bcceef10-12c0-307a-56f7-332c4b97552f@oracle.com>
 <CAL4Qsgv5Qk=61BY7=Zhtp-CXepu8mqHK-N+GMr_rk-_SEwQtZw@mail.gmail.com>
 <09b9ebcf-cb6e-416f-44f7-deb0b0659541@oracle.com>
 <CAL4Qsgs6zwBYy5x76yfXUHcz+4mTc3Z3-zJx_-ZWiTJg6Ph4aw@mail.gmail.com>
Message-ID: <dda80062-0e1a-ae25-fdca-46c9eb560778@oracle.com>

OK ... but with a trivial style issue.

In the test-description comment block, the one beginning @test, the 
recommended style is to not start the comment with "/**" because it is 
not a documentation comment.

Fix that and you're good to go.

-- Jon


On 03/26/2019 05:47 PM, Liam Miller-Cushon wrote:
> Thanks, I updated the patch to use your text.
>
> I also remembered to update CheckExamples, and fixed a bug I 
> introduced moving this patch around earlier:
>
> diff -r 491d5bc43f86 
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java 
> Tue Mar 26 16:09:33 2019 -0700
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java 
> Tue Mar 26 16:57:37 2019 -0700
> @@ -723,13 +723,14 @@
> ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ?case ERROR:
> -? ? ? ? ? ? ? ? if (nerrors < MaxErrors &&
> - (diagnostic.isFlagSet(DiagnosticFlag.API) ||
> -? ? ? ? ? ? ? ? ? ? ?shouldReport(diagnostic))) {
> -? ? ? ? ? ? ? ? ? ? writeDiagnostic(diagnostic);
> -? ? ? ? ? ? ? ? ? ? nerrors++;
> -? ? ? ? ? ? ? ? } else {
> -? ? ? ? ? ? ? ? ? ? nsuppressederrors++;
> +? ? ? ? ? ? ? ? if (diagnostic.isFlagSet(DiagnosticFlag.API) ||
> +? ? ? ? ? ? ? ? ? ? ?shouldReport(diagnostic)) {
> +? ? ? ? ? ? ? ? ? ? if (nerrors < MaxErrors) {
> +? ? ? ? ? ? ? ? ? ? ? ? writeDiagnostic(diagnostic);
> +? ? ? ? ? ? ? ? ? ? ? ? nerrors++;
> +? ? ? ? ? ? ? ? ? ? } else {
> +? ? ? ? ? ? ? ? ? ? ? ? nsuppressederrors++;
> +? ? ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ?}
>
> The (hopefully final) version of the webrev is here:
> http://cr.openjdk.java.net/~cushon/8220632/webrev.02/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220632/webrev.02/>
>
> On Tue, Mar 26, 2019 at 11:40 AM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     OK, with a suggestion.
>
>     The basic update is OK.? Seeing the messages in context, I would
>     suggest to tweak the messages as follows:
>
>     1640 compiler.misc.count.error.recompile=\
>     1641 only showing the first {0} errors, of {1} total; use
>     -Xmaxerrs if you would like to see more
>
>     I like the text for explicitly hinting at why you might want to
>     use the option, as compared to just telling people to consider
>     using the option, without saying why.
>
>     No need to re-review if you keep the webrev as is, or change to
>     the suggested text, for both messages
>
>     -- Jon
>
>     On 03/15/2019 11:31 AM, Liam Miller-Cushon wrote:
>>     I updated the webrev with the suggested changes to the diagnostic
>>     text:
>>
>>     http://cr.openjdk.java.net/~cushon/8220632/webrev.01/
>>     <http://cr.openjdk.java.net/%7Ecushon/8220632/webrev.01/>
>>
>>     On Fri, Mar 15, 2019 at 11:26 AM Jonathan Gibbons
>>     <jonathan.gibbons at oracle.com
>>     <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>
>>         On 3/15/19 11:21 AM, Liam Miller-Cushon wrote:
>>>         On Fri, Mar 15, 2019 at 11:11 AM Ron Shapiro
>>>         <ronshapiro at google.com <mailto:ronshapiro at google.com>> wrote:
>>>
>>>             Regarding Jonathan's comments in the bug, would it be
>>>             helpful/possible to categorize the types of diagnostics
>>>             not shown? For built-in diagnostics we could try to
>>>             group (maybe just the popular ones?) by their key?
>>>
>>>             42 symbols could not be found
>>>             15 errors from com.example.proc.ExampleProcessor
>>>             etc
>>>
>>>             ?
>>>
>>>
>>>         It's certainly possible. I think we want to strike a balance
>>>         between providing enough information to help avoid users
>>>         getting stuck when diagnostics are suppressed, but not so
>>>         much information that it's distracting (since hopefully in
>>>         the common case the suppressed diagnostics are not necessary
>>>         to understand the problem).
>>>
>>>         In that specific example, Jon's suggestion to sort the
>>>         non-recoverable diagnostics first (which I intend to follow
>>>         up on JDK-8220691) would avoid suppressing the
>>>         com.example.proc.ExampleProcessor diagnostics entirely.
>>
>>
>>         If we were to provide this extra info, maybe it could/should
>>         be opt-in.? But, I think it is a better use of resources to
>>         make javac more friendly "out of the box" and to print the
>>         more-likely-important messages first, so that users don't
>>         have to wade through too much info.
>>
>>         -- Jon
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/b6800617/attachment-0001.html>

From forax at univ-mlv.fr  Thu Mar 28 22:14:14 2019
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 28 Mar 2019 23:14:14 +0100 (CET)
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <CACA6h9toQu5=bKqkHV4U1=yY6-qDtwCrfR86NbJiAdf=AWwiMQ@mail.gmail.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>
 <CACA6h9toQu5=bKqkHV4U1=yY6-qDtwCrfR86NbJiAdf=AWwiMQ@mail.gmail.com>
Message-ID: <1287209895.949274.1553811254455.JavaMail.zimbra@u-pem.fr>

> De: "Ron Shapiro" <ronshapiro at google.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "jonathan gibbons" <jonathan.gibbons at oracle.com>, "compiler-dev"
> <compiler-dev at openjdk.java.net>
> Envoy?: Jeudi 28 Mars 2019 22:58:00
> Objet: Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
> CompletionFailures

> It's currently being reset by the cached CompletionFailure in ClassFinder - I
> can replace that with a method call that resets the supplier and then nulls the
> diagnostic. Suggestions on a method name for this?

resetDiagnostic() ? 

> Does this complicate the API of this type?

yes, but i believe the complexity comes from the fact you want lazy loading thus it's not a plain data type anymore. 

R?mi 

> On Thu, Mar 28, 2019 at 5:51 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> Hi Ron,
>> In Symbol.java, having the field 'diag' being public means that you can access
>> to the object without calling the getter so without calling the supplier.
>> I also think that the supplier should not be public too.

>> regards,
>> R?mi

>>> De: "Ron Shapiro" < [ mailto:ronshapiro at google.com | ronshapiro at google.com ] >
>>> ?: "jonathan gibbons" < [ mailto:jonathan.gibbons at oracle.com |
>>> jonathan.gibbons at oracle.com ] >
>>> Cc: "compiler-dev" < [ mailto:compiler-dev at openjdk.java.net |
>>> compiler-dev at openjdk.java.net ] >
>>> Envoy?: Mercredi 27 Mars 2019 18:46:09
>>> Objet: Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
>>> CompletionFailures

>>> I missed a few cases earlier - see this updated webrev: [
>>> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/ |
>>> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/ ]

>>> On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons < [
>>> mailto:jonathan.gibbons at oracle.com | jonathan.gibbons at oracle.com ] > wrote:

>>>> Looks OK to me, especially the similarity to JDK-8215368

>>>> -- Jon

>>>> On 03/19/2019 03:37 PM, Ron Shapiro wrote:

>>>>> Hi,

>>>>> This is a small change that avoids eagerly creating JCDiagnostic for
>>>>> CompletionFailures.

>>>>> webrev: [ http://cr.openjdk.java.net/%7Eronsh/8221118/webrev.00/ |
>>>>> http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/ ]
>>>>> bug: [ https://bugs.openjdk.java.net/browse/JDK-8221118 |
>>>>> https://bugs.openjdk.java.net/browse/JDK-8221118 ]

>>>>> Thanks,
>>>>> Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/f7f3caff/attachment.html>

From ronshapiro at google.com  Thu Mar 28 22:30:25 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Thu, 28 Mar 2019 18:30:25 -0400
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <1287209895.949274.1553811254455.JavaMail.zimbra@u-pem.fr>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>
 <CACA6h9toQu5=bKqkHV4U1=yY6-qDtwCrfR86NbJiAdf=AWwiMQ@mail.gmail.com>
 <1287209895.949274.1553811254455.JavaMail.zimbra@u-pem.fr>
Message-ID: <CACA6h9ue=QMSRbpLbxkAKKb2oeCFENqWRs5x-OEG5s6pV4EbMw@mail.gmail.com>

Here's an updated webrev with resetDiagnostic():
http://cr.openjdk.java.net/~ronsh/8221118/webrev.04/

On Thu, Mar 28, 2019 at 6:14 PM <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *De: *"Ron Shapiro" <ronshapiro at google.com>
> *?: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"jonathan gibbons" <jonathan.gibbons at oracle.com>, "compiler-dev" <
> compiler-dev at openjdk.java.net>
> *Envoy?: *Jeudi 28 Mars 2019 22:58:00
> *Objet: *Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
> CompletionFailures
>
> It's currently being reset by the cached CompletionFailure in ClassFinder
> - I can replace that with a method call that resets the supplier and then
> nulls the diagnostic. Suggestions on a method name for this?
>
>
> resetDiagnostic() ?
>
> Does this complicate the API of this type?
>
>
> yes, but i believe the complexity comes from the fact you want lazy
> loading thus it's not a plain data type anymore.
>
> R?mi
>
>
> On Thu, Mar 28, 2019 at 5:51 PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Hi Ron,
>> In Symbol.java, having the field 'diag' being public means that you can
>> access to the object without calling the getter so without calling the
>> supplier.
>> I also think that the supplier should not be public too.
>>
>> regards,
>> R?mi
>>
>> ------------------------------
>>
>> *De: *"Ron Shapiro" <ronshapiro at google.com>
>> *?: *"jonathan gibbons" <jonathan.gibbons at oracle.com>
>> *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>> *Envoy?: *Mercredi 27 Mars 2019 18:46:09
>> *Objet: *Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
>> CompletionFailures
>>
>> I missed a few cases earlier - see this updated webrev:
>> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/
>>
>> On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> Looks OK to me, especially the similarity to JDK-8215368
>>>
>>> -- Jon
>>>
>>> On 03/19/2019 03:37 PM, Ron Shapiro wrote:
>>>
>>> Hi,
>>>
>>> This is a small change that avoids eagerly creating JCDiagnostic for
>>> CompletionFailures.
>>>
>>> webrev: http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8221118
>>>
>>> Thanks,
>>> Ron
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/ea2e95c7/attachment.html>

From forax at univ-mlv.fr  Thu Mar 28 22:42:33 2019
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 28 Mar 2019 23:42:33 +0100 (CET)
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <CACA6h9ue=QMSRbpLbxkAKKb2oeCFENqWRs5x-OEG5s6pV4EbMw@mail.gmail.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>
 <CACA6h9toQu5=bKqkHV4U1=yY6-qDtwCrfR86NbJiAdf=AWwiMQ@mail.gmail.com>
 <1287209895.949274.1553811254455.JavaMail.zimbra@u-pem.fr>
 <CACA6h9ue=QMSRbpLbxkAKKb2oeCFENqWRs5x-OEG5s6pV4EbMw@mail.gmail.com>
Message-ID: <1592300395.950140.1553812953515.JavaMail.zimbra@u-pem.fr>

Looks good to me. 

R?mi 

> De: "Ron Shapiro" <ronshapiro at google.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "jonathan gibbons" <jonathan.gibbons at oracle.com>, "compiler-dev"
> <compiler-dev at openjdk.java.net>
> Envoy?: Jeudi 28 Mars 2019 23:30:25
> Objet: Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
> CompletionFailures

> Here's an updated webrev with resetDiagnostic(): [
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.04/ |
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.04/ ]

> On Thu, Mar 28, 2019 at 6:14 PM < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr
> ] > wrote:

>>> De: "Ron Shapiro" < [ mailto:ronshapiro at google.com | ronshapiro at google.com ] >
>>> ?: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "jonathan gibbons" < [ mailto:jonathan.gibbons at oracle.com |
>>> jonathan.gibbons at oracle.com ] >, "compiler-dev" < [
>>> mailto:compiler-dev at openjdk.java.net | compiler-dev at openjdk.java.net ] >
>>> Envoy?: Jeudi 28 Mars 2019 22:58:00
>>> Objet: Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
>>> CompletionFailures

>>> It's currently being reset by the cached CompletionFailure in ClassFinder - I
>>> can replace that with a method call that resets the supplier and then nulls the
>>> diagnostic. Suggestions on a method name for this?

>> resetDiagnostic() ?

>>> Does this complicate the API of this type?

>> yes, but i believe the complexity comes from the fact you want lazy loading thus
>> it's not a plain data type anymore.

>> R?mi

>>> On Thu, Mar 28, 2019 at 5:51 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
>>> forax at univ-mlv.fr ] > wrote:

>>>> Hi Ron,
>>>> In Symbol.java, having the field 'diag' being public means that you can access
>>>> to the object without calling the getter so without calling the supplier.
>>>> I also think that the supplier should not be public too.

>>>> regards,
>>>> R?mi

>>>>> De: "Ron Shapiro" < [ mailto:ronshapiro at google.com | ronshapiro at google.com ] >
>>>>> ?: "jonathan gibbons" < [ mailto:jonathan.gibbons at oracle.com |
>>>>> jonathan.gibbons at oracle.com ] >
>>>>> Cc: "compiler-dev" < [ mailto:compiler-dev at openjdk.java.net |
>>>>> compiler-dev at openjdk.java.net ] >
>>>>> Envoy?: Mercredi 27 Mars 2019 18:46:09
>>>>> Objet: Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
>>>>> CompletionFailures

>>>>> I missed a few cases earlier - see this updated webrev: [
>>>>> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/ |
>>>>> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/ ]

>>>>> On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons < [
>>>>> mailto:jonathan.gibbons at oracle.com | jonathan.gibbons at oracle.com ] > wrote:

>>>>>> Looks OK to me, especially the similarity to JDK-8215368

>>>>>> -- Jon

>>>>>> On 03/19/2019 03:37 PM, Ron Shapiro wrote:

>>>>>>> Hi,

>>>>>>> This is a small change that avoids eagerly creating JCDiagnostic for
>>>>>>> CompletionFailures.

>>>>>>> webrev: [ http://cr.openjdk.java.net/%7Eronsh/8221118/webrev.00/ |
>>>>>>> http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/ ]
>>>>>>> bug: [ https://bugs.openjdk.java.net/browse/JDK-8221118 |
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8221118 ]

>>>>>>> Thanks,
>>>>>>> Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/8497cdd2/attachment-0001.html>

From david.holmes at oracle.com  Thu Mar 28 23:54:06 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Mar 2019 09:54:06 +1000
Subject: RFC: Make test failed because of the locale LANG
In-Reply-To: <f3415f7c-224a-3abd-a3b5-dc912b60fbac@oracle.com>
References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn>
 <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com>
 <f3415f7c-224a-3abd-a3b5-dc912b60fbac@oracle.com>
Message-ID: <d0bb1f8e-5c40-15e8-f762-5e3b1c200a2c@oracle.com>

On 29/03/2019 1:59 am, Naoto Sato wrote:
> Hi,
> 
> I don't think there is any *official* rule for the regression tests to 
> succeed in any locale, but if the test case is locale sensitive such as 
> in this case, I'd suggest it should correctly specify the locale 
> beforehand, or quit gracefully in general.
> 
> For this specific case, I'd suggest not set the environment variable (as 
> it won't work with Windows), using runtime system properties 
> (user.language/user.country) would help.

Which specific case are you referring to? :)

Given there are well over a thousand failures in total I think we need 
to set a reasonable initial locale as part of the test setup. Many of 
the hotspot tests check actual and expected output and we, in general, 
have no idea what kinds of output may be subject to locale specific changes.

Cheers,
David

> Naoto
> 
> On 3/27/19 10:47 PM, David Holmes wrote:
>> Hi Jing,
>>
>> On 28/03/2019 3:22 pm, Jing Tian wrote:
>>> Hi,
>>>
>>> When I am doing the 'make test'.If the local LANG is set as 
>>> 'zh_CN.UTF-8', Test cases will have a lot of error messages.
>>>
>>> ==============================
>>> Test summary
>>> ==============================
>>> ??? TEST????????????????????????????????????????????? TOTAL? PASS 
>>> FAIL ERROR
>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2 0 <<
>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7 0 <<
>>> ?>> jtreg:test/langtools:tier1???????????????????????? 3922 2470 
>>> 1450???? 2 <<
>>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0     
>>> 0???? 0
>>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0     
>>> 0???? 0
>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 29 0 <<
>>> ?>> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 <<
>>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 0???? 0
>>> ?>> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1 0 <<
>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 36 0 <<
>>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0     
>>> 0???? 0
>>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0     
>>> 0???? 0
>>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0     
>>> 0???? 0
>>> ==============================
>>
>> Given most of these are not hotspot issues and given the number of 
>> failures, I think this is something that would need to be discussed 
>> much more broadly. So I've cc'd core-libs-dev and compiler-dev. I 
>> recall there was a very recent discussion regarding some tests failing 
>> for the same reason, but don't recall the outcome.
>>
>> David
>> -----
>>
>>> On the same machine,when i set LANG=en_US.UTF-8.
>>>
>>> ==============================
>>> Test summary
>>> ==============================
>>> ??? TEST????????????????????????????????????????????? TOTAL? PASS 
>>> FAIL ERROR
>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2 0 <<
>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 19 5 <<
>>> ??? jtreg:test/langtools:tier1???????????????????????? 3920 3920 0???? 0
>>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0     
>>> 0???? 0
>>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0     
>>> 0???? 0
>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 31 7 <<
>>> ??? jtreg:test/langtools:tier2?????????????????????????? 11 11 0???? 0
>>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 0???? 0
>>> ??? jtreg:test/jaxp:tier2?????????????????????????????? 438 438 0???? 0
>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 37 0 <<
>>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0     
>>> 0???? 0
>>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0     
>>> 0???? 0
>>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0     
>>> 0???? 0
>>>
>>>
>>> By comparison we can find, lots of(1000+) langtools tests will get 
>>> fail, and other(about 30+, exclude some X11 and sanity that
>>>
>>> result problem) test cases will also fail because of local LANG.
>>>
>>>
>>> such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java,
>>>
>>> shouldContain("Error: Could not find or load main class " + CLASSNAME)
>>>
>>>
>>> When in the zh_CN.UTF-8 environment, because some of the output 
>>> information is changed to Chinese by some properties file,
>>>
>>> the English cannot be matched, which will result in an fail.
>>>
>>> When I set? LANG=en_US/LC_ALL=C, this test will pass.
>>>
>>>
>>> I think there are some possible solutions.
>>>
>>>
>>> 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this 
>>> modification is more violent because he will affect all test cases.
>>>
>>>
>>> 2.We modify each individual test?E.g 
>>> test/hotspot/jtreg/compiler/c2/Test8062950.java
>>>
>>> diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java
>>> ??package compiler.c2;
>>> ??import jdk.test.lib.process.ProcessTools;
>>> +import java.util.Map;
>>> +import jdk.test.lib.process.OutputAnalyzer;
>>>
>>> ??public class Test8062950 {
>>> ????? private static final String CLASSNAME = "DoesNotExist";
>>> ????? public static void main(String[] args) throws Exception {
>>> - ProcessTools.executeTestJvm("-Xcomp",
>>> - "-XX:-TieredCompilation",
>>> - "-XX:-UseOptoBiasInlining",
>>> - CLASSNAME)
>>> - .shouldHaveExitValue(1)
>>> -??????????????????? .shouldContain("Error: Could not find or load 
>>> main class " + CLASSNAME)
>>> -??????????????????? .shouldNotContain("A fatal error has been 
>>> detected")
>>> -??????????????????? .shouldNotContain("Internal Error")
>>> -??????????????????? .shouldNotContain("HotSpot Virtual Machine Error");
>>> +??????? final ProcessBuilder pb = 
>>> ProcessTools.createJavaProcessBuilder(true,
>>> + "-Xcomp",
>>> + "-XX:-TieredCompilation",
>>> + "-XX:-UseOptoBiasInlining",
>>> + CLASSNAME);
>>> +??????? final Map<String, String> env = pb.environment();
>>> +??????? env.put("LC_ALL", "en_US.UTF-8");
>>> +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>> + output.shouldHaveExitValue(1);
>>> +??????? output.shouldContain("Error: Could not find or load main 
>>> class " + CLASSNAME);
>>> +??????? output.shouldNotContain("A fatal error has been detected");
>>> +??????? output.shouldNotContain("Internal Error");
>>> +??????? output.shouldNotContain("HotSpot Virtual Machine Error");
>>> }
>>> ??}
>>>
>>> But I don't know if this will change the test program too much, 
>>> because the related problems are a lot in langtools tests.
>>>
>>>
>>> 3.And i find that there is a function can judge the locale
>>>
>>> ??if (!isEnglishLocale()) { // only english version
>>> return;
>>> ??}
>>>
>>> But in this case, I think in many test cases, we may not be able to 
>>> return so directly, because some test cases may have other test 
>>> purposes.
>>>
>>>
>>> So I don't know if you have any ideas or some suggestions to solve 
>>> the problem that the output information and English do not match in this
>>>
>>> non-English environment.
>>>
>>>
>>> Cheers,
>>>
>>> Jing Tian
>>>
>>>
>>>
>>>

From cushon at google.com  Fri Mar 29 00:25:57 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 28 Mar 2019 17:25:57 -0700
Subject: RFR: 8220632: Suggest recompiling with a larger value of
 -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
In-Reply-To: <dda80062-0e1a-ae25-fdca-46c9eb560778@oracle.com>
References: <CAL4QsguvN7yOp0HjFcyhMBnAhuxgGLwX_C+gxZe35Uc+5zNELA@mail.gmail.com>
 <a5bb9003-e856-6716-0a40-06d57715f7fb@oracle.com>
 <CAL4QsgtZJwd_xvG1UCG+vSdK4Wi7Kng8to8XXkh2j2a15EHgCg@mail.gmail.com>
 <67bf3c7d-56aa-d843-865f-cfe186d17006@oracle.com>
 <CAL4QsgtePR5NKg1ohfDYwPuBatRgcHkDHnY=FAz5vT1XGyHJiQ@mail.gmail.com>
 <204bf859-cf0b-85c3-df2d-3c160f1d4fa6@oracle.com>
 <CACA6h9t2k73yLPVaG+0A1eAmiLAkq8r=MaA4tov6XD81wjjArw@mail.gmail.com>
 <CAL4Qsgu5U_GMwtpddhz5_7DAyVep8qPvJFNman2E88BqmBb-WQ@mail.gmail.com>
 <bcceef10-12c0-307a-56f7-332c4b97552f@oracle.com>
 <CAL4Qsgv5Qk=61BY7=Zhtp-CXepu8mqHK-N+GMr_rk-_SEwQtZw@mail.gmail.com>
 <09b9ebcf-cb6e-416f-44f7-deb0b0659541@oracle.com>
 <CAL4Qsgs6zwBYy5x76yfXUHcz+4mTc3Z3-zJx_-ZWiTJg6Ph4aw@mail.gmail.com>
 <dda80062-0e1a-ae25-fdca-46c9eb560778@oracle.com>
Message-ID: <CAL4QsgutaNy7b=8vT5srVVYBz-iq4zvsqmUdaGrdpRtsctRTNw@mail.gmail.com>

On Thu, Mar 28, 2019 at 2:58 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> In the test-description comment block, the one beginning @test, the
> recommended style is to not start the comment with "/**" because it is not
> a documentation comment.
>
Thanks, I fixed the style issue and pushed as:
http://hg.openjdk.java.net/jdk/jdk/rev/9a8fe0bc38c3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/2d87b30f/attachment.html>

From naoto.sato at oracle.com  Fri Mar 29 01:23:29 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 28 Mar 2019 18:23:29 -0700
Subject: RFC: Make test failed because of the locale LANG
In-Reply-To: <d0bb1f8e-5c40-15e8-f762-5e3b1c200a2c@oracle.com>
References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn>
 <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com>
 <f3415f7c-224a-3abd-a3b5-dc912b60fbac@oracle.com>
 <d0bb1f8e-5c40-15e8-f762-5e3b1c200a2c@oracle.com>
Message-ID: <794486e3-0a12-7605-2be4-abd3916d030f@oracle.com>

On 3/28/19 4:54 PM, David Holmes wrote:
> On 29/03/2019 1:59 am, Naoto Sato wrote:
>> Hi,
>>
>> I don't think there is any *official* rule for the regression tests to 
>> succeed in any locale, but if the test case is locale sensitive such 
>> as in this case, I'd suggest it should correctly specify the locale 
>> beforehand, or quit gracefully in general.
>>
>> For this specific case, I'd suggest not set the environment variable 
>> (as it won't work with Windows), using runtime system properties 
>> (user.language/user.country) would help.
> 
> Which specific case are you referring to? :)

I was referring to the test case below, Test8062950.java, where it 
issues "env.put("LC_ALL", "en_US.UTF-8")". Instead I would recommend 
"-Duser.language=en -Duser.country=US" runtime system property.

> 
> Given there are well over a thousand failures in total I think we need 
> to set a reasonable initial locale as part of the test setup. Many of 
> the hotspot tests check actual and expected output and we, in general, 
> have no idea what kinds of output may be subject to locale specific > changes.

Agree. Specifying a reasonable default locale would not be a bad idea.

Naoto

> 
> Cheers,
> David
> 
>> Naoto
>>
>> On 3/27/19 10:47 PM, David Holmes wrote:
>>> Hi Jing,
>>>
>>> On 28/03/2019 3:22 pm, Jing Tian wrote:
>>>> Hi,
>>>>
>>>> When I am doing the 'make test'.If the local LANG is set as 
>>>> 'zh_CN.UTF-8', Test cases will have a lot of error messages.
>>>>
>>>> ==============================
>>>> Test summary
>>>> ==============================
>>>> ??? TEST????????????????????????????????????????????? TOTAL? PASS 
>>>> FAIL ERROR
>>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2 0 <<
>>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7 0 <<
>>>> ?>> jtreg:test/langtools:tier1???????????????????????? 3922 2470 
>>>> 1450???? 2 <<
>>>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0 0???? 0
>>>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0 0???? 0
>>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 29 
>>>> 0 <<
>>>> ?>> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 <<
>>>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 0???? 0
>>>> ?>> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1 0 <<
>>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 36 
>>>> 0 <<
>>>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0 0???? 0
>>>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0 0???? 0
>>>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0 0???? 0
>>>> ==============================
>>>
>>> Given most of these are not hotspot issues and given the number of 
>>> failures, I think this is something that would need to be discussed 
>>> much more broadly. So I've cc'd core-libs-dev and compiler-dev. I 
>>> recall there was a very recent discussion regarding some tests 
>>> failing for the same reason, but don't recall the outcome.
>>>
>>> David
>>> -----
>>>
>>>> On the same machine,when i set LANG=en_US.UTF-8.
>>>>
>>>> ==============================
>>>> Test summary
>>>> ==============================
>>>> ??? TEST????????????????????????????????????????????? TOTAL? PASS 
>>>> FAIL ERROR
>>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2 0 <<
>>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 19 
>>>> 5 <<
>>>> ??? jtreg:test/langtools:tier1???????????????????????? 3920 3920 
>>>> 0???? 0
>>>> ??? jtreg:test/nashorn:tier1????????????????????????????? 0 0 0???? 0
>>>> ??? jtreg:test/jaxp:tier1???????????????????????????????? 0 0 0???? 0
>>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 31 
>>>> 7 <<
>>>> ??? jtreg:test/langtools:tier2?????????????????????????? 11 11 0???? 0
>>>> ??? jtreg:test/nashorn:tier2???????????????????????????? 35 35 0???? 0
>>>> ??? jtreg:test/jaxp:tier2?????????????????????????????? 438 438 0???? 0
>>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 37 
>>>> 0 <<
>>>> ??? jtreg:test/langtools:tier3??????????????????????????? 0 0 0???? 0
>>>> ??? jtreg:test/nashorn:tier3????????????????????????????? 0 0 0???? 0
>>>> ??? jtreg:test/jaxp:tier3???????????????????????????????? 0 0 0???? 0
>>>>
>>>>
>>>> By comparison we can find, lots of(1000+) langtools tests will get 
>>>> fail, and other(about 30+, exclude some X11 and sanity that
>>>>
>>>> result problem) test cases will also fail because of local LANG.
>>>>
>>>>
>>>> such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java,
>>>>
>>>> shouldContain("Error: Could not find or load main class " + CLASSNAME)
>>>>
>>>>
>>>> When in the zh_CN.UTF-8 environment, because some of the output 
>>>> information is changed to Chinese by some properties file,
>>>>
>>>> the English cannot be matched, which will result in an fail.
>>>>
>>>> When I set? LANG=en_US/LC_ALL=C, this test will pass.
>>>>
>>>>
>>>> I think there are some possible solutions.
>>>>
>>>>
>>>> 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this 
>>>> modification is more violent because he will affect all test cases.
>>>>
>>>>
>>>> 2.We modify each individual test?E.g 
>>>> test/hotspot/jtreg/compiler/c2/Test8062950.java
>>>>
>>>> diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java
>>>> ??package compiler.c2;
>>>> ??import jdk.test.lib.process.ProcessTools;
>>>> +import java.util.Map;
>>>> +import jdk.test.lib.process.OutputAnalyzer;
>>>>
>>>> ??public class Test8062950 {
>>>> ????? private static final String CLASSNAME = "DoesNotExist";
>>>> ????? public static void main(String[] args) throws Exception {
>>>> - ProcessTools.executeTestJvm("-Xcomp",
>>>> - "-XX:-TieredCompilation",
>>>> - "-XX:-UseOptoBiasInlining",
>>>> - CLASSNAME)
>>>> - .shouldHaveExitValue(1)
>>>> -??????????????????? .shouldContain("Error: Could not find or load 
>>>> main class " + CLASSNAME)
>>>> -??????????????????? .shouldNotContain("A fatal error has been 
>>>> detected")
>>>> -??????????????????? .shouldNotContain("Internal Error")
>>>> -??????????????????? .shouldNotContain("HotSpot Virtual Machine 
>>>> Error");
>>>> +??????? final ProcessBuilder pb = 
>>>> ProcessTools.createJavaProcessBuilder(true,
>>>> + "-Xcomp",
>>>> + "-XX:-TieredCompilation",
>>>> + "-XX:-UseOptoBiasInlining",
>>>> + CLASSNAME);
>>>> +??????? final Map<String, String> env = pb.environment();
>>>> +??????? env.put("LC_ALL", "en_US.UTF-8");
>>>> +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>> + output.shouldHaveExitValue(1);
>>>> +??????? output.shouldContain("Error: Could not find or load main 
>>>> class " + CLASSNAME);
>>>> +??????? output.shouldNotContain("A fatal error has been detected");
>>>> +??????? output.shouldNotContain("Internal Error");
>>>> +??????? output.shouldNotContain("HotSpot Virtual Machine Error");
>>>> }
>>>> ??}
>>>>
>>>> But I don't know if this will change the test program too much, 
>>>> because the related problems are a lot in langtools tests.
>>>>
>>>>
>>>> 3.And i find that there is a function can judge the locale
>>>>
>>>> ??if (!isEnglishLocale()) { // only english version
>>>> return;
>>>> ??}
>>>>
>>>> But in this case, I think in many test cases, we may not be able to 
>>>> return so directly, because some test cases may have other test 
>>>> purposes.
>>>>
>>>>
>>>> So I don't know if you have any ideas or some suggestions to solve 
>>>> the problem that the output information and English do not match in 
>>>> this
>>>>
>>>> non-English environment.
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Jing Tian
>>>>
>>>>
>>>>
>>>>

From jingtian at loongson.cn  Fri Mar 29 02:20:29 2019
From: jingtian at loongson.cn (Jing Tian)
Date: Fri, 29 Mar 2019 10:20:29 +0800
Subject: RFC: Make test failed because of the locale LANG
In-Reply-To: <794486e3-0a12-7605-2be4-abd3916d030f@oracle.com>
References: <5fd4d748-c9cf-3779-3a65-b7c7547ab9ce@loongson.cn>
 <396490c6-9917-2306-c288-2de5ec92bdc9@oracle.com>
 <f3415f7c-224a-3abd-a3b5-dc912b60fbac@oracle.com>
 <d0bb1f8e-5c40-15e8-f762-5e3b1c200a2c@oracle.com>
 <794486e3-0a12-7605-2be4-abd3916d030f@oracle.com>
Message-ID: <ae88b95c-1241-7cd5-b535-c1eb42614b62@loongson.cn>

Hi,
First of all, I want to say sorry . Because of the problems with my mail 
client, this typography looks bad.I found the typography so bad on the 
webpage today. T_T
These suggestions I just want to show some ideas. We can't make changes 
in each test case, because it is too much, and the changes I made are 
not good.

The following is the fail test cases because of the locale(exclude some 
X11 fail and sanity fail, because some of fails are in the list because 
of them):
java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java
java/util/logging/LocalizedLevelName.java
java/util/logging/SimpleFormatterFormat.java
sun/util/logging/SourceClassName.java
tools/pack200/DeprecatePack200.java
java/security/KeyStore/PKCS12/KeytoolReaderP12Test.java
java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
javax/security/auth/login/JAASConfigSyntaxCheck/JAASConfigSyntaxTest.java
javax/security/auth/login/LoginContext/DynamicConfigurationTest.java
jdk/security/logging/TestSecurityPropertyModificationLog.java
jdk/security/logging/TestTLSHandshakeLog.java
jdk/security/logging/TestX509CertificateLog.java
jdk/security/logging/TestX509ValidationLog.java
tools/jar/DeprecateOptionN.java
tools/jar/compat/CLICompatibility.java
tools/jar/mmrjar/Basic.java
tools/jar/modularJar/Basic.java
tools/jar/multiRelease/ApiValidatorTest.java
tools/jar/multiRelease/Basic.java
tools/jar/multiRelease/Basic1.java
tools/jlink/JLinkNegativeTest.java
tools/jlink/JLinkOptionsTest.java
tools/jlink/JLinkPluginsTest.java
tools/jlink/JLinkTest.java
tools/jlink/bindservices/SuggestProviders.java
tools/jlink/plugins/LegalFilePluginTest.java
tools/jmod/JmodNegativeTest.java
tools/jmod/JmodTest.java
tools/launcher/FXLauncherTest.java
tools/launcher/InfoStreams.java
tools/launcher/SourceMode.java
tools/launcher/TestSpecialArgs.java
javax/xml/jaxp/functional/org/xml/sax/ptests/EHFatalTest.java
test/hotspot/jtreg/compiler/c2/Test8062950.java
test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java

The following is the langtools fail test cases.(1450/3922)
jdk/javadoc/doclet/AccessAsciiArt/AccessAsciiArt.java
jdk/javadoc/doclet/AccessFrameTitle/AccessFrameTitle.java
jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java
jdk/javadoc/doclet/AuthorDD/AuthorDD.java
jdk/javadoc/doclet/MetaTag/MetaTag.java
jdk/javadoc/doclet/WindowTitles/WindowTitles.java
jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java
jdk/javadoc/doclet/testAnchorNames/TestAnchorNames.java
jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java
jdk/javadoc/doclet/testAuthor/TestAuthor.java
jdk/javadoc/doclet/testBadPackageFileInJar/TestBadPackageFileInJar.java
jdk/javadoc/doclet/testCharsetDocencodingOptions/TestCharsetDocencodingOptions.java 

jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java
jdk/javadoc/doclet/testClassDocCatalog/TestClassDocCatalog.java
..........

I don't know how to solve this problem is a better solution.

? 2019/3/29 9:23, naoto.sato at oracle.com ??:
> On 3/28/19 4:54 PM, David Holmes wrote:
>> On 29/03/2019 1:59 am, Naoto Sato wrote:
>>> Hi,
>>>
>>> I don't think there is any *official* rule for the regression tests 
>>> to succeed in any locale, but if the test case is locale sensitive 
>>> such as in this case, I'd suggest it should correctly specify the 
>>> locale beforehand, or quit gracefully in general.
>>>
>>> For this specific case, I'd suggest not set the environment variable 
>>> (as it won't work with Windows), using runtime system properties 
>>> (user.language/user.country) would help.
>>
>> Which specific case are you referring to? :)
>
> I was referring to the test case below, Test8062950.java, where it 
> issues "env.put("LC_ALL", "en_US.UTF-8")". Instead I would recommend 
> "-Duser.language=en -Duser.country=US" runtime system property.
>
>>
>> Given there are well over a thousand failures in total I think we 
>> need to set a reasonable initial locale as part of the test setup. 
>> Many of the hotspot tests check actual and expected output and we, in 
>> general, have no idea what kinds of output may be subject to locale 
>> specific > changes.
>
> Agree. Specifying a reasonable default locale would not be a bad idea.
>
> Naoto
>
>>
>> Cheers,
>> David
>>
>>> Naoto
>>>
>>> On 3/27/19 10:47 PM, David Holmes wrote:
>>>> Hi Jing,
>>>>
>>>> On 28/03/2019 3:22 pm, Jing Tian wrote:
>>>>> Hi,
>>>>>
>>>>> When I am doing the 'make test'.If the local LANG is set as 
>>>>> 'zh_CN.UTF-8', Test cases will have a lot of error messages.
>>>>>
>>>>> ==============================
>>>>> Test summary
>>>>> ==============================
>>>>> ??? TEST TOTAL? PASS FAIL ERROR
>>>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1373 1371 2 
>>>>> 0 <<
>>>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1860 7 
>>>>> 0 <<
>>>>> ?>> jtreg:test/langtools:tier1???????????????????????? 3922 2470 
>>>>> 1450???? 2 <<
>>>>> ??? jtreg:test/nashorn:tier1 0 0 0???? 0
>>>>> ??? jtreg:test/jaxp:tier1 0 0 0???? 0
>>>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3334 3305 
>>>>> 29 0 <<
>>>>> ?>> jtreg:test/langtools:tier2 11???? 9???? 2???? 0 <<
>>>>> ??? jtreg:test/nashorn:tier2 35 35 0???? 0
>>>>> ?>> jtreg:test/jaxp:tier2?????????????????????????????? 438 437 1 
>>>>> 0 <<
>>>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1068 
>>>>> 36 0 <<
>>>>> ??? jtreg:test/langtools:tier3 0 0 0???? 0
>>>>> ??? jtreg:test/nashorn:tier3 0 0 0???? 0
>>>>> ??? jtreg:test/jaxp:tier3 0 0 0???? 0
>>>>> ==============================
>>>>
>>>> Given most of these are not hotspot issues and given the number of 
>>>> failures, I think this is something that would need to be discussed 
>>>> much more broadly. So I've cc'd core-libs-dev and compiler-dev. I 
>>>> recall there was a very recent discussion regarding some tests 
>>>> failing for the same reason, but don't recall the outcome.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> On the same machine,when i set LANG=en_US.UTF-8.
>>>>>
>>>>> ==============================
>>>>> Test summary
>>>>> ==============================
>>>>> ??? TEST TOTAL? PASS FAIL ERROR
>>>>> ?>> jtreg:test/hotspot/jtreg:tier1???????????????????? 1388 1386 2 
>>>>> 0 <<
>>>>> ?>> jtreg:test/jdk:tier1?????????????????????????????? 1867 1843 
>>>>> 19 5 <<
>>>>> ??? jtreg:test/langtools:tier1 3920 3920 0???? 0
>>>>> ??? jtreg:test/nashorn:tier1 0 0 0???? 0
>>>>> ??? jtreg:test/jaxp:tier1 0 0 0???? 0
>>>>> ?>> jtreg:test/jdk:tier2?????????????????????????????? 3328 3290 
>>>>> 31 7 <<
>>>>> ??? jtreg:test/langtools:tier2 11 11 0???? 0
>>>>> ??? jtreg:test/nashorn:tier2 35 35 0???? 0
>>>>> ??? jtreg:test/jaxp:tier2 438 438 0???? 0
>>>>> ?>> jtreg:test/jdk:tier3?????????????????????????????? 1104 1067 
>>>>> 37 0 <<
>>>>> ??? jtreg:test/langtools:tier3 0 0 0???? 0
>>>>> ??? jtreg:test/nashorn:tier3 0 0 0???? 0
>>>>> ??? jtreg:test/jaxp:tier3 0 0 0???? 0
>>>>>
>>>>>
>>>>> By comparison we can find, lots of(1000+) langtools tests will get 
>>>>> fail, and other(about 30+, exclude some X11 and sanity that
>>>>>
>>>>> result problem) test cases will also fail because of local LANG.
>>>>>
>>>>>
>>>>> such as in the test/hotspot/jtreg/compiler/c2/Test8062950.java,
>>>>>
>>>>> shouldContain("Error: Could not find or load main class " + 
>>>>> CLASSNAME)
>>>>>
>>>>>
>>>>> When in the zh_CN.UTF-8 environment, because some of the output 
>>>>> information is changed to Chinese by some properties file,
>>>>>
>>>>> the English cannot be matched, which will result in an fail.
>>>>>
>>>>> When I set? LANG=en_US/LC_ALL=C, this test will pass.
>>>>>
>>>>>
>>>>> I think there are some possible solutions.
>>>>>
>>>>>
>>>>> 1.we set LC_ALL=C/LANG=EN_us in the Runtests.gmk, but this 
>>>>> modification is more violent because he will affect all test cases.
>>>>>
>>>>>
>>>>> 2.We modify each individual test?E.g 
>>>>> test/hotspot/jtreg/compiler/c2/Test8062950.java
>>>>>
>>>>> diff -r 0421d49b6217 test/hotspot/jtreg/compiler/c2/Test8062950.java
>>>>> ??package compiler.c2;
>>>>> ??import jdk.test.lib.process.ProcessTools;
>>>>> +import java.util.Map;
>>>>> +import jdk.test.lib.process.OutputAnalyzer;
>>>>>
>>>>> ??public class Test8062950 {
>>>>> ????? private static final String CLASSNAME = "DoesNotExist";
>>>>> ????? public static void main(String[] args) throws Exception {
>>>>> - ProcessTools.executeTestJvm("-Xcomp",
>>>>> - "-XX:-TieredCompilation",
>>>>> - "-XX:-UseOptoBiasInlining",
>>>>> - CLASSNAME)
>>>>> - .shouldHaveExitValue(1)
>>>>> -??????????????????? .shouldContain("Error: Could not find or load 
>>>>> main class " + CLASSNAME)
>>>>> -??????????????????? .shouldNotContain("A fatal error has been 
>>>>> detected")
>>>>> -??????????????????? .shouldNotContain("Internal Error")
>>>>> -??????????????????? .shouldNotContain("HotSpot Virtual Machine 
>>>>> Error");
>>>>> +??????? final ProcessBuilder pb = 
>>>>> ProcessTools.createJavaProcessBuilder(true,
>>>>> + "-Xcomp",
>>>>> + "-XX:-TieredCompilation",
>>>>> + "-XX:-UseOptoBiasInlining",
>>>>> + CLASSNAME);
>>>>> +??????? final Map<String, String> env = pb.environment();
>>>>> +??????? env.put("LC_ALL", "en_US.UTF-8");
>>>>> +??????? OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>>> + output.shouldHaveExitValue(1);
>>>>> +??????? output.shouldContain("Error: Could not find or load main 
>>>>> class " + CLASSNAME);
>>>>> +??????? output.shouldNotContain("A fatal error has been detected");
>>>>> +??????? output.shouldNotContain("Internal Error");
>>>>> +??????? output.shouldNotContain("HotSpot Virtual Machine Error");
>>>>> }
>>>>> ??}
>>>>>
>>>>> But I don't know if this will change the test program too much, 
>>>>> because the related problems are a lot in langtools tests.
>>>>>
>>>>>
>>>>> 3.And i find that there is a function can judge the locale
>>>>>
>>>>> ??if (!isEnglishLocale()) { // only english version
>>>>> return;
>>>>> ??}
>>>>>
>>>>> But in this case, I think in many test cases, we may not be able 
>>>>> to return so directly, because some test cases may have other test 
>>>>> purposes.
>>>>>
>>>>>
>>>>> So I don't know if you have any ideas or some suggestions to solve 
>>>>> the problem that the output information and English do not match 
>>>>> in this
>>>>>
>>>>> non-English environment.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Jing Tian
>>>>>
>>>>>
>>>>>
>>>>>



From maurizio.cimadamore at oracle.com  Fri Mar 29 11:39:59 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 29 Mar 2019 11:39:59 +0000
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <1592300395.950140.1553812953515.JavaMail.zimbra@u-pem.fr>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>
 <CACA6h9toQu5=bKqkHV4U1=yY6-qDtwCrfR86NbJiAdf=AWwiMQ@mail.gmail.com>
 <1287209895.949274.1553811254455.JavaMail.zimbra@u-pem.fr>
 <CACA6h9ue=QMSRbpLbxkAKKb2oeCFENqWRs5x-OEG5s6pV4EbMw@mail.gmail.com>
 <1592300395.950140.1553812953515.JavaMail.zimbra@u-pem.fr>
Message-ID: <51d542e5-5d84-d67b-7771-4611d96c5178@oracle.com>

Looks good - for bonus points, you could condense the code a bit - e.g. 
turn this

Supplier<JCDiagnostic> diag =
+??????????????? () -> 
diagFactory.fragment(Fragments.ClassFileNotFound(c.flatname));
 ???????????? return newCompletionFailure(c, diag);

into this:

 ???????????? return newCompletionFailure(c, () -> 
diagFactory.fragment(Fragments.ClassFileNotFound(c.flatname)));


When the local var type used to be JCDiagnostic it was sort of ok, now 
we have all these Supplier<JCDiagnostic> plus a throwaway variable name...

I'll leave this to your judgement.

Maurizio

On 28/03/2019 22:42, forax at univ-mlv.fr wrote:
> Looks good to me.
>
> R?mi
>
> ------------------------------------------------------------------------
>
>     *De: *"Ron Shapiro" <ronshapiro at google.com>
>     *?: *"Remi Forax" <forax at univ-mlv.fr>
>     *Cc: *"jonathan gibbons" <jonathan.gibbons at oracle.com>,
>     "compiler-dev" <compiler-dev at openjdk.java.net>
>     *Envoy?: *Jeudi 28 Mars 2019 23:30:25
>     *Objet: *Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
>     CompletionFailures
>
>     Here's an updated webrev with resetDiagnostic():
>     http://cr.openjdk.java.net/~ronsh/8221118/webrev.04/
>
>     On Thu, Mar 28, 2019 at 6:14 PM <forax at univ-mlv.fr
>     <mailto:forax at univ-mlv.fr>> wrote:
>
>
>
>         ------------------------------------------------------------------------
>
>             *De: *"Ron Shapiro" <ronshapiro at google.com
>             <mailto:ronshapiro at google.com>>
>             *?: *"Remi Forax" <forax at univ-mlv.fr
>             <mailto:forax at univ-mlv.fr>>
>             *Cc: *"jonathan gibbons" <jonathan.gibbons at oracle.com
>             <mailto:jonathan.gibbons at oracle.com>>, "compiler-dev"
>             <compiler-dev at openjdk.java.net
>             <mailto:compiler-dev at openjdk.java.net>>
>             *Envoy?: *Jeudi 28 Mars 2019 22:58:00
>             *Objet: *Re: RFR 8221118: Avoid eagerly creating
>             JCDiagnostic for CompletionFailures
>
>             It's currently being reset by the cached CompletionFailure
>             in ClassFinder - I can replace that with a method call
>             that resets the supplier and then nulls the diagnostic.
>             Suggestions on a method name for this?
>
>
>         resetDiagnostic() ?
>
>             Does this complicate the API of this type?
>
>
>         yes, but i believe the complexity comes from the fact you want
>         lazy loading thus it's not a plain data type anymore.
>
>         R?mi
>
>
>             On Thu, Mar 28, 2019 at 5:51 PM Remi Forax
>             <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>> wrote:
>
>                 Hi Ron,
>                 In Symbol.java, having the field 'diag' being public
>                 means that you can access to the object without
>                 calling the getter so without calling the supplier.
>                 I also think that the supplier should not be public too.
>
>                 regards,
>                 R?mi
>
>                 ------------------------------------------------------------------------
>
>                     *De: *"Ron Shapiro" <ronshapiro at google.com
>                     <mailto:ronshapiro at google.com>>
>                     *?: *"jonathan gibbons"
>                     <jonathan.gibbons at oracle.com
>                     <mailto:jonathan.gibbons at oracle.com>>
>                     *Cc: *"compiler-dev"
>                     <compiler-dev at openjdk.java.net
>                     <mailto:compiler-dev at openjdk.java.net>>
>                     *Envoy?: *Mercredi 27 Mars 2019 18:46:09
>                     *Objet: *Re: RFR 8221118: Avoid eagerly creating
>                     JCDiagnostic for CompletionFailures
>
>                     I missed a few cases earlier - see this updated
>                     webrev:
>                     http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/
>
>                     On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons
>                     <jonathan.gibbons at oracle.com
>                     <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>                         Looks OK to me, especially the similarity to
>                         JDK-8215368
>
>                         -- Jon
>
>
>                         On 03/19/2019 03:37 PM, Ron Shapiro wrote:
>
>                             Hi,
>
>                             This is a small change that avoids eagerly
>                             creating JCDiagnostic for CompletionFailures.
>
>                             webrev:
>                             http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/
>                             <http://cr.openjdk.java.net/%7Eronsh/8221118/webrev.00/>
>                             bug:
>                             https://bugs.openjdk.java.net/browse/JDK-8221118
>
>                             Thanks,
>                             Ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190329/178d7b87/attachment-0001.html>

From ronshapiro at google.com  Fri Mar 29 13:31:54 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Fri, 29 Mar 2019 09:31:54 -0400
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <51d542e5-5d84-d67b-7771-4611d96c5178@oracle.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>
 <CACA6h9toQu5=bKqkHV4U1=yY6-qDtwCrfR86NbJiAdf=AWwiMQ@mail.gmail.com>
 <1287209895.949274.1553811254455.JavaMail.zimbra@u-pem.fr>
 <CACA6h9ue=QMSRbpLbxkAKKb2oeCFENqWRs5x-OEG5s6pV4EbMw@mail.gmail.com>
 <1592300395.950140.1553812953515.JavaMail.zimbra@u-pem.fr>
 <51d542e5-5d84-d67b-7771-4611d96c5178@oracle.com>
Message-ID: <CACA6h9ty8VHWOHVfufMiRJ8sa-UObiVzTKkmpnHntHSP5UCpLA@mail.gmail.com>

Sure thing. Here's that change:
http://cr.openjdk.java.net/~ronsh/8221118/webrev.05/

Thanks for the review!

On Fri, Mar 29, 2019 at 7:40 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Looks good - for bonus points, you could condense the code a bit - e.g.
> turn this
>
> Supplier<JCDiagnostic> diag =
> +                () ->
> diagFactory.fragment(Fragments.ClassFileNotFound(c.flatname));
>              return newCompletionFailure(c, diag);
>
> into this:
>
>              return newCompletionFailure(c, () ->
> diagFactory.fragment(Fragments.ClassFileNotFound(c.flatname)));
>
>
> When the local var type used to be JCDiagnostic it was sort of ok, now we
> have all these Supplier<JCDiagnostic> plus a throwaway variable name...
>
> I'll leave this to your judgement.
>
> Maurizio
> On 28/03/2019 22:42, forax at univ-mlv.fr wrote:
>
> Looks good to me.
>
> R?mi
>
> ------------------------------
>
> *De: *"Ron Shapiro" <ronshapiro at google.com> <ronshapiro at google.com>
> *?: *"Remi Forax" <forax at univ-mlv.fr> <forax at univ-mlv.fr>
> *Cc: *"jonathan gibbons" <jonathan.gibbons at oracle.com>
> <jonathan.gibbons at oracle.com>, "compiler-dev"
> <compiler-dev at openjdk.java.net> <compiler-dev at openjdk.java.net>
> *Envoy?: *Jeudi 28 Mars 2019 23:30:25
> *Objet: *Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
> CompletionFailures
>
> Here's an updated webrev with resetDiagnostic():
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.04/
>
> On Thu, Mar 28, 2019 at 6:14 PM <forax at univ-mlv.fr> wrote:
>
>>
>>
>> ------------------------------
>>
>> *De: *"Ron Shapiro" <ronshapiro at google.com>
>> *?: *"Remi Forax" <forax at univ-mlv.fr>
>> *Cc: *"jonathan gibbons" <jonathan.gibbons at oracle.com>, "compiler-dev" <
>> compiler-dev at openjdk.java.net>
>> *Envoy?: *Jeudi 28 Mars 2019 22:58:00
>> *Objet: *Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
>> CompletionFailures
>>
>> It's currently being reset by the cached CompletionFailure in ClassFinder
>> - I can replace that with a method call that resets the supplier and then
>> nulls the diagnostic. Suggestions on a method name for this?
>>
>>
>> resetDiagnostic() ?
>>
>> Does this complicate the API of this type?
>>
>>
>> yes, but i believe the complexity comes from the fact you want lazy
>> loading thus it's not a plain data type anymore.
>>
>> R?mi
>>
>>
>> On Thu, Mar 28, 2019 at 5:51 PM Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>> Hi Ron,
>>> In Symbol.java, having the field 'diag' being public means that you can
>>> access to the object without calling the getter so without calling the
>>> supplier.
>>> I also think that the supplier should not be public too.
>>>
>>> regards,
>>> R?mi
>>>
>>> ------------------------------
>>>
>>> *De: *"Ron Shapiro" <ronshapiro at google.com>
>>> *?: *"jonathan gibbons" <jonathan.gibbons at oracle.com>
>>> *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>>> *Envoy?: *Mercredi 27 Mars 2019 18:46:09
>>> *Objet: *Re: RFR 8221118: Avoid eagerly creating JCDiagnostic for
>>> CompletionFailures
>>>
>>> I missed a few cases earlier - see this updated webrev:
>>> http://cr.openjdk.java.net/~ronsh/8221118/webrev.01/
>>>
>>> On Tue, Mar 26, 2019 at 4:10 PM Jonathan Gibbons <
>>> jonathan.gibbons at oracle.com> wrote:
>>>
>>>> Looks OK to me, especially the similarity to JDK-8215368
>>>>
>>>> -- Jon
>>>>
>>>> On 03/19/2019 03:37 PM, Ron Shapiro wrote:
>>>>
>>>> Hi,
>>>>
>>>> This is a small change that avoids eagerly creating JCDiagnostic for
>>>> CompletionFailures.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ronsh/8221118/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8221118
>>>>
>>>> Thanks,
>>>> Ron
>>>>
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190329/a1026769/attachment.html>

From ronshapiro at google.com  Fri Mar 29 14:10:23 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Fri, 29 Mar 2019 10:10:23 -0400
Subject: RFR 8220792: JavacFileManager.list() performance
In-Reply-To: <86018eba-aecb-0005-390d-0ce2b662a4df@oracle.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
 <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com>
 <CACA6h9uNhmzqAf=tN33Y-WL9fK-oqmwRDDykP3iZB5WRm88aJg@mail.gmail.com>
 <86018eba-aecb-0005-390d-0ce2b662a4df@oracle.com>
Message-ID: <CACA6h9tjFmmHvbYqXg-v_2EpfwJzh8+-Z3FWn-HvqJ1mZr9fMQ@mail.gmail.com>

- Added a comment explaining the ordering. LMK if you have a better way of
explaining it, as I think you grok it better than I do
- Thanks for the pointer to javacFileManagerOptions. I updated to use that.
Both are in this updated webrev:
http://cr.openjdk.java.net/~ronsh/8220792/webrev.02/

- Regarding indexing: I don't think today anything would detect updates to
a jar file if a new RelativeDirectory was added. Perhaps that's
intentional, because we don't care/don't even want to try to support
someone updating their jarfile in the middle of a compilation. I defer to
others about indexing other containers - it looks like the
JRTImageContainer depends on the JRTIndex class, which does a lazy
computation of the index, so it looks like it would be some additional work
to add that to the index. But perhaps it's not even worth it - IIUC, there
should only be one JRTImageContainer, and probably a limited amount of
DirectoryContainers - the performance issue that I was observing was that
with many jars, each needed to do some work for every call to list. We've
now reduced O(O(JRTImageContainer = 1) + O(DirectoryContainer = likely to
be small) + O(ArchiveContainer = possibly large)) per list() call
to O(O(JRTImageContainer = 1) + O(DirectoryContainer = likely to be
small) + O(overlapping ArchiveContainers, which is hopefully small))



On Wed, Mar 27, 2019 at 1:47 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
> On 3/27/19 9:06 AM, Ron Shapiro wrote:
> >
> > > It's not clear to me why you maintain the list of PathAndContainer
> > as a sorted list, and hence why you need to use java.util.List instead
> > of javac's List.
> > There are some tests that ensure that the classpath that javac sees is
> > equivalent to the classpath the JVM sees vis-a-vis ordering. Without
> > sorting, javac was seeing a different order, and I presume that is
> > because the JRTImageContainer and DirectoryContainers could appear
> > anywhere. Sorting solved that issue.
>
> OK, I think I understand the issue and why sorting fixes it.
>
> While some tests may check that "the classpath that javac sees is
> equivalent to the classpath the JVM sees vis-a-vis ordering", that's not
> the primary issue. The primary issue is that the new cache must preserve
> the order in which containers are searched on the classpath (i.e just
> within javac, separate from any part set by the JVM). While this is not
> so important when looking up classes in "well-behaved" packages, it is
> important when handling split packages and resources, where the contents
> in one container may hide the contents in another container.
>
> I think this is subtle enough that it is worth a comment in the code,
> explaining that it is important to preserve the search order used in the
> uncached Location path.
>
> -- Jon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190329/a1b14860/attachment-0001.html>

From cushon at google.com  Fri Mar 29 15:21:00 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 29 Mar 2019 08:21:00 -0700
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <CACA6h9ty8VHWOHVfufMiRJ8sa-UObiVzTKkmpnHntHSP5UCpLA@mail.gmail.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>
 <CACA6h9toQu5=bKqkHV4U1=yY6-qDtwCrfR86NbJiAdf=AWwiMQ@mail.gmail.com>
 <1287209895.949274.1553811254455.JavaMail.zimbra@u-pem.fr>
 <CACA6h9ue=QMSRbpLbxkAKKb2oeCFENqWRs5x-OEG5s6pV4EbMw@mail.gmail.com>
 <1592300395.950140.1553812953515.JavaMail.zimbra@u-pem.fr>
 <51d542e5-5d84-d67b-7771-4611d96c5178@oracle.com>
 <CACA6h9ty8VHWOHVfufMiRJ8sa-UObiVzTKkmpnHntHSP5UCpLA@mail.gmail.com>
Message-ID: <CAL4Qsgvm4BPnOv9Gzt0Ji-tL-=cO71OqQJh9-SR9hCp4yaB=Xg@mail.gmail.com>

On Fri, Mar 29, 2019 at 6:34 AM Ron Shapiro <ronshapiro at google.com> wrote:

> Sure thing. Here's that change:
> http://cr.openjdk.java.net/~ronsh/8221118/webrev.05
>

I committed the final version as:
http://hg.openjdk.java.net/jdk/jdk/rev/f69a2f675f19
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190329/c65e8811/attachment.html>

From maurizio.cimadamore at oracle.com  Fri Mar 29 15:38:13 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 29 Mar 2019 15:38:13 +0000
Subject: RFR 8221118: Avoid eagerly creating JCDiagnostic for
 CompletionFailures
In-Reply-To: <CAL4Qsgvm4BPnOv9Gzt0Ji-tL-=cO71OqQJh9-SR9hCp4yaB=Xg@mail.gmail.com>
References: <CACA6h9twzCxYUwwMrotrW82RzKtR6vL99HZp-+QddPTPU8eATg@mail.gmail.com>
 <ee02fff1-9677-118d-5ccd-63f51f2e7ac5@oracle.com>
 <CACA6h9sXzsRaYjD40GrAw7nrmzUa9RLwjMeXDw2jCPw6hzhv3g@mail.gmail.com>
 <1557026637.947296.1553809891646.JavaMail.zimbra@u-pem.fr>
 <CACA6h9toQu5=bKqkHV4U1=yY6-qDtwCrfR86NbJiAdf=AWwiMQ@mail.gmail.com>
 <1287209895.949274.1553811254455.JavaMail.zimbra@u-pem.fr>
 <CACA6h9ue=QMSRbpLbxkAKKb2oeCFENqWRs5x-OEG5s6pV4EbMw@mail.gmail.com>
 <1592300395.950140.1553812953515.JavaMail.zimbra@u-pem.fr>
 <51d542e5-5d84-d67b-7771-4611d96c5178@oracle.com>
 <CACA6h9ty8VHWOHVfufMiRJ8sa-UObiVzTKkmpnHntHSP5UCpLA@mail.gmail.com>
 <CAL4Qsgvm4BPnOv9Gzt0Ji-tL-=cO71OqQJh9-SR9hCp4yaB=Xg@mail.gmail.com>
Message-ID: <6b7ea18e-30ee-e53f-f8cc-80bdeec08ca1@oracle.com>

Thanks!

Maurizio

On 29/03/2019 15:21, Liam Miller-Cushon wrote:
> On Fri, Mar 29, 2019 at 6:34 AM Ron Shapiro <ronshapiro at google.com 
> <mailto:ronshapiro at google.com>> wrote:
>
>     Sure thing. Here's that change:
>     http://cr.openjdk.java.net/~ronsh/8221118/webrev.05
>     <http://cr.openjdk.java.net/~ronsh/8221118/webrev.05/>
>
>
> I committed the final version as: 
> http://hg.openjdk.java.net/jdk/jdk/rev/f69a2f675f19
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190329/73b978e6/attachment.html>

From jonathan.gibbons at oracle.com  Sat Mar 30 01:21:22 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 29 Mar 2019 18:21:22 -0700
Subject: RFR 8220792: JavacFileManager.list() performance
In-Reply-To: <CACA6h9tjFmmHvbYqXg-v_2EpfwJzh8+-Z3FWn-HvqJ1mZr9fMQ@mail.gmail.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
 <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com>
 <CACA6h9uNhmzqAf=tN33Y-WL9fK-oqmwRDDykP3iZB5WRm88aJg@mail.gmail.com>
 <86018eba-aecb-0005-390d-0ce2b662a4df@oracle.com>
 <CACA6h9tjFmmHvbYqXg-v_2EpfwJzh8+-Z3FWn-HvqJ1mZr9fMQ@mail.gmail.com>
Message-ID: <825a8a08-5213-ea02-c95e-d07ef5f1d734@oracle.com>

Ron,

Although I've not checked in deep detail, I think there may be an 
inherent problem with the caching you are doing, as regards to recursive 
list.

The list method takes a "recurse" parameter, which can be used to list 
the contents of a package /and its subpackages/.

If you have two containers, one containing package "p", and another 
containing package "p.q", if you try a recursive list of "p", I believe 
your code may miss the contents of "p.q" in the second container. If 
nothing else, this is an important case to be checked and tested. 
Although this feature is not typically used in javac itself, it is used 
in javadoc, which also uses the same file manager.

It may be that the cache needs to be smart enough to handle the case 
when an archive has subdirectories of a package, even if it does not 
have any direct contents of the package.

-- Jon

On 3/29/19 7:10 AM, Ron Shapiro wrote:
> - Added a comment explaining the ordering. LMK if you have a better 
> way of explaining it, as I think you grok it better than I do
> - Thanks for the pointer to javacFileManagerOptions. I updated to use 
> that.
> Both are in this updated webrev: 
> http://cr.openjdk.java.net/~ronsh/8220792/webrev.02/
>
> - Regarding indexing: I don't think today anything would detect 
> updates to a jar file if a new RelativeDirectory was added. Perhaps 
> that's intentional, because we don't care/don't even want to try to 
> support someone updating their jarfile in the middle of a compilation. 
> I defer to others about indexing other containers - it looks like the 
> JRTImageContainer depends on the JRTIndex class, which does a lazy 
> computation of the index, so it looks like it would be some additional 
> work to add that to the index. But perhaps it's not even worth it - 
> IIUC, there should only be one JRTImageContainer, and probably a 
> limited amount of DirectoryContainers - the performance issue that I 
> was observing was that with many jars, each needed to do some work for 
> every call to list. We've now reduced O(O(JRTImageContainer = 1)?+ 
> O(DirectoryContainer = likely to be small)?+ O(ArchiveContainer = 
> possibly large)) per list() call to?O(O(JRTImageContainer = 1)?+ 
> O(DirectoryContainer = likely to be small)?+ O(overlapping 
> ArchiveContainers, which is hopefully small))
>
>
>
> On Wed, Mar 27, 2019 at 1:47 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>
>     On 3/27/19 9:06 AM, Ron Shapiro wrote:
>     >
>     > > It's not clear to me why you maintain the list of
>     PathAndContainer
>     > as a sorted list, and hence why you need to use java.util.List
>     instead
>     > of javac's List.
>     > There are some tests that ensure that the classpath that javac
>     sees is
>     > equivalent to the classpath the JVM sees vis-a-vis ordering.
>     Without
>     > sorting, javac was seeing a different order, and I presume that is
>     > because the JRTImageContainer and DirectoryContainers could appear
>     > anywhere. Sorting solved that issue.
>
>     OK, I think I understand the issue and why sorting fixes it.
>
>     While some tests may check that "the classpath that javac sees is
>     equivalent to the classpath the JVM sees vis-a-vis ordering",
>     that's not
>     the primary issue. The primary issue is that the new cache must
>     preserve
>     the order in which containers are searched on the classpath (i.e just
>     within javac, separate from any part set by the JVM). While this
>     is not
>     so important when looking up classes in "well-behaved" packages,
>     it is
>     important when handling split packages and resources, where the
>     contents
>     in one container may hide the contents in another container.
>
>     I think this is subtle enough that it is worth a comment in the code,
>     explaining that it is important to preserve the search order used
>     in the
>     uncached Location path.
>
>     -- Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190329/49152668/attachment.html>

From ronshapiro at google.com  Sun Mar 31 12:04:57 2019
From: ronshapiro at google.com (Ron Shapiro)
Date: Sun, 31 Mar 2019 08:04:57 -0400
Subject: RFR 8220792: JavacFileManager.list() performance
In-Reply-To: <825a8a08-5213-ea02-c95e-d07ef5f1d734@oracle.com>
References: <CACA6h9vGY1-N_ZLfmyweyag9C5SHXeriKnqAs23OnSFiaJq2Gw@mail.gmail.com>
 <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com>
 <CACA6h9uNhmzqAf=tN33Y-WL9fK-oqmwRDDykP3iZB5WRm88aJg@mail.gmail.com>
 <86018eba-aecb-0005-390d-0ce2b662a4df@oracle.com>
 <CACA6h9tjFmmHvbYqXg-v_2EpfwJzh8+-Z3FWn-HvqJ1mZr9fMQ@mail.gmail.com>
 <825a8a08-5213-ea02-c95e-d07ef5f1d734@oracle.com>
Message-ID: <CACA6h9tNA5hy0-6sXOrzzN5eHfh6CwQ8A1FLivN-F7irf=648Q@mail.gmail.com>

My initial inclination was to say that you were right, but that this would
have been the case even before my change, since already ArchiveContainer
did nothing to index parent directories of the directories that actually
have files in the archive. But then I did some debugging to see what
actually happens, and it seems that the archive filesystem visits all
parent directories, and thus those are also indexed. Here's one example
from running jtreg:

indexing archivePath: .../asmtools.jar
preVisit: /
preVisit: /org
preVisit: /org/openjdk
preVisit: /org/openjdk/asmtools
preVisit: /org/openjdk/asmtools/util
preVisit: /org/openjdk/asmtools/jdis
preVisit: /org/openjdk/asmtools/jdec
preVisit: /org/openjdk/asmtools/jcoder
preVisit: /org/openjdk/asmtools/jcdec
preVisit: /org/openjdk/asmtools/jasm
preVisit: /org/openjdk/asmtools/common
preVisit: /org/openjdk/asmtools/asmutils
preVisit: /META-INF

I checked the code for ZipFileSystem, and it hard-codes the root directory
as "/" for all zip files no matter the contents.

So for the example above, list("org", recurse=true) should still recur
properly.

On Fri, Mar 29, 2019 at 9:21 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Ron,
>
> Although I've not checked in deep detail, I think there may be an inherent
> problem with the caching you are doing, as regards to recursive list.
>
> The list method takes a "recurse" parameter, which can be used to list the
> contents of a package *and its subpackages*.
>
> If you have two containers, one containing package "p", and another
> containing package "p.q", if you try a recursive list of "p", I believe
> your code may miss the contents of "p.q" in the second container. If
> nothing else, this is an important case to be checked and tested. Although
> this feature is not typically used in javac itself, it is used in javadoc,
> which also uses the same file manager.
>
> It may be that the cache needs to be smart enough to handle the case when
> an archive has subdirectories of a package, even if it does not have any
> direct contents of the package.
>
> -- Jon
> On 3/29/19 7:10 AM, Ron Shapiro wrote:
>
> - Added a comment explaining the ordering. LMK if you have a better way of
> explaining it, as I think you grok it better than I do
> - Thanks for the pointer to javacFileManagerOptions. I updated to use that.
> Both are in this updated webrev:
> http://cr.openjdk.java.net/~ronsh/8220792/webrev.02/
>
> - Regarding indexing: I don't think today anything would detect updates to
> a jar file if a new RelativeDirectory was added. Perhaps that's
> intentional, because we don't care/don't even want to try to support
> someone updating their jarfile in the middle of a compilation. I defer to
> others about indexing other containers - it looks like the
> JRTImageContainer depends on the JRTIndex class, which does a lazy
> computation of the index, so it looks like it would be some additional work
> to add that to the index. But perhaps it's not even worth it - IIUC, there
> should only be one JRTImageContainer, and probably a limited amount of
> DirectoryContainers - the performance issue that I was observing was that
> with many jars, each needed to do some work for every call to list. We've
> now reduced O(O(JRTImageContainer = 1) + O(DirectoryContainer = likely to
> be small) + O(ArchiveContainer = possibly large)) per list() call
> to O(O(JRTImageContainer = 1) + O(DirectoryContainer = likely to be
> small) + O(overlapping ArchiveContainers, which is hopefully small))
>
>
>
> On Wed, Mar 27, 2019 at 1:47 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>>
>> On 3/27/19 9:06 AM, Ron Shapiro wrote:
>> >
>> > > It's not clear to me why you maintain the list of PathAndContainer
>> > as a sorted list, and hence why you need to use java.util.List instead
>> > of javac's List.
>> > There are some tests that ensure that the classpath that javac sees is
>> > equivalent to the classpath the JVM sees vis-a-vis ordering. Without
>> > sorting, javac was seeing a different order, and I presume that is
>> > because the JRTImageContainer and DirectoryContainers could appear
>> > anywhere. Sorting solved that issue.
>>
>> OK, I think I understand the issue and why sorting fixes it.
>>
>> While some tests may check that "the classpath that javac sees is
>> equivalent to the classpath the JVM sees vis-a-vis ordering", that's not
>> the primary issue. The primary issue is that the new cache must preserve
>> the order in which containers are searched on the classpath (i.e just
>> within javac, separate from any part set by the JVM). While this is not
>> so important when looking up classes in "well-behaved" packages, it is
>> important when handling split packages and resources, where the contents
>> in one container may hide the contents in another container.
>>
>> I think this is subtle enough that it is worth a comment in the code,
>> explaining that it is important to preserve the search order used in the
>> uncached Location path.
>>
>> -- Jon
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190331/79cb9020/attachment.html>