From thomas.stuefe at gmail.com  Mon Mar  1 04:54:03 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 1 Mar 2021 05:54:03 +0100
Subject: CFV: New JDK Committer: Adam Sotona
In-Reply-To: <59a38c0f-45c0-80f9-f2e6-9ac88ab7760a@oracle.com>
References: <6c1af5f7-6d0d-4972-93db-2f7bb015eea9@oracle.com>
 <59a38c0f-45c0-80f9-f2e6-9ac88ab7760a@oracle.com>
Message-ID: <CAA-vtUwe+URjokw8h3m=HfxrwbQLGAorzQmw9vGSeieXif07Jw@mail.gmail.com>

+1 From the title alone this is difficult to gauge, and hunting every
change down is time consuming.

Thanks, Thomas

On Thu, Feb 25, 2021 at 8:00 PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Hi Jonathan,
>
> Please, add links to commits. We need to see changes done by Adam and
> judge if they are *significant*.
>
> Thanks,
> Vladimir K
>
> On 2/25/21 9:52 AM, Jonathan Gibbons wrote:
> >
> > I hereby nominate Adam Sotona to JDK Committer.
> >
> > Adam is a member of Oracle's JDK LangTools team, working on javac and
> related tools and API. He has made over a dozen
> > contributions so far. The list is given below.
> >
> > Votes are due by the 11 March, 2021.
> >
> > Only current JDK Committers [1] are eligible to vote
> > on this nomination.  Votes must be cast in the open by replying
> > to this mailing list.
> >
> > For Lazy Consensus voting instructions, see [2].
> >
> > -- Jonathan Gibbons
> >
> > [1] https://openjdk.java.net/census
> > [2] https://openjdk.java.net/projects/#committer-vote
> >
> > commit 7d4f60b16beda722c430f7d6c4b63a5d2a5eb79d
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Thu Feb 25 16:03:04 2021 +0000
> >
> >      8260403: javap should be more robust in the face of invalid class
> files
> > --
> > --
> > commit 2eca17d1b1b6535f3424026c536cde8697a4ec5d
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Thu Feb 25 14:59:32 2021 +0000
> >
> >      8261457: test/langtools/tools/javac/T8187978 can fail if ArrayList
> class is modified
> > --
> > --
> > commit ed4b80177186c56e50c63c1f8f61e7887f2a7861
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Wed Jun 17 13:18:19 2020 +0200
> >
> >      8238735: NPE compiling lambda expression within conditional
> expression
> > --
> > --
> > commit 63ade9c49cc3a2ef26f7b01bbd0dc5393fdfd9c9
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Mon Jun 8 16:07:03 2020 -0400
> >
> >      8236697: Stack overflow with cyclic hierarchy in class file
> > --
> > --
> > commit 022d7a19d37836bbc101c94c84f81520385b824f
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Tue Jun 9 09:37:53 2020 -0400
> >
> >      8236108: tools/javac/lambda/LambdaParserTest.java timed out
> > --
> > --
> > commit 456fe234cef6b69bc577e2de93ecf6b0a1a71505
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Thu May 28 10:52:37 2020 +0200
> >
> >      8230827: javac gives inappropriate warning about potentially
> ambiguous methods
> > --
> > --
> > commit 954db3353ee437959a196a951ee08a3b586beb4e
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Wed May 27 10:16:19 2020 -0400
> >
> >      8241312: missing code coverage for records
> > --
> > --
> > commit c2efd224ca3cfd213d2d53ac7731a7f6bffdddfa
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Wed Apr 8 15:00:39 2020 +0200
> >
> >      8239544: Javac does not respect should-stop.ifNoError policy to
> stop after CompileState PARSE, ENTER and PROCESS
> > --
> > --
> > commit 5a57b9f8ec83b401342f525ebf6035c7fd977467
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Fri May 29 09:56:05 2020 +0200
> >
> >      8245153: Unicode encoded double-quoted empty string does not compile
> > --
> > --
> > commit 4eeb61299f27a7db7049cb47e56563a1eaf8bd69
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Sat May 30 20:10:18 2020 -0400
> >
> >      8244573: java.lang.ArrayIndexOutOfBoundsException thrown for
> malformed class file
> > --
> > --
> > commit 5b323a86568ea2be7653bd09809d572e194005fa
> > Author: Adam Sotona <adam.sotona at oracle.com>
> > Date:   Wed Mar 11 12:30:23 2020 -0400
> >
> >      8230117: Remove unused JAR tool classes
> > --
> > --
> > commit 5eef59d22df7b434093ec26ff8e933ca19d1c070
> > Author: Adam Sotona <asotona at openjdk.org>
> > Date:   Tue Mar 10 17:33:37 2020 +0100
> >
> >      8235216: typo in test filename
> > --
> > --
> > commit f2013ac2471b2322c7a6e146001ad203ec2c4b5d
> > Author: Adam Sotona <adam.sotona at oracle.com>
> > Date:   Tue Jan 28 09:13:27 2020 +0100
> >
> >      8236997: tools/javac tests fail with --illegal-access=deny
> > --
> > --
> > commit d97fe7b05033636dcfbcead77f0b92ca3b014429
> > Author: Adam Sotona <adam.sotona at oracle.com>
> > Date:   Fri Jan 24 12:31:51 2020 +0100
> >
> >      8042742: possible error in Tokens.Token.checkKind() for javac
> >
> >
> >
>

From mik3hall at gmail.com  Wed Mar  3 00:30:00 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 2 Mar 2021 18:30:00 -0600
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <d1aff437-3431-59dd-ceaf-c277516d4ba7@gmail.com>
References: <23b446ad-6fdd-f016-a8ba-9f0f482efb82@gmail.com>
 <ae01958d-1e1b-d25d-fa78-e6cdf5d954d9@oracle.com>
 <ba5f4e6a-d9cb-ab51-a99d-b985d9f63673@gmail.com>
 <f84b2f5d-6dcd-b4b2-23b9-6f9bbb380438@oracle.com>
 <5b0d5fe2-f9cc-cb86-6c63-605a6b935535@gmail.com>
 <d184eda6-9954-33f3-7837-412514212f33@oracle.com>
 <abae3f37-0458-58da-9e3b-87e09fd12821@gmail.com>
 <F7A61173-D10D-4092-B3FC-F43F76B8DBAF@gmail.com>
 <0eba1b31-013b-e717-8d38-aafe46c2c8b8@gmail.com>
 <7b0d4f30-4d17-ee84-bc9c-ea83f9b4eda2@oracle.com>
 <d1aff437-3431-59dd-ceaf-c277516d4ba7@gmail.com>
Message-ID: <BD23CCAD-3726-4C72-B35C-51A8FDDE9969@gmail.com>



> On Feb 27, 2021, at 11:05 AM, Tobias Oelgarte <tobias.oelgarte at gmail.com> wrote:
> 
> This works. Thank you very much.
> -
> Sadly i have to copy the files to different image app folder locations, depending on the operating system. Under Windows it is 'image/AppName/app/' and under Linux it is 'image/AppName/lib/app'. Would have been nice if all images would have the same directory structure. This way i have to create OS specific maven profiles.
> 
> On 27.02.21 14:42, Andy Herrick wrote:
>> If you want to find the app dir directly on all platforms, use a command line option as Michael does in HalfPipe, except directly:
>> 
>> --java-options -Djpackage.app.dir='$APPDIR'
>> 
>> this $APPDIR will be expanded when jli is invoked to point to the applications app dir. ($BINDIR, and $ROOTDIR can be used in similar ways)
>> 
>> /Andy
>> 

I noticed the Windows version of my app was out of date. Other fixes seemed necessary. So I decided to re-do all my builds.

Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in java.library.path: /opt/ooRexx/lib/ooRexx:/Users/mjh/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
	at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
	at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)
	at java.base/java.lang.System.loadLibrary(Unknown Source)
	at us.hall.osx.LogOut.<clinit>(LogOut.java:9)
	at us.hall.hp.common.LoaderLaunchStub.main(LoaderLaunchStub.java:59)

It does seem there is some kind of regression on java.library.path where it doesn?t do the application specific internal paths anymore.
-Djava.library.path=$APPDIR
Seems a work around.
You might have a bug report there. I don?t think I can do one.

jpackage --version
WARNING: Using incubator modules: jdk.incubator.jpackage
15.0.2





From gzsombor at gmail.com  Wed Mar  3 17:16:25 2021
From: gzsombor at gmail.com (Zs.)
Date: Wed, 3 Mar 2021 18:16:25 +0100
Subject: Shortcuts on Collections to create Streams
Message-ID: <CAOO3hRC7Fxw7zm4HNVXa7F--s9Y2Y99t6e6h7CL8GBNKhKCXxA@mail.gmail.com>

Hi,

 As Collection already has a default implementation for 'forEach', I'm
wondering why there is no similar shortcuts for a couple of repeating
patterns around the Collection <--> Stream transitions?
For example, if you could write:
 collection.map(...) instead of collection.stream().map(...);
 collection.filter(...) instead of collection.stream().filter(...);
Or for the other direction:
 stream.toList() instead of stream.collect(Collectors.toList())
 stream.toSet() instead of stream.collect(Collectors.toSet())

They are heavily used even in OpenJDK's source code:

   -
   https://github.com/search?q=stream%5C%28%5C%29.filter%28+repo%3Aopenjdk%2Fjdk+language%3AJava&type=Code&ref=advsearch&l=Java&l=
   -  380 results, unfortunately with false matches from javax.xml.stream.
      StreamFilter
   -
   https://github.com/search?q=stream%5C%28%5C%29.map%5C%28%5C%29+repo%3Aopenjdk%2Fjdk&type=Code
      - 559 results, unfortunately with false matches from comments or
      streams().mapToInt or not related code


   -
   https://github.com/openjdk/jdk/search?q=collect%28Collectors.toList%28%29%29
   -  367 results
   -
   https://github.com/openjdk/jdk/search?q=collect%28Collectors.toSet%28%29%29
   -  117 results

Any particular reason, why adding these - 4 or more - default method to a
collection deemed unnecessary or harmful? Unfortunately I haven't been able
to find the answers for this question using internet searches.

Thanks,
 Zsombor

From thihup at gmail.com  Wed Mar  3 21:53:14 2021
From: thihup at gmail.com (Thiago Henrique Hupner)
Date: Wed, 3 Mar 2021 18:53:14 -0300
Subject: Shortcuts on Collections to create Streams
In-Reply-To: <CAOO3hRC7Fxw7zm4HNVXa7F--s9Y2Y99t6e6h7CL8GBNKhKCXxA@mail.gmail.com>
References: <CAOO3hRC7Fxw7zm4HNVXa7F--s9Y2Y99t6e6h7CL8GBNKhKCXxA@mail.gmail.com>
Message-ID: <CAENv9VFS5Qgz2DgfYUD5T_uUa4sxfZK=f5SvX-NR5udYTQVSog@mail.gmail.com>

They have added the Stream#toList in JDK 16:
https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/util/stream/Stream.html#toList()


Em qua., 3 de mar. de 2021 ?s 18:45, Zs. <gzsombor at gmail.com> escreveu:

> Hi,
>
>  As Collection already has a default implementation for 'forEach', I'm
> wondering why there is no similar shortcuts for a couple of repeating
> patterns around the Collection <--> Stream transitions?
> For example, if you could write:
>  collection.map(...) instead of collection.stream().map(...);
>  collection.filter(...) instead of collection.stream().filter(...);
> Or for the other direction:
>  stream.toList() instead of stream.collect(Collectors.toList())
>  stream.toSet() instead of stream.collect(Collectors.toSet())
>
> They are heavily used even in OpenJDK's source code:
>
>    -
>
> https://github.com/search?q=stream%5C%28%5C%29.filter%28+repo%3Aopenjdk%2Fjdk+language%3AJava&type=Code&ref=advsearch&l=Java&l=
>    -  380 results, unfortunately with false matches from javax.xml.stream.
>       StreamFilter
>    -
>
> https://github.com/search?q=stream%5C%28%5C%29.map%5C%28%5C%29+repo%3Aopenjdk%2Fjdk&type=Code
>       - 559 results, unfortunately with false matches from comments or
>       streams().mapToInt or not related code
>
>
>    -
>
> https://github.com/openjdk/jdk/search?q=collect%28Collectors.toList%28%29%29
>    -  367 results
>    -
>
> https://github.com/openjdk/jdk/search?q=collect%28Collectors.toSet%28%29%29
>    -  117 results
>
> Any particular reason, why adding these - 4 or more - default method to a
> collection deemed unnecessary or harmful? Unfortunately I haven't been able
> to find the answers for this question using internet searches.
>
> Thanks,
>  Zsombor
>

From mik3hall at gmail.com  Thu Mar  4 02:05:00 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 3 Mar 2021 20:05:00 -0600
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <BD23CCAD-3726-4C72-B35C-51A8FDDE9969@gmail.com>
References: <23b446ad-6fdd-f016-a8ba-9f0f482efb82@gmail.com>
 <ae01958d-1e1b-d25d-fa78-e6cdf5d954d9@oracle.com>
 <ba5f4e6a-d9cb-ab51-a99d-b985d9f63673@gmail.com>
 <f84b2f5d-6dcd-b4b2-23b9-6f9bbb380438@oracle.com>
 <5b0d5fe2-f9cc-cb86-6c63-605a6b935535@gmail.com>
 <d184eda6-9954-33f3-7837-412514212f33@oracle.com>
 <abae3f37-0458-58da-9e3b-87e09fd12821@gmail.com>
 <F7A61173-D10D-4092-B3FC-F43F76B8DBAF@gmail.com>
 <0eba1b31-013b-e717-8d38-aafe46c2c8b8@gmail.com>
 <7b0d4f30-4d17-ee84-bc9c-ea83f9b4eda2@oracle.com>
 <d1aff437-3431-59dd-ceaf-c277516d4ba7@gmail.com>
 <BD23CCAD-3726-4C72-B35C-51A8FDDE9969@gmail.com>
Message-ID: <8D152843-3118-490F-B119-D0B46E463556@gmail.com>



> On Mar 2, 2021, at 6:30 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Feb 27, 2021, at 11:05 AM, Tobias Oelgarte <tobias.oelgarte at gmail.com <mailto:tobias.oelgarte at gmail.com>> wrote:
>> 
>> This works. Thank you very much.
>> -
>> Sadly i have to copy the files to different image app folder locations, depending on the operating system. Under Windows it is 'image/AppName/app/' and under Linux it is 'image/AppName/lib/app'. Would have been nice if all images would have the same directory structure. This way i have to create OS specific maven profiles.
>> 
>> On 27.02.21 14:42, Andy Herrick wrote:
>>> If you want to find the app dir directly on all platforms, use a command line option as Michael does in HalfPipe, except directly:
>>> 
>>> --java-options -Djpackage.app.dir='$APPDIR'
>>> 
>>> this $APPDIR will be expanded when jli is invoked to point to the applications app dir. ($BINDIR, and $ROOTDIR can be used in similar ways)
>>> 
>>> /Andy
>>> 
> 
> I noticed the Windows version of my app was out of date. Other fixes seemed necessary. So I decided to re-do all my builds.
> 
> Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in java.library.path: /opt/ooRexx/lib/ooRexx:/Users/mjh/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
> 	at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
> 	at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)
> 	at java.base/java.lang.System.loadLibrary(Unknown Source)
> 	at us.hall.osx.LogOut.<clinit>(LogOut.java:9)
> 	at us.hall.hp.common.LoaderLaunchStub.main(LoaderLaunchStub.java:59)
> 
> It does seem there is some kind of regression on java.library.path where it doesn?t do the application specific internal paths anymore.
> -Djava.library.path=$APPDIR
> Seems a work around.
> You might have a bug report there. I don?t think I can do one.

I found that using the JIRA link given by Alexey Semenyuk I could file a bug report and did so.
Internal review ID 9069348
If anyone wants to bump it.
Sorry, I forgot you indicated you had also previously had problems filing a bug. 


From thomas.schatzl at oracle.com  Thu Mar  4 08:04:25 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 4 Mar 2021 09:04:25 +0100
Subject: CFV: New JDK Committer: Albert Mingkun Yang
In-Reply-To: <ea850e14-0006-52fb-1d55-9b407937c20e@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
 <ea850e14-0006-52fb-1d55-9b407937c20e@oracle.com>
Message-ID: <294e8ab7-1ecb-548f-9f09-501d9a71fd55@oracle.com>

Hi all,

On 17.02.21 09:36, Thomas Schatzl wrote:
> Hi all,
> 
>  ? in my nomination I messed up the project name, I meant to nominate 
> Albert for the JDK project, not OpenJDK, which isn't a project.

Actually there has been another typo, this time in the name of 
nominatee, it should have been

Albert Mingkun Yang

not

Albert Mingkun *W*ang.

My sincere apologies for this second slip-up.

The name used to find his contributions has been correct, so I believe 
the voting has been valid. Since we are already past the voting time 
frame, I will follow-up with the results.

Anyway, for the record, the correct nomination request, again:

Hi all,

    I hereby nominate Albert Mingkun Yang to JDK Committer.

Albert is part of the Oracle Hotspot GC team and has contributed or
contributed to 16 changesets [3].

Votes are due by March 03, 2021 all over the world.

Only current JDK Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
  list.

  For Lazy Consensus voting instructions, see [2]

  Thanks,
     Thomas Schatzl

[1] https://openjdk.java.net/census
[2] https://openjdk.java.net/projects/#committer-vote
[3] Contributions:
https://bugs.openjdk.java.net/browse/JDK-8259668
https://bugs.openjdk.java.net/browse/JDK-8261356
https://bugs.openjdk.java.net/browse/JDK-8260574
https://bugs.openjdk.java.net/browse/JDK-8253420
https://bugs.openjdk.java.net/browse/JDK-8259851
https://bugs.openjdk.java.net/browse/JDK-8074101
https://bugs.openjdk.java.net/browse/JDK-8257149
https://bugs.openjdk.java.net/browse/JDK-8252859
https://bugs.openjdk.java.net/browse/JDK-8252093
https://bugs.openjdk.java.net/browse/JDK-8251463
https://bugs.openjdk.java.net/browse/JDK-8250628
https://bugs.openjdk.java.net/browse/JDK-8245030
https://bugs.openjdk.java.net/browse/JDK-8242036
Co-authored:
https://bugs.openjdk.java.net/browse/JDK-8261661
https://bugs.openjdk.java.net/browse/JDK-8255237
https://bugs.openjdk.java.net/browse/JDK-8255234

From thomas.schatzl at oracle.com  Thu Mar  4 08:14:07 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 4 Mar 2021 09:14:07 +0100
Subject: Result: New JDK Committer: Albert Mingkun Yang
Message-ID: <383074b2-ccc3-42b8-0e39-6d0f55b2abb5@oracle.com>

Hi all,

   voting for Albert Mingkun Yang [1][2] is now closed.

Yes: 22
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Thomas Schatzl

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-February/005068.html
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005162.html

From gzsombor at gmail.com  Thu Mar  4 06:56:31 2021
From: gzsombor at gmail.com (Zs.)
Date: Thu, 4 Mar 2021 07:56:31 +0100
Subject: Shortcuts on Collections to create Streams
In-Reply-To: <CAENv9VFS5Qgz2DgfYUD5T_uUa4sxfZK=f5SvX-NR5udYTQVSog@mail.gmail.com>
References: <CAOO3hRC7Fxw7zm4HNVXa7F--s9Y2Y99t6e6h7CL8GBNKhKCXxA@mail.gmail.com>
 <CAENv9VFS5Qgz2DgfYUD5T_uUa4sxfZK=f5SvX-NR5udYTQVSog@mail.gmail.com>
Message-ID: <CAOO3hRB8O7k8mAVku7nju-5by4x3JJefAtzqQVZdv4sDhfz8BQ@mail.gmail.com>

Thanks, so I'm late by about 4 months for that method.
I've found the tickets about this for future reference:
https://bugs.openjdk.java.net/browse/JDK-8180352
and the pull request - https://github.com/openjdk/jdk/pull/1026
Now, I only miss the 3 other what I've mentioned :)

Best regards,
 Zsombor

On Wed, Mar 3, 2021 at 10:53 PM Thiago Henrique Hupner <thihup at gmail.com>
wrote:

> They have added the Stream#toList in JDK 16:
> https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/util/stream/Stream.html#toList()
>
>
> Em qua., 3 de mar. de 2021 ?s 18:45, Zs. <gzsombor at gmail.com> escreveu:
>
>> Hi,
>>
>>  As Collection already has a default implementation for 'forEach', I'm
>> wondering why there is no similar shortcuts for a couple of repeating
>> patterns around the Collection <--> Stream transitions?
>> For example, if you could write:
>>  collection.map(...) instead of collection.stream().map(...);
>>  collection.filter(...) instead of collection.stream().filter(...);
>> Or for the other direction:
>>  stream.toList() instead of stream.collect(Collectors.toList())
>>  stream.toSet() instead of stream.collect(Collectors.toSet())
>>
>> They are heavily used even in OpenJDK's source code:
>>
>>    -
>>
>> https://github.com/search?q=stream%5C%28%5C%29.filter%28+repo%3Aopenjdk%2Fjdk+language%3AJava&type=Code&ref=advsearch&l=Java&l=
>>    -  380 results, unfortunately with false matches from javax.xml.stream.
>>       StreamFilter
>>    -
>>
>> https://github.com/search?q=stream%5C%28%5C%29.map%5C%28%5C%29+repo%3Aopenjdk%2Fjdk&type=Code
>>       - 559 results, unfortunately with false matches from comments or
>>       streams().mapToInt or not related code
>>
>>
>>    -
>>
>> https://github.com/openjdk/jdk/search?q=collect%28Collectors.toList%28%29%29
>>    -  367 results
>>    -
>>
>> https://github.com/openjdk/jdk/search?q=collect%28Collectors.toSet%28%29%29
>>    -  117 results
>>
>> Any particular reason, why adding these - 4 or more - default method to a
>> collection deemed unnecessary or harmful? Unfortunately I haven't been
>> able
>> to find the answers for this question using internet searches.
>>
>> Thanks,
>>  Zsombor
>>
>

From brian.goetz at oracle.com  Thu Mar  4 18:54:10 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 4 Mar 2021 13:54:10 -0500
Subject: Shortcuts on Collections to create Streams
In-Reply-To: <CAOO3hRB8O7k8mAVku7nju-5by4x3JJefAtzqQVZdv4sDhfz8BQ@mail.gmail.com>
References: <CAOO3hRC7Fxw7zm4HNVXa7F--s9Y2Y99t6e6h7CL8GBNKhKCXxA@mail.gmail.com>
 <CAENv9VFS5Qgz2DgfYUD5T_uUa4sxfZK=f5SvX-NR5udYTQVSog@mail.gmail.com>
 <CAOO3hRB8O7k8mAVku7nju-5by4x3JJefAtzqQVZdv4sDhfz8BQ@mail.gmail.com>
Message-ID: <c23d841d-a47f-fc73-812f-d97c1b22b46c@oracle.com>

We are extremely conservative about adding "convenience" methods; in 
general, they don't carry their weight.? There are exceptions, but these 
have to be justified carefully.

Your original mail illustrates one of the many problems with convenience 
methods: every one we add leads to a call for more:

>   As Collection already has a default implementation for 'forEach', I'm
> wondering why there is no similar shortcuts for a couple of repeating
> patterns around the Collection <--> Stream transitions?

But a world with the union of all possible convenience methods that 
someone could imagine being useful, is not the world we want to live in; 
both library implementors and users would be overwhelmed with trivial 
differences, and this crowds out higher-value activities. In general, we 
prefer to expose the primitives, and let users combine them, though 
different JDK libraries follow this to different degrees.? But, in 
general, a "trivial" method requires a nontrivial amount of justification.

On 3/4/2021 1:56 AM, Zs. wrote:
> Thanks, so I'm late by about 4 months for that method.
> I've found the tickets about this for future reference:
> https://bugs.openjdk.java.net/browse/JDK-8180352
> and the pull request - https://github.com/openjdk/jdk/pull/1026
> Now, I only miss the 3 other what I've mentioned :)
>
> Best regards,
>   Zsombor
>
> On Wed, Mar 3, 2021 at 10:53 PM Thiago Henrique Hupner <thihup at gmail.com>
> wrote:
>
>> They have added the Stream#toList in JDK 16:
>> https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/util/stream/Stream.html#toList()
>>
>>
>> Em qua., 3 de mar. de 2021 ?s 18:45, Zs. <gzsombor at gmail.com> escreveu:
>>
>>> Hi,
>>>
>>>   As Collection already has a default implementation for 'forEach', I'm
>>> wondering why there is no similar shortcuts for a couple of repeating
>>> patterns around the Collection <--> Stream transitions?
>>> For example, if you could write:
>>>   collection.map(...) instead of collection.stream().map(...);
>>>   collection.filter(...) instead of collection.stream().filter(...);
>>> Or for the other direction:
>>>   stream.toList() instead of stream.collect(Collectors.toList())
>>>   stream.toSet() instead of stream.collect(Collectors.toSet())
>>>
>>> They are heavily used even in OpenJDK's source code:
>>>
>>>     -
>>>
>>> https://github.com/search?q=stream%5C%28%5C%29.filter%28+repo%3Aopenjdk%2Fjdk+language%3AJava&type=Code&ref=advsearch&l=Java&l=
>>>     -  380 results, unfortunately with false matches from javax.xml.stream.
>>>        StreamFilter
>>>     -
>>>
>>> https://github.com/search?q=stream%5C%28%5C%29.map%5C%28%5C%29+repo%3Aopenjdk%2Fjdk&type=Code
>>>        - 559 results, unfortunately with false matches from comments or
>>>        streams().mapToInt or not related code
>>>
>>>
>>>     -
>>>
>>> https://github.com/openjdk/jdk/search?q=collect%28Collectors.toList%28%29%29
>>>     -  367 results
>>>     -
>>>
>>> https://github.com/openjdk/jdk/search?q=collect%28Collectors.toSet%28%29%29
>>>     -  117 results
>>>
>>> Any particular reason, why adding these - 4 or more - default method to a
>>> collection deemed unnecessary or harmful? Unfortunately I haven't been
>>> able
>>> to find the answers for this question using internet searches.
>>>
>>> Thanks,
>>>   Zsombor
>>>


From arjan.tijms at gmail.com  Thu Mar  4 20:57:09 2021
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 4 Mar 2021 21:57:09 +0100
Subject: TLS 1.3 Post-handshake authentication
Message-ID: <CAE=-AhAHegi4ZXHtBb95=oxTmQBYSwiZ_mxp6YfKstZXB83nbg@mail.gmail.com>

Hi,

I noticed the following issue was recently closed:

https://bugs.openjdk.java.net/browse/JDK-8206923

For the Servlet spec this is however a very important feature, to the point
that for the Servlet TCK we would need to explicitly allow vendors to use
TLS 1.2 for the client-cert authentication mechanism test.

Servlet needs this post-handshake authentication, since it allows the
server to have protected/secured resources on a URL basis. During the
handshake the URL that the client wishes to request is not yet available,
so the server is unable to determine at that point whether it requires the
client to present a certificate.

Only when the request is being serviced can the server determine this, and
respond with a certificate request. This however fails when using TLS 1.3,
since it's not implemented in Java.

The issue mentions that it might be implemented on request, so hereby I
would like to request this.

Kind regards,
Arjan Tijms (Servlet spec committer)

From aron at aron.nu  Fri Mar  5 05:07:28 2021
From: aron at aron.nu (Andreas Aronsson)
Date: Fri, 5 Mar 2021 06:07:28 +0100
Subject: Shortcuts on Collections to create Streams
In-Reply-To: <c23d841d-a47f-fc73-812f-d97c1b22b46c@oracle.com>
References: <CAOO3hRC7Fxw7zm4HNVXa7F--s9Y2Y99t6e6h7CL8GBNKhKCXxA@mail.gmail.com>
 <CAENv9VFS5Qgz2DgfYUD5T_uUa4sxfZK=f5SvX-NR5udYTQVSog@mail.gmail.com>
 <CAOO3hRB8O7k8mAVku7nju-5by4x3JJefAtzqQVZdv4sDhfz8BQ@mail.gmail.com>
 <c23d841d-a47f-fc73-812f-d97c1b22b46c@oracle.com>
