From jesper.wilhelmsson at oracle.com  Fri Jun  3 09:21:26 2022
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 3 Jun 2022 09:21:26 +0000
Subject: On applying for Author at the JDK Project
In-Reply-To: <CAP2b4GPsT6Cpq92+=JFHoGHiLOT0jdV5p2eBLkWS_LAVQVQqDw@mail.gmail.com>
References: <CAP2b4GPsT6Cpq92+=JFHoGHiLOT0jdV5p2eBLkWS_LAVQVQqDw@mail.gmail.com>
Message-ID: <CEAF8988-2872-43A8-818E-6EAC0E559BED@oracle.com>

Hi Julian,

After having read your mail I put a note on my todo-list to update the Developers' Guide to better clarify the details around becoming an author. That has finally been done and is now online: https://openjdk.java.net/guide/#becoming-an-author

If you have the time to have a look I would very much like to know if this description is now sufficient to have answered your question.

Thanks,
/Jesper

On 27 Feb 2022, at 08:38, Jules W. <tanksherman27 at gmail.com<mailto:tanksherman27 at gmail.com>> wrote:

Hi all,

Currently I'm thinking of applying for the Author position at the JDK
project, but the OpenJDK Project page (https://openjdk.java.net/projects/) is
somewhat vague about how to do so, simply saying to contact the project
lead after 2 pull requests have been merged without offering a proper
communication channel to do so. Additionally some of the information on the
site also seems to be outdated, and I'm unsure of whether this outdated
information also includes the section describing the Author application
process. Currently the census lists Mr. Reinhold as the project lead for
the JDK, is there an unmentioned formal communication channel I can use to
apply for Author or should I contact Mr. Reinhold directly as per the
page's instructions? (And if I should do the latter, do I contact him
directly through his Oracle email address?)

Thanks for your patience.

best regards,
Julian


From steffen.moser at uni-ulm.de  Fri Jun  3 20:51:45 2022
From: steffen.moser at uni-ulm.de (Steffen Moser)
Date: Fri, 3 Jun 2022 22:51:45 +0200
Subject: HTTP Error 500 when accessing hg.openjdk.java.net
In-Reply-To: <0adee14c-7c9c-a68f-f9b2-e92117e7c3a9@oracle.com>
References: <ff66dfce-83c3-8790-2453-b82da2f88ca1@uni-ulm.de>
 <0adee14c-7c9c-a68f-f9b2-e92117e7c3a9@oracle.com>
Message-ID: <d2ed7f05-aa10-fffe-0ae0-9e4bd6b95f1b@uni-ulm.de>

Hello Tim,

thank you very much - it's working again. :-)

We build OpenJDK 9..18 for Oracle Solaris 11.4 x86 with a chain of build 
scripts. Especially for OpenJDK 9, I think that "hg.openjdk.java.net" is 
really needed because of the sub-repositories I need to fetch. I am 
aware that I need to fetch from Github for the latest updated versions 
especially of OpenJDK 11 and 17 which we actually use.

Thanks for pointing out the list <ops at openjdk.java.net>.

Kind regards,
Steffen

On 30.05.22 17:26, tim.bell at oracle.com wrote:
> Hello Steffen
>
> On 5/29/22 01:46, Steffen Moser wrote:
> > seems to be something broken on (one of the?) Mercurial server(s). 
> > Does anybody know who I should inform about this?
> >
> > How to reproduce: Go, for example, to 
> > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ebc6c83bfa9e  and
> > press "Reload" several times.
>
> This is fixed onhttp://hg.openjdk.java.net. Please try it again.
>
> For future use, the list to notify regarding technical problems is
> ops at openjdk.java.net.
>
> As an additional note, all Mercurial repositories on hg.openjdk.java.net
> are read-only.? Active OpenJDK development migrated to github at
> https://github.com/openjdk
>
> For jdk11u specifically, look here:
> *https://github.com/openjdk/jdk11u
> *https://github.com/openjdk/jdk11u-dev
>
> Tim
>

-- 
?-----------------------------------------------------------------------
Dipl.-Inf. Steffen Moser		  Tel (Office): +49.731.50.32407
School of Advanced Professional Studies   Fax (Office): +49.731.50.32409
Ulm University, Room: 02_11.4               Tel (Home): +49.731.36080158
Lise-Meitner-Stra?e 16, 89081 Ulm, Germanyhttp://saps.uni-ulm.de/
GDPR Statement:https://wissenschaftliche-weiterbildung.org/datenschutz/

From robbepincket at live.be  Fri Jun 10 15:21:39 2022
From: robbepincket at live.be (Robbe Pincket)
Date: Fri, 10 Jun 2022 15:21:39 +0000
Subject: jls-jvm-spec mail list
In-Reply-To: <AS1PR01MB92285C7524A5D1BE4B55B5D8D3A19@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
References: <AS1PR01MB92285C7524A5D1BE4B55B5D8D3A19@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
Message-ID: <AS1PR01MB92289FE4FCB39E97168A4CC2D3A69@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>

Hi everyone

I sent an email to the jls and jvm specifications ?drop box? mail list, but I haven?t gotten any indication it got received or read by anybody. Does anyone here know if that list is being read, or if I?m supposed to send my email to a different list?

Greetings
Robbe Pincket