Message-ID: <CALG28eukuxF_QZ6qxC546sqMTamGRMP-A2i0ifW2M0D288=V=g@mail.gmail.com>

All Brian's points are valid.

I am really happy about this addition
https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/util/stream/Stream.html#toList()
It is really very useful to me.

Thanks to Zs for raising this.


On Thu, Mar 4, 2021 at 7:54 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> We are extremely conservative about adding "convenience" methods; in
> general, they don't carry their weight.  There are exceptions, but these
> have to be justified carefully.
>
> Your original mail illustrates one of the many problems with convenience
> methods: every one we add leads to a call for more:
>
> >   As Collection already has a default implementation for 'forEach', I'm
> > wondering why there is no similar shortcuts for a couple of repeating
> > patterns around the Collection <--> Stream transitions?
>
> But a world with the union of all possible convenience methods that
> someone could imagine being useful, is not the world we want to live in;
> both library implementors and users would be overwhelmed with trivial
> differences, and this crowds out higher-value activities. In general, we
> prefer to expose the primitives, and let users combine them, though
> different JDK libraries follow this to different degrees.  But, in
> general, a "trivial" method requires a nontrivial amount of justification.
>
> On 3/4/2021 1:56 AM, Zs. wrote:
> > Thanks, so I'm late by about 4 months for that method.
> > I've found the tickets about this for future reference:
> > https://bugs.openjdk.java.net/browse/JDK-8180352
> > and the pull request - https://github.com/openjdk/jdk/pull/1026
> > Now, I only miss the 3 other what I've mentioned :)
> >
> > Best regards,
> >   Zsombor
> >
> > On Wed, Mar 3, 2021 at 10:53 PM Thiago Henrique Hupner <thihup at gmail.com
> >
> > wrote:
> >
> >> They have added the Stream#toList in JDK 16:
> >>
> https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/util/stream/Stream.html#toList()
> >>
> >>
> >> Em qua., 3 de mar. de 2021 ?s 18:45, Zs. <gzsombor at gmail.com> escreveu:
> >>
> >>> Hi,
> >>>
> >>>   As Collection already has a default implementation for 'forEach', I'm
> >>> wondering why there is no similar shortcuts for a couple of repeating
> >>> patterns around the Collection <--> Stream transitions?
> >>> For example, if you could write:
> >>>   collection.map(...) instead of collection.stream().map(...);
> >>>   collection.filter(...) instead of collection.stream().filter(...);
> >>> Or for the other direction:
> >>>   stream.toList() instead of stream.collect(Collectors.toList())
> >>>   stream.toSet() instead of stream.collect(Collectors.toSet())
> >>>
> >>> They are heavily used even in OpenJDK's source code:
> >>>
> >>>     -
> >>>
> >>>
> https://github.com/search?q=stream%5C%28%5C%29.filter%28+repo%3Aopenjdk%2Fjdk+language%3AJava&type=Code&ref=advsearch&l=Java&l=
> >>>     -  380 results, unfortunately with false matches from
> javax.xml.stream.
> >>>        StreamFilter
> >>>     -
> >>>
> >>>
> https://github.com/search?q=stream%5C%28%5C%29.map%5C%28%5C%29+repo%3Aopenjdk%2Fjdk&type=Code
> >>>        - 559 results, unfortunately with false matches from comments or
> >>>        streams().mapToInt or not related code
> >>>
> >>>
> >>>     -
> >>>
> >>>
> https://github.com/openjdk/jdk/search?q=collect%28Collectors.toList%28%29%29
> >>>     -  367 results
> >>>     -
> >>>
> >>>
> https://github.com/openjdk/jdk/search?q=collect%28Collectors.toSet%28%29%29
> >>>     -  117 results
> >>>
> >>> Any particular reason, why adding these - 4 or more - default method
> to a
> >>> collection deemed unnecessary or harmful? Unfortunately I haven't been
> >>> able
> >>> to find the answers for this question using internet searches.
> >>>
> >>> Thanks,
> >>>   Zsombor
> >>>
>
>

-- 
Andreas Aronsson
Mobil: +46 704 566 595
http://www.aron.nu

"I'd rather have friends who care than friends who agree with me."
Arlo Guthrie

From arjan.tijms at gmail.com  Fri Mar  5 13:37:29 2021
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 5 Mar 2021 14:37:29 +0100
Subject: X509Certificate#getSubjectDN, "denigrated"?
Message-ID: <CAE=-AhC0qRv6isT3Bmz3BT0_a3yO7H0p0i2N791x_SOynq7ShA@mail.gmail.com>

Hi,

For some time now, X509Certificate#getSubjectDN is "denigrated":

  /**
     * <strong>Denigrated</strong>, replaced by {@linkplain
     * #getSubjectX500Principal()}. This method returns the {@code subject}
     * as an implementation specific Principal object, which should not be
     * relied upon by portable code.
     *
     * <p>
     * Gets the {@code subject} (subject distinguished name) value
     * from the certificate.  If the {@code subject} value is empty,
     * then the {@code getName()} method of the returned
     * {@code Principal} object returns an empty string ("").
     *
     * <p> The ASN.1 definition for this is:
     * <pre>
     * subject    Name
     * </pre>
     *
     * <p>See {@link #getIssuerDN() getIssuerDN} for {@code Name}
     * and other relevant definitions.
     *
     * @return a Principal whose name is the subject name.
     */
    public abstract Principal getSubjectDN();

Maybe the original writer meant "deprecated"? If so, maybe it's time to
deprecate the denigrated term here, and formally deprecate getSubjectDN?

Kind regards,
Arjan Tijms

From sean.mullan at oracle.com  Fri Mar  5 13:52:45 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 5 Mar 2021 08:52:45 -0500
Subject: X509Certificate#getSubjectDN, "denigrated"?
In-Reply-To: <CAE=-AhC0qRv6isT3Bmz3BT0_a3yO7H0p0i2N791x_SOynq7ShA@mail.gmail.com>
References: <CAE=-AhC0qRv6isT3Bmz3BT0_a3yO7H0p0i2N791x_SOynq7ShA@mail.gmail.com>
Message-ID: <f373978d-2160-758c-782d-0923871fecbc@oracle.com>

(Moving to security-dev and bcc-ing jdk-dev)

This issue is fixed in JDK 16 [1], and the API is now deprecated [2], 
along with several other related APIs that used that term.

--Sean

[1] https://hg.openjdk.java.net/jdk/jdk/rev/145e1859a0a8
[2] 
https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/security/cert/X509Certificate.html#getSubjectDN()

On 3/5/21 8:37 AM, arjan tijms wrote:
> Hi,
> 
> For some time now, X509Certificate#getSubjectDN is "denigrated":
> 
>    /**
>       * <strong>Denigrated</strong>, replaced by {@linkplain
>       * #getSubjectX500Principal()}. This method returns the {@code subject}
>       * as an implementation specific Principal object, which should not be
>       * relied upon by portable code.
>       *
>       * <p>
>       * Gets the {@code subject} (subject distinguished name) value
>       * from the certificate.  If the {@code subject} value is empty,
>       * then the {@code getName()} method of the returned
>       * {@code Principal} object returns an empty string ("").
>       *
>       * <p> The ASN.1 definition for this is:
>       * <pre>
>       * subject    Name
>       * </pre>
>       *
>       * <p>See {@link #getIssuerDN() getIssuerDN} for {@code Name}
>       * and other relevant definitions.
>       *
>       * @return a Principal whose name is the subject name.
>       */
>      public abstract Principal getSubjectDN();
> 
> Maybe the original writer meant "deprecated"? If so, maybe it's time to
> deprecate the denigrated term here, and formally deprecate getSubjectDN?
> 
> Kind regards,
> Arjan Tijms
> 

From xuelei.fan at oracle.com  Thu Mar  4 21:48:46 2021
From: xuelei.fan at oracle.com (Xue-Lei Fan)
Date: Thu, 4 Mar 2021 21:48:46 +0000
Subject: TLS 1.3 Post-handshake authentication
In-Reply-To: <CAE=-AhAHegi4ZXHtBb95=oxTmQBYSwiZ_mxp6YfKstZXB83nbg@mail.gmail.com>
References: <CAE=-AhAHegi4ZXHtBb95=oxTmQBYSwiZ_mxp6YfKstZXB83nbg@mail.gmail.com>
Message-ID: <MWHPR1001MB22703C9B9E23F0A6466C7E64EC979@MWHPR1001MB2270.namprd10.prod.outlook.com>

<BCC jdk-dev, forward to security-dev>

Hi Arjan,

Did you have a chance to read RFC 8740?  Post-Handshake authentication in HTTP/2 is not allowed for TLS 1.3.  Is there a concern for the use case you mentioned?


Xuelei
________________________________
From: jdk-dev <jdk-dev-retn at openjdk.java.net> on behalf of arjan tijms <arjan.tijms at gmail.com>
Sent: Thursday, March 4, 2021 12:57 PM
To: jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
Subject: TLS 1.3 Post-handshake authentication

Hi,

I noticed the following issue was recently closed:

https://bugs.openjdk.java.net/browse/JDK-8206923

For the Servlet spec this is however a very important feature, to the point
that for the Servlet TCK we would need to explicitly allow vendors to use
TLS 1.2 for the client-cert authentication mechanism test.

Servlet needs this post-handshake authentication, since it allows the
server to have protected/secured resources on a URL basis. During the
handshake the URL that the client wishes to request is not yet available,
so the server is unable to determine at that point whether it requires the
client to present a certificate.

Only when the request is being serviced can the server determine this, and
respond with a certificate request. This however fails when using TLS 1.3,
since it's not implemented in Java.

The issue mentions that it might be implemented on request, so hereby I
would like to request this.

Kind regards,
Arjan Tijms (Servlet spec committer)

From mark.reinhold at oracle.com  Fri Mar  5 22:08:22 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 05 Mar 2021 14:08:22 -0800
Subject: JEP proposed to target JDK 17: 382: New macOS Rendering Pipeline
In-Reply-To: <20210225212728.1AD393D9641@eggemoggin.niobe.net>
References: <20210225212728.1AD393D9641@eggemoggin.niobe.net>
Message-ID: <20210305140822.571538353@eggemoggin.niobe.net>

2021/2/25 13:27:28 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 17:
> 
>   382: New macOS Rendering Pipeline
>        https://openjdk.java.net/jeps/382
> 
>   Summary: Implement a Java 2D internal rendering pipeline for macOS
>   using the Apple Metal API as alternative to the existing pipeline,
>   which uses the deprecated Apple OpenGL API.
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Thursday, 4 March, or if they?re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I?ll target this JEP to JDK 17.

Hearing no objections, I?ve targeted this JEP to JDK 17.

- Mark

From mark.reinhold at oracle.com  Fri Mar  5 22:19:26 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri,  5 Mar 2021 14:19:26 -0800 (PST)
Subject: New candidate JEP: 398: Deprecate the Applet API for Removal
Message-ID: <20210305221926.8432D3DA440@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/398

  Summary: Deprecate the Applet API for removal.  It is essentially
  irrelevant since all web-browser vendors have either removed support
  for Java browser plug-ins or announced plans to do so.

- Mark

From philip.race at oracle.com  Wed Mar 10 22:40:57 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 10 Mar 2021 14:40:57 -0800
Subject: Result: New JDK Reviewer : Alexey Semenyuk
Message-ID: <4c32b001-2ac3-4db6-d440-7c9a60513ea1@oracle.com>

Voting for Alexey Semenyuk [1] has now closed.

Yes: 17
Veto: 0
Abstain: 0

According to the Bylaws definition of Three Vote Consensus [2], this is 
sufficient to approve the nomination.

-phil.

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-February/005102.html
[2] https://openjdk.java.net/projects/#reviewer-vote

From mark.reinhold at oracle.com  Thu Mar 11 00:14:37 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 10 Mar 2021 16:14:37 -0800 (PST)
Subject: New candidate JEP: 399: Intermediate-Representation Graph
 Serialization
Message-ID: <20210311001437.7C6C33DABDB@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/399

  Summary: To aid in testing, create a facility to serialize and
  deserialize the intermediate-representation (IR) graphs used in the
  HotSpot run-time compilers.

- Mark

From mark.reinhold at oracle.com  Thu Mar 11 00:27:05 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 10 Mar 2021 16:27:05 -0800 (PST)
Subject: New candidate JEP: 400: UTF-8 by Default
Message-ID: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/400

  Summary: Use UTF-8 as the JDK's default charset, so that APIs that
  depend on the default charset behave consistently across all platforms
  and independently of the user???s locale and configuration.

- Mark

From ecki at zusammenkunft.net  Thu Mar 11 01:12:49 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 11 Mar 2021 01:12:49 +0000
Subject: New candidate JEP: 400: UTF-8 by Default
In-Reply-To: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>
References: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>
Message-ID: <AM0PR03MB4145FF6666B48693F3DB80EAFF909@AM0PR03MB4145.eurprd03.prod.outlook.com>

I like it. The only thing which I feel is missing would be an official API to get the operating environments default encoding (essentially to get the value used if COMPAT would have been specified).

For example, in our server application, we do have some code which is specified as using exactly this charset  (I.e. if user configures targetEncoding=PLATFORM we are using intentionally the no-arg APIs). We can change that code to specify a Charset, but then we need a way to retrieve that - without poking into unsupported system properties or environment properties. For example System.platformCharset().

I understand that this might have it?s own complications - as not all OS have this concept (for example on Windows there might be different codepages depending on the unicode status of an application). But falling back to today?s file.encoding code would at least be consistent and the behavior most implementer would desire when adapting legacy code to this JEP.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von mark.reinhold at oracle.com <mark.reinhold at oracle.com>
Gesendet: Thursday, March 11, 2021 1:27:05 AM
An: naoto.sato at oracle.com <naoto.sato at oracle.com>
Cc: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
Betreff: New candidate JEP: 400: UTF-8 by Default

https://openjdk.java.net/jeps/400

  Summary: Use UTF-8 as the JDK's default charset, so that APIs that
  depend on the default charset behave consistently across all platforms
  and independently of the user???s locale and configuration.

- Mark

From forax at univ-mlv.fr  Thu Mar 11 01:19:19 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 11 Mar 2021 02:19:19 +0100 (CET)
Subject: New candidate JEP: 400: UTF-8 by Default
In-Reply-To: <AM0PR03MB4145FF6666B48693F3DB80EAFF909@AM0PR03MB4145.eurprd03.prod.outlook.com>
References: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>
 <AM0PR03MB4145FF6666B48693F3DB80EAFF909@AM0PR03MB4145.eurprd03.prod.outlook.com>
Message-ID: <763613412.4787.1615425559076.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Bernd Eckenfels" <ecki at zusammenkunft.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Jeudi 11 Mars 2021 02:12:49
> Objet: Re: New candidate JEP: 400: UTF-8 by Default

> I like it. The only thing which I feel is missing would be an official API to
> get the operating environments default encoding (essentially to get the value
> used if COMPAT would have been specified).
> 
> For example, in our server application, we do have some code which is specified
> as using exactly this charset  (I.e. if user configures targetEncoding=PLATFORM
> we are using intentionally the no-arg APIs). We can change that code to specify
> a Charset, but then we need a way to retrieve that - without poking into
> unsupported system properties or environment properties. For example
> System.platformCharset().
> 
> I understand that this might have it?s own complications - as not all OS have
> this concept (for example on Windows there might be different codepages
> depending on the unicode status of an application). But falling back to today?s
> file.encoding code would at least be consistent and the behavior most
> implementer would desire when adapting legacy code to this JEP.

Hi,
FileReader has a method named getEncoding()

> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net

regards,
R?mi

From ecki at zusammenkunft.net  Thu Mar 11 02:27:05 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 11 Mar 2021 02:27:05 +0000
Subject: New candidate JEP: 400: UTF-8 by Default
In-Reply-To: <763613412.4787.1615425559076.JavaMail.zimbra@u-pem.fr>
References: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>
 <AM0PR03MB4145FF6666B48693F3DB80EAFF909@AM0PR03MB4145.eurprd03.prod.outlook.com>,
 <763613412.4787.1615425559076.JavaMail.zimbra@u-pem.fr>
Message-ID: <AM0PR03MB4145BFDBC6A7DDD9026A1F80FF909@AM0PR03MB4145.eurprd03.prod.outlook.com>

Hello,

Thanks for the hint. The question is if this would return UTF-8 after the JEP is implemented or not (should probably be mentioned in the JEP). If it keeps returning the legacy/platform file encoding that would be a good API for my purpose (but sounds like that would be rather confusing in regards to the default constructor)


--
http://bernd.eckenfels.net
________________________________
Von: Remi Forax <forax at univ-mlv.fr>
Gesendet: Thursday, March 11, 2021 2:19:19 AM
An: Bernd Eckenfels <ecki at zusammenkunft.net>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; jdk-dev <jdk-dev at openjdk.java.net>
Betreff: Re: New candidate JEP: 400: UTF-8 by Default

----- Mail original -----
> De: "Bernd Eckenfels" <ecki at zusammenkunft.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Jeudi 11 Mars 2021 02:12:49
> Objet: Re: New candidate JEP: 400: UTF-8 by Default

> I like it. The only thing which I feel is missing would be an official API to
> get the operating environments default encoding (essentially to get the value
> used if COMPAT would have been specified).
>
> For example, in our server application, we do have some code which is specified
> as using exactly this charset  (I.e. if user configures targetEncoding=PLATFORM
> we are using intentionally the no-arg APIs). We can change that code to specify
> a Charset, but then we need a way to retrieve that - without poking into
> unsupported system properties or environment properties. For example
> System.platformCharset().
>
> I understand that this might have it?s own complications - as not all OS have
> this concept (for example on Windows there might be different codepages
> depending on the unicode status of an application). But falling back to today?s
> file.encoding code would at least be consistent and the behavior most
> implementer would desire when adapting legacy code to this JEP.

Hi,
FileReader has a method named getEncoding()

>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net

regards,
R?mi

From jai.forums2013 at gmail.com  Thu Mar 11 12:33:30 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 11 Mar 2021 18:03:30 +0530
Subject: JBS logins not working?
Message-ID: <fa8f7bd1-6879-ce3d-c60e-61d23f819328@gmail.com>

Hello,

Is the JBS login infrastructure currently working? I've been trying to 
login using my account since the past 4-5 hours, but the login doesn't 
seem to be happening. Once I enter my credentials on the login page, I 
get redirected to the JBS issue as if the login successfully happened, 
but I am still logged out. No errors reported on the page from what I 
can see.

-Jaikiran


From volker.simonis at gmail.com  Thu Mar 11 13:36:25 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 11 Mar 2021 14:36:25 +0100
Subject: JBS logins not working?
In-Reply-To: <fa8f7bd1-6879-ce3d-c60e-61d23f819328@gmail.com>
References: <fa8f7bd1-6879-ce3d-c60e-61d23f819328@gmail.com>
Message-ID: <CA+3eh12XL060s8s2o7neHN888jf+4dDKKXo53tz5v_NXLcFQPQ@mail.gmail.com>

Hi Jaikiran,

It works for me.