From alex.buckley at oracle.com  Fri Jun 10 16:56:37 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 10 Jun 2022 09:56:37 -0700
Subject: jls-jvm-spec mail list
In-Reply-To: <AS1PR01MB92289FE4FCB39E97168A4CC2D3A69@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
References: <AS1PR01MB92285C7524A5D1BE4B55B5D8D3A19@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
 <AS1PR01MB92289FE4FCB39E97168A4CC2D3A69@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
Message-ID: <2cc24f0f-7092-29d7-bbae-44c680e1fa93@oracle.com>

Hi Robbe,

The list is read, but only from time to time. I see you have two mails 
from May, and will file issues for them in the Java Bug System today.

Alex

On 6/10/2022 8:21 AM, Robbe Pincket wrote:
> Hi everyone
> 
> I sent an email to the jls and jvm specifications ?drop box? mail list, but I haven?t gotten any indication it got received or read by anybody. Does anyone here know if that list is being read, or if I?m supposed to send my email to a different list?
> 
> Greetings
> Robbe Pincket

From coderodd3 at gmail.com  Sat Jun 11 07:38:44 2022
From: coderodd3 at gmail.com (Rodion Efremov)
Date: Sat, 11 Jun 2022 10:38:44 +0300
Subject: Very fast List/Deque to java.util?
Message-ID: <CADLcvWnYZ5htW7mQXx3gt8Xm8gJ6CPJe6ZNHmEoR3URNQ6H6ig@mail.gmail.com>

Hi,

I have this List/Deque implementation that runs (in a rather versatile
benchmark) much faster than ArrayList and LinkedList:

https://github.com/coderodde/IndexedLinkedList

What do you think? Does it deserve to be included in JDK?

Best regards,
rodde

From david.holmes at oracle.com  Sat Jun 11 13:21:10 2022
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 11 Jun 2022 23:21:10 +1000
Subject: jls-jvm-spec mail list
In-Reply-To: <AS1PR01MB92289FE4FCB39E97168A4CC2D3A69@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
References: <AS1PR01MB92285C7524A5D1BE4B55B5D8D3A19@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
 <AS1PR01MB92289FE4FCB39E97168A4CC2D3A69@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
Message-ID: <134b2d7d-d37c-9aca-5be6-3e41649ec0fe@oracle.com>

Hi Robbe,

On 11/06/2022 1:21 am, Robbe Pincket wrote:
> Hi everyone
> 
> I sent an email to the jls and jvm specifications ?drop box? mail list, but I haven?t gotten any indication it got received or read by anybody. Does anyone here know if that list is being read, or if I?m supposed to send my email to a different list?

You won't get any indication that it has been read, nor get any response 
- that is why it is a "drop box" mailing list. Rest assured it is being 
monitored. You can see your mail was posted here:

https://mail.openjdk.java.net/pipermail/jls-jvms-spec-comments/2022-May/thread.html

Cheers,
David

> Greetings
> Robbe Pincket

From david.holmes at oracle.com  Sat Jun 11 13:22:38 2022
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 11 Jun 2022 23:22:38 +1000
Subject: jls-jvm-spec mail list
In-Reply-To: <134b2d7d-d37c-9aca-5be6-3e41649ec0fe@oracle.com>
References: <AS1PR01MB92285C7524A5D1BE4B55B5D8D3A19@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
 <AS1PR01MB92289FE4FCB39E97168A4CC2D3A69@AS1PR01MB9228.eurprd01.prod.exchangelabs.com>
 <134b2d7d-d37c-9aca-5be6-3e41649ec0fe@oracle.com>
Message-ID: <1a2c0823-3035-9eb9-b5b8-dea2c3e40894@oracle.com>

Sorry - missed that Alex already responded to this.

David

On 11/06/2022 11:21 pm, David Holmes wrote:
> Hi Robbe,
> 
> On 11/06/2022 1:21 am, Robbe Pincket wrote:
>> Hi everyone
>>
>> I sent an email to the jls and jvm specifications ?drop box? mail 
>> list, but I haven?t gotten any indication it got received or read by 
>> anybody. Does anyone here know if that list is being read, or if I?m 
>> supposed to send my email to a different list?
> 
> You won't get any indication that it has been read, nor get any response 
> - that is why it is a "drop box" mailing list. Rest assured it is being 
> monitored. You can see your mail was posted here:
> 
> https://mail.openjdk.java.net/pipermail/jls-jvms-spec-comments/2022-May/thread.html 
> 
> 
> Cheers,
> David
> 
>> Greetings
>> Robbe Pincket

From david.holmes at oracle.com  Sat Jun 11 13:40:13 2022
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 11 Jun 2022 23:40:13 +1000
Subject: Very fast List/Deque to java.util?
In-Reply-To: <CADLcvWnYZ5htW7mQXx3gt8Xm8gJ6CPJe6ZNHmEoR3URNQ6H6ig@mail.gmail.com>
References: <CADLcvWnYZ5htW7mQXx3gt8Xm8gJ6CPJe6ZNHmEoR3URNQ6H6ig@mail.gmail.com>
Message-ID: <c784a720-25a0-cdad-0a12-92af6360156c@oracle.com>

Hi Rodde,

This is the wrong mailing list for this kind of query. If you want to 
propose a new class then you need to take it to 
core-libs-dev at openjdk.java.net but be fore-warned you need to have a 
full story here:
- benchmarks showing the improvements and under what circumstances; and 
just as importantly under what circumstances there will be performance 
regressions
- "proof" that the implementation adheres to all specified behaviours
- a sound argument as to why you think it deserves to be in the OpenJDK

Also note that OpenJDK can only accept a contribution when it is 
submitted directly into some part of the OpenJDK infrastructure (mailing 
list, wiki page, bug report, code review or pull request). This is 
necessary for intellectual-property rights.

Cheers,
David

On 11/06/2022 5:38 pm, Rodion Efremov wrote:
> Hi,
> 
> I have this List/Deque implementation that runs (in a rather versatile
> benchmark) much faster than ArrayList and LinkedList:
> 
> https://github.com/coderodde/IndexedLinkedList
> 
> What do you think? Does it deserve to be included in JDK?
> 
> Best regards,
> rodde

From victorwssilva at gmail.com  Sun Jun 12 20:30:42 2022
From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva)
Date: Sun, 12 Jun 2022 17:30:42 -0300
Subject: Record's elements unavailable inside methods called on constructors
Message-ID: <CAJ0GajRoRUbbMTs9LmFSf2g2qMHEs4n=Q4ySPUDyfPMAbnrGig@mail.gmail.com>

Sorry if this is the wrong mail list or has already been answered before,
but I couldn't find any relevant information. I was playing around with
record classes:

public class MyRecordTest {

    public record Foo1(String x) {
        public Foo1 {
            if (x == null) throw new IllegalArgumentException("null
Foo1.x");
        }
    }

    public record Foo2(String x) {
        public Foo2 {
            checkNulls();
        }

        private void checkNulls() {
            if (x == null) throw new IllegalArgumentException("null
Foo2.x");
        }
    }

    public record Foo3(String x) {
        public Foo3 {
            x = x + x;
        }
    }