There's a known issue with JBS if you're behind a corporate firewall
or in a VPN. Try connecting directly if possible. JBS is also quite
slow from Europe (I'm in Germany).

Best regards,
Volker

On Thu, Mar 11, 2021 at 1:34 PM Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>
> Hello,
>
> Is the JBS login infrastructure currently working? I've been trying to
> login using my account since the past 4-5 hours, but the login doesn't
> seem to be happening. Once I enter my credentials on the login page, I
> get redirected to the JBS issue as if the login successfully happened,
> but I am still logged out. No errors reported on the page from what I
> can see.
>
> -Jaikiran
>

From jai.forums2013 at gmail.com  Thu Mar 11 13:56:03 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 11 Mar 2021 19:26:03 +0530
Subject: JBS logins not working?
In-Reply-To: <CA+3eh12XL060s8s2o7neHN888jf+4dDKKXo53tz5v_NXLcFQPQ@mail.gmail.com>
References: <fa8f7bd1-6879-ce3d-c60e-61d23f819328@gmail.com>
 <CA+3eh12XL060s8s2o7neHN888jf+4dDKKXo53tz5v_NXLcFQPQ@mail.gmail.com>
Message-ID: <e914f5be-4a1d-3d49-3f76-ef0800ea282d@gmail.com>

Hello Volker,

Thank you for checking.

Right now I'm not behind any VPN or a firewall. I tried giving an 
incorrect password (once) just check if there's something else going on 
and it correctly shows the Invalid user/pass message. A correct 
user/pass works as if the login successfully happened and I get 
redirected to the JBS issues but in reality I'm still logged out. I kind 
of felt it might be some cookie issues so I tried this with various 
different browsers (Safari, Firefox). None work. The only difference I 
can think of, since my last successful login (yesterday night) to today 
is that I rebooted (after a very very long time) this laptop. I don't 
see how that should have mattered, but given that this issue looks very 
specific to my account/setup, I will try out a few things later today 
and see if I can sort it out.

Many thanks for your response.

P.S: JBS is (and has been) slow in my part of the world too (India).

-Jaikiran

On 11/03/21 7:06 pm, Volker Simonis wrote:
> Hi Jaikiran,
>
> It works for me.
>
> There's a known issue with JBS if you're behind a corporate firewall
> or in a VPN. Try connecting directly if possible. JBS is also quite
> slow from Europe (I'm in Germany).
>
> Best regards,
> Volker
>
> On Thu, Mar 11, 2021 at 1:34 PM Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>> Hello,
>>
>> Is the JBS login infrastructure currently working? I've been trying to
>> login using my account since the past 4-5 hours, but the login doesn't
>> seem to be happening. Once I enter my credentials on the login page, I
>> get redirected to the JBS issue as if the login successfully happened,
>> but I am still logged out. No errors reported on the page from what I
>> can see.
>>
>> -Jaikiran
>>


From dalibor.topic at oracle.com  Thu Mar 11 18:40:41 2021
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Thu, 11 Mar 2021 19:40:41 +0100
Subject: JBS logins not working?
In-Reply-To: <e914f5be-4a1d-3d49-3f76-ef0800ea282d@gmail.com>
References: <fa8f7bd1-6879-ce3d-c60e-61d23f819328@gmail.com>
 <CA+3eh12XL060s8s2o7neHN888jf+4dDKKXo53tz5v_NXLcFQPQ@mail.gmail.com>
 <e914f5be-4a1d-3d49-3f76-ef0800ea282d@gmail.com>
Message-ID: <2d6cb0e0-4c73-bcc7-ee1e-a8e381c17056@oracle.com>

Hi Jaikrian,

if you keep running into issues, please contact ops at openjdk and let them 
know about it.

cheers,
dalibor topic

On 11.03.2021 14:56, Jaikiran Pai wrote:
> Hello Volker,
> 
> Thank you for checking.
> 
> Right now I'm not behind any VPN or a firewall. I tried giving an 
> incorrect password (once) just check if there's something else going on 
> and it correctly shows the Invalid user/pass message. A correct 
> user/pass works as if the login successfully happened and I get 
> redirected to the JBS issues but in reality I'm still logged out. I kind 
> of felt it might be some cookie issues so I tried this with various 
> different browsers (Safari, Firefox). None work. The only difference I 
> can think of, since my last successful login (yesterday night) to today 
> is that I rebooted (after a very very long time) this laptop. I don't 
> see how that should have mattered, but given that this issue looks very 
> specific to my account/setup, I will try out a few things later today 
> and see if I can sort it out.
> 
> Many thanks for your response.
> 
> P.S: JBS is (and has been) slow in my part of the world too (India).
> 
> -Jaikiran
> 
> On 11/03/21 7:06 pm, Volker Simonis wrote:
>> Hi Jaikiran,
>>
>> It works for me.
>>
>> There's a known issue with JBS if you're behind a corporate firewall
>> or in a VPN. Try connecting directly if possible. JBS is also quite
>> slow from Europe (I'm in Germany).
>>
>> Best regards,
>> Volker
>>
>> On Thu, Mar 11, 2021 at 1:34 PM Jaikiran Pai 
>> <jai.forums2013 at gmail.com> wrote:
>>> Hello,
>>>
>>> Is the JBS login infrastructure currently working? I've been trying to
>>> login using my account since the past 4-5 hours, but the login doesn't
>>> seem to be happening. Once I enter my credentials on the login page, I
>>> get redirected to the JBS issue as if the login successfully happened,
>>> but I am still logged out. No errors reported on the page from what I
>>> can see.
>>>
>>> -Jaikiran
>>>
> 

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>, Video: dalibor.topic at oracle.com
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From jai.forums2013 at gmail.com  Fri Mar 12 05:32:16 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 12 Mar 2021 11:02:16 +0530
Subject: JBS logins not working?
In-Reply-To: <2d6cb0e0-4c73-bcc7-ee1e-a8e381c17056@oracle.com>
References: <fa8f7bd1-6879-ce3d-c60e-61d23f819328@gmail.com>
 <CA+3eh12XL060s8s2o7neHN888jf+4dDKKXo53tz5v_NXLcFQPQ@mail.gmail.com>
 <e914f5be-4a1d-3d49-3f76-ef0800ea282d@gmail.com>
 <2d6cb0e0-4c73-bcc7-ee1e-a8e381c17056@oracle.com>
Message-ID: <ddd4fd9e-e620-93c9-a55d-98ef0d1703a5@gmail.com>

Hello Dalibor,

I sent out a mail to help at o.j.n yesterday and they suggested I try 
logging in from a different system. I tried that today and I have got 
past this issue. After that successful login, I have been able to use my 
regular system and login now works fine from this one too. I don't know 
what was causing the problem, but at this point it's solved.

Thank you all for the help.

-Jaikiran

On 12/03/21 12:10 am, Dalibor Topic wrote:
> Hi Jaikrian,
>
> if you keep running into issues, please contact ops at openjdk and let 
> them know about it.
>
> cheers,
> dalibor topic
>
> On 11.03.2021 14:56, Jaikiran Pai wrote:
>> Hello Volker,
>>
>> Thank you for checking.
>>
>> Right now I'm not behind any VPN or a firewall. I tried giving an 
>> incorrect password (once) just check if there's something else going 
>> on and it correctly shows the Invalid user/pass message. A correct 
>> user/pass works as if the login successfully happened and I get 
>> redirected to the JBS issues but in reality I'm still logged out. I 
>> kind of felt it might be some cookie issues so I tried this with 
>> various different browsers (Safari, Firefox). None work. The only 
>> difference I can think of, since my last successful login (yesterday 
>> night) to today is that I rebooted (after a very very long time) this 
>> laptop. I don't see how that should have mattered, but given that 
>> this issue looks very specific to my account/setup, I will try out a 
>> few things later today and see if I can sort it out.
>>
>> Many thanks for your response.
>>
>> P.S: JBS is (and has been) slow in my part of the world too (India).
>>
>> -Jaikiran
>>
>> On 11/03/21 7:06 pm, Volker Simonis wrote:
>>> Hi Jaikiran,
>>>
>>> It works for me.
>>>
>>> There's a known issue with JBS if you're behind a corporate firewall
>>> or in a VPN. Try connecting directly if possible. JBS is also quite
>>> slow from Europe (I'm in Germany).
>>>
>>> Best regards,
>>> Volker
>>>
>>> On Thu, Mar 11, 2021 at 1:34 PM Jaikiran Pai 
>>> <jai.forums2013 at gmail.com> wrote:
>>>> Hello,
>>>>
>>>> Is the JBS login infrastructure currently working? I've been trying to
>>>> login using my account since the past 4-5 hours, but the login doesn't
>>>> seem to be happening. Once I enter my credentials on the login page, I
>>>> get redirected to the JBS issue as if the login successfully happened,
>>>> but I am still logged out. No errors reported on the page from what I
>>>> can see.
>>>>
>>>> -Jaikiran
>>>>
>>
>

From x4e_x4e at protonmail.com  Mon Mar 15 18:33:40 2021
From: x4e_x4e at protonmail.com (x4e_x4e)
Date: Mon, 15 Mar 2021 18:33:40 +0000
Subject: Spelling mistake in classFileParser
Message-ID: <pbydAwDt2PbqwmLSWYOlJ8UX8EpgTcfb7R1IYckSzYBXeRpc5Hb7wygeW4FRgIwDLw_MHtyIcJx5ZCXGKPWsu0BFwF-tPUixex6vKDOJBRs=@protonmail.com>

Hi,

I have noticed a spelling mistake in classfileparser.cpp: https://github.com/openjdk/jdk/blob/4f1cda4fd744ca159782c09e9c8098f3aa196e72/src/hotspot/share/classfile/classFileParser.cpp#L3769.

It is only in a comment so not very critical.
I do not have Committer rights, so this is the only way I know to raise the error.

Please let me know if it is not worthwhile to report spelling mistakes, or if there is a better place to do so.

Thanks

From daniel.daugherty at oracle.com  Mon Mar 15 20:21:11 2021
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Mon, 15 Mar 2021 16:21:11 -0400
Subject: Spelling mistake in classFileParser
In-Reply-To: <pbydAwDt2PbqwmLSWYOlJ8UX8EpgTcfb7R1IYckSzYBXeRpc5Hb7wygeW4FRgIwDLw_MHtyIcJx5ZCXGKPWsu0BFwF-tPUixex6vKDOJBRs=@protonmail.com>
References: <pbydAwDt2PbqwmLSWYOlJ8UX8EpgTcfb7R1IYckSzYBXeRpc5Hb7wygeW4FRgIwDLw_MHtyIcJx5ZCXGKPWsu0BFwF-tPUixex6vKDOJBRs=@protonmail.com>
Message-ID: <1065988d-d24e-ada6-5a5d-c9c4a7291e3d@oracle.com>

Filed the following new bug for this:

 ??? JDK-8263616 'Deprecatd' typo in 
src/hotspot/share/classfile/classFileParser.cpp
 ??? https://bugs.openjdk.java.net/browse/JDK-8263616

Dan


On 3/15/21 2:33 PM, x4e_x4e wrote:
> Hi,
>
> I have noticed a spelling mistake in classfileparser.cpp: https://github.com/openjdk/jdk/blob/4f1cda4fd744ca159782c09e9c8098f3aa196e72/src/hotspot/share/classfile/classFileParser.cpp#L3769.
>
> It is only in a comment so not very critical.
> I do not have Committer rights, so this is the only way I know to raise the error.
>
> Please let me know if it is not worthwhile to report spelling mistakes, or if there is a better place to do so.
>
> Thanks


From jonathan.gibbons at oracle.com  Tue Mar 16 05:15:31 2021
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 15 Mar 2021 22:15:31 -0700
Subject: Result: New JDK Committer: Adam Sotona
In-Reply-To: <6c1af5f7-6d0d-4972-93db-2f7bb015eea9@oracle.com>
References: <6c1af5f7-6d0d-4972-93db-2f7bb015eea9@oracle.com>
Message-ID: <1b716ad9-73d1-43b2-7b62-68b76bc7327e@oracle.com>

Voting for Adam Sotona [1] is now closed.

Yes: 9
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

-- Jonathan Gibbons

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-February/005130.html



From jesper.wilhelmsson at oracle.com  Tue Mar 16 13:43:10 2021
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 16 Mar 2021 14:43:10 +0100
Subject: Spelling mistake in classFileParser
In-Reply-To: <pbydAwDt2PbqwmLSWYOlJ8UX8EpgTcfb7R1IYckSzYBXeRpc5Hb7wygeW4FRgIwDLw_MHtyIcJx5ZCXGKPWsu0BFwF-tPUixex6vKDOJBRs=@protonmail.com>
References: <pbydAwDt2PbqwmLSWYOlJ8UX8EpgTcfb7R1IYckSzYBXeRpc5Hb7wygeW4FRgIwDLw_MHtyIcJx5ZCXGKPWsu0BFwF-tPUixex6vKDOJBRs=@protonmail.com>
Message-ID: <8F432AEE-3631-44D6-969B-0151962D0FF2@oracle.com>

Personally I think it's very much worthwhile to report and fix typos and weird language in our comments and code.
Thank you for taking the time to clean up the code!

Best regards,
/Jesper

> On 15 Mar 2021, at 19:33, x4e_x4e <x4e_x4e at protonmail.com> wrote:
> 
> Hi,
> 
> I have noticed a spelling mistake in classfileparser.cpp: https://github.com/openjdk/jdk/blob/4f1cda4fd744ca159782c09e9c8098f3aa196e72/src/hotspot/share/classfile/classFileParser.cpp#L3769.
> 
> It is only in a comment so not very critical.
> I do not have Committer rights, so this is the only way I know to raise the error.
> 
> Please let me know if it is not worthwhile to report spelling mistakes, or if there is a better place to do so.
> 
> Thanks


From mark.reinhold at oracle.com  Tue Mar 16 14:29:59 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 16 Mar 2021 07:29:59 -0700 (PDT)
Subject: Java 16 / JDK 16: General Availability
Message-ID: <20210316142959.9BFD93DB53D@eggemoggin.niobe.net>

JDK 16, the reference implementation of Java 16, is now Generally
Available.  We?ve identified no P1 bugs since we promoted build 36
over five weeks ago so that?s the official GA release, ready for
production use.

GPL-licensed OpenJDK builds from Oracle are available here:

  https://jdk.java.net/16

Builds from other implementors will no doubt be available soon.

This release includes seventeen features [1]:

  338: Vector API (Incubator)
  347: Enable C++14 Language Features
  357: Migrate from Mercurial to Git
  369: Migrate to GitHub
  376: ZGC: Concurrent Thread-Stack Processing
  380: Unix-Domain Socket Channels
  386: Alpine Linux Port
  387: Elastic Metaspace
  388: Windows/AArch64 Port
  389: Foreign Linker API (Incubator)
  390: Warnings for Value-Based Classes
  392: Packaging Tool
  393: Foreign-Memory Access API (Third Incubator)
  394: Pattern Matching for instanceof
  395: Records
  396: Strongly Encapsulate JDK Internals by Default
  397: Sealed Classes (Second Preview)

along with, as usual, hundreds of smaller enhancements and thousands
of bug fixes.

Thanks to everyone who contributed to JDK 16, whether by creating
features or enhancements, fixing bugs, or downloading and testing
the early-access builds!

- Mark


[1] https://openjdk.java.net/projects/jdk/16

From mark.reinhold at oracle.com  Tue Mar 16 18:22:09 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 16 Mar 2021 11:22:09 -0700 (PDT)
Subject: JEP proposed to target JDK 17: 391: macOS/AArch64 Port
Message-ID: <20210316182209.855FF3DB764@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 17:

  391: macOS/AArch64 Port
       https://openjdk.java.net/jeps/391

  Summary: Port the JDK to macOS/AArch64.

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Monday, 30 March, or if they?re raised and
then satisfactorily answered, then per the JEP 2.0 process proposal [2]
I?ll target this JEP to JDK 17.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Tue Mar 16 18:35:46 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 16 Mar 2021 11:35:46 -0700 (PDT)
Subject: JEP proposed to target JDK 17: 391: macOS/AArch64 Port
Message-ID: <20210316183546.5F14A3DB76B@eggemoggin.niobe.net>

// Resend, with a deadline in the future rather than the past

The following JEP is proposed to target JDK 17:

  391: macOS/AArch64 Port
       https://openjdk.java.net/jeps/391

  Summary: Port the JDK to macOS/AArch64.

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Tuesday, 23 March, or if they?re raised and
then satisfactorily answered, then per the JEP 2.0 process proposal [2]
I?ll target this JEP to JDK 17.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Tue Mar 16 18:37:44 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 16 Mar 2021 11:37:44 -0700 (PDT)
Subject: JEP proposed to target JDK 17: 398: Deprecate the Applet API for
 Removal
Message-ID: <20210316183744.375C43DB770@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 17:

  398: Deprecate the Applet API for Removal
       https://openjdk.java.net/jeps/398

  Summary: Deprecate the Applet API for removal.  It is essentially
  irrelevant since all web-browser vendors have either removed support
  for Java browser plug-ins or announced plans to do so.

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Tuesday, 23 March, or if they?re raised and
then satisfactorily answered, then per the JEP 2.0 process proposal [2]
I?ll target this JEP to JDK 17.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From aph at redhat.com  Wed Mar 17 11:39:58 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Mar 2021 11:39:58 +0000
Subject: JEP proposed to target JDK 17: 391: macOS/AArch64 Port
In-Reply-To: <20210316182209.855FF3DB764@eggemoggin.niobe.net>
References: <20210316182209.855FF3DB764@eggemoggin.niobe.net>
Message-ID: <8dcfecd7-b0de-60b6-e9e3-b44188b5d681@redhat.com>

On 3/16/21 6:22 PM, mark.reinhold at oracle.com wrote:
> The following JEP is proposed to target JDK 17:
> 
>   391: macOS/AArch64 Port
>        https://openjdk.java.net/jeps/391
> 
>   Summary: Port the JDK to macOS/AArch64.
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.

Super! Let's get it done.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From magnus.ihse.bursie at oracle.com  Wed Mar 17 11:42:43 2021
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 17 Mar 2021 12:42:43 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
Message-ID: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>

There have been a lot of questions and uncertainty about the recently 
enabled GitHub Actions pre-submit testing. Let me clarify a few points 
about these GHA tests.

* It is not a requirement to have green results from GHA tests to 
integrate a fix. Nothing in the OpenJDK bylaws, or the JDK project rules 
requires this.

* That being said, you should of course only integrate correct and 
working code. If you believe GHA is a tool for you to discover bugs, by 
all means, use it. But if it shows up red, that does not mean *in 
itself* that your code is broken.

* The Build Team will not engage in solving problems with building or 
running tests on GHA machines. We have no access to these machines, and 
no ability to fix problems with them. Any requests to fix issues with 
GHA will be ignored.

* Oracle employees should not engage with GHA issues. Oracle has its own 
internal, and much superior, building and testing system. Oracle 
employees should use and rely on this system for building and testing 
code, instead of GHA.

/Magnus

From shade at redhat.com  Wed Mar 17 13:43:26 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Mar 2021 14:43:26 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
Message-ID: <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>

Hi,

A significant part of it feels like Oracle-specific matter.
But no worries, we can discuss OpenJDK here.

TL;DR: I view GHA as the OpenJDK-wide litmus test for the "green" master.

On 3/17/21 12:42 PM, Magnus Ihse Bursie wrote:
> * It is not a requirement to have green results from GHA tests to
> integrate a fix. Nothing in the OpenJDK bylaws, or the JDK project rules
> requires this.

IIRC, GHA workflows were introduced as the replacement for Oracle's jdk-submit forest, which was not 
implemented for Git after the move to Skara. Anyhow, jdk-submit was also a recommendation, as far as 
I can remember. Still, Oracle folks asked contributors to pass it before push, and contributors 
generally obliged. It seems fair to ask for reciprocity here.

> * That being said, you should of course only integrate correct and
> working code. If you believe GHA is a tool for you to discover bugs, by
> all means, use it. But if it shows up red, that does not mean *in
> itself* that your code is broken.

That is true. And like with jdk-submit before, you can reasonably ignore some failures, by 
rationally arguing they are not related to the current PR.

> * The Build Team will not engage in solving problems with building or
> running tests on GHA machines. We have no access to these machines, and
> no ability to fix problems with them. Any requests to fix issues with
> GHA will be ignored.

Now that I am thinking about it, is the crux of the issue in the implicit _mapping_ of every 
.github/workflows/ problem to infrastructure/build and build-dev@? I can see how that can be 
frustrating and arguably outside the build-infra team charter. If that is the issue, we should be 
addressing it: e.g. by adding more members to build-infra (I volunteer here), or remapping GHA 
worklows out of build-infra to something more generic e.g. "jdk"?

That is to say, even though Magnus, being the build-infra lead, can clarify that build team is not 
responsible for GHA issues, the OpenJDK Project as whole would still benefit from functional GHA. I 
am fixing GHA problems when I discover them, and I invite others to join in analyzing/fixing 
problems with it. Over last few months, many Oracle engineers did offer a helping hand in this, and 
I hope that would continue, even if at lower priority.

This is why I am concerned to see this:

> * Oracle employees should not engage with GHA issues. Oracle has its own
> internal, and much superior, building and testing system. Oracle
> employees should use and rely on this system for building and testing
> code, instead of GHA.

"Should not engage" sounds odd here. Was that meant as "${vendor} employees are required to pass 
${vendor}-internal testing, and GHA is not enough alone"? That looks fine, and what I expect 
${vendor} to have as policy. Otherwise it can be sadly read -- while within the ${vendor}'s freedom 
to conduct their business as they want -- as the order to ignore the problems in shared community 
systems.

Generally speaking:

It is beyond doubt that many OpenJDK vendors have testing systems that are more comprehensive than 
what is currently done in GHA -- which is absolutely expected, given that GHA is essentially a 
litmus test. This is not specific for Oracle's testing. To shamelessly plug myself, I have my own CI 
farm for builds.shipilev.net, and in many areas it is also more comprehensive than GHA. Still, it 
does not replace GHA, because only myself has access to it. Having my own testing capability does 
not limit me from maintaining and using GHA.

Technically speaking, in the last few months we saw issues that slipped through Oracle's build-test 
system. Arch-specific build breakages were caught by GHA. Not sure if Oracle systems run any 32-bit 
tests, so 32-bit build/test failures were caught. There were issues when a minor 
post-internal-testing fix actually broke the code, and it was caught by GHA, which runs on every sync.

Also, GHA improves the OpenJDK community story: external contributors, especially first time 
contributors, and/or those not employed by big OpenJDK vendors, benefit from GHA greatly by getting 
their patches built/tested on the systems they cannot otherwise build/test at all.

This is why I view GHA as the important community service that is complementary for vendors' 
testing. For the sake of the shared project health, let's keep GHA stable, reliable, green.

-- 
Thanks,
-Aleksey


From Alan.Bateman at oracle.com  Wed Mar 17 14:49:23 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Mar 2021 14:49:23 +0000
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
Message-ID: <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>

On 17/03/2021 13:43, Aleksey Shipilev wrote:
> :
>
> Technically speaking, in the last few months we saw issues that 
> slipped through Oracle's build-test system. Arch-specific build 
> breakages were caught by GHA. Not sure if Oracle systems run any 
> 32-bit tests, so 32-bit build/test failures were caught. There were 
> issues when a minor post-internal-testing fix actually broke the code, 
> and it was caught by GHA, which runs on every sync.

The topic of ports and maintainers has come up a few times at the 
OpenJDK Committers Workshop. At least some of us had hoped it would lead 
to some agreement on the ports that are required to build at all times, 
and/or a maintainers file that name the people responsible for keeping 
specific ports and features alive.

For the most part it has defined itself. If a change causes breakage on 
linux-x64, windows-x64, macosx-x64 or linux-aarch64 then it is 
disruptive to a lot of people and needs urgent attention, at least when 
it breaks with versions of a toolchain that are widely used. On the 
other hand, breakage to ports such as linux-s390 or aix-ppc64 doesn't 
impact too many people and can be fixed up later (the SAP engineers seem 
to work tirelessly to keep these ports going).

I'm not aware of any recent discussion/agreement on the 32-bit ports. 
Oracle engineers haven't been building the main line on 32-bit for 
several years (I think JDK 8 was the last) so periodic/temporary 
breakage isn't too surprising. I don't know when 32-bit was added to the 
GitHub Actions but requiring all changes to be build/tested on 32-bit 
would need discussion. I'm thinking specifically of some of the bigger 
OpenJDK projects that will involving non-trivial porting? and whether 
they will now be required to have 32-bit ports completed before integrating.

-Alan.

From mark.reinhold at oracle.com  Wed Mar 17 21:35:07 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 17 Mar 2021 14:35:07 -0700
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
Message-ID: <20210317143507.859716414@eggemoggin.niobe.net>

2021/3/17 4:42:43 -0700, magnus.ihse.bursie at oracle.com:
> There have been a lot of questions and uncertainty about the recently 
> enabled GitHub Actions pre-submit testing. Let me clarify a few points 
> about these GHA tests.
> 
> * It is not a requirement to have green results from GHA tests to 
> integrate a fix. Nothing in the OpenJDK bylaws, or the JDK project rules 
> requires this.

It?s true that there?s no formal requirement of this nature, but it
seems that some contributors think that it should be a requirement.

A discussion of this issue is overdue, so let?s have it.

> ...
> 
> * The Build Team will not engage in solving problems with building or 
> running tests on GHA machines. We have no access to these machines, and 
> no ability to fix problems with them. Any requests to fix issues with 
> GHA will be ignored.

Who is the ?Build Team??  Are you speaking for yourself, or on their
behalf?

> * Oracle employees should not engage with GHA issues. Oracle has its own 
> internal, and much superior, building and testing system. Oracle 
> employees should use and rely on this system for building and testing 
> code, instead of GHA.

It is not appropriate, on this list, to discuss what Oracle employees
should or should not do.

- Mark

From mark.reinhold at oracle.com  Wed Mar 17 21:49:43 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 17 Mar 2021 14:49:43 -0700 (PDT)
Subject: New candidate JEP: 401: Primitive Objects (Preview)
Message-ID: <20210317214943.085423DBBFE@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/401

  Summary: Enhance the Java object model with user-declared primitive
  objects, which are class instances that lack object identity
  and can be stored and passed directly, without object headers or
  indirections. This is a preview language and VM feature.

- Mark

From mark.reinhold at oracle.com  Wed Mar 17 21:49:45 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 17 Mar 2021 14:49:45 -0700 (PDT)
Subject: New candidate JEP: 402: Unify the Basic Primitives with Objects
 (Preview)
Message-ID: <20210317214945.A99CD3DBC00@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/402

  Summary: Unify the basic primitives (int, double, etc.) with objects by
  modeling the basic primitive values as instances of primitive classes
  (introduced by JEP 401) and repurposing the wrapper class declarations
  to act as the basic primitives' class declarations.  As a result
  of this change, all Java values will be objects.  This is a preview
  language and VM feature.

- Mark

From mark.reinhold at oracle.com  Wed Mar 17 22:05:14 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 17 Mar 2021 15:05:14 -0700 (PDT)
Subject: New candidate JEP: 403: Strongly Encapsulate JDK Internals
Message-ID: <20210317220514.2F9A73DBC0C@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/403

  Summary: Strongly encapsulate all internal elements of the JDK, except
  for critical internal APIs such as sun.misc.Unsafe.  It will no longer
  be possible to relax the strong encapsulation of internal elements
  via a single command-line option, as was possible in JDK??9 through
  JDK??16.

- Mark

From mark.reinhold at oracle.com  Wed Mar 17 22:08:25 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 17 Mar 2021 15:08:25 -0700 (PDT)
Subject: New candidate JEP: 404: Generational Shenandoah
Message-ID: <20210317220825.56E303DBC11@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/404

  Summary: Enhance the Shenandoah garbage collector with generational
  collection capabilities to improve sustainable throughput, load-spike
  resilience, and memory utilization.

- Mark

From mark.reinhold at oracle.com  Thu Mar 18 00:22:17 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 17 Mar 2021 17:22:17 -0700
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
Message-ID: <20210317172217.299659169@eggemoggin.niobe.net>

2021/3/17 7:49:23 -0700, alan.bateman at oracle.com:
> On 17/03/2021 13:43, Aleksey Shipilev wrote:
>> :
>> 
>> Technically speaking, in the last few months we saw issues that 
>> slipped through Oracle's build-test system. Arch-specific build 
>> breakages were caught by GHA. Not sure if Oracle systems run any 
>> 32-bit tests, so 32-bit build/test failures were caught. There were 
>> issues when a minor post-internal-testing fix actually broke the code, 
>> and it was caught by GHA, which runs on every sync.
> 
> The topic of ports and maintainers has come up a few times at the 
> OpenJDK Committers Workshop. At least some of us had hoped it would lead 
> to some agreement on the ports that are required to build at all times, 
> and/or a maintainers file that name the people responsible for keeping 
> specific ports and features alive.
> 
> For the most part it has defined itself. If a change causes breakage on 
> linux-x64, windows-x64, macosx-x64 or linux-aarch64 then it is 
> disruptive to a lot of people and needs urgent attention, at least when 
> it breaks with versions of a toolchain that are widely used. On the 
> other hand, breakage to ports such as linux-s390 or aix-ppc64 doesn't 
> impact too many people and can be fixed up later (the SAP engineers seem 
> to work tirelessly to keep these ports going).
> 
> I'm not aware of any recent discussion/agreement on the 32-bit ports. 
> Oracle engineers haven't been building the main line on 32-bit for 
> several years (I think JDK 8 was the last) so periodic/temporary 
> breakage isn't too surprising. I don't know when 32-bit was added to the 
> GitHub Actions but requiring all changes to be build/tested on 32-bit 
> would need discussion. I'm thinking specifically of some of the bigger 
> OpenJDK projects that will involving non-trivial porting and whether 
> they will now be required to have 32-bit ports completed before integrating.

As Alan?s summary suggests, in practice we already have two categories
of ports -- we just don?t have names for them.

  - _Primary ports_ (for lack of a better term) are the most broadly
    used.  They can be built and tested on hardware and software
    platforms that are commonly available.

    Examples of primary ports: linux-{x64,aarch64}, windows-x64, macosx-x64

    If the build or testing of a primary port breaks in the main line
    then those responsible for the change generally scramble to fix it.
    A change that requires porting work cannot be integrated into the
    main line until it supports all of the primary ports.

  - _Secondary ports_ (again, for lack of a better term) are less
    broadly used, though they are important to some developers and
    companies.  Building them often requires hardware and software
    platforms that are not commonly available.

    Examples of secondary ports: linux-{arm,ppc64,s390}, aix-ppc64

    If the build or testing of a secondary port breaks in the main line
    then those who maintain that port generally fix it.  A change that
    requires porting work can be integrated into the main line without
    supporting the secondary ports, but contributors of such changes are
    encouraged to assist the maintainers of the secondary ports in doing
    the necessary porting work.

Assuming that we agree on this story so far, where does that leave the
32-bit ports presently tested in GitHub actions?  Primary, or secondary?

Where does that leave windows-aarch64, and the forthcoming macos-aarch64?

Must Valhalla?s JEP 401 (Primitive Objects) support windows-aarch64,
macos-aarch64, linux-{arm,ppc64,s390}, and aix-ppc64 before it?s
integrated?

- Mark

From stuart.marks at oracle.com  Thu Mar 18 02:55:28 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 17 Mar 2021 19:55:28 -0700
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
Message-ID: <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>



On 3/17/21 6:43 AM, Aleksey Shipilev wrote:
> TL;DR: I view GHA as the OpenJDK-wide litmus test for the "green" master.

I think this is premature. Who is responsible for maintaining the systems on which 
GHA workflows run? Are they configured correctly and consistently? Who keeps the 
configurations up to date? If they are broken, who fixes them? Do they produce 
reliable results? etc.

My main takeaway from Magnus' message is that his team doesn't have these 
responsibilities. Ok, then who does? Or... is nobody responsible? (Seems plausible.) 
Until this is resolved, GHA can't be the indicator of a green master.

Now certainly it would be sensible to be pragmatic. If a commit causes ALL the 
builds to fail, sure, it seems likely there's a problem with the commit that will 
need to be fixed before integration. If there's some random test failure somewhere 
unrelated and I can't ascertain why, well, I have limited time to spend chasing down 
random failures that seem unlikely to indicate an actual problem.

s'marks

From shade at redhat.com  Thu Mar 18 08:29:54 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Mar 2021 09:29:54 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <20210317172217.299659169@eggemoggin.niobe.net>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
Message-ID: <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>

Hi,

On 3/18/21 1:22 AM, mark.reinhold at oracle.com wrote:
> As Alan?s summary suggests, in practice we already have two categories
> of ports -- we just don?t have names for them.
> 
>    - _Primary ports_ (for lack of a better term) are the most broadly
>      used.  They can be built and tested on hardware and software
>      platforms that are commonly available.
> 
>      Examples of primary ports: linux-{x64,aarch64}, windows-x64, macosx-x64
> 
>      If the build or testing of a primary port breaks in the main line
>      then those responsible for the change generally scramble to fix it.
>      A change that requires porting work cannot be integrated into the
>      main line until it supports all of the primary ports.

FWIW, it is odd to see linux-aarch64 in this list. For all the progress aarch64 made in these years, 
linux-aarch64 is still not as commonly available as one might hope. GHA also has no linux-aarch64 
hosts to run any tests on, AFAIU. If we are drawing the line in the sand based on what the regular 
developer has, it leaves only x86_64.


>    - _Secondary ports_ (again, for lack of a better term) are less
>      broadly used, though they are important to some developers and
>      companies.  Building them often requires hardware and software
>      platforms that are not commonly available.
> 
>      Examples of secondary ports: linux-{arm,ppc64,s390}, aix-ppc64
> 
>      If the build or testing of a secondary port breaks in the main line
>      then those who maintain that port generally fix it.  A change that
>      requires porting work can be integrated into the main line without
>      supporting the secondary ports, but contributors of such changes are
>      encouraged to assist the maintainers of the secondary ports in doing
>      the necessary porting work.

Yes.

There is a major minor thing to mention here. The overwhelming majority of the issues are simple 
omissions that break builds/tests in a painfully obvious way. The contributors I worked with are 
usually saying something like "I would have fixed this trivial issue if I knew it was broken!". The 
breakages are very seldom intentional, they mostly come from the absence of mechanical checks that 
would warn a contributor. GHA gives the warning that something is broken, providing the contributor 
to push the day-1 high-grade patch.

Our only GHA workflow, as it stands right now, builds:
   windows-x86_64
   macos-x86_64
   linux-x86_64
   linux-x86_32
   windows-aarch64 (only hotspot)
   linux-x86_64-fastdebug (only hotspot)
   linux-x86_64-optimized (only hotspot)
   linux-x86_64-minimal (only hotspot)
   linux-x86_64-zero (only hotspot)
   linux-ppc64le (only hotspot)
   linux-s390x (only hotspot)
   linux-arm (only hotspot)
   linux-arch64 (only hotspot)

...and runs tier1 on:
   windows-x86_64
   macos-x86_64
   linux-x86_64
   linux-x86_32

So for "secondary ports", GHA overwhelmingly verifies buildability.

Which is good for a litmus test: it verifies that JDK is not significantly broken to block the 
arch-specific testing in the vendor-specific testing systems. True, the contributors are not 
expected to fix the arch-specific test issues for the platforms they do not maintain. But that is 
not what current GHA workflow effectively asks. It asks to pass a low bar of keeping the master 
buildable on those port arches, so porter's CIs can still run tests. I say "low bar" from experience 
of fixing arch-specific build failures over the years. Most of the time those are trivial few-liners.

In fact, the amount of follow-up "build is broken" fixes I submitted after GHA workflows covered 
most of the bases had dwindled to nearly zero. I don't see Linaro's or others CIs complain about 
broken builds as often now. Which in my mind makes the global GHA workflow a resounding success in 
simplifying the OpenJDK development.

> Assuming that we agree on this story so far, where does that leave the
> 32-bit ports presently tested in GitHub actions?  Primary, or secondary?

I believe buildability on x86_32 is as important to enforce as buildability on foreign arches like 
aarch64, arm, ppc64, s390x. The 32/64 bit cleanliness issues in a languages like C/C++ are 
unfortunately only exposed by an attempt to build. x86_32 is special in this regard, because you can 
easily do the reduced build on x86_64.

I agree that running tier1 on x86_32 might not be necessary. Most of the time, x86_32 tests catch 
the test configuration problems that would manifest uniformly across x86_32, ARM32, MIPS, etc. -- 
with the benefit of being able to reproduce x86_32 locally on x86_64 host.

So I am kind of on the fence. x86_32 is at least "secondary".

> Where does that leave windows-aarch64, and the forthcoming macos-aarch64?

Windows-aarch64 is built like a foreign arch in current GHA, and I believe it should continue to 
build. I hope when/if GH adds macos-aarch64, we would build it as foreign arch on GHA as well. Both 
seem "secondary".

> Must Valhalla?s JEP 401 (Primitive Objects) support windows-aarch64,
> macos-aarch64, linux-{arm,ppc64,s390}, and aix-ppc64 before it?s
> integrated?

Based on what I said above:

Support, as in fully passing at least tier1 tests on a secondary platform, while nice to have, is 
not necessary. Being buildable and hopefully failing (more or less) gracefully/consistently at 
runtime -- should be strongly considered, unless there are good reasons why would e.g. stubbing out 
the other arches implementations would not work to regain the buildability.

It is fine to have some platforms build-broken when projects are developed outside the mainline. But 
when the contribution to the mainline happens, I think it is fair to ask to meet this -- quite low! 
-- standard of being buildable everywhere. Unless, of course, there is a sound reason why it is 
complicated to do. In that case, I would hope that porters get notified about these issues before 
the integration happens, so they can implement missing parts sooner.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Mar 18 08:36:19 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Mar 2021 09:36:19 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
Message-ID: <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>

On 3/18/21 3:55 AM, Stuart Marks wrote:
> On 3/17/21 6:43 AM, Aleksey Shipilev wrote:
>> TL;DR: I view GHA as the OpenJDK-wide litmus test for the "green" master.
> 
> I think this is premature. Who is responsible for maintaining the systems on which
> GHA workflows run? Are they configured correctly and consistently? Who keeps the
> configurations up to date? If they are broken, who fixes them? Do they produce
> reliable results? etc.

I believe the answers to some of these questions are in GHA workflow history:
   https://github.com/openjdk/jdk/commits/master/.github/workflows/submit.yml

Yes, systems-wise with GHA, we are in somewhat awkward position to trust that GH Cloud (Azure?) is 
configured correctly, runs on proper hardware, and is being maintained. There is a fair amount of 
trust in this equation. I haven't seen that trust broken in the last half a year the GHA were 
running for OpenJDK (both for mainline JDK and Codetools projects), so I am keeping hopeful.

The fact that GHA is not ideal does not make it less useful. As I note in the reply to Mark, the 
number of follow-up trivial build/test fixes had dropped palpably after GHA were introduced in JDK 
mainline repo.

> My main takeaway from Magnus' message is that his team doesn't have these
> responsibilities. Ok, then who does? Or... is nobody responsible? (Seems plausible.)

Again, at present this seems to be the self-appointed duty of some OpenJDK contributors, look at GHA 
workflow history. If the only thing missing here is formal assignment to maintain this, we can solve 
that. I am not sure that is a problem worth solving, though, based on our current experience: there 
are interested parties that do that outside the formal assignment.

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Thu Mar 18 09:06:13 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 18 Mar 2021 10:06:13 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
 <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
Message-ID: <7abcedc3-a2e4-64cc-2e13-d4254c67c7f2@redhat.com>

I am not quite sure why all of this even needs discussing. Besides GHA, 
we currently have *zero* gating checks in OpenJDK workflow. Yes we used 
to have jdk-submit repo, but that was *very* awkward. What GHA provides 
us is so much more useful and accessible IMO.

If you don't like it, well, then I think it's ok to ignore it and rely 
only on vendor-internal testing. My opinion is that checking GHA results 
and fixing obvious build breakages is an action of minimal respect vs 
the wider OpenJDK community and the various porters, and most often 
doesn't cost very much (or nothing at all). If something shows up that 
doesn't look related to your change, you can still ignore it, or, if you 
have some ideas, ping the right people.

Roman


> On 3/18/21 3:55 AM, Stuart Marks wrote:
>> On 3/17/21 6:43 AM, Aleksey Shipilev wrote:
>>> TL;DR: I view GHA as the OpenJDK-wide litmus test for the "green" 
>>> master.
>>
>> I think this is premature. Who is responsible for maintaining the 
>> systems on which
>> GHA workflows run? Are they configured correctly and consistently? Who 
>> keeps the
>> configurations up to date? If they are broken, who fixes them? Do they 
>> produce
>> reliable results? etc.
> 
> I believe the answers to some of these questions are in GHA workflow 
> history:
>    
> https://github.com/openjdk/jdk/commits/master/.github/workflows/submit.yml
> 
> Yes, systems-wise with GHA, we are in somewhat awkward position to trust 
> that GH Cloud (Azure?) is configured correctly, runs on proper hardware, 
> and is being maintained. There is a fair amount of trust in this 
> equation. I haven't seen that trust broken in the last half a year the 
> GHA were running for OpenJDK (both for mainline JDK and Codetools 
> projects), so I am keeping hopeful.
> 
> The fact that GHA is not ideal does not make it less useful. As I note 
> in the reply to Mark, the number of follow-up trivial build/test fixes 
> had dropped palpably after GHA were introduced in JDK mainline repo.
> 
>> My main takeaway from Magnus' message is that his team doesn't have these
>> responsibilities. Ok, then who does? Or... is nobody responsible? 
>> (Seems plausible.)
> 
> Again, at present this seems to be the self-appointed duty of some 
> OpenJDK contributors, look at GHA workflow history. If the only thing 
> missing here is formal assignment to maintain this, we can solve that. I 
> am not sure that is a problem worth solving, though, based on our 
> current experience: there are interested parties that do that outside 
> the formal assignment.
> 


From Alan.Bateman at oracle.com  Thu Mar 18 11:32:01 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Mar 2021 11:32:01 +0000
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
Message-ID: <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>

On 18/03/2021 08:29, Aleksey Shipilev wrote:
> :
>
> It is fine to have some platforms build-broken when projects are 
> developed outside the mainline. But when the contribution to the 
> mainline happens, I think it is fair to ask to meet this -- quite low! 
> -- standard of being buildable everywhere. Unless, of course, there is 
> a sound reason why it is complicated to do. In that case, I would hope 
> that porters get notified about these issues before the integration 
> happens, so they can implement missing parts sooner
"build everywhere" is a high bar in the context of JEPs from big 
projects such as Project Valhalla or Loom that may have a lot of 
architecture specific code. You've listed building of hotspot on 
linux-ppc64le, linux-s390x, and a few others as being enabled for the 
Github Actions now but I wouldn't expect JEPs from these projects to 
have to wait for these ports. If the ports are done before integration 
then great, if they happen a few weeks or months after integration then 
that might be okay too. Inviting maintainers of ports to get involved at 
an appropriate time is reasonable but if the port is not complete then I 
don't think it should be a blocker for integration.

-Alan.


From magnus.ihse.bursie at oracle.com  Thu Mar 18 12:43:21 2021
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 18 Mar 2021 13:43:21 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <20210317143507.859716414@eggemoggin.niobe.net>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <20210317143507.859716414@eggemoggin.niobe.net>
Message-ID: <083baa8f-7d2b-5a79-8fce-3aaee3b9be6b@oracle.com>

First of all, let me apologize for my previous mail. It was really 
expressing my personal opinions, but I framed it as a general dictate. 
We need to discuss this question as a community, and establish ground 
rules that everyone can accept, and that we can practically continue to 
uphold.

On 2021-03-17 22:35, mark.reinhold at oracle.com wrote:
> 2021/3/17 4:42:43 -0700, magnus.ihse.bursie at oracle.com:
>> There have been a lot of questions and uncertainty about the recently
>> enabled GitHub Actions pre-submit testing. Let me clarify a few points
>> about these GHA tests.
>>
>> * It is not a requirement to have green results from GHA tests to
>> integrate a fix. Nothing in the OpenJDK bylaws, or the JDK project rules
>> requires this.
> It?s true that there?s no formal requirement of this nature, but it
> seems that some contributors think that it should be a requirement.
>
> A discussion of this issue is overdue, so let?s have it.
Great! I'm really looking forward to this discussion and I'm glad to 
finally see it happening.

/Magnus
>
>> ...
>>
>> * The Build Team will not engage in solving problems with building or
>> running tests on GHA machines. We have no access to these machines, and
>> no ability to fix problems with them. Any requests to fix issues with
>> GHA will be ignored.
> Who is the ?Build Team??  Are you speaking for yourself, or on their
> behalf?
>
>> * Oracle employees should not engage with GHA issues. Oracle has its own
>> internal, and much superior, building and testing system. Oracle
>> employees should use and rely on this system for building and testing
>> code, instead of GHA.
> It is not appropriate, on this list, to discuss what Oracle employees
> should or should not do.
>
> - Mark


From shade at redhat.com  Thu Mar 18 13:18:25 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Mar 2021 14:18:25 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
Message-ID: <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>

On 3/18/21 12:32 PM, Alan Bateman wrote:
> On 18/03/2021 08:29, Aleksey Shipilev wrote:
>> It is fine to have some platforms build-broken when projects are
>> developed outside the mainline. But when the contribution to the
>> mainline happens, I think it is fair to ask to meet this -- quite low!
>> -- standard of being buildable everywhere. Unless, of course, there is
>> a sound reason why it is complicated to do. In that case, I would hope
>> that porters get notified about these issues before the integration
>> happens, so they can implement missing parts sooner
> "build everywhere" is a high bar in the context of JEPs from big
> projects such as Project Valhalla or Loom that may have a lot of
> architecture specific code. 

I agree that you cannot force Valhalla/Loom/etc developers to _implement_ the architecture-specific 
code for secondary ports.

What I am talking about is much weaker: buildability. I believe it is fair to ask that when the 
mainline integration PR is done, the arch-specific code is clearly isolated, new declarations in 
arch-specific headers are done, their implementations are stubbed out with NotImplemented(), etc.

So that VM builds, and then hopefully passes old tests as much as possible, and fails on new tests 
at sensible points where the implementation is expected to be. I am saying this with the experience 
of doing so multiple times across many JDK releases: that is a low bar to pass. It becomes painful 
when code does not fit the Hotspot's established ways to isolate the arch-specific code. In other 
words, that pain is instructional.

Taking current state of Loom as the example: it has lots of direct uses of x86-only definitions from 
the shared code. As I said before, it is a fair game for non-mainline development to hack the 
prototypes any way they want, including focusing only on one platform at a time. But if we decide to 
integrate current Loom into mainline, then GHA would complain that foreign arches are not buildable, 
and that would point to this not-yet-reconciled cohesion between shared and arch-specific code. That 
is, GHA would be a very basic quality gate working as intended.

I hope this clarifies that I am not suggesting something drastic here. I am only talking about the 
basic quality gate check: buildability on primary/secondary ports; tier1 on primary ports.

-- 
Thanks,
-Aleksey


From david.lloyd at redhat.com  Thu Mar 18 13:32:28 2021
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 18 Mar 2021 08:32:28 -0500
Subject: New candidate JEP: 401: Primitive Objects (Preview)
In-Reply-To: <20210317214943.085423DBBFE@eggemoggin.niobe.net>
References: <20210317214943.085423DBBFE@eggemoggin.niobe.net>
Message-ID: <CANghgrTn5LLfu43LfivxGVT9vm_i=ndCO+uF0kEeJZJifMwHag@mail.gmail.com>

Are we completely sure that having every existing class suddenly implement
IdentityObject isn't going to break all kinds of reflection-based
frameworks?  I'd be very nervous about making a change like that.

Reinterpreting calls to `new Object()` seems like trouble to me as well;
it'd be downright bizarre to have `new Object().getClass() !=
Object.class`.  Making `Object` be special is just going to make the
language that much more awkward overall; I honestly can't imagine the
tradeoffs that made this seem like a good idea in comparison.

I'm surprised that adding these special cases would be preferable to having
primitive types be isolated to their own space (i.e. not extending Object)
or other options.  For example, by having an isolated root primitive class
analog to Object (with a box type extending Object directly), and requiring
any base abstract types to extend that class, the existing language
behaviors would not have to change AFAICT.  Primitive classes would be much
easier to recognize.  Primitive base classes could even have state.  What
critical use case did such a design inhibit?  Where were such decisions
documented?

Historically, I personally have failed to understand how these kinds of
language-level enhancements balance preserving consistent and simple
behavior with enabling specific use cases in certain ways; from the outside
it seems very ad-hoc (retroactively updating requirements to adhere to new
design ideas).  I wish there were some better way to have this be
communicated through the life of a project.  In the case of valhalla, it
seems that new requirements have arisen (and some old requirements have
been invalidated) over time/iterations, but unless one follows the project
discussion from the absolute beginning and keeps careful notes throughout
(and is privy to what appear to be possibly non-public design discussions),
apart from occasional big-document drops and actually building prototypes,
there really seems to be no way to understand what the total set of
requirements of the final iteration actually are, or what design
considerations went into it.  Is this something that can be improved
somehow?  It would be nice to see, for exampe, a living document with use
cases (including use cases that are later rejected) which map to goals and
requirements, that could be updated after each design decision.  Even if
many of the use cases are along the lines of "we want this user experience"
in the form of "here is some syntax we'd like users to be able to use, with
justifications", this would be really nice to maintain publicly in a simple
living document.  It would, for example, provide a nice and simple way for
news media to inform users about the project progress.  All the better if
changes for the document could be managed publicly somehow (GitHub pull
requests for example).

If nothing else, something like this might help mitigate the inevitably
repetitive user-level questions that are associated with substantial
changes.  At best, it avoids the major change "bomb drop" - which IMO
leaves the user base with the impression that they have no choice but to
accept these kinds of changes - and gives users more of a reason to look
forward to a change, with *more* of a possibility of accurate expectations.

I'm not saying *nothing* was done on this effort but the end impression for
me is that the process resulting in this design has been substantially more
obscure than, say, the process of designing pattern-matching switch
statements, which seems much more accessible to users.  For such important
changes, wouldn't it be good to have a more consistent and public process
for communication?


On Wed, Mar 17, 2021 at 4:50 PM <mark.reinhold at oracle.com> wrote:

> https://openjdk.java.net/jeps/401
>
>   Summary: Enhance the Java object model with user-declared primitive
>   objects, which are class instances that lack object identity
>   and can be stored and passed directly, without object headers or
>   indirections. This is a preview language and VM feature.
>
> - Mark
>
>

-- 
- DML ? he/him

From aph at redhat.com  Thu Mar 18 16:51:42 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 18 Mar 2021 16:51:42 +0000
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
Message-ID: <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>

On 3/18/21 1:18 PM, Aleksey Shipilev wrote:
> Taking current state of Loom as the example: it has lots of direct uses of x86-only definitions from 
> the shared code. As I said before, it is a fair game for non-mainline development to hack the 
> prototypes any way they want, including focusing only on one platform at a time. But if we decide to 
> integrate current Loom into mainline, then GHA would complain that foreign arches are not buildable, 
> and that would point to this not-yet-reconciled cohesion between shared and arch-specific code. That 
> is, GHA would be a very basic quality gate working as intended.

The question is this: on whom does the buildability requirement rest?

If we are to allow many ports into OpenJDK, and I believe we should,
then the burden of even stubbing things out to make sure that all
weird ports work is intolerable for contributors. It can not scale.

I say, therefore, that it's for the maintainers of those ports to
fix things up, before a patch is committed if they can, after if
they can't.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From maurizio.cimadamore at oracle.com  Thu Mar 18 17:29:25 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 18 Mar 2021 17:29:25 +0000
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
Message-ID: <b42bfe6f-2342-d07b-47ed-293ea65a5741@oracle.com>


On 18/03/2021 13:18, Aleksey Shipilev wrote:
> What I am talking about is much weaker: buildability. I believe it is 
> fair to ask that when the mainline integration PR is done, the 
> arch-specific code is clearly isolated, new declarations in 
> arch-specific headers are done, their implementations are stubbed out 
> with NotImplemented(), etc. 

With Panama, we ended up in the place you describe.

While that might take some "sting" off the initial integration, one 
thing worth mentioning is that it's not clear how things move from a 
"buildable but not working" state into a "fully working" state (to date, 
Panama has not received any contribution/help in terms of porting the 
foreign linker API to x86 and other platforms).

So, while I generally agree that we should try to minimize disruptions 
as much as possible, I think what users want is something that builds 
and that _does what it's supposed to do_ - otherwise we quickly end up 
with ports which only support a subset of the features that are 
supported by the "first-class" ports, which isn't great either.

Maurizio




From shade at redhat.com  Thu Mar 18 18:14:59 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Mar 2021 19:14:59 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
Message-ID: <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>

On 3/18/21 5:51 PM, Andrew Haley wrote:
> On 3/18/21 1:18 PM, Aleksey Shipilev wrote:
>> Taking current state of Loom as the example: it has lots of direct uses of x86-only definitions from
>> the shared code. As I said before, it is a fair game for non-mainline development to hack the
>> prototypes any way they want, including focusing only on one platform at a time. But if we decide to
>> integrate current Loom into mainline, then GHA would complain that foreign arches are not buildable,
>> and that would point to this not-yet-reconciled cohesion between shared and arch-specific code. That
>> is, GHA would be a very basic quality gate working as intended.
> 
> The question is this: on whom does the buildability requirement rest?

I believe pre-integration testing, including buildability checks, always rests on contributor, 
unless reviewers agree the usual rules can be relaxed. What constitutes "usual rules" with regards 
to builds/tests is codifiable into mechanical checks. GHA seems to be as good vehicle for this 
codification. So...

> If we are to allow many ports into OpenJDK, and I believe we should,
> then the burden of even stubbing things out to make sure that all
> weird ports work is intolerable for contributors. It can not scale.

...that feeds into question which ports do we accept to GHA.

"Weird ports" [1] should not be the part of it. Current list includes all actively maintained 
mainline ports: x86_64, x86_32, aarch64, arm32, ppc64le, s390x, zero. For which not only we have 
active maintainers, but we also have build instructions in OpenJDK docs, not to mention the GHA 
workflow script itself.

-- 
Thanks,
-Aleksey

[1] At this point, they seem to be: armel, m68k, mips64el, mipsel, ppc, ppc64be, sh4, 
windows-x86_32, etc. These are not and should not be the part of pre-integration testing.


From gnu.andrew at redhat.com  Thu Mar 18 18:25:21 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 18 Mar 2021 18:25:21 +0000
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
Message-ID: <20210318182521.GA728349@rincewind>

On 16:51 Thu 18 Mar     , Andrew Haley wrote:
> On 3/18/21 1:18 PM, Aleksey Shipilev wrote:
> > Taking current state of Loom as the example: it has lots of direct uses of x86-only definitions from 
> > the shared code. As I said before, it is a fair game for non-mainline development to hack the 
> > prototypes any way they want, including focusing only on one platform at a time. But if we decide to 
> > integrate current Loom into mainline, then GHA would complain that foreign arches are not buildable, 
> > and that would point to this not-yet-reconciled cohesion between shared and arch-specific code. That 
> > is, GHA would be a very basic quality gate working as intended.
> 
> The question is this: on whom does the buildability requirement rest?
> 
> If we are to allow many ports into OpenJDK, and I believe we should,
> then the burden of even stubbing things out to make sure that all
> weird ports work is intolerable for contributors. It can not scale.
> 
> I say, therefore, that it's for the maintainers of those ports to
> fix things up, before a patch is committed if they can, after if
> they can't.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 

This is nothing new; I've lost count of the number of times the
Zero assembler port has been broken by changes to HotSpot over
the years, and that doesn't even require configuring a different
operating system and/or architecture, just a build flag.

On the other hand, we've been expected to blindly fix build failures
on Oracle build systems before, including on systems like Solaris
where we don't build ourselves. At first, this was only indirectly via
an Oracle sponsor, and then the jdk-submit system, which was also not
required in any Bylaws or even documented clearly on the OpenJDK
website. Yet, we were expected to use it and fix issues on whatever
the build configuration was there e.g. [0].

It feels to me like the GitHub setup brings a little equality to this
situation. Now there is better coverage and everyone has the same
access to the build systems and results, as far as I can see.

I agree with Roman & Aleksey that having a pass on this should be
a requirement. This also means making it a requirement for GitHub
Actions (GHA) to be setup before proposing a PR.

I think doing so is basic community responsibility, where you try
and minimise the effect your work has on others. It also works
both ways; if you don't break the ports of others, then they
won't break yours.

I think the burden here is being overstated. There is no requirement
to do anything to activate these tests after the initial setup; I
actually ended up testing something I didn't even file a PR for, until
I found how to filter out certain pushes to the branch! [1] The
majority of patches will pass straight away, because they are either
pure Java or don't make arch-dependent changes to the code.

What this will catch is where a new function needs to be defined for a
particular port or a particular compiler dislikes a line of code.
Given you have the build log, it is likely to be a simple fix. No-one
is expecting you to port the code to that setup; a stub will do.
You're also not in isolation; catching such things is a good time to
flag the issue to the maintainers of that port. By far the biggest
problem in my experience is that port maintainers often aren't aware
of the breakage until they discover it themselves further down the
track, so the build failure at the time of PR alone is helpful.

Where we can perhaps draw a compromise is on the systems that go
through this testing. If the systems building a particular port
regularly throw up spurious failures, or the port maintainers are
unresponsive, then it should be dropped from the setup by community
consensus. But I see no reason to abandon the whole thing because of
the hypothetical case that some port may be troublesome in the future.

If we do choose not to make this a requirement, I think it sends a
very selfish message that people only care about their own particular
setups and are quite happy to unknowingly break the work of others
without even engaging with them to fix it.

[0] https://bugs.openjdk.java.net/browse/JDK-8243114
[1] https://wiki.openjdk.java.net/display/SKARA/Testing
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From aph at redhat.com  Thu Mar 18 18:31:25 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 18 Mar 2021 18:31:25 +0000
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
 <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>
Message-ID: <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>

On 3/18/21 6:14 PM, Aleksey Shipilev wrote:
> On 3/18/21 5:51 PM, Andrew Haley wrote:
>> On 3/18/21 1:18 PM, Aleksey Shipilev wrote:
>>> Taking current state of Loom as the example: it has lots of direct uses of x86-only definitions from
>>> the shared code. As I said before, it is a fair game for non-mainline development to hack the
>>> prototypes any way they want, including focusing only on one platform at a time. But if we decide to
>>> integrate current Loom into mainline, then GHA would complain that foreign arches are not buildable,
>>> and that would point to this not-yet-reconciled cohesion between shared and arch-specific code. That
>>> is, GHA would be a very basic quality gate working as intended.
>>
>> The question is this: on whom does the buildability requirement rest?
>
> I believe pre-integration testing, including buildability checks, always rests on contributor,
> unless reviewers agree the usual rules can be relaxed. What constitutes "usual rules" with regards
> to builds/tests is codifiable into mechanical checks. GHA seems to be as good vehicle for this
> codification. So...
>
>> If we are to allow many ports into OpenJDK, and I believe we should,
>> then the burden of even stubbing things out to make sure that all
>> weird ports work is intolerable for contributors. It can not scale.
>
> ...that feeds into question which ports do we accept to GHA.
>
> "Weird ports" [1] should not be the part of it. Current list
> includes all actively maintained mainline ports: x86_64,
> x86_32, aarch64, arm32, ppc64le, s390x, zero. For which not
> only we have active maintainers, but we also have build
> instructions in OpenJDK docs, not to mention the GHA workflow
> script itself.

For avoidance of doubt, I'm very much in favour of GHA testing and
think there should be more of it, and weird ports may be included.
Information is good.

Here's how I think it could work. If there is an obvious/trivial
fix revealed by GHA testing, the committer should fix it,
Otherwise, it should be fixed by the port maintainer. In the
latter case, the committer should try to contact the port
maintainer to explain the situation. The committer isn't required
to wait for longer than X days.

That's a best effort way we can all work together, doesn't impose
undue burdens on either committers or port maintainers, and we
should all be happy to do as good citizens.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From sgehwolf at redhat.com  Thu Mar 18 18:47:28 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 18 Mar 2021 19:47:28 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
 <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>
 <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
Message-ID: <87dda2e0c54327403c181154a3452a252c8c5f86.camel@redhat.com>

On Thu, 2021-03-18 at 18:31 +0000, Andrew Haley wrote:
> On 3/18/21 6:14 PM, Aleksey Shipilev wrote:
> > On 3/18/21 5:51 PM, Andrew Haley wrote:
> > > On 3/18/21 1:18 PM, Aleksey Shipilev wrote:
> > > > Taking current state of Loom as the example: it has lots of
> > > > direct uses of x86-only definitions from
> > > > the shared code. As I said before, it is a fair game for non-
> > > > mainline development to hack the
> > > > prototypes any way they want, including focusing only on one
> > > > platform at a time. But if we decide to
> > > > integrate current Loom into mainline, then GHA would complain
> > > > that foreign arches are not buildable,
> > > > and that would point to this not-yet-reconciled cohesion
> > > > between shared and arch-specific code. That
> > > > is, GHA would be a very basic quality gate working as intended.
> > > 
> > > The question is this: on whom does the buildability requirement
> > > rest?
> > 
> > I believe pre-integration testing, including buildability checks,
> > always rests on contributor,
> > unless reviewers agree the usual rules can be relaxed. What
> > constitutes "usual rules" with regards
> > to builds/tests is codifiable into mechanical checks. GHA seems to
> > be as good vehicle for this
> > codification. So...
> > 
> > > If we are to allow many ports into OpenJDK, and I believe we
> > > should,
> > > then the burden of even stubbing things out to make sure that all
> > > weird ports work is intolerable for contributors. It can not
> > > scale.
> > 
> > ...that feeds into question which ports do we accept to GHA.
> > 
> > "Weird ports" [1] should not be the part of it. Current list
> > includes all actively maintained mainline ports: x86_64,
> > x86_32, aarch64, arm32, ppc64le, s390x, zero. For which not
> > only we have active maintainers, but we also have build
> > instructions in OpenJDK docs, not to mention the GHA workflow
> > script itself.
> 
> For avoidance of doubt, I'm very much in favour of GHA testing and
> think there should be more of it, and weird ports may be included.
> Information is good.

+1

> Here's how I think it could work. If there is an obvious/trivial
> fix revealed by GHA testing, the committer should fix it,
> Otherwise, it should be fixed by the port maintainer. In the
> latter case, the committer should try to contact the port
> maintainer to explain the situation. The committer isn't required
> to wait for longer than X days.
> 
> That's a best effort way we can all work together, doesn't impose
> undue burdens on either committers or port maintainers, and we
> should all be happy to do as good citizens.

That sounds very reasonable to me. I'm convinced a best effort approach
like this would already go a long way.

Thanks,
Severin


From shade at redhat.com  Thu Mar 18 18:54:47 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Mar 2021 19:54:47 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
 <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>
 <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
Message-ID: <2c881dd4-0bfa-a9d7-4b99-11d1910677e2@redhat.com>

On 3/18/21 7:31 PM, Andrew Haley wrote:
> Here's how I think it could work. If there is an obvious/trivial
> fix revealed by GHA testing, the committer should fix it,
> Otherwise, it should be fixed by the port maintainer. In the
> latter case, the committer should try to contact the port
> maintainer to explain the situation. The committer isn't required
> to wait for longer than X days.

Agreed, this seems like a good compromise.

This works well with the majority of problems that are easily resolvable (the point that I was 
trying to stress in this thread), while leaving the contributor with the way to sidestep a hard 
issue that only a port maintainer can resolve, *and* port maintainer gets heads-up to step in before 
the avoidable breakage is introduced.

Port-maintainer view: contributing an addendum to the large feature PR that stubs out / unbreaks the 
platform is much less stressful than fixing the post-integration build failures days after, while 
CIs are in shambles and are missing other build/test bugs.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Mar 18 19:47:59 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Mar 2021 20:47:59 +0100
Subject: Aleksey is off on two next Fridays
Message-ID: <9f8822e7-2c77-5e25-c8df-abcb6a670004@redhat.com>

Workday reminds me that carryover vacation days are about to expire.
Taking this and next Friday off.

-- 
Thanks,
-Aleksey


From stuart.marks at oracle.com  Thu Mar 18 22:03:43 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 18 Mar 2021 15:03:43 -0700
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
 <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
Message-ID: <680b906a-4889-fcf9-7b4f-964c755a2b4e@oracle.com>



On 3/18/21 1:36 AM, Aleksey Shipilev wrote:
> On 3/18/21 3:55 AM, Stuart Marks wrote:
>> On 3/17/21 6:43 AM, Aleksey Shipilev wrote:
>>> TL;DR: I view GHA as the OpenJDK-wide litmus test for the "green" master.
>>
>> I think this is premature. Who is responsible for maintaining the systems on which
>> GHA workflows run? Are they configured correctly and consistently? Who keeps the
>> configurations up to date? If they are broken, who fixes them? Do they produce
>> reliable results? etc.
> 
> I believe the answers to some of these questions are in GHA workflow history:
>    
> https://github.com/openjdk/jdk/commits/master/.github/workflows/submit.yml

Based on Magnus' message, it seems like this is a group of volunteers. While having 
people volunteer is helpful, it's not the same as being responsible for something.

> Yes, systems-wise with GHA, we are in somewhat awkward position to trust that GH 
> Cloud (Azure?) is configured correctly, runs on proper hardware, and is being 
> maintained. There is a fair amount of trust in this equation. I haven't seen that 
> trust broken in the last half a year the GHA were running for OpenJDK (both for 
> mainline JDK and Codetools projects), so I am keeping hopeful.

Well this "awkwardness" is exactly what I'm concerned about. But "trust" is I think 
the wrong concept. There's no one there to trust.

The word you're looking for is "hope". The systems are there, we're using them, they 
seem to work, a few volunteers tinker with how we use them, and we hope that continues.

> The fact that GHA is not ideal does not make it less useful. As I note in the reply 
> to Mark, the number of follow-up trivial build/test fixes had dropped palpably after 
> GHA were introduced in JDK mainline repo.

I didn't say they're not useful. In fact, they're useful in that for most developers 
they get run automatically with zero effort, and they'll probably pick up gross 
errors (like forgetting to check in a file) fairly quickly.

I object, and continue to object to GHA as a litmus test.

Well, maybe we should be clear on what you mean by a litmus test. When I read it, I 
thought, "GHA must be green before integration." If that's what you mean, then I 
would disagree with this policy. (And I note Magnus did as well.)

But if you mean something different by "litmus test", perhaps you could clarify 
that; I'm making a bunch of assumptions about what you meant that might be incorrect.

>> My main takeaway from Magnus' message is that his team doesn't have these
>> responsibilities. Ok, then who does? Or... is nobody responsible? (Seems plausible.)
> 
> Again, at present this seems to be the self-appointed duty of some OpenJDK 
> contributors, look at GHA workflow history. If the only thing missing here is formal 
> assignment to maintain this, we can solve that. I am not sure that is a problem 
> worth solving, though, based on our current experience: there are interested parties 
> that do that outside the formal assignment.

In other words, we're hoping there are sufficient volunteers to keep this thing going.

Having a volunteer crew is probably sufficient to keep it running as a convenience, 
but if it turns into a gatekeeper, then it's not sufficient.

s'marks





From stuart.marks at oracle.com  Thu Mar 18 22:19:44 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 18 Mar 2021 15:19:44 -0700
Subject: [External] : Re: Clarification regarding the GitHub Actions
 pre-submit testing
In-Reply-To: <7abcedc3-a2e4-64cc-2e13-d4254c67c7f2@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
 <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
 <7abcedc3-a2e4-64cc-2e13-d4254c67c7f2@redhat.com>
Message-ID: <2156761f-55bf-f67f-34a4-eb7b530414dc@oracle.com>



On 3/18/21 2:06 AM, Roman Kennke wrote:
> I am not quite sure why all of this even needs discussing. Besides GHA, we currently 
> have *zero* gating checks in OpenJDK workflow. Yes we used to have jdk-submit repo, 
> but that was *very* awkward. What GHA provides us is so much more useful and 
> accessible IMO.

I'm mainly objecting to (a possibly implicit) hint that GHA ought to be considered 
some kind of gating check, for the reasons I outlined in my reply to Alexey.

Or I might have misinterpreted things and there was no such suggestion; if so, ok.

I agree that GHA is much more useful and accessible than jdk-submit.

> If you don't like it, well, then I think it's ok to ignore it and rely only on 
> vendor-internal testing. My opinion is that checking GHA results and fixing obvious 
> build breakages is an action of minimal respect vs the wider OpenJDK community and 
> the various porters, and most often doesn't cost very much (or nothing at all). If 
> something shows up that doesn't look related to your change, you can still ignore 
> it, or, if you have some ideas, ping the right people.

Again, I agree, GHA is good for pointing out things like obvious build breakages.

The kind of thing I'm concerned about here is if (say) some machine off in the cloud 
that nobody in OpenJDK has control over has its multicast networking misconfigured, 
or there's a DNS outage or something, causing a bunch of tests to fail. Internally, 
if this were to happen, we can track it on an outage board, or remove misconfigured 
or faulting machines from the pool, etc. If this were to happen in GHA then ... ?

(In fact this scenario can't happen today, because AFAIK the GHA actions don't run 
the networking tests. But this scenario *will* happen when somebody gets the bright 
idea to add those tests to GHA.)

So yes, GHA is useful, but we should take it for what it is, which is a bunch of 
systems that we hope provide useful results, being maintained by volunteers.

s'marks


From mark.reinhold at oracle.com  Thu Mar 18 22:20:28 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 18 Mar 2021 15:20:28 -0700
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
 <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>
 <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
Message-ID: <20210318152028.291370240@eggemoggin.niobe.net>

2021/3/18 11:31:25 -0700, Andrew Haley <aph at redhat.com>:
> On 3/18/21 6:14 PM, Aleksey Shipilev wrote:
>> On 3/18/21 5:51 PM, Andrew Haley wrote:
>>> ...
>>> 
>>> If we are to allow many ports into OpenJDK, and I believe we should,
>>> then the burden of even stubbing things out to make sure that all
>>> weird ports work is intolerable for contributors. It can not scale.
>> 
>> ...that feeds into question which ports do we accept to GHA.
>> 
>> "Weird ports" [1] should not be the part of it. Current list
>> includes all actively maintained mainline ports: x86_64,
>> x86_32, aarch64, arm32, ppc64le, s390x, zero. For which not
>> only we have active maintainers, but we also have build
>> instructions in OpenJDK docs, not to mention the GHA workflow
>> script itself.
> 
> For avoidance of doubt, I'm very much in favour of GHA testing and
> think there should be more of it, and weird ports may be included.
> Information is good.
> 
> Here's how I think it could work. If there is an obvious/trivial
> fix revealed by GHA testing, the committer should fix it,
> Otherwise, it should be fixed by the port maintainer. In the
> latter case, the committer should try to contact the port
> maintainer to explain the situation. The committer isn't required
> to wait for longer than X days.

Two questions:

  (1) If weird ports are included in GHA testing then doesn?t that leave
      contributors with the intolerable burden of stubbing things out in
      a way that does not scale, as you wrote earlier (see above)?

  (2) If the fix is non-trivial and the committer is obliged to contact
      the port maintainer to explain the situation, what is it that you
      expect to happen before X days pass?  Is the committer supposed to
      wait for at most X days for the port maintainer to provide a fix?

> That's a best effort way we can all work together, doesn't impose
> undue burdens on either committers or port maintainers, and we
> should all be happy to do as good citizens.

A laudable goal, I agree.

I?d like to hear from other contributors on this -- especially those who
work on code that often requires architecture- or OS-specific porting
(e.g., HotSpot, core libraries).

- Mark

From neugens.limasoftware at gmail.com  Fri Mar 19 00:27:12 2021
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 19 Mar 2021 01:27:12 +0100
Subject: [External] : Re: Clarification regarding the GitHub Actions
 pre-submit testing
In-Reply-To: <2156761f-55bf-f67f-34a4-eb7b530414dc@oracle.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
 <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
 <7abcedc3-a2e4-64cc-2e13-d4254c67c7f2@redhat.com>
 <2156761f-55bf-f67f-34a4-eb7b530414dc@oracle.com>
Message-ID: <8f1f16cc-080c-490c-83c9-d61c00d4d00e@Canary>

In practice you have ?volunteers? already, those are the port maintainers.

I would expect that if an Oracle patch breaks Shenandoah for example Roman would be quick in fixing it. In the past when this happened we would notice when pulling and testing internally, now a GHA would tell before.

I don?t think the latency would increase too much so it can be an hard gate but a soft gate is better than nothing. Said Oracle engineer may decide that the fix is a trivial one liner or that it requires more work and is better to ask for a followup.

Essentially, all this already happens, GHA just makes it more explicit.

Cheers,
Mario

?
Mario Torre
Java Champion and OpenJDK contributor

PGP Key: 0BAB254E
Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E

Twitter: @neugens
Web: https://www.mario-torre.eu/
Music: https://mario-torre.bandcamp.com/

> On Thursday, Mar 18, 2021 at 23:20, Stuart Marks <stuart.marks at oracle.com (mailto:stuart.marks at oracle.com)> wrote:
>
>
> On 3/18/21 2:06 AM, Roman Kennke wrote:
> > I am not quite sure why all of this even needs discussing. Besides GHA, we currently
> > have *zero* gating checks in OpenJDK workflow. Yes we used to have jdk-submit repo,
> > but that was *very* awkward. What GHA provides us is so much more useful and
> > accessible IMO.
>
> I'm mainly objecting to (a possibly implicit) hint that GHA ought to be considered
> some kind of gating check, for the reasons I outlined in my reply to Alexey.
>
> Or I might have misinterpreted things and there was no such suggestion; if so, ok.
>
> I agree that GHA is much more useful and accessible than jdk-submit.
>
> > If you don't like it, well, then I think it's ok to ignore it and rely only on
> > vendor-internal testing. My opinion is that checking GHA results and fixing obvious
> > build breakages is an action of minimal respect vs the wider OpenJDK community and
> > the various porters, and most often doesn't cost very much (or nothing at all). If
> > something shows up that doesn't look related to your change, you can still ignore
> > it, or, if you have some ideas, ping the right people.
>
> Again, I agree, GHA is good for pointing out things like obvious build breakages.
>
> The kind of thing I'm concerned about here is if (say) some machine off in the cloud
> that nobody in OpenJDK has control over has its multicast networking misconfigured,
> or there's a DNS outage or something, causing a bunch of tests to fail. Internally,
> if this were to happen, we can track it on an outage board, or remove misconfigured
> or faulting machines from the pool, etc. If this were to happen in GHA then ... ?
>
> (In fact this scenario can't happen today, because AFAIK the GHA actions don't run
> the networking tests. But this scenario *will* happen when somebody gets the bright
> idea to add those tests to GHA.)
>
> So yes, GHA is useful, but we should take it for what it is, which is a bunch of
> systems that we hope provide useful results, being maintained by volunteers.
>
> s'marks
>

From ioi.lam at oracle.com  Fri Mar 19 00:28:38 2021
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 18 Mar 2021 17:28:38 -0700
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
Message-ID: <65317123-4a31-278c-cfd4-c5a7c4fad786@oracle.com>

One problem with GHA is the frequent false negatives. I think if we can 
reduce that, people will be more willing to trust the results of the GHA 
runs.

[1] Intermittent failures due to machine configuration. Some of those 
are network related (e.g., multi casting). Some are related to user 
privileges (process attachment). Etc.

My feeling is that such environment-sensitive tests are a very minor 
part of the overall tests. Maybe we can have a GHA-specific problem list 
to exclude these tests?

If you are touching these areas, you will need to test your changes 
using other means. However, I think this affects only a small number of 
JDK contributors.

[2] Random build failures, apparently due to toolchain variation. I've 
seen this quite a few times in the past week.

This doesn't seem to be specific to OpenJDK. I assume many other 
projects use GHA as well. How do they handle this situation?

Any other type of issues?

Thanks
- Ioi

From shade at redhat.com  Fri Mar 19 06:26:45 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 19 Mar 2021 07:26:45 +0100
Subject: Aleksey is off on two next Fridays
In-Reply-To: <9f8822e7-2c77-5e25-c8df-abcb6a670004@redhat.com>
References: <9f8822e7-2c77-5e25-c8df-abcb6a670004@redhat.com>
Message-ID: <6a9ce2f2-0c77-ef57-afe8-c1b234e7a783@redhat.com>

On 3/18/21 8:47 PM, Aleksey Shipilev wrote:
> Workday reminds me that carryover vacation days are about to expire.
> Taking this and next Friday off.

Ah, wrong list, ha :) Anyways...

-- 
Thanks,
-Aleksey


From thomas.stuefe at gmail.com  Fri Mar 19 08:44:56 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 19 Mar 2021 09:44:56 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <20210318152028.291370240@eggemoggin.niobe.net>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
 <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>
 <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
 <20210318152028.291370240@eggemoggin.niobe.net>
Message-ID: <CAA-vtUwSCZd1j3p9oFNfuDZU0v2xRygdRsCce9DrrFMujA9Jmw@mail.gmail.com>

On Thu, Mar 18, 2021 at 11:21 PM <mark.reinhold at oracle.com> wrote:

> 2021/3/18 11:31:25 -0700, Andrew Haley <aph at redhat.com>:
> > On 3/18/21 6:14 PM, Aleksey Shipilev wrote:
> >> On 3/18/21 5:51 PM, Andrew Haley wrote:
> >>> ...
> >>>
> >>> If we are to allow many ports into OpenJDK, and I believe we should,
> >>> then the burden of even stubbing things out to make sure that all
> >>> weird ports work is intolerable for contributors. It can not scale.
> >>
> >> ...that feeds into question which ports do we accept to GHA.
> >>
> >> "Weird ports" [1] should not be the part of it. Current list
> >> includes all actively maintained mainline ports: x86_64,
> >> x86_32, aarch64, arm32, ppc64le, s390x, zero. For which not
> >> only we have active maintainers, but we also have build
> >> instructions in OpenJDK docs, not to mention the GHA workflow
> >> script itself.
> >
> > For avoidance of doubt, I'm very much in favour of GHA testing and
> > think there should be more of it, and weird ports may be included.
> > Information is good.
> >
> > Here's how I think it could work. If there is an obvious/trivial
> > fix revealed by GHA testing, the committer should fix it,
> > Otherwise, it should be fixed by the port maintainer. In the
> > latter case, the committer should try to contact the port
> > maintainer to explain the situation. The committer isn't required
> > to wait for longer than X days.
>
> Two questions:
>
>   (1) If weird ports are included in GHA testing then doesn?t that leave
>       contributors with the intolerable burden of stubbing things out in
>       a way that does not scale, as you wrote earlier (see above)?
>
>
Large projects like Valhalla or Panama aside, I don't believe this is such
a harsh requirement. The vast majority of everyday fixes are platform
independent. We use a very small range of compilers (gcc, VC++, clang) so
compiler-specific issues show seldom up on just one platform only. In my
experience single-platform breakages are not that frequent. And as was
stated before are usually trivial to fix, e.g. missing includes.

Requiring build cleanliness on multiple platforms is also also a good
incentive to clean out platform dependencies. For example, a lot of work
was done recently to move unify platform-specific coding into the general
Posix layer. This improves long term maintainability. We will continue
reducing platform dependent coding this way.

  (2) If the fix is non-trivial and the committer is obliged to contact
>       the port maintainer to explain the situation, what is it that you
>       expect to happen before X days pass?  Is the committer supposed to
>       wait for at most X days for the port maintainer to provide a fix?
>
>
The port maintainer would get a short time to fix the breakage. To propose
a patch atop of that patch. I believe the maintainer could even commit
directly into the PR, though I am not sure if that works.
If the maintainer does not react, it would be fine to push the change.


> > That's a best effort way we can all work together, doesn't impose
> > undue burdens on either committers or port maintainers, and we
> > should all be happy to do as good citizens.
>
> A laudable goal, I agree.
>
> I?d like to hear from other contributors on this -- especially those who
> work on code that often requires architecture- or OS-specific porting
> (e.g., HotSpot, core libraries).
>
> - Mark
>

As for larger projects, Maurizio brought up the point of diverging feature
sets for different architectures. While this is valid, I think of this as
the lesser of two evils. Better have a VM which has the core functionality
expected from a VM, but maybe misses Shenandoah or Z or Panama, then to
have no implementation at all. Also, we have been in this place for years
already.

We want all the same, no? A broad adoption of java, lots of talent which
will come to use the language in the future, and a high quality VM. For all
that, platform breadth is important. The weird niches where the tinkerers
roam are important. E.g. I believe the fact that Java runs on a 32bit
Raspberry Pi is really a good thing. That is why I also like Zero, since it
is the bridgehead into new platforms. Beside giving Debian a VM to run on
almost all of its variants. I was happy to see Zero in GHAs.

About quality. Different compilers find different errors. I think both
32bit- and big-endian-cleanliness affect overall quality in a good way.
Bugs catched via those routes can also impact mainline architectures. I
realize that big-endian-cleanliness is probably a lost battle. But it is
really simple to build 32bit nowadays. E.g. The multiarch support on Debian
distros is excellent. Therefore I would like to see 32bit (linux x86) as a
primary platform. Not only is it simple to build, but as Alexey wrote, it
also benefits a whole range of other 32bit platforms.

Thanks, Thomas

From shade at redhat.com  Fri Mar 19 09:02:47 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 19 Mar 2021 10:02:47 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <680b906a-4889-fcf9-7b4f-964c755a2b4e@oracle.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
 <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
 <680b906a-4889-fcf9-7b4f-964c755a2b4e@oracle.com>
Message-ID: <3d53caf1-a574-b4b8-5f91-93855a85e40a@redhat.com>

On 3/18/21 11:03 PM, Stuart Marks wrote:
> Well, maybe we should be clear on what you mean by a litmus test. When I read it, I
> thought, "GHA must be green before integration." If that's what you mean, then I
> would disagree with this policy. (And I note Magnus did as well.)

And here I thought I successfully avoided the word "must" to avoid this impression. D'oh.

To me more precise, I would say "GHA should be green before integration", where "should" is as per 
ISO definition: "should" indicates a recommendation, where "a recommendation is defined as an 
"expression [...] conveying a suggested possible choice or course of action deemed to be 
particularly suitable without necessarily mentioning or excluding others."

I keep drawing parallels with jdk-submit, because I believe GHA is the spiritual successor for 
jdk-submit:
  *) Like jdk-submit, GHA is not a requirement, but a strong recommendation; Reviewers can ask for 
jdk-submit/GHA runs, and contributors are encouraged to be proactive and run jdk-submit/GHA without 
  Reviewers explicitly asking;
  *) Like jdk-submit, GHA can be skipped if you are reasonably sure your testing is comprehensive 
(i.e. you run through vendor test systems); still, the strong recommendation to run jdk-submit/GHA 
still applies;
  *) Like with jdk-submit, GHA alone is not always sufficient to cover all testing bases;
  *) Like with jdk-submit, the failures with GHA can be reasonably ignored;

In my original reply, I said "...like with jdk-submit before, you can reasonably ignore some 
failures, by rationally arguing they are not related to the current PR." [1].

After yesterday's discussion, that can be amended to "You can reasonably ignore GHA failures by 
securing the reviewers agreement that: a) failures are not related to the current PR; or b) 
failures, while related, are beyond the scope of this PR and/or contributor capabilities, and the 
breakage is, while unfortunate, intentional, known and recorded in these follow-up bugs".

I think that is a reasonable thing to do, process-wise: failures do not necessarily block 
integration, simple failures are detected and hopefully fixed before integration, complex failures 
that require followups become known right away.

(Off to enjoy my day off; to be continued on Monday...)

-- 
Thanks,
-Aleksey

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005194.html


From aph at redhat.com  Fri Mar 19 10:00:16 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Mar 2021 10:00:16 +0000
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <20210318152028.291370240@eggemoggin.niobe.net>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
 <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>
 <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
 <20210318152028.291370240@eggemoggin.niobe.net>
Message-ID: <9648d802-cf9d-c777-5c35-788d50b638a8@redhat.com>

On 3/18/21 10:20 PM, mark.reinhold at oracle.com wrote:
> 2021/3/18 11:31:25 -0700, Andrew Haley <aph at redhat.com>:
>> On 3/18/21 6:14 PM, Aleksey Shipilev wrote:
>>> On 3/18/21 5:51 PM, Andrew Haley wrote:
>>>> ...
>>>>
>>>> If we are to allow many ports into OpenJDK, and I believe we should,
>>>> then the burden of even stubbing things out to make sure that all
>>>> weird ports work is intolerable for contributors. It can not scale.
>>>
>>> ...that feeds into question which ports do we accept to GHA.
>>>
>>> "Weird ports" [1] should not be the part of it. Current list
>>> includes all actively maintained mainline ports: x86_64,
>>> x86_32, aarch64, arm32, ppc64le, s390x, zero. For which not
>>> only we have active maintainers, but we also have build
>>> instructions in OpenJDK docs, not to mention the GHA workflow
>>> script itself.
>>
>> For avoidance of doubt, I'm very much in favour of GHA testing and
>> think there should be more of it, and weird ports may be included.
>> Information is good.
>>
>> Here's how I think it could work. If there is an obvious/trivial
>> fix revealed by GHA testing, the committer should fix it,
>> Otherwise, it should be fixed by the port maintainer. In the
>> latter case, the committer should try to contact the port
>> maintainer to explain the situation. The committer isn't required
>> to wait for longer than X days.
> 
> Two questions:
> 
>   (1) If weird ports are included in GHA testing then doesn?t that leave
>       contributors with the intolerable burden of stubbing things out in
>       a way that does not scale, as you wrote earlier (see above)?

Perhaps. In that case all a contributor has to do is send a mail to
porters-dev saying "This patch may break your port." That doesn't even
need to scale out because porters-dev reaches maintainers of all ports.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From thomas.stuefe at gmail.com  Fri Mar 19 10:09:01 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 19 Mar 2021 11:09:01 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <3d53caf1-a574-b4b8-5f91-93855a85e40a@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
 <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
 <680b906a-4889-fcf9-7b4f-964c755a2b4e@oracle.com>
 <3d53caf1-a574-b4b8-5f91-93855a85e40a@redhat.com>
Message-ID: <CAA-vtUztc_oVyDffjeytmKf+DSarEDOMwGujUmrVCERSsCQ9oQ@mail.gmail.com>

>
>
> After yesterday's discussion, that can be amended to "You can reasonably
> ignore GHA failures by
> securing the reviewers agreement that: a) failures are not related to the
> current PR; or b)
> failures, while related, are beyond the scope of this PR and/or
> contributor capabilities, and the
> breakage is, while unfortunate, intentional, known and recorded in these
> follow-up bugs".
>

What about failures that are not related to the patch but prevent execution
of tests which are needed to validate the patch? We should prevent
piling untested patches upon broken ones, like in a rush before code
freeze. This is mostly an issue with independents which have no vendor
system to test.

From volker.simonis at gmail.com  Fri Mar 19 10:12:58 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 19 Mar 2021 11:12:58 +0100
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <3d53caf1-a574-b4b8-5f91-93855a85e40a@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
 <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
 <680b906a-4889-fcf9-7b4f-964c755a2b4e@oracle.com>
 <3d53caf1-a574-b4b8-5f91-93855a85e40a@redhat.com>
Message-ID: <CA+3eh10V+o-2cWGEHp_Rm=mYuS6Vt2ZNdT4adWQtAOpx21=KSQ@mail.gmail.com>

This is a very good discussion which is important to have. I want to
share my thoughts as a long-term contributor to this project (my first
changeset is from 2008) and long-term maintainer of what was called
_Secondary_ports_ like linux-{ppc64,s390} and aix-ppc64:

- First of all, I think that the current GH Actions testing is by far
the *best* system we ever had! It's not only worth supporting it but
instead we should do everything possible to improve it.
- It is also the *most democratic* system we every had because it
removes the difference between "internal" (i.e. Oracle employees) and
"external" (i.e. everybody else) Contributors which I never liked .
This distinction is obviously not an explicit part of any of the
OpenJDK project rules or bylaws but has factually existed for a long
time (e.g. in the beginning only "internal" Contributors could push
HotSpot changes and later only "internal" Contributors could see the
full results of submit-repo tests).
- From my experience, ALL Contribuors ("internal" and "external") have
ALWAYS been supportive and willing to help port maintainers to
maintain their ports in the event of breaking changes. The problem has
never been the good will and intent on the side of Contributors but
rather the absence of good tools and infrastructure.
- The hurdles for a port to be accepted into the OpenJDK mainline are
quite high and if ports are not used or supported any more they get
removed quickly (e.g. Solaris, SPARC). I'd call such ports "official"
JDK ports in contrast to ports which exist outside the OpenJDK project
or outside the main repository. As long as "official" ports can be
easily be tested/verified by GH Actions I think it is reasonable and
feasible to keep them at least buildable. For official OpenJDK ports
without GH Actions support this remains the responsibility of the
maintainers. It might be nice to have a kind of automatic notification
process for such ports in the future (e.g. special commit commands
like "/breaks-AIX"?).
- I think there's a little confusion in the previous post whether new
features need to support ALL "official" ports or if they should just
not break them. While I agree that the former requirement is excessive
and unrealistic, the latter should be a must, at least to the extent
that's easily verifiable by the automated GH Action testing. For small
changes such a requirement is usually trivially achievable. For larger
features like Loom or Valhalla the effort is a little higher but still
reasonable. Such features are developed for years and bringing the
final version into a shape which can easily by stubbed out on
unsupported platforms is not an undue request but merely a matter of
proper design. It's also not unreasonable for such features which has
been developed for several years to wait a few more weeks until the
build works on ALL "official" OpenJDK platforms.
- There were concerns about the  reliability and availability of GH
Actions. In my opinion these concerns are either invalid or they apply
just as well to the whole GitHub infrastructure we depend on. If we
trust the latter, why not the former as well? It was also mentioned
that the current GH Actions infrastructure is only maintained by
"volunteers" and that's why we can't rely on it. To me this sounds a
little like "internal"/"external" Contributor problem mentioned
before. There's nothing that prevents skeptics from jumping in and
supporting these volunteers :)

The current system is already pretty good. Aleksey's definition of how
it should be used (see below) is to the point. Of coarse there's
always room for improvements but instead of criticizing the current
system I think we should rather focus on improving it.

Best regards,
Volker

On Fri, Mar 19, 2021 at 10:03 AM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 3/18/21 11:03 PM, Stuart Marks wrote:
> > Well, maybe we should be clear on what you mean by a litmus test. When I read it, I
> > thought, "GHA must be green before integration." If that's what you mean, then I
> > would disagree with this policy. (And I note Magnus did as well.)
>
> And here I thought I successfully avoided the word "must" to avoid this impression. D'oh.
>
> To me more precise, I would say "GHA should be green before integration", where "should" is as per
> ISO definition: "should" indicates a recommendation, where "a recommendation is defined as an
> "expression [...] conveying a suggested possible choice or course of action deemed to be
> particularly suitable without necessarily mentioning or excluding others."
>
> I keep drawing parallels with jdk-submit, because I believe GHA is the spiritual successor for
> jdk-submit:
>   *) Like jdk-submit, GHA is not a requirement, but a strong recommendation; Reviewers can ask for
> jdk-submit/GHA runs, and contributors are encouraged to be proactive and run jdk-submit/GHA without
>   Reviewers explicitly asking;
>   *) Like jdk-submit, GHA can be skipped if you are reasonably sure your testing is comprehensive
> (i.e. you run through vendor test systems); still, the strong recommendation to run jdk-submit/GHA
> still applies;
>   *) Like with jdk-submit, GHA alone is not always sufficient to cover all testing bases;
>   *) Like with jdk-submit, the failures with GHA can be reasonably ignored;
>
> In my original reply, I said "...like with jdk-submit before, you can reasonably ignore some
> failures, by rationally arguing they are not related to the current PR." [1].
>
> After yesterday's discussion, that can be amended to "You can reasonably ignore GHA failures by
> securing the reviewers agreement that: a) failures are not related to the current PR; or b)
> failures, while related, are beyond the scope of this PR and/or contributor capabilities, and the
> breakage is, while unfortunate, intentional, known and recorded in these follow-up bugs".
>
> I think that is a reasonable thing to do, process-wise: failures do not necessarily block
> integration, simple failures are detected and hopefully fixed before integration, complex failures
> that require followups become known right away.
>
> (Off to enjoy my day off; to be continued on Monday...)
>
> --
> Thanks,
> -Aleksey
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005194.html
>

From Alan.Bateman at oracle.com  Fri Mar 19 14:19:16 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Mar 2021 14:19:16 +0000
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
Message-ID: <13723bbb-2449-def0-1879-4989ec43e09a@oracle.com>

On 18/03/2021 13:18, Aleksey Shipilev wrote:
> :
>
> What I am talking about is much weaker: buildability. I believe it is 
> fair to ask that when the mainline integration PR is done, the 
> arch-specific code is clearly isolated, new declarations in 
> arch-specific headers are done, their implementations are stubbed out 
> with NotImplemented(), etc.
>
> So that VM builds, and then hopefully passes old tests as much as 
> possible, and fails on new tests at sensible points where the 
> implementation is expected to be.
>
> :
>
> I hope this clarifies that I am not suggesting something drastic here. 
> I am only talking about the basic quality gate check: buildability on 
> primary/secondary ports; tier1 on primary ports.
>

Asking to keep secondary ports building if possible is not unreasonable. 
Most changes aren't massive features so if it's something small and 
trivial to avoid a follow-up (and annoying) "broken by JDK-XXXX" issue 
then it might be okay, but within reason. I think it would be unfair to 
ask someone to spend significant time on a secondary port when they have 
no access to such as system.

Maurizio pointed to the integration of the foreign linker API which went 
into JDK 16 with only support for x64 and aarch64. It builds on other 
architectures but I think the feature is DOA until he gets attention 
from port maintainers. I've no doubt there will be some cases where "not 
implemented" means the VM can't start so it can't run any tests. Is this 
useful? I'm not sure.

My personal view is that the bar for primary platforms needs to be high, 
probably more than tier1. A significant chunk of the tests in libraries 
areas are currently in tier2 and beyond. I don't know how the VMs for 
the GitHub Actions are configured but if there is firewall or other 
configuration that is blocking network connections they it could be 
annoying.

I hope this thread will come back to discussing the 
platform/ports/features that are considered primary vs. secondary, the 
32-bit ports in particular. The discussion lead may lead into the 
versions of the various tool chains too.

-Alan.

From ebresie at gmail.com  Sat Mar 20 13:46:34 2021
From: ebresie at gmail.com (Eric Bresie)
Date: Sat, 20 Mar 2021 08:46:34 -0500
Subject: Unpack200 alternatives
Message-ID: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>

On another project, there are ?modules? (not yet Java modules) that
leveraged the pack200 compression.  There are many legacy package that need
uncompressing.

Given new JDK versions have remove pack200, with the proposed way of using
jpackage or Jlink when packaging new compressed packs, but how is one
expected to unpack pack200?

Is pack compatible with another format (i.e. gzip) which could be used
instead?

Or is it preferred to use something like
https://github.com/pack200/pack200 or other offshoots?

Eric
-- 
Eric Bresie
ebresie at gmail.com

From stuart.marks at oracle.com  Tue Mar 23 06:50:44 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 22 Mar 2021 23:50:44 -0700
Subject: [External] : Re: Clarification regarding the GitHub Actions
 pre-submit testing
In-Reply-To: <3d53caf1-a574-b4b8-5f91-93855a85e40a@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
 <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
 <680b906a-4889-fcf9-7b4f-964c755a2b4e@oracle.com>
 <3d53caf1-a574-b4b8-5f91-93855a85e40a@redhat.com>
Message-ID: <5bd1b858-3b44-ca3c-460a-1ccf22f44da2@oracle.com>



On 3/19/21 2:02 AM, Aleksey Shipilev wrote:
> And here I thought I successfully avoided the word "must" to avoid this impression. 
> D'oh.
> 
> To me more precise, I would say "GHA should be green before integration", where 
> "should" is as per ISO definition: "should" indicates a recommendation, where "a 
> recommendation is defined as an "expression [...] conveying a suggested possible 
> choice or course of action deemed to be particularly suitable without necessarily 
> mentioning or excluding others."
> ...
> After yesterday's discussion, that can be amended to "You can reasonably ignore GHA 
> failures by securing the reviewers agreement that: a) failures are not related to 
> the current PR; or b) failures, while related, are beyond the scope of this PR 
> and/or contributor capabilities, and the breakage is, while unfortunate, 
> intentional, known and recorded in these follow-up bugs".
> 
> I think that is a reasonable thing to do, process-wise: failures do not necessarily 
> block integration, simple failures are detected and hopefully fixed before 
> integration, complex failures that require followups become known right away.

OK, I'm glad to hear there's some pragmatism here. What you're saying is quite 
reasonable.

Your nuanced statement, while generally agreeable (at least to me) still allows a 
situation where disagreements over expectations and responsibilities can occur. I 
think it's fairly important to be explicit about these. The reason is that while I 
think we can generally assume that most people on here are reasonable, it's not 
valid to assume that reasonable people will all come to the same conclusion on 
everything.

What makes this complicated is that the GHA submit actions aren't just one thing. 
There's a whole bunch of stuff, with lots of different configuration options about 
what gets run on which platform. It's important to make sure that decisions about 
these configurations, and changes to them, are discussed and decided openly, and 
that adjustments to expectations and responsibilities are also communicated accordingly.

Let me take a hypothetical example of enabling tier2 tests in GHA. (Just to be 
clear, nobody has proposed this. This is something I just made up.) We might want to 
do this in order to improve test coverage and to provide earlier warning of actual 
failures, especially to people outside of Oracle. However, the tier2 tests include 
networking tests, which are notoriously dependent on machine configurations, 
timeouts, etc., and thus are susceptible to intermittent failures. A consequence of 
this change would then be that the GHA board would have red spots on it more of the 
time.

If there's open discussion of this, and everyone is clear that getting better test 
coverage is worth tolerating more red on the GHA board, then that's ok. If the 
decision is NOT to enable tier2, because keeping the GHA board green is more 
important than improving test coverage, that's ok too.

What I do NOT want to see is a situation where a few people get together and decide 
to make some change, and this is a surprise to the rest of the project. This leads 
to mismatches in expectations and responsibilities. I could see the following 
conversation ensue:

  - Hey, why am I suddenly getting red spots on the GHA board?
  - Those are intermittent failures from tier2.
  - When did we start running those?
  - The other day; I think there was a message on build-dev about it.
  - Well I can't integrate since the board isn't green; what am I supposed to do now?
  - Oh, just ignore the intermittent failures, they're ok.
  - When did that rule change?
  - There was no rule change, it's accommodated by the policy expressed in the
    middle of some email from Shipilev buried in the middle of a thread on jdk-dev
    last year....
  - etc.

The way to avoid such problems is to have clear communication about changes to the 
GHA submit actions, especially those that change responsibilities of all JDK 
developers. (This would be a good topic for a Committers' Workshop, but as we know, 
circumstances have prevented these from occurring.) Meanwhile, email to jdk-dev will 
have to suffice.

s'marks

From erik.helin at oracle.com  Tue Mar 23 07:41:09 2021
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 23 Mar 2021 08:41:09 +0100
Subject: New Skara feature: dependent pull requests
Message-ID: <34c2711b-e1b3-6537-8044-2cc6fed2f7ec@oracle.com>

Hi all,

me and Robin are looking to deploy a new feature for the jdk [0] 
repository this week: dependent pull requests. Dependent pull requests 
are used when you have a change that depends on work in a pull request 
that is not yet integrated.

For an example, lets say that you are fixing a bug and realize that you 
first need to refactor a piece of code in order to make the bugfix 
cleaner. To aid reviewers you do *not* want to create a pull request 
containing both the refactoring and the bugfix - they are distinct 
changes and should be reviewed independently. You create a pull request 
for the first change, the refactoring, but then what? You cannot create 
a pull request for the bugfix only since the refactoring is not yet 
integrated. The review of the refactoring might take a while and during 
this time you cannot receive reviews for the bugfix.

Dependent pull requests will help in the above scenario. When a pull 
request is created then the Skara bots will automatically create a 
branch in the upstream repository named `pr/<ID>` where `<ID>` is the 
id of the pull request (e.g. `17`). This `pr/<ID>` branch can then be 
used as the target branch when creating a pull request. A pull request 
with a dependency is automatically targeted to the dependency's target 
branch when the dependency is integrated. For example, if the first pull 
request (with id `17`) targets the `master` branch and the second pull 
request targets the `pr/17` branch, then the second pull request will be 
automatically re-targeted to the `master` branch when the first pull 
request (with id `17`) is integrated. It is not possible to integrate a 
pull request with a dependency on an open pull request (i.e. the 
dependency must be integrated first). The branches named `pr/<ID>` are 
automatically removed when the corresponding pull request is closed.

Dependent pull requests have been enabled for a long time for the skara 
repository [1] and an example of a pull request with a dependency can be 
seen here [2].

For those of you using the Skara CLI tools [3] then `git-sync` will by 
default *not* sync branches named `pr/<ID>` to the personal fork. If it 
did then you would have to delete all `pr/<ID>` branches in your 
personal fork yourself. This default behavior can be overridden by 
passing `--branches` to `git-sync`.

Let us know on the skara-dev [4] mailing list if you have any questions!

Thanks,
Erik and Robin

[0]: https://github.com/openjdk/jdk
[1]: https://github.com/openjdk/skara
[2]: https://github.com/openjdk/skara/pull/1087
[3]: https://wiki.openjdk.java.net/display/SKARA/CLI+Tools
[4]: https://mail.openjdk.java.net/mailman/listinfo/skara-dev

From sgehwolf at redhat.com  Tue Mar 23 09:01:12 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 23 Mar 2021 10:01:12 +0100
Subject: [External] : Re: Clarification regarding the GitHub Actions
 pre-submit testing
In-Reply-To: <5bd1b858-3b44-ca3c-460a-1ccf22f44da2@oracle.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <4911935a-2ebe-3fa6-8aff-94142fb566f6@oracle.com>
 <196d7fae-3ee9-7d3f-db3b-17126fd557ae@redhat.com>
 <680b906a-4889-fcf9-7b4f-964c755a2b4e@oracle.com>
 <3d53caf1-a574-b4b8-5f91-93855a85e40a@redhat.com>
 <5bd1b858-3b44-ca3c-460a-1ccf22f44da2@oracle.com>
Message-ID: <da9b94dfca68880584c86cfdbf665ea5848bea88.camel@redhat.com>

On Mon, 2021-03-22 at 23:50 -0700, Stuart Marks wrote:
> The way to avoid such problems is to have clear communication about changes to the
> GHA submit actions, especially those that change responsibilities of
> all JDK developers. (This would be a good topic for a Committers' Workshop, but as we know, 
> circumstances have prevented these from occurring.) Meanwhile, email to jdk-dev will 
> have to suffice.

That's a good point. It seems very reasonable to seek some form of
consensus on build/test coverage changes to GHA on jdk-dev before they
go live.

+1

Thanks,
Severin


From aph at redhat.com  Tue Mar 23 09:46:58 2021
From: aph at redhat.com (Andrew Haley)
Date: Tue, 23 Mar 2021 09:46:58 +0000
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <20210318152028.291370240@eggemoggin.niobe.net>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
 <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>
 <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
 <20210318152028.291370240@eggemoggin.niobe.net>
Message-ID: <3e94c7f1-8d3e-1538-800e-3ab5c0d0b42f@redhat.com>

For some reason I didn't reply to Question 2, sorry.

On 3/18/21 10:20 PM, mark.reinhold at oracle.com wrote:
>   (2) If the fix is non-trivial and the committer is obliged to contact
>       the port maintainer to explain the situation, what is it that you
>       expect to happen before X days pass?  Is the committer supposed to
>       wait for at most X days for the port maintainer to provide a fix?

Yes, that's what I meant.

So, what about it? Does any disagree that this is fair and reasonable?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From ron.pressler at oracle.com  Tue Mar 23 12:19:44 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 23 Mar 2021 12:19:44 +0000
Subject: Unpack200 alternatives
In-Reply-To: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>
References: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>
Message-ID: <8F3C9272-485E-45EB-970A-9BA613557BA5@oracle.com>

Use the unpack200 tool of an old JDK to decompress those JARs and redistribute them before using them with a new JDK.

? Ron


> On 20 Mar 2021, at 13:46, Eric Bresie <ebresie at gmail.com> wrote:
> 
> On another project, there are ?modules? (not yet Java modules) that
> leveraged the pack200 compression.  There are many legacy package that need
> uncompressing.
> 
> Given new JDK versions have remove pack200, with the proposed way of using
> jpackage or Jlink when packaging new compressed packs, but how is one
> expected to unpack pack200?
> 
> Is pack compatible with another format (i.e. gzip) which could be used
> instead?
> 
> Or is it preferred to use something like
> https://github.com/pack200/pack200 or other offshoots?
> 
> Eric
> -- 
> Eric Bresie
> ebresie at gmail.com


From ebresie at gmail.com  Tue Mar 23 12:41:50 2021
From: ebresie at gmail.com (Eric Bresie)
Date: Tue, 23 Mar 2021 07:41:50 -0500
Subject: Unpack200 alternatives
In-Reply-To: <8F3C9272-485E-45EB-970A-9BA613557BA5@oracle.com>
References: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>
 <8F3C9272-485E-45EB-970A-9BA613557BA5@oracle.com>
Message-ID: <CAHw6w1QbWuE9M1XLVOU39wRSnQXkhK-xYbKE1k1xK08wcS_fRQ@mail.gmail.com>

Yes that is one way...

However  these are legacy modules many of which are still of use but not
actively maintained.  So the IDE is expecting to load these modules but
because internally when running with a new JDK, it can no longer unpack
these, it would require extra manual steps to resolve this or use an old
JDK to install and then revert to a newer JDK for normal use.  None of that
seems to provide an ideal user experience.  Ideally an alternative can be
identified and the application can be updated to start using the
alternative without any complications for the user.

I?m sure the counter argument is probably, this has been deprecated for
some time and the application developers should had taken this
into consideration, but that is not always as cut and dry.  With the
frequency of releases, that doesn?t guarantee that projects will be able to
migrate immediately.  Migrating between JDK various on a massive project is
not necessarily an easy task nor is it potentially feasible when working
with volunteer effort without the resources of a fee/service based
development model.

It would have been nice to have the ?removed? functionality , prior to
actual removal, get donated (including any potential licensing concerns) so
it can help in migrating and it can be maintained with any official
documentation for migrating reference the new open product for those that
may need it.  I guess the previously mentioned github project is a fork
prior to this so maybe that is the way forward.

Eric

On Tue, Mar 23, 2021 at 7:19 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

> Use the unpack200 tool of an old JDK to decompress those JARs and
> redistribute them before using them with a new JDK.
>
> ? Ron
>
>
> > On 20 Mar 2021, at 13:46, Eric Bresie <ebresie at gmail.com> wrote:
> >
> > On another project, there are ?modules? (not yet Java modules) that
> > leveraged the pack200 compression.  There are many legacy package that
> need
> > uncompressing.
> >
> > Given new JDK versions have remove pack200, with the proposed way of
> using
> > jpackage or Jlink when packaging new compressed packs, but how is one
> > expected to unpack pack200?
> >
> > Is pack compatible with another format (i.e. gzip) which could be used
> > instead?
> >
> > Or is it preferred to use something like
> > https://github.com/pack200/pack200 or other offshoots?
> >
> > Eric
> > --
> > Eric Bresie
> > ebresie at gmail.com
>
> --
Eric Bresie
ebresie at gmail.com

From alex.buckley at oracle.com  Tue Mar 23 17:26:08 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 23 Mar 2021 10:26:08 -0700
Subject: Unpack200 alternatives
In-Reply-To: <CAHw6w1QbWuE9M1XLVOU39wRSnQXkhK-xYbKE1k1xK08wcS_fRQ@mail.gmail.com>
References: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>
 <8F3C9272-485E-45EB-970A-9BA613557BA5@oracle.com>
 <CAHw6w1QbWuE9M1XLVOU39wRSnQXkhK-xYbKE1k1xK08wcS_fRQ@mail.gmail.com>
Message-ID: <9200cc14-6bc3-ce29-11d1-894f7978b69e@oracle.com>

Eric,

On 3/23/2021 5:41 AM, Eric Bresie wrote:
> ... With the frequency of releases, that doesn?t guarantee that 
> projects will be able to migrate immediately.  Migrating between JDK 
> various [presumably you meant "variations"?] on a massive project is
> not necessarily an easy task nor is it potentially feasible when
> working with volunteer effort ...

Is your "massive project" listed at 
https://wiki.openjdk.java.net/display/quality/Quality+Outreach ?

Can you share some of the problems migrating from JDK N to JDK N+1? We 
understand that JDK 8 to 9 (or straight to 11) can be tough, but 
migrating from JDK 15 to 16 should be straightforward.

Alex

From ron.pressler at oracle.com  Tue Mar 23 21:04:19 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 23 Mar 2021 21:04:19 +0000
Subject: [External] : Re: Unpack200 alternatives
In-Reply-To: <CAHw6w1QbWuE9M1XLVOU39wRSnQXkhK-xYbKE1k1xK08wcS_fRQ@mail.gmail.com>
References: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>
 <8F3C9272-485E-45EB-970A-9BA613557BA5@oracle.com>
 <CAHw6w1QbWuE9M1XLVOU39wRSnQXkhK-xYbKE1k1xK08wcS_fRQ@mail.gmail.com>
Message-ID: <6289C2EC-F74D-413D-8803-8B558C647A16@oracle.com>

I?m not sure I understand the issue. The JARs don?t need to be actively maintained to be decompressed,
and there is no code-level migration required; we?re talking about an offline tool. Decompress them once, 
put them in a public or private Maven repo, and then they can be used by new and old JDKs alike.

BTW, the removed functionality is open-source, with an established license, and anyone can fork
it in accordance with that license, as it seems someone already has.

As to the more general pain of migration, the encapsulation effort that is underway (JEPs 396 and 403), is
intended to address exactly that (as well as tools like jdeprscan).

? Ron


> On 23 Mar 2021, at 12:41, Eric Bresie <ebresie at gmail.com> wrote:
> 
> Yes that is one way...
> 
> However  these are legacy modules many of which are still of use but not actively maintained.  So the IDE is expecting to load these modules but because internally when running with a new JDK, it can no longer unpack these, it would require extra manual steps to resolve this or use an old JDK to install and then revert to a newer JDK for normal use.  None of that seems to provide an ideal user experience.  Ideally an alternative can be identified and the application can be updated to start using the alternative without any complications for the user.
> 
> I?m sure the counter argument is probably, this has been deprecated for some time and the application developers should had taken this into consideration, but that is not always as cut and dry.  With the frequency of releases, that doesn?t guarantee that projects will be able to migrate immediately.  Migrating between JDK various on a massive project is not necessarily an easy task nor is it potentially feasible when working with volunteer effort without the resources of a fee/service based development model.
> 
> It would have been nice to have the ?removed? functionality , prior to actual removal, get donated (including any potential licensing concerns) so it can help in migrating and it can be maintained with any official documentation for migrating reference the new open product for those that may need it.  I guess the previously mentioned github project is a fork prior to this so maybe that is the way forward.
> 
> Eric
> 
> On Tue, Mar 23, 2021 at 7:19 AM Ron Pressler <ron.pressler at oracle.com> wrote:
> Use the unpack200 tool of an old JDK to decompress those JARs and redistribute them before using them with a new JDK.
> 
> ? Ron
> 
> 
> > On 20 Mar 2021, at 13:46, Eric Bresie <ebresie at gmail.com> wrote:
> > 
> > On another project, there are ?modules? (not yet Java modules) that
> > leveraged the pack200 compression.  There are many legacy package that need
> > uncompressing.
> > 
> > Given new JDK versions have remove pack200, with the proposed way of using
> > jpackage or Jlink when packaging new compressed packs, but how is one
> > expected to unpack pack200?
> > 
> > Is pack compatible with another format (i.e. gzip) which could be used
> > instead?
> > 
> > Or is it preferred to use something like
> > https://github.com/pack200/pack200 or other offshoots?
> > 
> > Eric
> > -- 
> > Eric Bresie
> > ebresie at gmail.com
> 
> -- 
> Eric Bresie
> ebresie at gmail.com


From shade at redhat.com  Thu Mar 25 09:35:05 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 25 Mar 2021 10:35:05 +0100
Subject: RFC: C1/C2 support for Blackholes
Message-ID: <6b1f4881-f56e-9a1d-be67-350ce5a0a854@redhat.com>

Hi,

Brian asked me to bring this discussion forward to jdk-dev at .

=== Synopsis

This is the "C1/C2 support for Blackholes" RFE that briefly discusses the motivation:
   https://bugs.openjdk.java.net/browse/JDK-8259316

This is the patch that implements the RFE in both C1 and C2:
   https://github.com/openjdk/jdk/pull/2024

Aside: Graal seems to do a similar thing for quite a while, which probably means that the same JMH 
nano-benchmark on C1/C2 and Graal behave differently due to [the absence of] this infrastructure 
overhead.

The implementation discussion seems to have reached the consensus (I see some comments from Doug, 
and there are some questions about testing). The post-integration discussion seemed to revolve 
around the major question: what should the interface look like? There was a discussion in the 
retroactive CSR: https://bugs.openjdk.java.net/browse/JDK-8257827 -- which eventually lead to the 
backout from JDK 16 for reconsideration for JDK 17.

Here, I would like to have a bit of discussion about it. To start from the clean slate, I submitted 
the new CSR that captures my current thinking:
   https://bugs.openjdk.java.net/browse/JDK-8264133

This thread is probably a better way to mull over the questions without piling on less-structured 
comments onto the CSR issue. In other words, let's discuss the interface and approach here.

Current implementation introduces a new sub-command, -XX:CompileCommand=blackhole,<method>. It is 
handy, because CompileCommand is a non-standard interface that: a) allows us to experiment with the 
implementation, while leaving us the escape hatch to revert it without raising hard compatibility 
questions; and b) JMH already uses to opt-in to inline/dontline hints for its infrastructure, thus 
requiring no further work to support.

Recurrent questions about this:

=== Should this be a public API instead?

Probably yes, at some point in the future.

The experience with implementing blackhole support in C2 (and doing follow-up bugfixes) tells me 
that it is hard to get it right and clean. I did 4 iterations of C2 code, every time being 
completely sure I did it right! There are interesting failure modes if the support is implemented 
incorrectly. There are probably other not-yet-identified corner cases, which would manifest on more 
complicated code shapes.

This is why I believe real-world experimental testing is important before we even consider 
graduating this into standard public API.

While it is too early to think about how such an API would look like, I believe it would take 
similar form as what JMH ships with (probably with consideration for value^W inline^W primitive 
types and whatever other feature shows up by then):
 
https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153

=== Should this (not) be an experimental option?

We can technically turn currently-Experimental CompileCommand=blackhole into Diagnostic one, which 
would move it out of formal requirement for having the CSR. Still, it would be an abuse of the 
process to avoid the compatibility discussion.

We can technically drop the Experimental flag from CompileCommand=blackhole completely, but this 
would formally corner us into compatibility questions, should we decide to drop it (either due to 
complete failure, or due to graduation into standard public APIs).

I am leaning towards keeping CompileCommand=blackhole "Experimental".

=== Should this be available/maintained in (previous) LTSes?

Let's face it: the majority of developer population is firmly sitting on LTSes. If we want to see 
more of the real world testing in JMH that results in prompt feedback, we should probably consider 
making this available/maintained in LTSes.

This also makes performance work on LTSes quite a bit more convenient.

17u is the easiest thing to do here. If the initial patch lands in 17, we would only need to do 
touch-ups, if any. At any given point, we should be able to remove/disable the blackhole support, in 
case it runs into irreconcilable problems.

Previous LTS releases are a bit harder, because doing this kind of support would require backporting 
the initial patch. Luckily, it is not hard to do. I proved it to myself the following way: 
8u/11u/16u testing binaries I ship at builds.shipilev.net include the experimental backports of 
current patch, and they proved to be no hassle to maintain. It is still an open question whether JDK 
Updates maintainers would accept these patches upstream. Anyhow, the same stance as for 17u stands: 
at any given moment, we should be able to remove/disable it.

Experimental CompileCommand=blackhole gives us a way to retract stuff.

=== Plans

Based on the considerations above, these are the plans I have in mind for this feature.

Short-term plan:
   a) Land the CompileCommand=blackhole support in JDK 17;
   b) Maintain the CompileCommand=blackhole support in JDK 17u, backporting fixes from mainline, if any;

Middle-term plan:
   c) (optimistically) Propose the CompileCommand=blackhole support to JDK 11u and JDK 8u (and maybe 
even 15u, 13u, time permitting), backporting fixes from mainline, if any;

...and long-term plan is predicated on real-world success and stability of C1/C2 implementations. I 
would say that once JMH uses in the wild start to de-facto default to these compiler-assisted 
Blackholes, we can claim the experiment is a success. I expect it to require at least a year since 
the LTS releases.

If experiment is successful, the long-term plan kicks in:
   d) Propose the public Blackhole API;
   e) Drop the CompileCommand=blackhole support in then-current JDK releases;
   f) Continue with supporting public Blackhole APIs in then-actual LTSes;
   g) Continue with supporting CompileCommand=blackhole in previous LTSes, waiting them to die off;

If experiment fails, the recovery plan kicks in:
   h) Drop the CompileCommand=blackhole from every actively maintained JDK release;

How does all this sound?

-- 
Thanks,
-Aleksey


From brian.goetz at oracle.com  Thu Mar 25 14:12:29 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 25 Mar 2021 10:12:29 -0400
Subject: RFC: C1/C2 support for Blackholes
In-Reply-To: <6b1f4881-f56e-9a1d-be67-350ce5a0a854@redhat.com>
References: <6b1f4881-f56e-9a1d-be67-350ce5a0a854@redhat.com>
Message-ID: <9e12ec30-4d60-1255-8286-50eadc619b87@oracle.com>



> The implementation discussion seems to have reached the consensus (I 
> see some comments from Doug, and there are some questions about 
> testing). The post-integration discussion seemed to revolve around the 
> major question: what should the interface look like? There was a 
> discussion in the retroactive CSR: 
> https://bugs.openjdk.java.net/browse/JDK-8257827 -- which eventually 
> lead to the backout from JDK 16 for reconsideration for JDK 17.

To put it another way: if this feature is "experimental", what are the 
plans to have it eventually graduate from that status, since 
"experimental" should not be (though sometimes has been) a permanent 
state.? There is precedent for public API point that "do nothing" (such 
as `reachabilityFence`) but provide hints to the VM, and as you point 
out, having one common way to do this is better than each JVM having its 
own way to do this.? It may be too early to make this choice, but it's 
not too early to start thinking about the options, so I'm glad to see 
this discussion restarted.

> While it is too early to think about how such an API would look like, 
> I believe it would take similar form as what JMH ships with (probably 
> with consideration for value^W inline^W primitive types and whatever 
> other feature shows up by then):
>
> https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153 
>

In theory, since all primitive classes will be subtypes of Object, we 
could in theory get away with a single bh(Object) method for all the 
primitive classes.? Whether that is actually true when you get down 
below the bytecode level remains to be seen.

> === Should this (not) be an experimental option?
>
> We can technically turn currently-Experimental 
> CompileCommand=blackhole into Diagnostic one, which would move it out 
> of formal requirement for having the CSR. Still, it would be an abuse 
> of the process to avoid the compatibility discussion.
>
> We can technically drop the Experimental flag from 
> CompileCommand=blackhole completely, but this would formally corner us 
> into compatibility questions, should we decide to drop it (either due 
> to complete failure, or due to graduation into standard public APIs).
>
> I am leaning towards keeping CompileCommand=blackhole "Experimental".

Agree.? This feels like an experimental feature (we're still evaluating 
how it works) and it does not feel like a diagnostic feature (these are 
intended for diagnosis of the VM, not user code.)

> Based on the considerations above, these are the plans I have in mind 
> for this feature.
>
> Short-term plan:
> ? a) Land the CompileCommand=blackhole support in JDK 17;
> ? b) Maintain the CompileCommand=blackhole support in JDK 17u, 
> backporting fixes from mainline, if any;
>
> Middle-term plan:
> ? c) (optimistically) Propose the CompileCommand=blackhole support to 
> JDK 11u and JDK 8u (and maybe even 15u, 13u, time permitting), 
> backporting fixes from mainline, if any;
>
> ...and long-term plan is predicated on real-world success and 
> stability of C1/C2 implementations. I would say that once JMH uses in 
> the wild start to de-facto default to these compiler-assisted 
> Blackholes, we can claim the experiment is a success. I expect it to 
> require at least a year since the LTS releases.
>
> If experiment is successful, the long-term plan kicks in:
> ? d) Propose the public Blackhole API;
> ? e) Drop the CompileCommand=blackhole support in then-current JDK 
> releases;
> ? f) Continue with supporting public Blackhole APIs in then-actual LTSes;
> ? g) Continue with supporting CompileCommand=blackhole in previous 
> LTSes, waiting them to die off;
>
> If experiment fails, the recovery plan kicks in:
> ? h) Drop the CompileCommand=blackhole from every actively maintained 
> JDK release;
>
> How does all this sound?

This sounds like a responsible plan.? (I assume that somewhere between 
"d" and "e" JMH acquires the ability to use both, depending on what it 
finds in the currently running VM.)





From shade at redhat.com  Thu Mar 25 14:50:05 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 25 Mar 2021 15:50:05 +0100
Subject: RFC: C1/C2 support for Blackholes
In-Reply-To: <9e12ec30-4d60-1255-8286-50eadc619b87@oracle.com>
References: <6b1f4881-f56e-9a1d-be67-350ce5a0a854@redhat.com>
 <9e12ec30-4d60-1255-8286-50eadc619b87@oracle.com>
Message-ID: <37970ddf-4831-00c2-042b-f4b60be72144@redhat.com>

On 3/25/21 3:12 PM, Brian Goetz wrote:
> In theory, since all primitive classes will be subtypes of Object, we
> could in theory get away with a single bh(Object) method for all the
> primitive classes.? Whether that is actually true when you get down
> below the bytecode level remains to be seen.

Speaking from JMH Blackhole experience, generic boxing is no-go here.

Mostly because bh.consume(Object) tries to perform freaky/identity-sensitive operations on the 
argument, in attempt to break scalar replacement of the object. Which is exactly the opposite of 
what we want for primitive consumes: we want optimizing compilers to eliminate the box, giving us 
the unboxed value to blackhole. This is why JMH Blackhole provides primitive overloads.

So it is an open question how primitive types fit into this picture. It would be nice to answer it 
in Valhalla context, if only to make current Valhalla nano-benchmarking more precise. Something like 
explaining to JIT compilers that boxing is unnecessary in that particular case, and instead it all 
the primitive type components should be blackholed. Or some such.

> This sounds like a responsible plan.? (I assume that somewhere between
> "d" and "e" JMH acquires the ability to use both, depending on what it
> finds in the currently running VM.)

Yes, of course. Once something is public API and we are sure compiler support is sane, we can just 
default to public API when available.

Technically, that is not hard to do. JMH lets users choose between "normal" and "compiler-command" 
(experimental) Blackholes, without apparent performance degradation. That switch can be extended to 
choose the public API method too. I don't believe it would require a lot of (byte)code gymnastics: 
the "public API" path would not be taken by legacy JDKs, and so we don't have to care about 
AbstractMethodError-s and such. JCStress shows that you can even mock out some "JDK" classes to keep 
the project buildable on non-latest JDKs that do not have the methods yet.

-- 
Thanks,
-Aleksey


From Rony.Flatscher at wu.ac.at  Thu Mar 25 17:16:49 2021
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Thu, 25 Mar 2021 18:16:49 +0100
Subject: JEP proposed to target JDK 17: 398: Deprecate the Applet API for
 Removal
In-Reply-To: <20210316183744.375C43DB770@eggemoggin.niobe.net>
References: <20210316183744.375C43DB770@eggemoggin.niobe.net>
Message-ID: <3ec99ca7-245a-ebce-31bb-0f7da36ba6fd@wu.ac.at>

If the Applet API gets removed from the OpenJDK, then there will be no reason and possibility in the
future to (re-)add a Java plugin to browsers anymore.

Also, it might be interesting to consider adding Applet API support to the JavaFX WebView (in
essence a web browser) where the Applet API could still be applied. Something maybe like
<https://github.com/brunoborges/webfx>.

---rony


On 16.03.2021 19:37, mark.reinhold at oracle.com wrote:

> The following JEP is proposed to target JDK 17:
>
>   398: Deprecate the Applet API for Removal
>        https://openjdk.java.net/jeps/398
>
>   Summary: Deprecate the Applet API for removal.  It is essentially
>   irrelevant since all web-browser vendors have either removed support
>   for Java browser plug-ins or announced plans to do so.
>
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Tuesday, 23 March, or if they?re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I?ll target this JEP to JDK 17.
>
> - Mark
>
>
> [1] https://openjdk.java.net/census#jdk
> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html


From kevin.rushforth at oracle.com  Thu Mar 25 19:55:10 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 25 Mar 2021 12:55:10 -0700
Subject: JEP proposed to target JDK 17: 398: Deprecate the Applet API for
 Removal
In-Reply-To: <3ec99ca7-245a-ebce-31bb-0f7da36ba6fd@wu.ac.at>
References: <20210316183744.375C43DB770@eggemoggin.niobe.net>
 <3ec99ca7-245a-ebce-31bb-0f7da36ba6fd@wu.ac.at>
Message-ID: <730866cd-8438-4416-07bc-ad526c9e9df9@oracle.com>

We have no plan to ever add Applet Plugin support back into the JDK. We 
also have no plans for applet support in JavaFX WebView as a core 
feature, but even if we did add something like that (which seems 
unlikely), I can't think of a good reason why it would need (or want) to 
use the java.applet.Applet or javax.swing.JApplet classes.

Worth noting is that the Applet API will be present in JDK 17. They are 
being deprecated for removal in a future (post-17) release.

-- Kevin


On 3/25/2021 10:16 AM, Rony G. Flatscher wrote:
> If the Applet API gets removed from the OpenJDK, then there will be no reason and possibility in the
> future to (re-)add a Java plugin to browsers anymore.
>
> Also, it might be interesting to consider adding Applet API support to the JavaFX WebView (in
> essence a web browser) where the Applet API could still be applied. Something maybe like
> <https://github.com/brunoborges/webfx>.
>
> ---rony
>
>
> On 16.03.2021 19:37, mark.reinhold at oracle.com wrote:
>
>> The following JEP is proposed to target JDK 17:
>>
>>    398: Deprecate the Applet API for Removal
>>         https://openjdk.java.net/jeps/398
>>
>>    Summary: Deprecate the Applet API for removal.  It is essentially
>>    irrelevant since all web-browser vendors have either removed support
>>    for Java browser plug-ins or announced plans to do so.
>>
>> Feedback on this proposal from JDK Project Committers and Reviewers [1]
>> is more than welcome, as are reasoned objections.  If no such objections
>> are raised by 23:59 UTC on Tuesday, 23 March, or if they?re raised and
>> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
>> I?ll target this JEP to JDK 17.
>>
>> - Mark
>>
>>
>> [1] https://openjdk.java.net/census#jdk
>> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html


From m.zajaczkowski at gmail.com  Thu Mar 25 20:20:09 2021
From: m.zajaczkowski at gmail.com (=?UTF-8?Q?Marcin_Zaj=c4=85czkowski?=)
Date: Thu, 25 Mar 2021 21:20:09 +0100
Subject: Make "-parameters" enabled by default?
Message-ID: <c8d538be-78a1-82f2-a0b7-d75203086bdb@gmail.com>

Tl;TD. JEP 118 [1] has added "-parameters" to Java 8 back in 2014 to
have parameter names available at runtime. In 2021, backward
compatibility of the bytecode-related tools should not be a big problem,
so maybe to simplify the things, it could be enabled by default?


Hi, I'm not sure this is the best place to touch such as topics, so
please show me a better way (or a "procedure") in a case that is not. I
also wasn't able to find a discussion about that, however, the code
words in the results were usually related to the default parameters
support, so I might miss something.

I have bumped into that idea, trying to explain why in one (Gradle)
project named parameters were available out of the box, but in another I
had to explicitly add "-parameters" to the compiler arguments. In the
end, it turned out that (here) the Spring Boot plugin enables
"-parameters" in the whole project if used (which looking at its usage
is an useful idea). First, I thought, I would be good to make it a
default behavior in all the Gradle projects, but after a moment, I
realized that behavior enabled by default would be much more natural
(and beneficial) for all the JDK project in general.

I realize that "-parameters" modifies bytecode structure in a non
backward compatible way. However, my first idea about potential problems
is related to the bytecode manipulating tools (such as ASM), which had
over 7 years to start supporting it and probably those versions are
already available in the majority of actively developed projects (at
least those who would like to be compilable with Java 17 :) ). As a
result, maybe it would be a good idea to have it available in one of the
further OpenJDK versions? Java 17 - as LTS - is definitely a good
candidate for that, but looking at the schedule it might be hard to get.

Of course, I might miss something obvious, what make my idea problematic
to implement (even with a switch to disable a default behavior). In that
case, please don't hesitate to write about that. On the other hand, if
you - by any chance - like that idea, please let me know, what is a
procedure to follow to make it (eventually) happen.

[1] - https://openjdk.java.net/jeps/118


Marcin Zaj?czkowski

From alex.buckley at oracle.com  Thu Mar 25 20:43:28 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 25 Mar 2021 13:43:28 -0700
Subject: Make "-parameters" enabled by default?
In-Reply-To: <c8d538be-78a1-82f2-a0b7-d75203086bdb@gmail.com>
References: <c8d538be-78a1-82f2-a0b7-d75203086bdb@gmail.com>
Message-ID: <ef2ded04-cf4e-6d87-32ea-e22000cc91ad@oracle.com>

On 3/25/2021 1:20 PM, Marcin Zaj?czkowski wrote:
> Tl;TD. JEP 118 has added "-parameters" to Java 8 back in 2014 to
> have parameter names available at runtime. In 2021, backward
> compatibility of the bytecode-related tools should not be a big problem,
> so maybe to simplify the things, it could be enabled by default?

There was never a compatibility problem with including the 
MethodParameters attribute in a class file, which is what `javac 
-parameters` does.

The attribute was excluded for reasons of policy, which largely still 
apply. As I wrote in May 2013 when someone asked "JEP-118: Why are 
parameter names not mandatory?" [1]:

"The bottom line is that for every programmer you please by including 
parameter names by default, you intensely anger another. Some people 
dislike the extra class file size; some dislike the new compatibility 
surface; some regard it as exposing sensitive information."

[1] 
https://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-May/000200.html

Quoting from the referenced PDF, now at [2]:

"Oracle believes the ability to retrieve parameter names at run time 
loses much of its value if parameters are "opted out" of class file 
storage by default, and instead have to "opt in" by some syntactic 
means. Unfortunately, the static and dynamic footprint of storing 
parameter names will be an unwelcome surprise for many class file 
producers and consumers. Also, storing parameter names by default means 
that new information will be exposed about security-sensitive methods, 
e.g. parameter names like `secret` or `password`. In light of these 
concerns, Oracle in Java SE 8 will consider parameter names as "opted 
out" of class file storage by default."

[2] https://cr.openjdk.java.net/~abuckley/jep120/8misc.pdf

Alex

From m.zajaczkowski at gmail.com  Thu Mar 25 21:05:09 2021
From: m.zajaczkowski at gmail.com (=?UTF-8?Q?Marcin_Zaj=c4=85czkowski?=)
Date: Thu, 25 Mar 2021 22:05:09 +0100
Subject: Make "-parameters" enabled by default?
In-Reply-To: <ef2ded04-cf4e-6d87-32ea-e22000cc91ad@oracle.com>
References: <c8d538be-78a1-82f2-a0b7-d75203086bdb@gmail.com>
 <ef2ded04-cf4e-6d87-32ea-e22000cc91ad@oracle.com>
Message-ID: <bbc2237d-0163-c797-89a0-e26856a8a8cd@gmail.com>

On 2021-03-25 21:43, Alex Buckley wrote:
> On 3/25/2021 1:20 PM, Marcin Zaj?czkowski wrote:
>> TL;TR. JEP 118 has added "-parameters" to Java 8 back in 2014 to
>> have parameter names available at runtime. In 2021, backward
>> compatibility of the bytecode-related tools should not be a big problem,
>> so maybe to simplify the things, it could be enabled by default?
> 
> There was never a compatibility problem with including the
> MethodParameters attribute in a class file, which is what `javac
> -parameters` does.
> 
> The attribute was excluded for reasons of policy, which largely still
> apply. As I wrote in May 2013 when someone asked "JEP-118: Why are
> parameter names not mandatory?" [1]:
> 
> "The bottom line is that for every programmer you please by including
> parameter names by default, you intensely anger another. Some people
> dislike the extra class file size; some dislike the new compatibility
> surface; some regard it as exposing sensitive information."

Thanks Alex for your explanations. I have missed that document.

Marcin


> 
> [1]
> https://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-May/000200.html
> 
> 
> Quoting from the referenced PDF, now at [2]:
> 
> "Oracle believes the ability to retrieve parameter names at run time
> loses much of its value if parameters are "opted out" of class file
> storage by default, and instead have to "opt in" by some syntactic
> means. Unfortunately, the static and dynamic footprint of storing
> parameter names will be an unwelcome surprise for many class file
> producers and consumers. Also, storing parameter names by default means
> that new information will be exposed about security-sensitive methods,
> e.g. parameter names like `secret` or `password`. In light of these
> concerns, Oracle in Java SE 8 will consider parameter names as "opted
> out" of class file storage by default."
> 
> [2] https://cr.openjdk.java.net/~abuckley/jep120/8misc.pdf
> 
> Alex

From erik.helin at oracle.com  Fri Mar 26 12:47:52 2021
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 26 Mar 2021 13:47:52 +0100
Subject: New Skara feature: dependent pull requests
In-Reply-To: <34c2711b-e1b3-6537-8044-2cc6fed2f7ec@oracle.com>
References: <34c2711b-e1b3-6537-8044-2cc6fed2f7ec@oracle.com>
Message-ID: <b4b15085-08ee-3cae-139e-e180b9bfd1e6@oracle.com>

On 3/23/21 8:41 AM, Erik Helin wrote:
> Hi all,
> 
> me and Robin are looking to deploy a new feature for the jdk [0] 
> repository this week: dependent pull requests. Dependent pull requests 
> are used when you have a change that depends on work in a pull request 
> that is not yet integrated.

We have now deployed the dependent pull requests feature for the jdk [0] 
repository. Feel free to try it out and let us know if you have any 
feedback!

Hope you all have a great weekend,
Erik & Robin

[0]: https://github.com/openjdk/jdk

From ron.pressler at oracle.com  Fri Mar 26 13:11:30 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 26 Mar 2021 13:11:30 +0000
Subject: [External] : Re: Unpack200 alternatives
In-Reply-To: <6289C2EC-F74D-413D-8803-8B558C647A16@oracle.com>
References: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>
 <8F3C9272-485E-45EB-970A-9BA613557BA5@oracle.com>
 <CAHw6w1QbWuE9M1XLVOU39wRSnQXkhK-xYbKE1k1xK08wcS_fRQ@mail.gmail.com>
 <6289C2EC-F74D-413D-8803-8B558C647A16@oracle.com>
Message-ID: <ADC4015C-0004-4FD0-BE15-CC4BF0DDA35C@oracle.com>

P.S.

You can run the following command with JDK 11 and get a self-contained, <30MB image, which you can use to run pack200 regardless of your development environment:

    jdk11/bin/jlink --output pack200runtime --compress=2 --no-header-files --no-man-pages --add-modules jdk.pack

(Then pack200runtime/bin/pack200 ?)

? Ron


> On 23 Mar 2021, at 21:04, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> I?m not sure I understand the issue. The JARs don?t need to be actively maintained to be decompressed,
> and there is no code-level migration required; we?re talking about an offline tool. Decompress them once, 
> put them in a public or private Maven repo, and then they can be used by new and old JDKs alike.
> 
> BTW, the removed functionality is open-source, with an established license, and anyone can fork
> it in accordance with that license, as it seems someone already has.
> 
> As to the more general pain of migration, the encapsulation effort that is underway (JEPs 396 and 403), is
> intended to address exactly that (as well as tools like jdeprscan).
> 
> ? Ron
> 
> 
>> On 23 Mar 2021, at 12:41, Eric Bresie <ebresie at gmail.com> wrote:
>> 
>> Yes that is one way...
>> 
>> However  these are legacy modules many of which are still of use but not actively maintained.  So the IDE is expecting to load these modules but because internally when running with a new JDK, it can no longer unpack these, it would require extra manual steps to resolve this or use an old JDK to install and then revert to a newer JDK for normal use.  None of that seems to provide an ideal user experience.  Ideally an alternative can be identified and the application can be updated to start using the alternative without any complications for the user.
>> 
>> I?m sure the counter argument is probably, this has been deprecated for some time and the application developers should had taken this into consideration, but that is not always as cut and dry.  With the frequency of releases, that doesn?t guarantee that projects will be able to migrate immediately.  Migrating between JDK various on a massive project is not necessarily an easy task nor is it potentially feasible when working with volunteer effort without the resources of a fee/service based development model.
>> 
>> It would have been nice to have the ?removed? functionality , prior to actual removal, get donated (including any potential licensing concerns) so it can help in migrating and it can be maintained with any official documentation for migrating reference the new open product for those that may need it.  I guess the previously mentioned github project is a fork prior to this so maybe that is the way forward.
>> 
>> Eric
>> 
>> On Tue, Mar 23, 2021 at 7:19 AM Ron Pressler <ron.pressler at oracle.com> wrote:
>> Use the unpack200 tool of an old JDK to decompress those JARs and redistribute them before using them with a new JDK.
>> 
>> ? Ron
>> 
>> 
>>> On 20 Mar 2021, at 13:46, Eric Bresie <ebresie at gmail.com> wrote:
>>> 
>>> On another project, there are ?modules? (not yet Java modules) that
>>> leveraged the pack200 compression.  There are many legacy package that need
>>> uncompressing.
>>> 
>>> Given new JDK versions have remove pack200, with the proposed way of using
>>> jpackage or Jlink when packaging new compressed packs, but how is one
>>> expected to unpack pack200?
>>> 
>>> Is pack compatible with another format (i.e. gzip) which could be used
>>> instead?
>>> 
>>> Or is it preferred to use something like
>>> https://github.com/pack200/pack200 or other offshoots?
>>> 
>>> Eric
>>> -- 
>>> Eric Bresie
>>> ebresie at gmail.com
>> 
>> -- 
>> Eric Bresie
>> ebresie at gmail.com
> 


From weijun.wang at oracle.com  Fri Mar 26 13:42:42 2021
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Fri, 26 Mar 2021 13:42:42 +0000
Subject: New Skara feature: dependent pull requests
In-Reply-To: <b4b15085-08ee-3cae-139e-e180b9bfd1e6@oracle.com>
References: <34c2711b-e1b3-6537-8044-2cc6fed2f7ec@oracle.com>
 <b4b15085-08ee-3cae-139e-e180b9bfd1e6@oracle.com>
Message-ID: <DE07EEA7-29D2-4F62-BF2F-D23F5DA25FBC@oracle.com>

Hi Erik and/or Robi,

Very great feature. Thanks a lot!

How do I create such a PR? Do I just create a new branch from the local branch where the 1st PR was created and then `git publish`?

If yes, what happens if I create a sub-branch now on an existing PR created some time ago which has no pr/nnnn in upstream. Will that remote branch be automatically created when I publish the 2nd branch?

Thanks again,
Max

p.s. Looks like we don?t use https://github.com/openjdk/playground anymore. I thought this is the place we can try out new features.


> On Mar 26, 2021, at 8:47 AM, Erik Helin <erik.helin at oracle.com> wrote:
> 
> On 3/23/21 8:41 AM, Erik Helin wrote:
>> Hi all,
>> me and Robin are looking to deploy a new feature for the jdk [0] repository this week: dependent pull requests. Dependent pull requests are used when you have a change that depends on work in a pull request that is not yet integrated.
> 
> We have now deployed the dependent pull requests feature for the jdk [0] repository. Feel free to try it out and let us know if you have any feedback!
> 
> Hope you all have a great weekend,
> Erik & Robin
> 
> [0]: https://github.com/openjdk/jdk


From ebresie at gmail.com  Fri Mar 26 14:14:07 2021
From: ebresie at gmail.com (Eric Bresie)
Date: Fri, 26 Mar 2021 14:14:07 +0000
Subject: Unpack200 alternatives
In-Reply-To: <9200cc14-6bc3-ce29-11d1-894f7978b69e@oracle.com>
References: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>
 <8F3C9272-485E-45EB-970A-9BA613557BA5@oracle.com>
 <CAHw6w1QbWuE9M1XLVOU39wRSnQXkhK-xYbKE1k1xK08wcS_fRQ@mail.gmail.com>,
 <9200cc14-6bc3-ce29-11d1-894f7978b69e@oracle.com>
Message-ID: <YQXPR01MB2901BAF7042E5EE4AF733862FC619@YQXPR01MB2901.CANPRD01.PROD.OUTLOOK.COM>

It is Apache Netbeans which is on the list.

The IDE/Platform is updated/updating to newer Java it?s how to handle the legacy plug-ins that I?m concerned about

Its the independent plugins which leverages pack 200 / unpack during plug-in install.

Presently there is issue (1) in work for this but it didn?t seem clear to me at first why it didn?t handle the use case of unpacking existing pack200 in a newer JDK environment but I?m guessing one of the pack200 forks may be the way forward.


(1) https://issues.apache.org/jira/browse/NETBEANS-2842?jql=text%20~%20%22pack200%22%20and%20project%20%3D%20NetBeans%20
________________________________
From: Alex Buckley <alex.buckley at oracle.com>
Sent: Tuesday, March 23, 2021 12:26:08 PM
To: Eric Bresie <ebresie at gmail.com>; jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
Subject: Re: Unpack200 alternatives

Eric,

On 3/23/2021 5:41 AM, Eric Bresie wrote:
> ... With the frequency of releases, that doesn?t guarantee that
> projects will be able to migrate immediately.  Migrating between JDK
> various [presumably you meant "variations"?] on a massive project is
> not necessarily an easy task nor is it potentially feasible when
> working with volunteer effort ...

Is your "massive project" listed at
https://wiki.openjdk.java.net/display/quality/Quality+Outreach ?

Can you share some of the problems migrating from JDK N to JDK N+1? We
understand that JDK 8 to 9 (or straight to 11) can be tough, but
migrating from JDK 15 to 16 should be straightforward.

Alex

From mark.reinhold at oracle.com  Thu Mar 25 15:36:14 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 25 Mar 2021 08:36:14 -0700
Subject: JEP proposed to target JDK 17: 391: macOS/AArch64 Port
In-Reply-To: <20210316182209.855FF3DB764@eggemoggin.niobe.net>
References: <20210316182209.855FF3DB764@eggemoggin.niobe.net>
Message-ID: <20210325083614.994786531@eggemoggin.niobe.net>

2021/3/16 11:22:09 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 17:
> 
>   391: macOS/AArch64 Port
>        https://openjdk.java.net/jeps/391
> 
>   Summary: Port the JDK to macOS/AArch64.
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Monday, 30 March, or if they?re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I?ll target this JEP to JDK 17.

Hearing no objections, I?ve targeted this JEP to JDK 17.

- Mark

From mark.reinhold at oracle.com  Thu Mar 25 15:38:36 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 25 Mar 2021 08:38:36 -0700
Subject: JEP proposed to target JDK 17: 398: Deprecate the Applet API for
 Removal
In-Reply-To: <20210316183744.375C43DB770@eggemoggin.niobe.net>
References: <20210316183744.375C43DB770@eggemoggin.niobe.net>
Message-ID: <20210325083836.623471013@eggemoggin.niobe.net>

2021/3/16 11:37:44 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 17:
> 
>   398: Deprecate the Applet API for Removal
>        https://openjdk.java.net/jeps/398
> 
>   Summary: Deprecate the Applet API for removal.  It is essentially
>   irrelevant since all web-browser vendors have either removed support
>   for Java browser plug-ins or announced plans to do so.
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Tuesday, 23 March, or if they?re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I?ll target this JEP to JDK 17.

Hearing no objections, I?ve targeted this JEP to JDK 17.

- Mark

From volker.simonis at gmail.com  Fri Mar 26 16:46:09 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 26 Mar 2021 17:46:09 +0100
Subject: JEP proposed to target JDK 17: 398: Deprecate the Applet API for
 Removal
In-Reply-To: <20210325083836.623471013@eggemoggin.niobe.net>
References: <20210316183744.375C43DB770@eggemoggin.niobe.net>
 <20210325083836.623471013@eggemoggin.niobe.net>
Message-ID: <CA+3eh13_7qxCsM6D8VTvr9q4yqU4rhOeLrxxtOhj5WHPKCp-8w@mail.gmail.com>

On Fri, Mar 26, 2021 at 5:15 PM <mark.reinhold at oracle.com> wrote:
>
> 2021/3/16 11:37:44 -0700, mark.reinhold at oracle.com:
> > The following JEP is proposed to target JDK 17:
> >
> >   398: Deprecate the Applet API for Removal
> >        https://openjdk.java.net/jeps/398
> >
> >   Summary: Deprecate the Applet API for removal.  It is essentially
> >   irrelevant since all web-browser vendors have either removed support
> >   for Java browser plug-ins or announced plans to do so.
> >
> > Feedback on this proposal from JDK Project Committers and Reviewers [1]
> > is more than welcome, as are reasoned objections.  If no such objections
> > are raised by 23:59 UTC on Tuesday, 23 March, or if they?re raised and
> > then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> > I?ll target this JEP to JDK 17.
>
> Hearing no objections, I?ve targeted this JEP to JDK 17.
>

This might require an update of "JSR 56: Java Network Launching
Protocol and API" [1] but this is probably not something that needs to
be handled in the OpenJDK project.

[1] https://jcp.org/en/jsr/detail?id=56


> - Mark

From mark.reinhold at oracle.com  Fri Mar 26 16:55:14 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 26 Mar 2021 09:55:14 -0700 (PDT)
Subject: New candidate JEP: 405: Record Patterns & Array Patterns (Preview)
Message-ID: <20210326165514.677353DD6DA@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/405

  Summary: Enhance the Java programming language with record patterns,
  to deconstruct record values, and array patterns, to deconstruct
  array values. Record patterns, array patterns, and type patterns
  ([JEP 394][jep394]) can be nested so as to significantly enhance the
  expressiveness and utility of pattern matching.

- Mark

From mark.reinhold at oracle.com  Fri Mar 26 17:34:15 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 26 Mar 2021 10:34:15 -0700 (PDT)
Subject: New candidate JEP: 406: Pattern Matching for switch (Preview)
Message-ID: <20210326173415.120283DD6FA@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/406

  Summary: Enhance the Java programming language with pattern matching
  for switch expressions and statements, along with extensions to the
  language of patterns.  Extending pattern matching to switch allows
  an expression to be tested against a number of patterns, each with a
  specific action, so that complex data-oriented queries can be expressed
  concisely and safely.

- Mark

From mark.reinhold at oracle.com  Fri Mar 26 18:01:48 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 26 Mar 2021 11:01:48 -0700 (PDT)
Subject: New candidate JEP: 407: Remove RMI Activation
Message-ID: <20210326180148.E84233DD70B@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/407

  Summary: Remove the Remote Method Invocation (RMI) Activation
  mechanism, while preserving the rest of RMI.

- Mark

From geertjan.wielenga at googlemail.com  Fri Mar 26 14:39:17 2021
From: geertjan.wielenga at googlemail.com (Geertjan Wielenga)
Date: Fri, 26 Mar 2021 15:39:17 +0100
Subject: Unpack200 alternatives
In-Reply-To: <YQXPR01MB2901BAF7042E5EE4AF733862FC619@YQXPR01MB2901.CANPRD01.PROD.OUTLOOK.COM>
References: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>
 <8F3C9272-485E-45EB-970A-9BA613557BA5@oracle.com>
 <CAHw6w1QbWuE9M1XLVOU39wRSnQXkhK-xYbKE1k1xK08wcS_fRQ@mail.gmail.com>
 <9200cc14-6bc3-ce29-11d1-894f7978b69e@oracle.com>
 <YQXPR01MB2901BAF7042E5EE4AF733862FC619@YQXPR01MB2901.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <CACkjAxS2xDf7xgs2zLM5mP_idLU+hEZvm+PpiSX2_L2Z1DNdVQ@mail.gmail.com>

Eric,

I recommend you don?t do this. Don?t write to the JDK developer list about
NetBeans without interacting about that first with others on the NetBeans
dev mailing list.

You?re generating a lot of noise.

Thanks,

Gj

On Fri, 26 Mar 2021 at 15:14, Eric Bresie <ebresie at gmail.com> wrote:

> It is Apache Netbeans which is on the list.
>
> The IDE/Platform is updated/updating to newer Java it?s how to handle the
> legacy plug-ins that I?m concerned about
>
> Its the independent plugins which leverages pack 200 / unpack during
> plug-in install.
>
> Presently there is issue (1) in work for this but it didn?t seem clear to
> me at first why it didn?t handle the use case of unpacking existing pack200
> in a newer JDK environment but I?m guessing one of the pack200 forks may be
> the way forward.
>
>
> (1)
> https://issues.apache.org/jira/browse/NETBEANS-2842?jql=text%20~%20%22pack200%22%20and%20project%20%3D%20NetBeans%20
> ________________________________
> From: Alex Buckley <alex.buckley at oracle.com>
> Sent: Tuesday, March 23, 2021 12:26:08 PM
> To: Eric Bresie <ebresie at gmail.com>; jdk-dev at openjdk.java.net <
> jdk-dev at openjdk.java.net>
> Subject: Re: Unpack200 alternatives
>
> Eric,
>
> On 3/23/2021 5:41 AM, Eric Bresie wrote:
> > ... With the frequency of releases, that doesn?t guarantee that
> > projects will be able to migrate immediately.  Migrating between JDK
> > various [presumably you meant "variations"?] on a massive project is
> > not necessarily an easy task nor is it potentially feasible when
> > working with volunteer effort ...
>
> Is your "massive project" listed at
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach ?
>
> Can you share some of the problems migrating from JDK N to JDK N+1? We
> understand that JDK 8 to 9 (or straight to 11) can be tough, but
> migrating from JDK 15 to 16 should be straightforward.
>
> Alex
>

From mark.reinhold at oracle.com  Fri Mar 26 23:19:41 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 26 Mar 2021 16:19:41 -0700
Subject: Clarification regarding the GitHub Actions pre-submit testing
In-Reply-To: <3e94c7f1-8d3e-1538-800e-3ab5c0d0b42f@redhat.com>
References: <7ef88086-887b-566f-a611-18ae1752f70b@oracle.com>
 <bcb16e4e-1736-7da3-d968-c390a69a2d34@redhat.com>
 <923207d3-5deb-41ad-5d9b-ca020f602955@oracle.com>
 <20210317172217.299659169@eggemoggin.niobe.net>
 <387873ec-ba3b-9bce-a177-5df3e13790dc@redhat.com>
 <43b1780b-abac-7f4a-5e10-1c0b15899f57@oracle.com>
 <027fadc5-0b1c-aad1-2fc6-c1b099658287@redhat.com>
 <9bff9fb3-f6ae-0c46-5548-252b42444757@redhat.com>
 <a7ac2c2e-6e9c-374c-0ae2-5fe0ba485901@redhat.com>
 <56837fbb-cb1f-ac52-a566-b0f69e59e166@redhat.com>
 <20210318152028.291370240@eggemoggin.niobe.net>
 <3e94c7f1-8d3e-1538-800e-3ab5c0d0b42f@redhat.com>
Message-ID: <20210326161941.881709978@eggemoggin.niobe.net>

2021/3/23 2:46:58 -0700, aph at redhat.com:
> For some reason I didn't reply to Question 2, sorry.
> 
> On 3/18/21 10:20 PM, mark.reinhold at oracle.com wrote:
>>  (2) If the fix is non-trivial and the committer is obliged to contact
>>      the port maintainer to explain the situation, what is it that you
>>      expect to happen before X days pass?  Is the committer supposed to
>>      wait for at most X days for the port maintainer to provide a fix?
> 
> Yes, that's what I meant.
> 
> So, what about it? Does any disagree that this is fair and reasonable?

Something like this is almost certainly fair and reasonable, but the
devil as usual is in the details.

To make sure we?re all on the same page, I?ll propose some text which
we can then revise and agree upon.

- Mark
 

From peter.firmstone at zeus.net.au  Fri Mar 26 23:44:29 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 27 Mar 2021 09:44:29 +1000
Subject: Unpack200 alternatives
In-Reply-To: <YQXPR01MB2901BAF7042E5EE4AF733862FC619@YQXPR01MB2901.CANPRD01.PROD.OUTLOOK.COM>
References: <CAHw6w1Q5fj4t2QFA_DPL5RwHEsmF3AePGO4fH485TKA1y-WQdQ@mail.gmail.com>
 <8F3C9272-485E-45EB-970A-9BA613557BA5@oracle.com>
 <CAHw6w1QbWuE9M1XLVOU39wRSnQXkhK-xYbKE1k1xK08wcS_fRQ@mail.gmail.com>
 <9200cc14-6bc3-ce29-11d1-894f7978b69e@oracle.com>
 <YQXPR01MB2901BAF7042E5EE4AF733862FC619@YQXPR01MB2901.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <28d59059-ad63-3cf0-94f6-915126475d53@zeus.net.au>

It would have been nice if the interfaces for packing and unpacking 
remained in the jdk, and only the implementation removed, this would 
make it a lot easier for others to package it separately.

Peter.

On 27/03/2021 12:14 am, Eric Bresie wrote:
> It is Apache Netbeans which is on the list.
>
> The IDE/Platform is updated/updating to newer Java it?s how to handle the legacy plug-ins that I?m concerned about
>
> Its the independent plugins which leverages pack 200 / unpack during plug-in install.
>
> Presently there is issue (1) in work for this but it didn?t seem clear to me at first why it didn?t handle the use case of unpacking existing pack200 in a newer JDK environment but I?m guessing one of the pack200 forks may be the way forward.
>
>
> (1) https://issues.apache.org/jira/browse/NETBEANS-2842?jql=text%20~%20%22pack200%22%20and%20project%20%3D%20NetBeans%20
> ________________________________
> From: Alex Buckley <alex.buckley at oracle.com>
> Sent: Tuesday, March 23, 2021 12:26:08 PM
> To: Eric Bresie <ebresie at gmail.com>; jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
> Subject: Re: Unpack200 alternatives
>
> Eric,
>
> On 3/23/2021 5:41 AM, Eric Bresie wrote:
>> ... With the frequency of releases, that doesn?t guarantee that
>> projects will be able to migrate immediately.  Migrating between JDK
>> various [presumably you meant "variations"?] on a massive project is
>> not necessarily an easy task nor is it potentially feasible when
>> working with volunteer effort ...
> Is your "massive project" listed at
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach ?
>
> Can you share some of the problems migrating from JDK N to JDK N+1? We
> understand that JDK 8 to 9 (or straight to 11) can be tough, but
> migrating from JDK 15 to 16 should be straightforward.
>
> Alex

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.


From ebresie at gmail.com  Sat Mar 27 11:44:38 2021
From: ebresie at gmail.com (Eric Bresie)
Date: Sat, 27 Mar 2021 06:44:38 -0500
Subject: JEP proposed to target JDK 17: 398: Deprecate the
 Applet API for Removal
In-Reply-To: CA+3eh13_7qxCsM6D8VTvr9q4yqU4rhOeLrxxtOhj5WHPKCp-8w@mail.gmail.com
References: 20210316183744.375C43DB770@eggemoggin.niobe.net
 20210325083836.623471013@eggemoggin.niobe.net
 20210325083836.623471013@eggemoggin.niobe.net
Message-ID: <733c40fb-fa9a-46b4-b06d-e19bf301d77f@Erics-iPhone-12-Pro-Max>

Are there plans to fork off to an open project with something similar to what was done with Java Webstart?

https://openwebstart.com/

Eric Bresie
Ebresie at gmail.com (mailto:Ebresie at gmail.com)

> On March 26, 2021 at 11:46:09 AM CDT, Volker Simonis <volker.simonis at gmail.com (mailto:volker.simonis at gmail.com)> wrote:
> On Fri, Mar 26, 2021 at 5:15 PM <mark.reinhold at oracle.com (mailto:mark.reinhold at oracle.com)> wrote:
> >
> > 2021/3/16 11:37:44 -0700, mark.reinhold at oracle.com (mailto:mark.reinhold at oracle.com):
> > > The following JEP is proposed to target JDK 17:
> > >
> > > 398: Deprecate the Applet API for Removal
> > > https://openjdk.java.net/jeps/398
> > >
> > > Summary: Deprecate the Applet API for removal. It is essentially
> > > irrelevant since all web-browser vendors have either removed support
> > > for Java browser plug-ins or announced plans to do so.
> > >
> > > Feedback on this proposal from JDK Project Committers and Reviewers [1]
> > > is more than welcome, as are reasoned objections. If no such objections
> > > are raised by 23:59 UTC on Tuesday, 23 March, or if they?re raised and
> > > then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> > > I?ll target this JEP to JDK 17.
> >
> > Hearing no objections, I?ve targeted this JEP to JDK 17.
> >
>
> This might require an update of "JSR 56: Java Network Launching
> Protocol and API" [1] but this is probably not something that needs to
> be handled in the OpenJDK project.
>
> [1] https://jcp.org/en/jsr/detail?id=56
>
>
> > - Mark

From aph at redhat.com  Sat Mar 27 14:42:08 2021
From: aph at redhat.com (Andrew Haley)
Date: Sat, 27 Mar 2021 14:42:08 +0000
Subject: JEP proposed to target JDK 17: 398: Deprecate the Applet API for
 Removal
In-Reply-To: <733c40fb-fa9a-46b4-b06d-e19bf301d77f@Erics-iPhone-12-Pro-Max>
References: <733c40fb-fa9a-46b4-b06d-e19bf301d77f@Erics-iPhone-12-Pro-Max>
Message-ID: <33883c4c-1563-b1a9-6e2d-87848fd669bc@redhat.com>

On 3/27/21 11:44 AM, Eric Bresie wrote:
> Are there plans to fork off to an open project with something similar to what was done with Java Webstart?
> 
> https://openwebstart.com/

It's be difficult to keep the API going with newer JDK releases.
Maybe a renaming exercise along the lines of Jakarta EE. Do you
think that applets have a long-term future, beyond the expected
lifetime of updating older JDK releases?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From fw at deneb.enyo.de  Sun Mar 28 15:15:35 2021
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 28 Mar 2021 17:15:35 +0200
Subject: New Skara feature: dependent pull requests
In-Reply-To: <34c2711b-e1b3-6537-8044-2cc6fed2f7ec@oracle.com> (Erik Helin's
 message of "Tue, 23 Mar 2021 08:41:09 +0100")
References: <34c2711b-e1b3-6537-8044-2cc6fed2f7ec@oracle.com>
Message-ID: <87blb348dk.fsf@mid.deneb.enyo.de>

* Erik Helin:

> The branches named `pr/<ID>` are automatically removed when the
> corresponding pull request is closed.

For the local clones, you need to run ?git remote prune origin?
periodically.

Alternatively, the repository could be configured in such a way that
the /pr/ branches are excluded from the default fetch set, if Github
supports that.

From mark.reinhold at oracle.com  Mon Mar 29 19:03:18 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 29 Mar 2021 12:03:18 -0700
Subject: New Skara feature: dependent pull requests
In-Reply-To: <87blb348dk.fsf@mid.deneb.enyo.de>
References: <34c2711b-e1b3-6537-8044-2cc6fed2f7ec@oracle.com>
 <87blb348dk.fsf@mid.deneb.enyo.de>
Message-ID: <20210329120318.596395888@eggemoggin.niobe.net>

2021/3/28 8:15:35 -0700, fw at deneb.enyo.de:
> * Erik Helin:
> 
>> The branches named `pr/<ID>` are automatically removed when the
>> corresponding pull request is closed.
> 
> For the local clones, you need to run ?git remote prune origin?
> periodically.
> 
> Alternatively, the repository could be configured in such a way that
> the /pr/ branches are excluded from the default fetch set, if Github
> supports that.

That would certainly be convenient, if it?s possible.

- Mark

From mark.reinhold at oracle.com  Mon Mar 29 19:16:06 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 29 Mar 2021 12:16:06 -0700 (PDT)
Subject: New candidate JEP: 408: Simple Web Server
Message-ID: <20210329191606.929913DDF64@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/408

  Summary: Provide a command-line tool to start a minimal web server
  that serves static files in the current directory. This low-threshold
  utility will be useful for prototyping, ad-hoc coding, and testing
  purposes, particularly in educational contexts.

- Mark

From forax at univ-mlv.fr  Mon Mar 29 19:41:03 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 29 Mar 2021 21:41:03 +0200 (CEST)
Subject: New candidate JEP: 408: Simple Web Server
In-Reply-To: <20210329191606.929913DDF64@eggemoggin.niobe.net>
References: <20210329191606.929913DDF64@eggemoggin.niobe.net>
Message-ID: <2038848436.662759.1617046863732.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> ?: "Julia Boes" <julia.boes at oracle.com>
> Cc: net-dev at openjdk.java.net, "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Lundi 29 Mars 2021 21:16:06
> Objet: New candidate JEP: 408: Simple Web Server

> https://openjdk.java.net/jeps/408
> 
>  Summary: Provide a command-line tool to start a minimal web server
>  that serves static files in the current directory. This low-threshold
>  utility will be useful for prototyping, ad-hoc coding, and testing
>  purposes, particularly in educational contexts.


big +1,

For teaching purpose, i'm currently using a thin wrapper with an API close to expressjs [1] on top of com.sun.net.httpserver.HttpServer.
 
> 
> - Mark

R?mi

[1] https://github.com/forax/jexpress

From mark.reinhold at oracle.com  Mon Mar 29 21:30:18 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 29 Mar 2021 14:30:18 -0700
Subject: Proposed schedule for JDK 17
Message-ID: <20210329143018.403323786@eggemoggin.niobe.net>

With JDK 16 done and gone, here?s a proposed schedule for JDK 17:

  2021/06/10  Rampdown Phase One
  2021/07/15  Rampdown Phase Two
  2021/08/05  Initial Release Candidate
  2021/08/19  Final Release Candidate
  2021/09/14  General Availability

The phases are defined in JEP 3 [1].

Comments on this proposal from JDK Committers and Reviewers [2] are
welcome, as are reasoned objections.  If no such objections are
raised by 23:00 UTC next Monday, 5 April, or if they?re raised and
satisfactorily answered, then per the JEP 2.0 process proposal [3]
this will be the schedule for JDK 17.

- Mark


[1] https://openjdk.java.net/jeps/3
[2] https://openjdk.java.net/census#jdk
[3] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From krzysztof.krason at gmail.com  Tue Mar 30 05:51:42 2021
From: krzysztof.krason at gmail.com (Krzysztof K.)
Date: Tue, 30 Mar 2021 07:51:42 +0200
Subject: New candidate JEP: 408: Simple Web Server
In-Reply-To: <20210329191606.929913DDF64@eggemoggin.niobe.net>
References: <20210329191606.929913DDF64@eggemoggin.niobe.net>
Message-ID: <CAF+zKUNbEuP9gyAeczPs7g=iJRGR3cOUNKEoLvQ7UvDugZy6DA@mail.gmail.com>

Hi,
Is there a plan to change the package name?
I always thought that com.sun.* package was for old internal code and I
assume I'm not the only one.

Regards,
Krzysztof Krason

On Mon, Mar 29, 2021 at 9:16 PM <mark.reinhold at oracle.com> wrote:

> https://openjdk.java.net/jeps/408
>
>   Summary: Provide a command-line tool to start a minimal web server
>   that serves static files in the current directory. This low-threshold
>   utility will be useful for prototyping, ad-hoc coding, and testing
>   purposes, particularly in educational contexts.
>
> - Mark
>


-- 
Krzysztof Krason

From julia.boes at oracle.com  Tue Mar 30 13:14:11 2021
From: julia.boes at oracle.com (Julia Boes)
Date: Tue, 30 Mar 2021 13:14:11 +0000
Subject: New candidate JEP: 408: Simple Web Server
In-Reply-To: <CAF+zKUNbEuP9gyAeczPs7g=iJRGR3cOUNKEoLvQ7UvDugZy6DA@mail.gmail.com>
References: <20210329191606.929913DDF64@eggemoggin.niobe.net>,
 <CAF+zKUNbEuP9gyAeczPs7g=iJRGR3cOUNKEoLvQ7UvDugZy6DA@mail.gmail.com>
Message-ID: <BY5PR10MB395671E992F14287C9708FF3ED7D9@BY5PR10MB3956.namprd10.prod.outlook.com>

Hi Krzysztof,

Is there a plan to change the package name?
I always thought that com.sun.* package was for old internal code and I assume I'm not the only one.

the simple server builds on the existing API in the com.sun.net.httpserver package, which was added in JDK 1.6. At that time, the convention for JDK-specific APIs was to use the com.sun namespace. Other examples are com.sun.nio.sctp or com.sun.security.ntlm. In more recent times, this convention has been replaced with the jdk namespace. Both name spaces are JDK-specific, as such the simple server API is a supported JDK API.

Given that we're simply building on top of the long-standing API in com.sun.net.httpserver, revisiting the package name is out of the scope of this project.

Regards,
Julia

From alex.buckley at oracle.com  Tue Mar 30 17:10:49 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 30 Mar 2021 10:10:49 -0700
Subject: New candidate JEP: 408: Simple Web Server
In-Reply-To: <CAF+zKUNbEuP9gyAeczPs7g=iJRGR3cOUNKEoLvQ7UvDugZy6DA@mail.gmail.com>
References: <20210329191606.929913DDF64@eggemoggin.niobe.net>
 <CAF+zKUNbEuP9gyAeczPs7g=iJRGR3cOUNKEoLvQ7UvDugZy6DA@mail.gmail.com>
Message-ID: <815f10e2-9bf0-d7aa-eeee-5209dd8ee882@oracle.com>

Further to Julia's comments:

All of the com.sun namespace is JDK-specific -- it's not part of the 
Java SE Platform API.

Around 90% of the com.sun namespace is internal to the JDK -- not 
intended for use outside the JDK. An example is the 
com.sun.security.ntlm package in the java.base module.

Around 10% of the com.sun namespace is supported for use outside the 
JDK. Examples of supported com.sun APIs include:

- The Compiler Tree API (four com.sun packages exported by the 
jdk.compiler module)
- The HTTP Server API (two com.sun packages exported by the 
jdk.httpserver module)
- The SCTP API (the com.sun.nio.sctp package exported by the jdk.sctp 
module)
- JDK-specific extensions to the NIO API (the com.sun.nio.file package 
exported by the jdk.unsupported module)

You can view a list of the internal com.sun packages and the supported 
com.sun packages at 
https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-strongly-encapsulated

To aid migration, all of the com.sun packages were open for reflection 
_by default_ in JDK 9 through 15. Things were tightened up in JDK 16, 
and from JDK 17 you will need to use `--add-opens` if your application 
or library code wants to reflect over a com.sun package. You will still 
be able to program directly against the _supported_ com.sun packages, 
such as the HTTP Server API.

Finally, a related point:  The sun.misc package has been exported and 
available for reflection since JDK 9. It was neither removed nor 
strongly encapsulated in JDK 9. It was available in JDK 9, and continues 
to be available in JDK 17.

Alex

On 3/29/2021 10:51 PM, Krzysztof K. wrote:
> Hi,
> Is there a plan to change the package name?
> I always thought that com.sun.* package was for old internal code and I
> assume I'm not the only one.
> 
> Regards,
> Krzysztof Krason
> 
> On Mon, Mar 29, 2021 at 9:16 PM <mark.reinhold at oracle.com> wrote:
> 
>> https://openjdk.java.net/jeps/408
>>
>>    Summary: Provide a command-line tool to start a minimal web server
>>    that serves static files in the current directory. This low-threshold
>>    utility will be useful for prototyping, ad-hoc coding, and testing
>>    purposes, particularly in educational contexts.
>>
>> - Mark
>>
> 
> 

From mark at lawinegevaar.nl  Wed Mar 31 11:24:27 2021
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Wed, 31 Mar 2021 13:24:27 +0200
Subject: New candidate JEP: 408: Simple Web Server
In-Reply-To: <815f10e2-9bf0-d7aa-eeee-5209dd8ee882@oracle.com>
References: <20210329191606.929913DDF64@eggemoggin.niobe.net>
 <CAF+zKUNbEuP9gyAeczPs7g=iJRGR3cOUNKEoLvQ7UvDugZy6DA@mail.gmail.com>
 <815f10e2-9bf0-d7aa-eeee-5209dd8ee882@oracle.com>
Message-ID: <8c6128fe-c6ca-78b9-1aca-0a6c7611762e@lawinegevaar.nl>

On 30-03-2021 19:10, Alex Buckley wrote:
> All of the com.sun namespace is JDK-specific -- it's not part of the 
> Java SE Platform API.
> 
> Around 90% of the com.sun namespace is internal to the JDK -- not 
> intended for use outside the JDK. An example is the 
> com.sun.security.ntlm package in the java.base module.

I think you need to qualify this to prevent confusion, because there are 
libraries that also use the com.sun namespace that are not part of the 
JDK, so are not JDK-specific nor internal only, e.g. 
https://github.com/java-native-access/jna, the reference implementation 
of JakartaMail (JavaMail).

Mark
-- 
Mark Rotteveel

From Alan.Bateman at oracle.com  Wed Mar 31 12:01:37 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Mar 2021 13:01:37 +0100
Subject: New candidate JEP: 408: Simple Web Server
In-Reply-To: <8c6128fe-c6ca-78b9-1aca-0a6c7611762e@lawinegevaar.nl>
References: <20210329191606.929913DDF64@eggemoggin.niobe.net>
 <CAF+zKUNbEuP9gyAeczPs7g=iJRGR3cOUNKEoLvQ7UvDugZy6DA@mail.gmail.com>
 <815f10e2-9bf0-d7aa-eeee-5209dd8ee882@oracle.com>
 <8c6128fe-c6ca-78b9-1aca-0a6c7611762e@lawinegevaar.nl>
Message-ID: <0df1fe4d-c179-56ff-086a-b142a61516da@oracle.com>

On 31/03/2021 12:24, Mark Rotteveel wrote:
> On 30-03-2021 19:10, Alex Buckley wrote:
>> All of the com.sun namespace is JDK-specific -- it's not part of the 
>> Java SE Platform API.
>>
>> Around 90% of the com.sun namespace is internal to the JDK -- not 
>> intended for use outside the JDK. An example is the 
>> com.sun.security.ntlm package in the java.base module.
>
> I think you need to qualify this to prevent confusion, because there 
> are libraries that also use the com.sun namespace that are not part of 
> the JDK, so are not JDK-specific nor internal only, e.g. 
> https://github.com/java-native-access/jna, the reference 
> implementation of JakartaMail (JavaMail).

The com.sun name space wasn't used exclusively by the JDK. The 
implementation of several Java EE and standalone technologies had 
implementation classes in the com.sun name space too.? I don't know the 
history of JNA to know why it has classes in this name space but it's 
probably not interesting here.

 From what I can tell, the original question about the com.sun name 
space here just missed it that the com.sun.net.httpserver API has 
existed since JDK 6. The JEP doesn't want to break existing usages of 
that API, instead it is focused on providing an entry point to its 
module to make it super easy to have a HTTP file server in the dev 
environment and some modest API additions to make it easy to do the same 
programmatically.

-Alan





From alex.buckley at oracle.com  Wed Mar 31 15:26:26 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 31 Mar 2021 08:26:26 -0700
Subject: New candidate JEP: 408: Simple Web Server
In-Reply-To: <8c6128fe-c6ca-78b9-1aca-0a6c7611762e@lawinegevaar.nl>
References: <20210329191606.929913DDF64@eggemoggin.niobe.net>
 <CAF+zKUNbEuP9gyAeczPs7g=iJRGR3cOUNKEoLvQ7UvDugZy6DA@mail.gmail.com>
 <815f10e2-9bf0-d7aa-eeee-5209dd8ee882@oracle.com>
 <8c6128fe-c6ca-78b9-1aca-0a6c7611762e@lawinegevaar.nl>
Message-ID: <75967c08-8c3d-7663-60f2-4074f2676ceb@oracle.com>

On 3/31/2021 4:24 AM, Mark Rotteveel wrote:
> On 30-03-2021 19:10, Alex Buckley wrote:
>> All of the com.sun namespace is JDK-specific -- it's not part of the 
>> Java SE Platform API.
>>
>> Around 90% of the com.sun namespace is internal to the JDK -- not 
>> intended for use outside the JDK. An example is the 
>> com.sun.security.ntlm package in the java.base module.
> 
> I think you need to qualify this to prevent confusion, because there are 
> libraries that also use the com.sun namespace that are not part of the 
> JDK, so are not JDK-specific nor internal only

Thank you. Given the sprawling nature of com.sun APIs in the JDK and the 
confusion I sometimes see between com.sun and sun.misc, I wanted to make 
easy-to-remember statements about the dominant com.sun container on the 
planet -- the JDK. Around 90% of the com.sun namespace in the JDK is for 
internal use by the JDK, while around 10% is supported for external use.

Let's reiterate:  The sun.misc package was not removed in JDK 9, nor 
strongly encapsulated. It was available in JDK 9 just like in JDK 8. It 
continues to be available in JDK 11 and JDK 17.

Alex

From shade at redhat.com  Wed Mar 31 15:45:05 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 31 Mar 2021 17:45:05 +0200
Subject: RFC: C1/C2 support for Blackholes
In-Reply-To: <6b1f4881-f56e-9a1d-be67-350ce5a0a854@redhat.com>
References: <6b1f4881-f56e-9a1d-be67-350ce5a0a854@redhat.com>
Message-ID: <a0f65272-9db5-781c-7c74-2f18303df932@redhat.com>

On 3/25/21 10:35 AM, Aleksey Shipilev wrote:
> Here, I would like to have a bit of discussion about it. To start from the clean slate, I submitted
> the new CSR that captures my current thinking:
>     https://bugs.openjdk.java.net/browse/JDK-8264133
> 
> This thread is probably a better way to mull over the questions without piling on less-structured
> comments onto the CSR issue. In other words, let's discuss the interface and approach here.

If there are no further comments and we are in agreement, please add yourself as "Reviewed By" to 
CSR, so I can "Finalize" it.

-- 
Thanks,
-Aleksey