    public static void main(String... args) {
        System.out.println(new Foo3("a").x());
        try {
            new Foo1("a");
            System.out.println("Foo 1 is ok.");
        } catch (Exception x) {
            x.printStackTrace(System.out);
        }
        try {
            new Foo2("a");
            System.out.println("Foo 2 is ok.");
        } catch (Exception x) {
            x.printStackTrace(System.out);
        }
    }
}

Running the above code gives the following output:

aa
Foo 1 is ok.
java.lang.IllegalArgumentException: null Foo2.x
        at MyRecordTest$Foo2.checkNulls(MyRecordTest.java:15)
        at MyRecordTest$Foo2.<init>(MyRecordTest.java:11)
        at MyRecordTest.main(MyRecordTest.java:34)

It seems that instance methods called inside the record's constructor can't
see its fields. This is at least an undesirable gotcha, and is a
side-effect from the way that the record values are implemented, since they
are still mutable inside the record's constructor and written only after
the given constructor implementation finishes.

Ok, so, what is my point? My point is that this behavior is either not
documented or poorly documented. The java.lang.Record class javadocs should
warn about calling instance methods inside the record constructor or
leaking out the "this" reference (including by indirect means through
instance methods called in the constructor).

Since it promises to be immutable, and the field attribution is handled by
the compiler, many people (including me until a few minutes ago) assumed
that the record instance values were already ready to use when the
programmer's custom constructor's code starts to run and that it would be
impossible to observe a field of the record's value mutating. However, it
does mutate once: it starts out with nulls and zeros and are mutated by the
assignments injected in the end of the constructor by the compiler, and not
in the beginning of the constructor as many people would assume. And,
although the javadocs does state that the values can be changed in the
constructor, it still does not make it clear what are the side-effects or
the not-so-obvious consequences of that.

From forax at univ-mlv.fr  Sun Jun 12 20:55:46 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 12 Jun 2022 22:55:46 +0200 (CEST)
Subject: Record's elements unavailable inside methods called on
 constructors
In-Reply-To: <CAJ0GajRoRUbbMTs9LmFSf2g2qMHEs4n=Q4ySPUDyfPMAbnrGig@mail.gmail.com>
References: <CAJ0GajRoRUbbMTs9LmFSf2g2qMHEs4n=Q4ySPUDyfPMAbnrGig@mail.gmail.com>
Message-ID: <706918425.6165020.1655067346450.JavaMail.zimbra@u-pem.fr>

Hi Victor,
i think you are misunderstanding how a canonical compact constructor works.

The Java language specification 8.10.4.2 [1] says:
"After the last statement, if any, in the body of the compact constructor has completed normally (?14.1), all component fields of the record class are implicitly initialized to the values of the corresponding formal parameters. The component fields are initialized in the order that the corresponding record components are declared in the record header. "

The component fields are initialized *after* the call to checkNulls(), that why you are seeing the "x" not yet initialized inside checkNulls().

regards,
R?mi

[1] https://docs.oracle.com/javase/specs/jls/se17/html/jls-8.html#jls-8.10.4.2

----- Original Message -----
> From: "Victor Williams Stafusa da Silva" <victorwssilva at gmail.com>
> To: "discuss" <discuss at openjdk.java.net>
> Sent: Sunday, June 12, 2022 10:30:42 PM
> Subject: Record's elements unavailable inside methods called on constructors

> Sorry if this is the wrong mail list or has already been answered before,
> but I couldn't find any relevant information. I was playing around with
> record classes:
> 
> public class MyRecordTest {
> 
>    public record Foo1(String x) {
>        public Foo1 {
>            if (x == null) throw new IllegalArgumentException("null
> Foo1.x");
>        }
>    }
> 
>    public record Foo2(String x) {
>        public Foo2 {
>            checkNulls();
>        }
> 
>        private void checkNulls() {
>            if (x == null) throw new IllegalArgumentException("null
> Foo2.x");
>        }
>    }
> 
>    public record Foo3(String x) {
>        public Foo3 {
>            x = x + x;
>        }
>    }
> 
>    public static void main(String... args) {
>        System.out.println(new Foo3("a").x());
>        try {
>            new Foo1("a");
>            System.out.println("Foo 1 is ok.");
>        } catch (Exception x) {
>            x.printStackTrace(System.out);
>        }
>        try {
>            new Foo2("a");
>            System.out.println("Foo 2 is ok.");
>        } catch (Exception x) {
>            x.printStackTrace(System.out);
>        }
>    }
> }
> 
> Running the above code gives the following output:
> 
> aa
> Foo 1 is ok.
> java.lang.IllegalArgumentException: null Foo2.x
>        at MyRecordTest$Foo2.checkNulls(MyRecordTest.java:15)
>        at MyRecordTest$Foo2.<init>(MyRecordTest.java:11)
>        at MyRecordTest.main(MyRecordTest.java:34)
> 
> It seems that instance methods called inside the record's constructor can't
> see its fields. This is at least an undesirable gotcha, and is a
> side-effect from the way that the record values are implemented, since they
> are still mutable inside the record's constructor and written only after
> the given constructor implementation finishes.
> 
> Ok, so, what is my point? My point is that this behavior is either not
> documented or poorly documented. The java.lang.Record class javadocs should
> warn about calling instance methods inside the record constructor or
> leaking out the "this" reference (including by indirect means through
> instance methods called in the constructor).
> 
> Since it promises to be immutable, and the field attribution is handled by
> the compiler, many people (including me until a few minutes ago) assumed
> that the record instance values were already ready to use when the
> programmer's custom constructor's code starts to run and that it would be
> impossible to observe a field of the record's value mutating. However, it
> does mutate once: it starts out with nulls and zeros and are mutated by the
> assignments injected in the end of the constructor by the compiler, and not
> in the beginning of the constructor as many people would assume. And,
> although the javadocs does state that the values can be changed in the
> constructor, it still does not make it clear what are the side-effects or
> the not-so-obvious consequences of that.

From akashche at redhat.com  Mon Jun 13 12:18:58 2022
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 13 Jun 2022 13:18:58 +0100
Subject: Call for Discussion: MSI installer for Windows
Message-ID: <CABUxsJ0x71Ojkzqgm+W37V-XptEk05-y4YYC+eWyRjbjiJLvmw@mail.gmail.com>

Hi,

I would like to open a discussion about possible addition of an MSI
installer as an additional OpenJDK build artifact on Windows.

The intention is to add two new build targets:

"make installer-msi": produces a vanilla upstream MSI installer from a JDK image

"make installer-msi-xml": produces an installer description as a
single XML file that can be used by OpenJDK vendors to create extended
installers based on a vanilla one


Longer description, a draft text for a possible JEP and a full
implementation (as a single squashed commit) is available in
"installer-msi-jpackage" branch in this GitHub repository:

https://github.com/akashche/jdk/tree/installer-msi-jpackage/make/data/installermsi/doc


Current status: implementation of both targets works with the latest
openjdk/jdk master and includes a test-suite.
It currently includes a number of MSI features hardcoded into the
custom template passed to jpackage tool. It is intended
to contribute support for these features to the jpackage tool itself
and to completely remove custom template before
proposing the change for integration into JDK.


Dogfooding: earlier version of this implementation is used to produce
Red Hat OpenJDK 17 Windows installers.


About the author: Alex Kashchenko (Kasko, census id: akasko) is an
engineer working on OpenJDK Windows builds at Red Hat since 2015.

-- 
-Alex


From volker.simonis at gmail.com  Fri Jun 17 18:20:35 2022
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 17 Jun 2022 20:20:35 +0200
Subject: OpenJDK Wiki back online
In-Reply-To: <20220617111320.805403883@eggemoggin.niobe.net>
References: <20220617111320.805403883@eggemoggin.niobe.net>
Message-ID: <CA+3eh10J_mQTwvdHLZd6ZW8NFLonRHngaArN2CX+qY5Zn1-+Jw@mail.gmail.com>

On Fri, Jun 17, 2022 at 8:14 PM <mark.reinhold at oracle.com> wrote:
>
> The OpenJDK Wiki (wiki.openjdk.org) is back online.
>

Thanks, Mark!

> - Mark

From i at qingly.me  Sun Jun 19 13:25:48 2022
From: i at qingly.me (wordlesswind)
Date: Sun, 19 Jun 2022 21:25:48 +0800
Subject: JDK (JRE) and Kernel TLS
Message-ID: <05b010f6-a4a1-afeb-4da5-516d08ff7ad6@qingly.me>

Hello guys,


Sorry to bother you guys, I'm not currently a developer.
But I wonder if JDK (JRE) supports Kernel TLS 
https://urldefense.com/v3/__https://docs.kernel.org/networking/tls.html__;!!ACWV5N9M2RV99hQ!KmhQ3QtLPUsHc-jUcg7_zJjx3Kt2zkHkjYQSWJQfMw4NfrNR7W9qsT7zYzzlZILEBrVpib2HAgs$  ?


Best Regards,

wordlesswind



From brian.goetz at oracle.com  Sun Jun 19 14:11:38 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 19 Jun 2022 10:11:38 -0400
Subject: New JEP: Classfile Processing API
Message-ID: <641b055b-a384-525a-f71a-81ccebd53bc2@oracle.com>


Generation, parsing, and transformation of classfiles is ubiquitous in 
the Java ecosystem.? Frameworks transform classfiles on the fly by 
hooking into classloaders or using `java.lang.instrument`; compilers and 
IDEs for all sorts of languages read and write classfiles; static 
analysis tools read classfiles; migration tools transform classfiles.? 
In the JDK, we have a static compiler (`javac`) and other tools 
(`javap`, `jlink`) that read or transform classfiles, and numerous 
platform features that operate by classfile generation (reflection, 
lambdas, dynamic proxies, method handles), as well as many tests that 
generate classfiles.? In fact, the JDK contains at least three libraries 
for processing classfiles: an internal one (used by JDK tools such as 
`javac`); a fork of ASM (used by lambdas and many other platform 
features), and a fork of BCEL (contained inside a fork of Xalan). And of 
course the ecosystem has many such libraries: ASM, javassist, cglib, 
BCEL, gnu.bytecode, ByteBuddy, and many others.

Over the years, there have been many calls for Java to have an 
"official" classfile library, and there are numerous practical reasons 
to create one, and the shift to the six-month cadence has added two new 
reasons.? Firstly, tools that bundle classfile libraries are more likely 
to encounter classfile versions "from the future", because they use a 
classfile library that knows about Java N, but the customer may be 
running it on Java N+1, which was released only six months later.? 
Second, the pace of classfile format evolution has picked up 
significantly in recent years, with a significant fraction of releases 
having at least some change to the classfile format (new attributes, new 
constant pool forms, new bytecodes, new combinations of flags, etc).? 
Having an official classfile library would mean that applications and 
tools are guaranteed to have access to a library that is up-to-date to 
the latest classfile version that will run on the current JDK.

It might seem an "obvious" choice to "just" standardize on ASM, but 
there are many reasons not to do so.? ASM is an old codebase with plenty 
of legacy baggage; the design priorities that informed its architecture 
are not ideal for the JDK in 2022; and the language has improved 
substantially since them (lambdas, records and sealed classes, pattern 
matching.)? What were the best possible API idioms in 2002 (visitors) 
may not be ideal two decades later.

A draft JEP can be found here:

https://openjdk.org/jeps/8280389

Such an API will have many consumers, both internal to the JDK and 
external: compilers, analysis tools, platform implementation, 3rd party 
libraries, tests, etc.? We will focus initially on the internal JDK 
consumers, incrementally migrating them off of the existing libraries 
and onto the new library.? Eventually, once all the internal consumers 
are migrated, we will be able to remove ASM from the JDK entirely.? 
Initially, the library will be internal-only (non-exported), to gain 
experience with and refine the API before committing to a public 
version. When the API is sufficiently stable, it will be exported for 
public use, first as a preview API and eventually as a permanent API.

Comments on the JEP itself -- the concept, motivation, and design goals 
-- are invited for discussion.? The JEP includes some code examples, 
which are hopefully illustrative, but I will request that people hold 
off on API discussions for the time being, to make room for discussion 
on the JEP itself first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20220619/9dd4048f/attachment-0001.htm>

From per at bothner.com  Sun Jun 19 15:59:28 2022
From: per at bothner.com (Per Bothner)
Date: Sun, 19 Jun 2022 08:59:28 -0700
Subject: New JEP: Classfile Processing API
In-Reply-To: <641b055b-a384-525a-f71a-81ccebd53bc2@oracle.com>
References: <641b055b-a384-525a-f71a-81ccebd53bc2@oracle.com>
Message-ID: <e76d7f52-8fa0-cff3-e3db-d66053ff6ac0@bothner.com>

Generally, this seems like a very good thing to do.

     "For example, branch offsets can be short or long. If clients generate instructions
     imperatively, they have to know how far the branch offset is at the time each branch
     is generated, which is complex and error-prone. But if the client provides a lambda
     that takes a builder, the library can optimistically try to generate the method with
     short offsets, and if this fails, discard the generated state and re-invoke the lambda
     with different code generation parameters.

An aside (and not telling you anything new I'm sure) but a "fixup" post-processing pass
is probably preferable to doing the code-generation twice: It's hard for the latter to use
a mix of short and long jumps as needed.

When gnu.bytecodes generates code the instructions are appended to a byte
array in optimistic form. In addition "fixup" operations are appended to the fixup
buffer (the arrays fixup_offset and fixup_labels).  Then when done emitting instructions
we call processFixups, which iterates over the fixups (3 times!) to adjust the bytecode
and assign final offsets to the labels.

The processFixups method is complicated because it handles a number of issues at
the same time: various optimizations (including moving some code blocks around),
as well as assigning offsets to Labels.

Feel free to get inspiration from:

https://gitlab.com/kashell/Kawa/-/blob/master/gnu/bytecode/CodeAttr.java

The code is a bit convoluted, written more for performance then readability.
However, it is at least somewhat commented - and I'm happy to answer any questions.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/

From brian.goetz at oracle.com  Sun Jun 19 18:21:21 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 19 Jun 2022 14:21:21 -0400
Subject: New JEP: Classfile Processing API
In-Reply-To: <e76d7f52-8fa0-cff3-e3db-d66053ff6ac0@bothner.com>
References: <641b055b-a384-525a-f71a-81ccebd53bc2@oracle.com>
 <e76d7f52-8fa0-cff3-e3db-d66053ff6ac0@bothner.com>
Message-ID: <82c5c1d3-f77c-38ba-e45e-00d104b3c2d1@oracle.com>

Hello Per!

Nice to hear from you again.

> An aside (and not telling you anything new I'm sure) but a "fixup" 
> post-processing pass
> is probably preferable to doing the code-generation twice: It's hard 
> for the latter to use
> a mix of short and long jumps as needed.

Yeah, it's unfortunate either way.? It turns out that 99+% of methods 
have no long jumps, either because they're shorter than 32K, or are 
longer but lucky.? So the retry approach is based on an optimistic 
assumption; we save having to do the fixup + compression pass almost all 
the time, at the cost of running the generation twice a tiny fraction of 
the time.? (Of course, if you know a method is going large, it might 
also be reasonable to indicate that when you start generating, to skip 
over the first pass -- this is something worth looking at.)

Even so, there are still fixups needed for forward branches since you 
don't know the offset until later (and have to hope that someone 
actually emits the corresponding label before the method is done.) But 
this can be accumulated as you go and patched cheaply in place at the 
end if you commit to a specific branch offset width.


Cheers,
-Brian

> When gnu.bytecodes generates code the instructions are appended to a byte
> array in optimistic form. In addition "fixup" operations are appended 
> to the fixup
> buffer (the arrays fixup_offset and fixup_labels).? Then when done 
> emitting instructions
> we call processFixups, which iterates over the fixups (3 times!) to 
> adjust the bytecode
> and assign final offsets to the labels.
>
> The processFixups method is complicated because it handles a number of 
> issues at
> the same time: various optimizations (including moving some code 
> blocks around),
> as well as assigning offsets to Labels.
>
> Feel free to get inspiration from:
>
> https://urldefense.com/v3/__https://gitlab.com/kashell/Kawa/-/blob/master/gnu/bytecode/CodeAttr.java__;!!ACWV5N9M2RV99hQ!NuFecLzqRMWfxSH4G-KYTp_9Jn6vyGPkm9yEuj7VQPxtb7CpXAzN5fAeyINsqhMRRkTrX_0Ua5gu7w$ 
>
> The code is a bit convoluted, written more for performance then 
> readability.
> However, it is at least somewhat commented - and I'm happy to answer 
> any questions.


From per at bothner.com  Sun Jun 19 19:08:28 2022
From: per at bothner.com (Per Bothner)
Date: Sun, 19 Jun 2022 12:08:28 -0700
Subject: New JEP: Classfile Processing API
In-Reply-To: <82c5c1d3-f77c-38ba-e45e-00d104b3c2d1@oracle.com>
References: <641b055b-a384-525a-f71a-81ccebd53bc2@oracle.com>
 <e76d7f52-8fa0-cff3-e3db-d66053ff6ac0@bothner.com>
 <82c5c1d3-f77c-38ba-e45e-00d104b3c2d1@oracle.com>
Message-ID: <00f5d5ff-9c49-6169-31b6-172aad776189@bothner.com>



On 6/19/22 11:21, Brian Goetz wrote:
> Hello Per!
> 
> Nice to hear from you again.
> 
>> An aside (and not telling you anything new I'm sure) but a "fixup" post-processing pass
>> is probably preferable to doing the code-generation twice: It's hard for the latter to use
>> a mix of short and long jumps as needed.
> 
> Yeah, it's unfortunate either way.? It turns out that 99+% of methods have no long jumps, either because they're shorter than 32K, or are longer but lucky.? So the retry approach is based on an optimistic assumption; we save having to do the fixup + compression pass almost all the time, at the cost of running the generation twice a tiny fraction of the time.

Fair enough - though if yu have a method larger than 32K you really don't want to
needlessly push the limit above 64K.  Unless the library has a mechanism to
deal with really large methods.

Kawa has a testsuite that fails because it compiles to larger than 64K.
(This is partly because each test is macro-expanded excessively.
It is fixable in various ways; I've been putting off dealing with it,
as I don't spend a lot of time on Kawa these days.)
I've argued before that this JVM limit should be fixed - unless there is
a library that can work around it in a reasonable way.

One other optimization that processFixups handles is eliminating
jumps to jumps.  I found them painful to deal with otherwise.
(In my recollection - this code appears to be from 2004.)
I realize the JIT can deal with such infelicities in the bytecode,
but I feel uncomfortable generating bloated bytecode.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/

From yogurtearl at gmail.com  Sun Jun 19 19:32:22 2022
From: yogurtearl at gmail.com (Michael Bailey)
Date: Sun, 19 Jun 2022 12:32:22 -0700
Subject: New JEP: Classfile Processing API
Message-ID: <CAAGPs2Tb8c-Oo3JbNXZkrtqF7=i=Sq81677HcYU_JvDw7gMdiw@mail.gmail.com>

Will this new Classfile Processing library implementation be licensed under
"GPL with classpath exception" ?

(For comparison, ASM is BSD licensed.)

Would be great to have it under  a license that is compatible with as many
other OSS licenses as possible.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20220619/71c05a50/attachment-0001.htm>

From brian.goetz at oracle.com  Sun Jun 19 20:36:46 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 19 Jun 2022 16:36:46 -0400
Subject: New JEP: Classfile Processing API
In-Reply-To: <CAAGPs2Tb8c-Oo3JbNXZkrtqF7=i=Sq81677HcYU_JvDw7gMdiw@mail.gmail.com>
References: <CAAGPs2Tb8c-Oo3JbNXZkrtqF7=i=Sq81677HcYU_JvDw7gMdiw@mail.gmail.com>
Message-ID: <71a699b0-7f1b-ea89-1406-a7c6d7db1d75@oracle.com>

It will be part of the JDK, under the same license.

On 6/19/2022 3:32 PM, Michael Bailey wrote:
> Will this new Classfile Processing library implementation be licensed 
> under "GPL with classpath exception" ?
>
> (For comparison, ASM is BSD licensed.)
>
> Would be great to have it under? a license that is compatible with as 
> many other OSS licenses as possible.
>
> -Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20220619/00c6bf6c/attachment.htm>

From aph at redhat.com  Mon Jun 20 07:00:19 2022
From: aph at redhat.com (Andrew Haley)
Date: Mon, 20 Jun 2022 08:00:19 +0100
Subject: JDK (JRE) and Kernel TLS
In-Reply-To: <05b010f6-a4a1-afeb-4da5-516d08ff7ad6@qingly.me>
References: <05b010f6-a4a1-afeb-4da5-516d08ff7ad6@qingly.me>
Message-ID: <0711578e-ffb7-879f-f4f8-88123c95d643@redhat.com>

On 6/19/22 14:25, wordlesswind wrote:
> Sorry to bother you guys, I'm not currently a developer.
> But I wonder if JDK (JRE) supports Kernel TLS
> https://urldefense.com/v3/__https://docs.kernel.org/networking/tls.html__;!!ACWV5N9M2RV99hQ!KmhQ3QtLPUsHc-jUcg7_zJjx3Kt2zkHkjYQSWJQfMw4NfrNR7W9qsT7zYzzlZILEBrVpib2HAgs$   ?

I don't think so. As far as I know, that would only happen if a crypto
provider library (e.g. NSS) was configured, and it used kernel crypto.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!LJUMxadOsQbBbLgglFJoIZlyKQeimePWAIxzfYIj5oxwp4WjbCI9cUWb1RSM3SNIC8bGjcvth6w$ >
https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!ACWV5N9M2RV99hQ!LJUMxadOsQbBbLgglFJoIZlyKQeimePWAIxzfYIj5oxwp4WjbCI9cUWb1RSM3SNIC8bG94HIMFU$ 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From brian.goetz at oracle.com  Fri Jun 24 15:51:34 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 24 Jun 2022 11:51:34 -0400
Subject: New JEP: Classfile Processing API
In-Reply-To: <641b055b-a384-525a-f71a-81ccebd53bc2@oracle.com>
References: <641b055b-a384-525a-f71a-81ccebd53bc2@oracle.com>
Message-ID: <f905d172-9ce9-2f21-5860-e3996ef1b7ab@oracle.com>

We've staged the current state of the in-development classfile API in 
the OpenJDK sandbox repo:

https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch

The README file there includes instructions for building, running the 
tests, and running the benchmarks.? The API is in the package 
`jdk.classfile` (a good starting point is the class `Classfile`, which 
contains the main entry points for parsing and generating classfiles).? 
It provides full coverage of the classfile format through Java 17.? The 
repo also includes experimental replacements for most uses of ASM in the 
JDK.

There is Javadoc here:

https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html

The package doc is a good place to start to get an overview of how it is 
used.? The docs so far are fairly thin, and need a lot of work, 
especially examples.

How can people contribute?

 ?- Try it out!? Bring your favorite code examples from ASM, cglib, or 
your favorite bytecode library, and try them with this library.? Post 
experience reports (but please, let's keep subjective "you should do it 
like my library does" down to a dull roar.)? Bear in mind that your 
first idea of how to do it in the library might be suboptimal, so ask 
questions.

 ?- Tests.? Our test coverage is good, but there are still corners of 
the API that are not fully covered.? We'll be posting some coverage 
metrics soon; additional tests are always useful.

 ?- Examples.? Our docs need lots of examples, and well-crafted examples 
are worth a thousand words.

Further discussion should take place on classfile-api-dev at openjdk.org 
(copied); you can sign up here:

https://mail.openjdk.org/mailman/listinfo/classfile-api-dev



On 6/19/2022 10:11 AM, Brian Goetz wrote:
>
> Generation, parsing, and transformation of classfiles is ubiquitous in 
> the Java ecosystem.? Frameworks transform classfiles on the fly by 
> hooking into classloaders or using `java.lang.instrument`; compilers 
> and IDEs for all sorts of languages read and write classfiles; static 
> analysis tools read classfiles; migration tools transform classfiles.? 
> In the JDK, we have a static compiler (`javac`) and other tools 
> (`javap`, `jlink`) that read or transform classfiles, and numerous 
> platform features that operate by classfile generation (reflection, 
> lambdas, dynamic proxies, method handles), as well as many tests that 
> generate classfiles.? In fact, the JDK contains at least three 
> libraries for processing classfiles: an internal one (used by JDK 
> tools such as `javac`); a fork of ASM (used by lambdas and many other 
> platform features), and a fork of BCEL (contained inside a fork of 
> Xalan).? And of course the ecosystem has many such libraries: ASM, 
> javassist, cglib, BCEL, gnu.bytecode, ByteBuddy, and many others.
>
> Over the years, there have been many calls for Java to have an 
> "official" classfile library, and there are numerous practical reasons 
> to create one, and the shift to the six-month cadence has added two 
> new reasons. Firstly, tools that bundle classfile libraries are more 
> likely to encounter classfile versions "from the future", because they 
> use a classfile library that knows about Java N, but the customer may 
> be running it on Java N+1, which was released only six months later.? 
> Second, the pace of classfile format evolution has picked up 
> significantly in recent years, with a significant fraction of releases 
> having at least some change to the classfile format (new attributes, 
> new constant pool forms, new bytecodes, new combinations of flags, 
> etc). Having an official classfile library would mean that 
> applications and tools are guaranteed to have access to a library that 
> is up-to-date to the latest classfile version that will run on the 
> current JDK.
>
> It might seem an "obvious" choice to "just" standardize on ASM, but 
> there are many reasons not to do so.? ASM is an old codebase with 
> plenty of legacy baggage; the design priorities that informed its 
> architecture are not ideal for the JDK in 2022; and the language has 
> improved substantially since them (lambdas, records and sealed 
> classes, pattern matching.)? What were the best possible API idioms in 
> 2002 (visitors) may not be ideal two decades later.
>
> A draft JEP can be found here:
>
> https://openjdk.org/jeps/8280389
>
> Such an API will have many consumers, both internal to the JDK and 
> external: compilers, analysis tools, platform implementation, 3rd 
> party libraries, tests, etc.? We will focus initially on the internal 
> JDK consumers, incrementally migrating them off of the existing 
> libraries and onto the new library. Eventually, once all the internal 
> consumers are migrated, we will be able to remove ASM from the JDK 
> entirely.? Initially, the library will be internal-only 
> (non-exported), to gain experience with and refine the API before 
> committing to a public version.? When the API is sufficiently stable, 
> it will be exported for public use, first as a preview API and 
> eventually as a permanent API.
>
> Comments on the JEP itself -- the concept, motivation, and design 
> goals -- are invited for discussion.? The JEP includes some code 
> examples, which are hopefully illustrative, but I will request that 
> people hold off on API discussions for the time being, to make room 
> for discussion on the JEP itself first.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20220624/d8f88d90/attachment-0001.htm>

From alexey.semenyuk at oracle.com  Mon Jun 27 16:21:42 2022
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 27 Jun 2022 12:21:42 -0400
Subject: Call for Discussion: MSI installer for Windows
In-Reply-To: <f412a36e-e286-5bb8-d987-e5d7c148cf42@oracle.com>
References: <f412a36e-e286-5bb8-d987-e5d7c148cf42@oracle.com>
Message-ID: <8f915495-c184-7321-f1e6-cdd7ac98c118@oracle.com>

Hi Alex,

OpenJDK already provides a packaging tool for Java applications and Java 
runtimes.
We don't believe OpenJDK needs another one targeting a narrower scope.

Rather than contributing an MSI installer to OpenJDK which would 
duplicate a lot of the functionality already in jpackage, we'd encourage 
you to contribute to jpackage enhancements allowing it to satisfy 
broader range of requirements for Java runtime installers and should 
allow any OpenJDK vendor to leverage it to create whatever exact 
installer they may want.

- Alexey


From akashche at redhat.com  Mon Jun 27 21:01:17 2022
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 27 Jun 2022 22:01:17 +0100
Subject: Call for Discussion: MSI installer for Windows
In-Reply-To: <8f915495-c184-7321-f1e6-cdd7ac98c118@oracle.com>
References: <f412a36e-e286-5bb8-d987-e5d7c148cf42@oracle.com>
 <8f915495-c184-7321-f1e6-cdd7ac98c118@oracle.com>
Message-ID: <CABUxsJ0kxEHoaA9hapn4+3s3w6mdNWo8uuH2PDmp0T2TykS9oA@mail.gmail.com>

Hi Alexey,

On 6/27/22, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
> Hi Alex,
>
> OpenJDK already provides a packaging tool for Java applications and Java
> runtimes.
> We don't believe OpenJDK needs another one targeting a narrower scope.
>
> Rather than contributing an MSI installer to OpenJDK which would
> duplicate a lot of the functionality already in jpackage, we'd encourage
> you to contribute to jpackage enhancements allowing it to satisfy
> broader range of requirements for Java runtime installers and should
> allow any OpenJDK vendor to leverage it to create whatever exact
> installer they may want.

Thanks for your comments!

While I may disagree about the "duplicate functionality", I would like
to note that jpackage enhancements (outlined in [1], but not limited
with the features listed there) were intended to be contributed as a
prerequisite to possible MSI installer make target. I believe, that
such enhancements to jpackage (in runtime installers area) can be
beneficial, regardless of whether the make target is added or not.

I also think, that some kind of "vanilla upstream" installer (produced
by jpackage from "make images" output, with a concrete fixed set of
input flags/resources) may be useful as a baseline for vendor-specific
installers. For example, we at Red Hat would prefer to maintain the
installer as close as possible to (supposed) vanilla upstream one.

I intend to continue with jpackage contributions, with a goal to be
able to create installers with the set of features that match existing
LTS Red Hat installers. Hopefully the idea of a "vanilla upstream"
installer JEP may be reconsidered in future.


[1] https://github.com/akashche/jdk/blob/installer-msi-jpackage/make/data/installermsi/doc/JPACKAGE.md#jpackage-additional-features

-- 
-Alex