From stuart.marks at oracle.com  Tue Feb  2 00:15:24 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 1 Feb 2021 16:15:24 -0800
Subject: I was running into problems with different teams at my employer
 using different Immutable Collection implementations and wanted to avoid
 writing code to adapt each Collection
In-Reply-To: <CA+c=zxy4LJeWU0U4bwm9yRWfb2rJNoqwfyEN-KFNt81T4UDcow@mail.gmail.com>
References: <CA+c=zxz=-hA9=Hh4s1wqun+drumQGXtru5tprLcUbhdRn+RQDw@mail.gmail.com>
 <470210907.2098557.1612127989863.JavaMail.zimbra@u-pem.fr>
 <CA+c=zxy4LJeWU0U4bwm9yRWfb2rJNoqwfyEN-KFNt81T4UDcow@mail.gmail.com>
Message-ID: <c2edba76-1f94-b975-cd8c-f8cc0dc14990@oracle.com>

As Remi pointed out, retrofitting the interfaces this way would imply that ArrayList 
implements UnmodifiableCollection. (This seems semantically wrong in the first 
place, but it might be mitigated by renaming things to ReadableCollection etc.)

Another point is that UnmodifiableCollection isn't a Collection, so adding its 
elements to an existing collection via myArrayList.addAll(unmodcoll) would no longer 
work without some additional adaptation.

Additionally, UnmodifiableCollection would implement UnmodifiableIterable but not 
Iterable, so it would no longer be possible to iterate using a for-loop. Again, not 
without additional adaptation.

I've written some about this issue here:

     https://stackoverflow.com/a/57926310/1441122

One alternative this SO answer doesn't cover is having no type relationship between 
UnmodifiableCollection and Collection, similar to the way Eclipse Collections does 
it. That's another stable point in the design space, and it has a bunch of different 
tradeoffs. It also requires the addition of a bunch of adapters between the hierarchies.

A central decision is whether "unmodifiable" allows unmodifiability to be cast away, 
whether it permits modification only via another reference (an "unmodifiable view"), 
or whether it indicates the underlying collection itself is unmodifiable ("shallowly 
immutable"). Closely related is the issue of what to do about the return type of 
methods like List.of() and Collections.unmodifiableList() and related methods.

Remi noted previously that the idea of unmodifiable collection interfaces was 
rejected from the initial design. That doesn't mean it's a bad idea and that they 
can never be added. Indeed, proposals and questions in this area do come up from 
time to time. The problem is that doing this (for whatever definition of "this") is 
harder than it seems at first glance, and the benefits provided have never been 
quite able to justify the additional complexity this would add to the platform.

s'marks



On 1/31/21 2:10 PM, Larry Diamond wrote:
> Wow thanks for getting back to me so quickly.   I'll read over the existing
> conversation.   Thank you very much
> 
> On Sun, Jan 31, 2021 at 4:19 PM Remi Forax <forax at univ-mlv.fr> wrote:
> 
>> Hi Larry,
>> this design was considered and rejected when the collection API vas
>> introduced in JDK 1.2
>> see
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066245.html
>>
>> Furthermore, if List extends ImmutableList, it means that ArrayList
>> implements ImmutableList which is just plain wrong.
>> Consider the following code
>>    record Foo(ImmutableList<String> list) { }
>>    var arrayList = new ArrayList<String>();
>>    var foo = new Foo(arrayList);
>>    System.out.println(foo.list()); // []
>>    arrayList.add("oops");
>>    System.out.println(foo.list()); // [oops]
>>
>> regards,
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Larry Diamond" <ldiamond at ldiamond.com>
>>> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
>>> Envoy?: Dimanche 31 Janvier 2021 21:28:33
>>> Objet: I was running into problems with different teams at my employer
>> using different Immutable Collection
>>> implementations and wanted to avoid writing code to adapt each Collection
>>
>>> I was thinking of submitting a proposal for UnmodifiableCollections for
>>> Java.
>>>
>>> I wrote up a first draft of a JEP for this.
>>>
>>> What do you think?
>>>
>>> Thank you very much
>>> Larry Diamond
>>

From thihup at gmail.com  Tue Feb  2 00:20:36 2021
From: thihup at gmail.com (Thiago Henrique Hupner)
Date: Mon, 1 Feb 2021 21:20:36 -0300
Subject: String interpolation
Message-ID: <CAENv9VG3jLfuP=sL=qBDdtWOZpmXSPnr9_dxydyeqVM39SDSFw@mail.gmail.com>

Hi!

Now that Text Blocks has been integrated, should be the time to start
thinking about the String interpolation?

One idea would be using the following syntax: String x = "Text
\(expression)";

PS: I've sent this message to the amber-dev but got no reply, where is the
correct place to send it?

From liangchenblue at gmail.com  Tue Feb  2 00:21:25 2021
From: liangchenblue at gmail.com (-)
Date: Mon, 1 Feb 2021 18:21:25 -0600
Subject: AbstractClassLoaderValue's 2 todos cleanup
Message-ID: <CABe8uE2ZjJTnTFvtZmk2bAJzD0qhUpwjVm5xp=CfqbHmjO59ZQ@mail.gmail.com>

Hello,
When I am browsing, I find two TODOs in
jdk.internal.loader.AbstractClassLoaderValue
at
https://github.com/openjdk/jdk/blob/a6d950587bc68f81495660f59169b7f1970076e7/src/java.base/share/classes/jdk/internal/loader/AbstractClassLoaderValue.java#L137
and
https://github.com/openjdk/jdk/blob/a6d950587bc68f81495660f59169b7f1970076e7/src/java.base/share/classes/jdk/internal/loader/AbstractClassLoaderValue.java#L230

They can be changed into Thread.onSpinWait() calls. Mind create an issue on
jdk bug tracker?

Best regards

From ldiamond at ldiamond.com  Tue Feb  2 01:44:05 2021
From: ldiamond at ldiamond.com (Larry Diamond)
Date: Mon, 1 Feb 2021 20:44:05 -0500
Subject: I was running into problems with different teams at my employer
 using different Immutable Collection implementations and wanted to avoid
 writing code to adapt each Collection
In-Reply-To: <c2edba76-1f94-b975-cd8c-f8cc0dc14990@oracle.com>
References: <CA+c=zxz=-hA9=Hh4s1wqun+drumQGXtru5tprLcUbhdRn+RQDw@mail.gmail.com>
 <470210907.2098557.1612127989863.JavaMail.zimbra@u-pem.fr>
 <CA+c=zxy4LJeWU0U4bwm9yRWfb2rJNoqwfyEN-KFNt81T4UDcow@mail.gmail.com>
 <c2edba76-1f94-b975-cd8c-f8cc0dc14990@oracle.com>
Message-ID: <CA+c=zxwuG8ExNVTvPnB5Y3DniY2nMUZYuM7W6ah7-ngHWKeMXQ@mail.gmail.com>

Thank you for taking the time to look over my proposal and give it some
really good thought.

I really like the idea of calling the interfaces "Readable" rather than
"Unmodifiable".
I agree that the every ArrayList is "Immutable" since that clearly isn't my
intent here,
and I like the "Readable" term much better than "Immutable" or
"Unmodifiable" and you've
clearly internalized what I was thinking about and are very familiar with
the Guava and Eclipse
attempts to implement this concept.  (and of yeah Readable is a lot easier
to spell than Unmodifiable!)

There are definitely some methods on the existing interfaces that would
need to change
types to accept ReadableCollection rather than Collection.   I'll compile a
list so at least
everybody can take a look at how big of a change that would be.

The for-loop connection to Iterable would need to change to
ReadableIterable.
I'm not sure how big of a job that is to change that, but since Iterable
would extend ReadableIterable
no existing code should be broken by that change.

My original idea was that Immutability is a "view" of the underlying
Collection and so changes
to the underlying Collection would change the Immutable view.
My original goal is to prevent software defects by allowing "readers" of a
Collection to have different rights
to that Collection than "owners" - to pass in an Immutable view of a
Collection into a method and be confident
that method could not change the Collection, and for the readers of that
Collection to be aware of that at compile
time and not run time.

   public void myMethod (Set<Something> mySet) {
      ReadableSet <Something> myReadableSet = mySet;
      boolean whatever = someOtherMethod (myReadableSet);

I know that someOtherMethod will never modify mySet and a developer
attempting
to do so will be blocked by the compiler.   It certainly does not prevent
another thread from
modifying mySet, just like today with a ConcurrentSkipListSet.   The
difference is that the developer
is preventing from compiling code that damages mySet, preventing the
introduction of unexpected behavior
from future code after the original developers have moved onto other
projects.

My original intent was to have an "unmodifiable view" rather than a
"shallowly immutable" Collection.
If somebody wants to have a "shallowly immutable" Collection, that can make
a "unmodifiable view" of
what they want in their Collection and then throw away the original
Collection reference and only use the
"unmodifiable view" in their code.

   Set<Something> mySet = loadFromDatabase();
   ReadableSet<Something> myReadableSet = mySet;
   mySet = null;

As regards to the List.of() methods and similar methods, I've proposed
List.uof() (Unmodifiable Of,
perhaps now rof() to say ReadableOf methods in the Readable interfaces that
would have default
implementations in the existing interfaces to return the value of the
existing of() method.
ReadableList<String> myList = ReadableList.rof ("A", "B", "C");
would be the same as
ReadableList<String> myList = List.of ("A", "B", "C");
and I hope that the default implementations in List reduce the need for
any implementing class
from needing to change - that is a goal of this design.

I agree that when the Collections framework was first created that these
classes wouldn't have made sense.
With (at least) three well known high quality attempts at hitting this
target, there's clearly some different
opinions in the community.   I think the use cases for Java applications
are much different now than they were
when the framework was written, many of them thanks to the success of
Java.  One of the documents that has
been referred to is
https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a2
which
states that in the case of a programming error that the program should
halt.   In the command line use cases
when the framework was written, I think that was a very reasonable decision
and reasonable behavior, and
now we've all no doubt had more than a few conversations about defensive
programming - I think the newer
use cases warrant a reconsideration of what I think was the right decision
at the time.   Software defects are
much more common now and I can't think of a single very large application
that does not have some defects
in them somewhere, even if we don't see them very often.   Security related
defects are particularly troublesome
and were not so much of an issue before we all had publicly accessible
RESTFul endpoints in our applications.

Thank you both very much for taking the time to discuss my suggestion in
extremely intelligent depth.
I greatly appreciate your feedback and consideration.

I will review the interfaces and come up with a list of methods where the
signature might change to accept
"Readable" interfaces.

Thank you very much
Larry Diamond









On Mon, Feb 1, 2021 at 7:17 PM Stuart Marks <stuart.marks at oracle.com> wrote:

> As Remi pointed out, retrofitting the interfaces this way would imply that
> ArrayList
> implements UnmodifiableCollection. (This seems semantically wrong in the
> first
> place, but it might be mitigated by renaming things to ReadableCollection
> etc.)
>
> Another point is that UnmodifiableCollection isn't a Collection, so adding
> its
> elements to an existing collection via myArrayList.addAll(unmodcoll) would
> no longer
> work without some additional adaptation.
>
> Additionally, UnmodifiableCollection would implement UnmodifiableIterable
> but not
> Iterable, so it would no longer be possible to iterate using a for-loop.
> Again, not
> without additional adaptation.
>
> I've written some about this issue here:
>
>      https://stackoverflow.com/a/57926310/1441122
>
> One alternative this SO answer doesn't cover is having no type
> relationship between
> UnmodifiableCollection and Collection, similar to the way Eclipse
> Collections does
> it. That's another stable point in the design space, and it has a bunch of
> different
> tradeoffs. It also requires the addition of a bunch of adapters between
> the hierarchies.
>
> A central decision is whether "unmodifiable" allows unmodifiability to be
> cast away,
> whether it permits modification only via another reference (an
> "unmodifiable view"),
> or whether it indicates the underlying collection itself is unmodifiable
> ("shallowly
> immutable"). Closely related is the issue of what to do about the return
> type of
> methods like List.of() and Collections.unmodifiableList() and related
> methods.
>
> Remi noted previously that the idea of unmodifiable collection interfaces
> was
> rejected from the initial design. That doesn't mean it's a bad idea and
> that they
> can never be added. Indeed, proposals and questions in this area do come
> up from
> time to time. The problem is that doing this (for whatever definition of
> "this") is
> harder than it seems at first glance, and the benefits provided have never
> been
> quite able to justify the additional complexity this would add to the
> platform.
>
> s'marks
>
>
>
> On 1/31/21 2:10 PM, Larry Diamond wrote:
> > Wow thanks for getting back to me so quickly.   I'll read over the
> existing
> > conversation.   Thank you very much
> >
> > On Sun, Jan 31, 2021 at 4:19 PM Remi Forax <forax at univ-mlv.fr> wrote:
> >
> >> Hi Larry,
> >> this design was considered and rejected when the collection API vas
> >> introduced in JDK 1.2
> >> see
> >>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066245.html
> >>
> >> Furthermore, if List extends ImmutableList, it means that ArrayList
> >> implements ImmutableList which is just plain wrong.
> >> Consider the following code
> >>    record Foo(ImmutableList<String> list) { }
> >>    var arrayList = new ArrayList<String>();
> >>    var foo = new Foo(arrayList);
> >>    System.out.println(foo.list()); // []
> >>    arrayList.add("oops");
> >>    System.out.println(foo.list()); // [oops]
> >>
> >> regards,
> >> R?mi
> >>
> >> ----- Mail original -----
> >>> De: "Larry Diamond" <ldiamond at ldiamond.com>
> >>> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> >>> Envoy?: Dimanche 31 Janvier 2021 21:28:33
> >>> Objet: I was running into problems with different teams at my employer
> >> using different Immutable Collection
> >>> implementations and wanted to avoid writing code to adapt each
> Collection
> >>
> >>> I was thinking of submitting a proposal for UnmodifiableCollections for
> >>> Java.
> >>>
> >>> I wrote up a first draft of a JEP for this.
> >>>
> >>> What do you think?
> >>>
> >>> Thank you very much
> >>> Larry Diamond
> >>
>

From ldiamond at ldiamond.com  Tue Feb  2 23:07:38 2021
From: ldiamond at ldiamond.com (Larry Diamond)
Date: Tue, 2 Feb 2021 18:07:38 -0500
Subject: I was running into problems with different teams at my employer
 using different Immutable Collection implementations and wanted to avoid
 writing code to adapt each Collection
In-Reply-To: <CA+c=zxwuG8ExNVTvPnB5Y3DniY2nMUZYuM7W6ah7-ngHWKeMXQ@mail.gmail.com>
References: <CA+c=zxz=-hA9=Hh4s1wqun+drumQGXtru5tprLcUbhdRn+RQDw@mail.gmail.com>
 <470210907.2098557.1612127989863.JavaMail.zimbra@u-pem.fr>
 <CA+c=zxy4LJeWU0U4bwm9yRWfb2rJNoqwfyEN-KFNt81T4UDcow@mail.gmail.com>
 <c2edba76-1f94-b975-cd8c-f8cc0dc14990@oracle.com>
 <CA+c=zxwuG8ExNVTvPnB5Y3DniY2nMUZYuM7W6ah7-ngHWKeMXQ@mail.gmail.com>
Message-ID: <CA+c=zxwUNm2R9o1NHh-T6Vms9obsQoFmsFmw+tMDc0X5_VNAcw@mail.gmail.com>

I'm looking through the Collections framework and I believe the following
methods
should be changed to take in a "Readable" counterpart:

Collection:
 containsAll (Collection<?> c)
 addAll (Collection<? extends E> c)
 removeAll (Collection<?> c)
 retainAll (Collection<?> c)

List:
 containsAll (Collection<?> c)   // from Collection
 addAll (Collection<? extends E> c)  // from Collection
 addAll (int index, Collection<? extends E> c)
 removeAll (Collection<?> c)   // from Collection
 retainAll (Collection<?> c)   // from Collection
 copyOf (Collection <> extends E> coll)


Set:
 containsAll (Collection<?> c)   // from Collection
 addAll (Collection<? extends E> c)  // from Collection
 removeAll (Collection<?> c)   // from Collection
 retainAll (Collection<?> c)   // from Collection
 copyOf (Collection <> extends E> coll)


Map:
 putAll(Map<? extends K, ? extends V> m)
 copyOf(Map<? extends K, ? extends V> map)


Deque:
 addAll (Collection<? extends E> c)  // from Collection


The following interfaces have been reviewed and I believe no changes to the
files would occur.   The interfaces may become changed due to a
superinterface change:
 Enumeration
 Iterable
 Iterator
 ListIterator
 NavigableMap
 NavigableSet
 Queue
 SortedMap
 SortedSet
 Spliterator

These are all the interfaces I reviewed, I doubt I know the details of the
Collections
framework nearly as well as anybody else on this distribution list.

Thank you for taking the time to review this proposal, I appreciate your
thought and
feedback.

Larry Diamond

On Mon, Feb 1, 2021 at 8:44 PM Larry Diamond <ldiamond at ldiamond.com> wrote:

> Thank you for taking the time to look over my proposal and give it some
> really good thought.
>
> I really like the idea of calling the interfaces "Readable" rather than
> "Unmodifiable".
> I agree that the every ArrayList is "Immutable" since that clearly isn't
> my intent here,
> and I like the "Readable" term much better than "Immutable" or
> "Unmodifiable" and you've
> clearly internalized what I was thinking about and are very familiar with
> the Guava and Eclipse
> attempts to implement this concept.  (and of yeah Readable is a lot easier
> to spell than Unmodifiable!)
>
> There are definitely some methods on the existing interfaces that would
> need to change
> types to accept ReadableCollection rather than Collection.   I'll compile
> a list so at least
> everybody can take a look at how big of a change that would be.
>
> The for-loop connection to Iterable would need to change to
> ReadableIterable.
> I'm not sure how big of a job that is to change that, but since Iterable
> would extend ReadableIterable
> no existing code should be broken by that change.
>
> My original idea was that Immutability is a "view" of the underlying
> Collection and so changes
> to the underlying Collection would change the Immutable view.
> My original goal is to prevent software defects by allowing "readers" of a
> Collection to have different rights
> to that Collection than "owners" - to pass in an Immutable view of a
> Collection into a method and be confident
> that method could not change the Collection, and for the readers of that
> Collection to be aware of that at compile
> time and not run time.
>
>    public void myMethod (Set<Something> mySet) {
>       ReadableSet <Something> myReadableSet = mySet;
>       boolean whatever = someOtherMethod (myReadableSet);
>
> I know that someOtherMethod will never modify mySet and a developer
> attempting
> to do so will be blocked by the compiler.   It certainly does not prevent
> another thread from
> modifying mySet, just like today with a ConcurrentSkipListSet.   The
> difference is that the developer
> is preventing from compiling code that damages mySet, preventing the
> introduction of unexpected behavior
> from future code after the original developers have moved onto other
> projects.
>
> My original intent was to have an "unmodifiable view" rather than a
> "shallowly immutable" Collection.
> If somebody wants to have a "shallowly immutable" Collection, that can
> make a "unmodifiable view" of
> what they want in their Collection and then throw away the original
> Collection reference and only use the
> "unmodifiable view" in their code.
>
>    Set<Something> mySet = loadFromDatabase();
>    ReadableSet<Something> myReadableSet = mySet;
>    mySet = null;
>
> As regards to the List.of() methods and similar methods, I've proposed
> List.uof() (Unmodifiable Of,
> perhaps now rof() to say ReadableOf methods in the Readable interfaces
> that would have default
> implementations in the existing interfaces to return the value of the
> existing of() method.
> ReadableList<String> myList = ReadableList.rof ("A", "B", "C");
> would be the same as
> ReadableList<String> myList = List.of ("A", "B", "C");
> and I hope that the default implementations in List reduce the need for
> any implementing class
> from needing to change - that is a goal of this design.
>
> I agree that when the Collections framework was first created that these
> classes wouldn't have made sense.
> With (at least) three well known high quality attempts at hitting this
> target, there's clearly some different
> opinions in the community.   I think the use cases for Java applications
> are much different now than they were
> when the framework was written, many of them thanks to the success of
> Java.  One of the documents that has
> been referred to is
> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a2
> which
> states that in the case of a programming error that the program should
> halt.   In the command line use cases
> when the framework was written, I think that was a very reasonable
> decision and reasonable behavior, and
> now we've all no doubt had more than a few conversations about defensive
> programming - I think the newer
> use cases warrant a reconsideration of what I think was the right decision
> at the time.   Software defects are
> much more common now and I can't think of a single very large application
> that does not have some defects
> in them somewhere, even if we don't see them very often.   Security
> related defects are particularly troublesome
> and were not so much of an issue before we all had publicly accessible
> RESTFul endpoints in our applications.
>
> Thank you both very much for taking the time to discuss my suggestion in
> extremely intelligent depth.
> I greatly appreciate your feedback and consideration.
>
> I will review the interfaces and come up with a list of methods where the
> signature might change to accept
> "Readable" interfaces.
>
> Thank you very much
> Larry Diamond
>
>
>
>
>
>
>
>
>
> On Mon, Feb 1, 2021 at 7:17 PM Stuart Marks <stuart.marks at oracle.com>
> wrote:
>
>> As Remi pointed out, retrofitting the interfaces this way would imply
>> that ArrayList
>> implements UnmodifiableCollection. (This seems semantically wrong in the
>> first
>> place, but it might be mitigated by renaming things to ReadableCollection
>> etc.)
>>
>> Another point is that UnmodifiableCollection isn't a Collection, so
>> adding its
>> elements to an existing collection via myArrayList.addAll(unmodcoll)
>> would no longer
>> work without some additional adaptation.
>>
>> Additionally, UnmodifiableCollection would implement UnmodifiableIterable
>> but not
>> Iterable, so it would no longer be possible to iterate using a for-loop.
>> Again, not
>> without additional adaptation.
>>
>> I've written some about this issue here:
>>
>>      https://stackoverflow.com/a/57926310/1441122
>>
>> One alternative this SO answer doesn't cover is having no type
>> relationship between
>> UnmodifiableCollection and Collection, similar to the way Eclipse
>> Collections does
>> it. That's another stable point in the design space, and it has a bunch
>> of different
>> tradeoffs. It also requires the addition of a bunch of adapters between
>> the hierarchies.
>>
>> A central decision is whether "unmodifiable" allows unmodifiability to be
>> cast away,
>> whether it permits modification only via another reference (an
>> "unmodifiable view"),
>> or whether it indicates the underlying collection itself is unmodifiable
>> ("shallowly
>> immutable"). Closely related is the issue of what to do about the return
>> type of
>> methods like List.of() and Collections.unmodifiableList() and related
>> methods.
>>
>> Remi noted previously that the idea of unmodifiable collection interfaces
>> was
>> rejected from the initial design. That doesn't mean it's a bad idea and
>> that they
>> can never be added. Indeed, proposals and questions in this area do come
>> up from
>> time to time. The problem is that doing this (for whatever definition of
>> "this") is
>> harder than it seems at first glance, and the benefits provided have
>> never been
>> quite able to justify the additional complexity this would add to the
>> platform.
>>
>> s'marks
>>
>>
>>
>> On 1/31/21 2:10 PM, Larry Diamond wrote:
>> > Wow thanks for getting back to me so quickly.   I'll read over the
>> existing
>> > conversation.   Thank you very much
>> >
>> > On Sun, Jan 31, 2021 at 4:19 PM Remi Forax <forax at univ-mlv.fr> wrote:
>> >
>> >> Hi Larry,
>> >> this design was considered and rejected when the collection API vas
>> >> introduced in JDK 1.2
>> >> see
>> >>
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066245.html
>> >>
>> >> Furthermore, if List extends ImmutableList, it means that ArrayList
>> >> implements ImmutableList which is just plain wrong.
>> >> Consider the following code
>> >>    record Foo(ImmutableList<String> list) { }
>> >>    var arrayList = new ArrayList<String>();
>> >>    var foo = new Foo(arrayList);
>> >>    System.out.println(foo.list()); // []
>> >>    arrayList.add("oops");
>> >>    System.out.println(foo.list()); // [oops]
>> >>
>> >> regards,
>> >> R?mi
>> >>
>> >> ----- Mail original -----
>> >>> De: "Larry Diamond" <ldiamond at ldiamond.com>
>> >>> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
>> >>> Envoy?: Dimanche 31 Janvier 2021 21:28:33
>> >>> Objet: I was running into problems with different teams at my employer
>> >> using different Immutable Collection
>> >>> implementations and wanted to avoid writing code to adapt each
>> Collection
>> >>
>> >>> I was thinking of submitting a proposal for UnmodifiableCollections
>> for
>> >>> Java.
>> >>>
>> >>> I wrote up a first draft of a JEP for this.
>> >>>
>> >>> What do you think?
>> >>>
>> >>> Thank you very much
>> >>> Larry Diamond
>> >>
>>
>

From sean.mullan at oracle.com  Thu Feb  4 21:30:24 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 4 Feb 2021 16:30:24 -0500
Subject: Result: New JDK Committer: Hai-May Chao
Message-ID: <ccaddce2-963a-2fd9-11a5-df1671333875@oracle.com>

Voting for Hai-May Chao [1] is now closed.

Yes: 25
Veto: 0
Abstain: 0

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

Sean Mullan

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

From mark.reinhold at oracle.com  Thu Feb  4 22:16:29 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  4 Feb 2021 14:16:29 -0800 (PST)
Subject: JDK 16: First Release Candidate
Message-ID: <20210204221629.7F88E3D6CEF@eggemoggin.niobe.net>

Per the JDK 16 schedule [1], we are now in the Release Candidate phase.
The stabilization repository [2] is open for P1 bug fixes per the JDK
Release Process (JEP 3) [3].  All changes require approval via the
Fix-Request Process [4].

If you?re responsible for any of the bugs on the RC candidate-bug list
[5] then please see JEP 3 for guidance on how to handle them.

There are no unresolved P1 bugs in build 35, so that is our first JDK 16
Release Candidate.

Binaries available here, as usual: https://jdk.java.net/16

- Mark


[1] https://openjdk.java.net/projects/jdk/16/#Schedule
[2] https://github.com/openjdk/jdk16
[3] https://openjdk.java.net/jeps/3
[4] https://openjdk.java.net/jeps/3#Fix-Request-Process
[5] https://j.mp/jdk-rc

From mark.reinhold at oracle.com  Fri Feb  5 16:44:36 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 05 Feb 2021 08:44:36 -0800
Subject: JEP proposed to target JDK 17: 356: Enhanced Pseudo-Random Number
 Generators
In-Reply-To: <20210128235143.269C13D5FE3@eggemoggin.niobe.net>
References: <20210128235143.269C13D5FE3@eggemoggin.niobe.net>
Message-ID: <20210205084436.162896448@eggemoggin.niobe.net>

2021/1/28 15:51:43 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 17:
> 
>   356: Enhanced Pseudo-Random Number Generators
>        https://openjdk.java.net/jeps/356
> 
>   Summary: Provide new interface types and implementations for
>   pseudorandom number generators (PRNGs), including jumpable PRNGs and an
>   additional class of splittable PRNG algorithms (LXM).
> 
> 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 February, 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 ebresie at gmail.com  Tue Feb  9 14:03:40 2021
From: ebresie at gmail.com (Eric Bresie)
Date: Tue, 9 Feb 2021 08:03:40 -0600
Subject: JPMS Runtime Swappable Modules
Message-ID: <CAHw6w1Qacs-7atbrUseiE7B=Zgj16=UysTnMjDmp+mJpYaHgjg@mail.gmail.com>

I?m still new to JPMS but in project discussion elsewhere, someone made the
observation that JPMS modules could not be swapped out during run time.  Is
this correct?

If its not possible, are there any plans to allow for a module to be
hot-swappable during runtime (I guess similar to OSGI)
-- 
Eric Bresie
ebresie at gmail.com

From Alan.Bateman at oracle.com  Tue Feb  9 14:37:49 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 9 Feb 2021 14:37:49 +0000
Subject: JPMS Runtime Swappable Modules
In-Reply-To: <CAHw6w1Qacs-7atbrUseiE7B=Zgj16=UysTnMjDmp+mJpYaHgjg@mail.gmail.com>
References: <CAHw6w1Qacs-7atbrUseiE7B=Zgj16=UysTnMjDmp+mJpYaHgjg@mail.gmail.com>
Message-ID: <caef3cc6-c774-a8e0-1401-1792a80039f4@oracle.com>

On 09/02/2021 14:03, Eric Bresie wrote:
> I?m still new to JPMS but in project discussion elsewhere, someone made the
> observation that JPMS modules could not be swapped out during run time.  Is
> this correct?
>
> If its not possible, are there any plans to allow for a module to be
> hot-swappable during runtime (I guess similar to OSGI)
In the Java Module System (the acronym "JPMS" is not used help), there 
is API support for loading coherent sets of modules at runtime. Look for 
"ModuleLayer" in the API docs.? You can load many layers with different 
versions of modules in different layers. Module layers are eligible to 
be GC'ed and? unloaded then they are no longer referenced. So if you do 
have a need for dynamic usages then think of it as loading and unloading 
of coherent graphs of modules rather than modules in isolation.

If you run into issue or have specific questions then it may be better 
to bring them to the jigsaw-dev mailing list rather than here.

-Alan.



From forax at univ-mlv.fr  Tue Feb  9 15:28:51 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 9 Feb 2021 16:28:51 +0100 (CET)
Subject: JPMS Runtime Swappable Modules
In-Reply-To: <caef3cc6-c774-a8e0-1401-1792a80039f4@oracle.com>
References: <CAHw6w1Qacs-7atbrUseiE7B=Zgj16=UysTnMjDmp+mJpYaHgjg@mail.gmail.com>
 <caef3cc6-c774-a8e0-1401-1792a80039f4@oracle.com>
Message-ID: <1226816634.1339375.1612884531312.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> ?: "Eric Bresie" <ebresie at gmail.com>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Mardi 9 F?vrier 2021 15:37:49
> Objet: Re: JPMS Runtime Swappable Modules

> On 09/02/2021 14:03, Eric Bresie wrote:
>> I?m still new to JPMS but in project discussion elsewhere, someone made the
>> observation that JPMS modules could not be swapped out during run time.  Is
>> this correct?
>>
>> If its not possible, are there any plans to allow for a module to be
>> hot-swappable during runtime (I guess similar to OSGI)
> In the Java Module System (the acronym "JPMS" is not used help), there
> is API support for loading coherent sets of modules at runtime. Look for
> "ModuleLayer" in the API docs.? You can load many layers with different
> versions of modules in different layers. Module layers are eligible to
> be GC'ed and? unloaded then they are no longer referenced. So if you do
> have a need for dynamic usages then think of it as loading and unloading
> of coherent graphs of modules rather than modules in isolation.
> 
> If you run into issue or have specific questions then it may be better
> to bring them to the jigsaw-dev mailing list rather than here.
> 
> -Alan.

There is an open source project called Layrry [1], that is able to load/unload JPMS modules.
This project also comes with several interesting blog posts on how things work.

regards,
R?mi

[1] https://github.com/moditect/layrry

From mark.reinhold at oracle.com  Fri Feb 12 18:25:26 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 12 Feb 2021 10:25:26 -0800 (PST)
Subject: JDK 16: Second Release Candidate
Message-ID: <20210212182526.5B8EF3D7AF9@eggemoggin.niobe.net>

Due to an oversight, a fix that was integrated at the tail end of RDP 2
was not included in the first Release Candidate [1].  Build 36 includes
that fix.

Binaries available here, as usual: https://jdk.java.net/16

- Mark


[1] https://bugs.openjdk.java.net/browse/JDK-8260709

From thomas.schatzl at oracle.com  Tue Feb 16 09:29:33 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 16 Feb 2021 10:29:33 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
Message-ID: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>

Hi all,

   I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 per.liden at oracle.com  Tue Feb 16 09:40:55 2021
From: per.liden at oracle.com (Per Liden)
Date: Tue, 16 Feb 2021 10:40:55 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <fa84fc25-e3da-c1db-e257-c91aefbe749c@oracle.com>

Vote: yes

/Per

On 2/16/21 10:29 AM, Thomas Schatzl wrote:
> Hi all,
> 
>  ? I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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  Tue Feb 16 09:43:11 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 16 Feb 2021 10:43:11 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <331a6fff-f78f-9e2d-4f56-28dce624f7c6@oracle.com>

Vote: yes

Thomas

On 16.02.21 10:29, Thomas Schatzl wrote:
> Hi all,
> 
>  ? I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 leo.korinth at oracle.com  Tue Feb 16 10:52:10 2021
From: leo.korinth at oracle.com (Leo Korinth)
Date: Tue, 16 Feb 2021 11:52:10 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <166b8be7-6a0e-d3cc-ef44-783dca25ff7f@oracle.com>

Vote: yes

/Leo

On 16/02/2021 10:29, Thomas Schatzl wrote:
> Hi all,
>
> ? I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 stefan.johansson at oracle.com  Tue Feb 16 14:51:48 2021
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 16 Feb 2021 15:51:48 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <acad97a6-e3fa-60bd-352f-f880a2c6c1d5@oracle.com>

Vote: yes

Cheers,
Stefan

On 2021-02-16 10:29, Thomas Schatzl wrote:
> Hi all,
> 
>  ? I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 sangheon.kim at oracle.com  Tue Feb 16 15:26:04 2021
From: sangheon.kim at oracle.com (Sangheon Kim)
Date: Tue, 16 Feb 2021 07:26:04 -0800
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <789994e1-7549-c677-6c8f-91e05af7cf3e@oracle.com>

Vote: yes

Thanks,
Sangheon


On 2/16/21 1:29 AM, Thomas Schatzl wrote:
> Hi all,
>
> ? I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 ivan.walulya at oracle.com  Tue Feb 16 15:32:47 2021
From: ivan.walulya at oracle.com (Ivan Walulya)
Date: Tue, 16 Feb 2021 16:32:47 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <1DFFE300-05A6-49F2-BBB5-9238A8EC7215@oracle.com>

Vote: yes

//Ivan

> On 16 Feb 2021, at 10:29, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 richard.reingruber at sap.com  Tue Feb 16 17:25:47 2021
From: richard.reingruber at sap.com (Reingruber, Richard)
Date: Tue, 16 Feb 2021 17:25:47 +0000
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <AM0PR0202MB3331002CFE7441815EA48CA19B879@AM0PR0202MB3331.eurprd02.prod.outlook.com>

Vote: yes

Richard.

-----Original Message-----
From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Thomas Schatzl
Sent: Dienstag, 16. Februar 2021 10:30
To: jdk-dev at openjdk.java.net
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang

Hi all,

   I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 eric.caspole at oracle.com  Tue Feb 16 17:42:13 2021
From: eric.caspole at oracle.com (eric.caspole at oracle.com)
Date: Tue, 16 Feb 2021 12:42:13 -0500
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <72c5b411-07c6-17a6-e1b1-368753320f3c@oracle.com>

Vote: yes


Eric


On 2/16/21 4:29 AM, Thomas Schatzl wrote:
> Hi all,
>
> ? I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 Alan.Bateman at oracle.com  Tue Feb 16 17:47:51 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Feb 2021 17:47:51 +0000
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <05b1a41b-16d3-5b51-80b9-0a15e7775a3d@oracle.com>

Vote: yes

From volker.simonis at gmail.com  Tue Feb 16 18:57:50 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 16 Feb 2021 19:57:50 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <CA+3eh135gFDabZgMeDAjj1Lp8kc3D0_Wa9tYxdZtr0_qJvQNAw@mail.gmail.com>

Vote: yes

Best regards,
Volker

On Tue, Feb 16, 2021 at 10:30 AM Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
>
> Hi all,
>
>    I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 mikael.vidstedt at oracle.com  Tue Feb 16 20:53:20 2021
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 16 Feb 2021 12:53:20 -0800
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <B1B3B264-CE90-4DD7-BF29-CD4BD4E40E16@oracle.com>


Vote: yes

Note: This is under the assumption that the CFV is for the JDK[1] project.

Cheers,
Mikael

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

> On Feb 16, 2021, at 1:29 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 kim.barrett at oracle.com  Wed Feb 17 02:55:10 2021
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 17 Feb 2021 02:55:10 +0000
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <927819ED-7E10-4550-A3CA-93EA3A499069@oracle.com>

vote: yes

> On Feb 16, 2021, at 4:29 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 jesper.wilhelmsson at oracle.com  Wed Feb 17 04:19:43 2021
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 17 Feb 2021 05:19:43 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <E6500081-B8FC-4E8A-8398-454F99661588@oracle.com>

Vote: Yes

I assume this vote refers to the JDK Project.
/Jesper

> On 16 Feb 2021, at 10:29, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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  Wed Feb 17 08:18:49 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 17 Feb 2021 09:18:49 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <E6500081-B8FC-4E8A-8398-454F99661588@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
 <E6500081-B8FC-4E8A-8398-454F99661588@oracle.com>
Message-ID: <7b04083c-7006-b471-ada6-a12e5a8a7049@oracle.com>

Hi,

On 17.02.21 05:19, Jesper Wilhelmsson wrote:
> Vote: Yes
> 
> I assume this vote refers to the JDK Project.

   it is :( Should I resend the vote request to be formally correct?

Thanks,
   Thomas

From jesper.wilhelmsson at oracle.com  Wed Feb 17 08:27:58 2021
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 17 Feb 2021 09:27:58 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <7b04083c-7006-b471-ada6-a12e5a8a7049@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
 <E6500081-B8FC-4E8A-8398-454F99661588@oracle.com>
 <7b04083c-7006-b471-ada6-a12e5a8a7049@oracle.com>
Message-ID: <5785B73C-6EAE-4C0D-A5E3-CCA0AE27099D@oracle.com>

I believe most people will assume you mean the JDK project so I think it's ok. You could send a reply to your CFV just to clarify this (and remove "Open" from the subject line).

/Jesper

> On 17 Feb 2021, at 09:18, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
> On 17.02.21 05:19, Jesper Wilhelmsson wrote:
>> Vote: Yes
>> I assume this vote refers to the JDK Project.
> 
>  it is :( Should I resend the vote request to be formally correct?
> 
> Thanks,
>  Thomas


From thomas.schatzl at oracle.com  Wed Feb 17 08:36:10 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 17 Feb 2021 09:36:10 +0100
Subject: CFV: New JDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <ea850e14-0006-52fb-1d55-9b407937c20e@oracle.com>

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.

Here's the intended, fixed nomination request:

> Hi all,
> 
>  ? I hereby nominate Albert Mingkun Wang 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

Sorry for the issue.

Thanks,
   Thomas

From erik.helin at oracle.com  Wed Feb 17 12:53:03 2021
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 17 Feb 2021 13:53:03 +0100
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <f786bade-c899-a5f7-c494-2c8a8869ed65@oracle.com>

Vote: yes

Thanks,
Erik

On 2/16/21 10:29 AM, Thomas Schatzl wrote:
> Hi all,
> 
>  ? I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 daniel.fuchs at oracle.com  Wed Feb 17 13:58:29 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 17 Feb 2021 13:58:29 +0000
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <6dec1059-981f-3a98-cca8-449264fd1c50@oracle.com>

Vote: yes

best regards,

-- daniel
On 16/02/2021 09:29, Thomas Schatzl wrote:
> 
>  ? I hereby nominate Albert Mingkun Wang to OpenJDK Committer.


From harold.seigel at oracle.com  Wed Feb 17 14:19:02 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Wed, 17 Feb 2021 09:19:02 -0500
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <2574f0b1-2d72-0129-e66c-0ee11d16b94d@oracle.com>

Vote: yes

Harold

On 2/16/2021 4:29 AM, Thomas Schatzl wrote:
> Hi all,
>
> ? I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 lois.foltan at oracle.com  Wed Feb 17 15:36:59 2021
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 17 Feb 2021 10:36:59 -0500
Subject: CFV: New JDK Committer: Albert Mingkun Wang
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: <4add47f6-8be8-b844-792a-049e7c292444@oracle.com>

Vote: yes

Lois

On 2/17/2021 3:36 AM, 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.
>
> Here's the intended, fixed nomination request:
>
>> Hi all,
>>
>> ?? I hereby nominate Albert Mingkun Wang 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
>
> Sorry for the issue.
>
> Thanks,
> ? Thomas


From stefan.karlsson at oracle.com  Wed Feb 17 20:17:13 2021
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 17 Feb 2021 21:17:13 +0100
Subject: CFV: New JDK Committer: Albert Mingkun Wang
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: <dbf05e9f-595a-f47b-43c1-331aa0169928@oracle.com>

Vote: yes

StefanK

On 2021-02-17 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.
>
> Here's the intended, fixed nomination request:
>
>> Hi all,
>>
>> ?? I hereby nominate Albert Mingkun Wang 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
>
> Sorry for the issue.
>
> Thanks,
> ? Thomas


From erik.osterlund at oracle.com  Wed Feb 17 22:06:24 2021
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Wed, 17 Feb 2021 22:06:24 +0000
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <AB4588A7-A467-4201-835A-6421DA81B29D@oracle.com>

Vote: yes

/Erik

> On 16 Feb 2021, at 10:30, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> ?Hi all,
> 
>  I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 christoph.langer at sap.com  Wed Feb 17 23:00:57 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 17 Feb 2021 23:00:57 +0000
Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
In-Reply-To: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
References: <1d6baa62-fff5-a314-e2ee-b71c267fff7c@oracle.com>
Message-ID: <AM4PR02MB3138F8AAE044A4B5486E43C88A869@AM4PR02MB3138.eurprd02.prod.outlook.com>

Vote: yes

/Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Thomas
> Schatzl
> Sent: Dienstag, 16. Februar 2021 10:30
> To: jdk-dev at openjdk.java.net
> Subject: CFV: New OpenJDK Committer: Albert Mingkun Wang
> 
> Hi all,
> 
>    I hereby nominate Albert Mingkun Wang to OpenJDK 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 OpenJDK 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 serguei.spitsyn at oracle.com  Thu Feb 18 00:48:04 2021
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Thu, 18 Feb 2021 00:48:04 +0000
Subject: New OpenJDK Committer: Albert Mingkun Wang
Message-ID: <A28B994C-A806-472D-9C80-7D66781A0C2D@oracle.com>

Vote: yes 


From jesper.wilhelmsson at oracle.com  Thu Feb 18 17:33:32 2021
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 18 Feb 2021 18:33:32 +0100
Subject: CFV: New JDK Committer: Albert Mingkun Wang
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: <F221712A-701A-4FD1-A1BC-815D00A65FB0@oracle.com>

Vote: Yes
/Jesper

> On 17 Feb 2021, at 09:36, Thomas Schatzl <thomas.schatzl at oracle.com> 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.
> 
> Here's the intended, fixed nomination request:
> 
>> Hi all,
>>   I hereby nominate Albert Mingkun Wang 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
> 
> Sorry for the issue.
> 
> Thanks,
>  Thomas


From orionllmain at gmail.com  Wed Feb 24 05:30:08 2021
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Wed, 24 Feb 2021 12:30:08 +0700
Subject: No runtime warnings for synchronization on value-based classes
Message-ID: <CAF2POUeiJgeMZmzHuUb1fnUrBrrWzqx71NGjccbVDrDQqQbJSg@mail.gmail.com>

Hi!

// Main.java
public class Main {
    public static void main(String[] args) {
        f(0D);
    }

    private static void f(Double value) {
        synchronized (value) {
            System.out.println(value);
        }
    }
}

> java --version
openjdk 16 2021-03-16
OpenJDK Runtime Environment (build 16+36-2231)
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)

> javac Main.java
Main.java:7: warning: [synchronization] attempt to synchronize on an
instance of a value-based class
        synchronized (value) {
        ^
1 warning

> java Main
0.0

According to JEP 390 [1], there should be a runtime warning. But there is
none. Or did I miss something?

[1] https://openjdk.java.net/jeps/390

From david.holmes at oracle.com  Wed Feb 24 05:55:38 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 24 Feb 2021 15:55:38 +1000
Subject: No runtime warnings for synchronization on value-based classes
In-Reply-To: <CAF2POUeiJgeMZmzHuUb1fnUrBrrWzqx71NGjccbVDrDQqQbJSg@mail.gmail.com>
References: <CAF2POUeiJgeMZmzHuUb1fnUrBrrWzqx71NGjccbVDrDQqQbJSg@mail.gmail.com>
Message-ID: <ddb3aca5-2639-6c1b-8f3d-b56cfcc83d71@oracle.com>

Hi,

On 24/02/2021 3:30 pm, Zheka Kozlov wrote:
> Hi!
> 
> // Main.java
> public class Main {
>      public static void main(String[] args) {
>          f(0D);
>      }
> 
>      private static void f(Double value) {
>          synchronized (value) {
>              System.out.println(value);
>          }
>      }
> }
> 
>> java --version
> openjdk 16 2021-03-16
> OpenJDK Runtime Environment (build 16+36-2231)
> OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)
> 
>> javac Main.java
> Main.java:7: warning: [synchronization] attempt to synchronize on an
> instance of a value-based class
>          synchronized (value) {
>          ^
> 1 warning
> 
>> java Main
> 0.0
> 
> According to JEP 390 [1], there should be a runtime warning. But there is
> none. Or did I miss something?

You need to enable it:

HotSpot implements runtime detection of monitorenter occurring on a 
value-based class instance. The command-line option 
-XX:DiagnoseSyncOnValueBasedClasses=1 will treat the operation as a 
fatal error. The command-line option 
-XX:DiagnoseSyncOnValueBasedClasses=2 will turn on logging, both via the 
console and via JDK Flight Recorder events.

---

Cheers,
David

> [1] https://openjdk.java.net/jeps/390
> 

From christoph.langer at sap.com  Wed Feb 24 10:40:36 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 24 Feb 2021 10:40:36 +0000
Subject: CFV: New JDK Committer: Arno Zeller
Message-ID: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hello,



I hereby nominate Arno Zeller (azeller) to JDK Committer.



Arno is a long time member of the SapMachine team at SAP. Most of his focus is dedicated to quality engineering for the various JDK releases that the SAP team is maintaining.

Over time he has cumulated 11 commits in OpenJDK [0] and recently co-authored another one [1]. Above that, he's constantly involved in reporting OpenJDK bugs, contributing to their root cause analysis and reviewing the fixes.



Votes are due by 12:00 UTC, 10th March 2021.



Only current JDK Committers [2] 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 [3].



Best regards

Christoph



[0] https://github.com/openjdk/jdk/search?q=author-name%3A%22zeller%22&type=commits

[1] https://github.com/openjdk/jdk/search?q=co-authored-by%3A%22zeller%22&type=commits

[2] https://openjdk.java.net/census
[3] https://openjdk.java.net/projects/#committer-vote


From goetz.lindenmaier at sap.com  Wed Feb 24 10:43:26 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 24 Feb 2021 10:43:26 +0000
Subject: CFV: New JDK Committer: Arno Zeller
In-Reply-To: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB3443B5EDF28BC73B346264DDEC9F9@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Vote: yes

Best,
  Goetz

> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Langer,
> Christoph
> Sent: Wednesday, February 24, 2021 11:41 AM
> To: jdk-dev at openjdk.java.net
> Cc: Zeller, Arno <arno.zeller at sap.com>
> Subject: [CAUTION] CFV: New JDK Committer: Arno Zeller
> 
> Hello,
> 
> 
> 
> I hereby nominate Arno Zeller (azeller) to JDK Committer.
> 
> 
> 
> Arno is a long time member of the SapMachine team at SAP. Most of his
> focus is dedicated to quality engineering for the various JDK releases that the
> SAP team is maintaining.
> 
> Over time he has cumulated 11 commits in OpenJDK [0] and recently co-
> authored another one [1]. Above that, he's constantly involved in reporting
> OpenJDK bugs, contributing to their root cause analysis and reviewing the
> fixes.
> 
> 
> 
> Votes are due by 12:00 UTC, 10th March 2021.
> 
> 
> 
> Only current JDK Committers [2] 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 [3].
> 
> 
> 
> Best regards
> 
> Christoph
> 
> 
> 
> [0] https://github.com/openjdk/jdk/search?q=author-
> name%3A%22zeller%22&type=commits
> 
> [1] https://github.com/openjdk/jdk/search?q=co-authored-
> by%3A%22zeller%22&type=commits
> 
> [2] https://openjdk.java.net/census
> [3] https://openjdk.java.net/projects/#committer-vote


From thomas.stuefe at gmail.com  Wed Feb 24 10:54:11 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 24 Feb 2021 11:54:11 +0100
Subject: CFV: New JDK Committer: Arno Zeller
In-Reply-To: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUzEtJQxWOp_T-YNjUbJyWkTA5CmF7ocaVFWGmr7LYPZ6Q@mail.gmail.com>

Vote: yes

About time :)

On Wed, Feb 24, 2021 at 11:41 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hello,
>
>
>
> I hereby nominate Arno Zeller (azeller) to JDK Committer.
>
>
>
> Arno is a long time member of the SapMachine team at SAP. Most of his
> focus is dedicated to quality engineering for the various JDK releases that
> the SAP team is maintaining.
>
> Over time he has cumulated 11 commits in OpenJDK [0] and recently
> co-authored another one [1]. Above that, he's constantly involved in
> reporting OpenJDK bugs, contributing to their root cause analysis and
> reviewing the fixes.
>
>
>
> Votes are due by 12:00 UTC, 10th March 2021.
>
>
>
> Only current JDK Committers [2] 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 [3].
>
>
>
> Best regards
>
> Christoph
>
>
>
> [0]
> https://github.com/openjdk/jdk/search?q=author-name%3A%22zeller%22&type=commits
>
> [1]
> https://github.com/openjdk/jdk/search?q=co-authored-by%3A%22zeller%22&type=commits
>
> [2] https://openjdk.java.net/census
> [3] https://openjdk.java.net/projects/#committer-vote
>
>

From matthias.baesken at sap.com  Wed Feb 24 11:00:08 2021
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 24 Feb 2021 11:00:08 +0000
Subject: CFV: New JDK Committer: Arno Zeller
In-Reply-To: <AM0PR0202MB3443B5EDF28BC73B346264DDEC9F9@AM0PR0202MB3443.eurprd02.prod.outlook.com>
References: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM0PR0202MB3443B5EDF28BC73B346264DDEC9F9@AM0PR0202MB3443.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB5412B5ED4B582C4EC08AF0C8939F9@AM0PR02MB5412.eurprd02.prod.outlook.com>


Vote: yes

Best regards, Matthias




> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Langer,
> Christoph
> Sent: Wednesday, February 24, 2021 11:41 AM
> To: jdk-dev at openjdk.java.net
> Cc: Zeller, Arno <arno.zeller at sap.com>
> Subject: [CAUTION] CFV: New JDK Committer: Arno Zeller
> 
> Hello,
> 
> 
> 
> I hereby nominate Arno Zeller (azeller) to JDK Committer.
> 
> 
> 
> Arno is a long time member of the SapMachine team at SAP. Most of his
> focus is dedicated to quality engineering for the various JDK releases that the
> SAP team is maintaining.
> 
> Over time he has cumulated 11 commits in OpenJDK [0] and recently co-
> authored another one [1]. Above that, he's constantly involved in reporting
> OpenJDK bugs, contributing to their root cause analysis and reviewing the
> fixes.
> 
> 
> 
> Votes are due by 12:00 UTC, 10th March 2021.
> 
> 
> 
> Only current JDK Committers [2] 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 [3].
> 
> 
> 
> Best regards
> 
> Christoph
> 
> 
> 
> [0] https://github.com/openjdk/jdk/search?q=author-
> name%3A%22zeller%22&type=commits
> 
> [1] https://github.com/openjdk/jdk/search?q=co-authored-
> by%3A%22zeller%22&type=commits
> 
> [2] https://openjdk.java.net/census
> [3] https://openjdk.java.net/projects/#committer-vote


From sgehwolf at redhat.com  Wed Feb 24 11:29:08 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 24 Feb 2021 12:29:08 +0100
Subject: CFV: New JDK Committer: Arno Zeller
In-Reply-To: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <f38d08faa0334089e2c32ae2a07cf8cdafa197d0.camel@redhat.com>

Vote: yes.

On Wed, 2021-02-24 at 10:40 +0000, Langer, Christoph wrote:
> I hereby nominate Arno Zeller (azeller) to JDK Committer.


From vladimir.kozlov at oracle.com  Wed Feb 24 17:43:23 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Feb 2021 09:43:23 -0800
Subject: CFV: New JDK Committer: Arno Zeller
In-Reply-To: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <8f7c13a7-2195-5197-a06b-239a2b9dc44a@oracle.com>

Vote: veto

I think it is too early for Arno.

I would like to remind that Committer candidate have to contribute *significant* changes:

"As a rough guide, a Contributor should make at least eight significant contributions to that Project before being 
nominated."

Most of changes on provided list are not significant from my POV. Also based dates, he was not active for more then one 
year except latest co-authored change.

Regards,
Vladimir K

On 2/24/21 2:40 AM, Langer, Christoph wrote:
> Hello,
> 
> 
> 
> I hereby nominate Arno Zeller (azeller) to JDK Committer.
> 
> 
> 
> Arno is a long time member of the SapMachine team at SAP. Most of his focus is dedicated to quality engineering for the various JDK releases that the SAP team is maintaining.
> 
> Over time he has cumulated 11 commits in OpenJDK [0] and recently co-authored another one [1]. Above that, he's constantly involved in reporting OpenJDK bugs, contributing to their root cause analysis and reviewing the fixes.
> 
> 
> 
> Votes are due by 12:00 UTC, 10th March 2021.
> 
> 
> 
> Only current JDK Committers [2] 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 [3].
> 
> 
> 
> Best regards
> 
> Christoph
> 
> 
> 
> [0] https://github.com/openjdk/jdk/search?q=author-name%3A%22zeller%22&type=commits
> 
> [1] https://github.com/openjdk/jdk/search?q=co-authored-by%3A%22zeller%22&type=commits
> 
> [2] https://openjdk.java.net/census
> [3] https://openjdk.java.net/projects/#committer-vote
> 

From philip.race at oracle.com  Wed Feb 24 19:08:23 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 24 Feb 2021 11:08:23 -0800
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
Message-ID: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>

I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
Project Reviewer.

Alexey is currently a JDK committer [1], and has been a long time member 
of the Java client team at Oracle
previously working on installer technologies and recently has made 
substantial contributions to the
development of the jpackage [2] tool from its inception and has 
continued to work on it and
has made 43 individual contributions [3]
In addition he has regularly reviewed changes even without the formal 
role of reviewer.

Only current JDK Project Reviewers [4] 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 [5].

Votes are due by 20:00 GMT on 10th March 2021.

-Phil.

[1] https://openjdk.java.net/census#asemenyuk
[2] https://openjdk.java.net/jeps/392
[3] 
https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
[4] https://openjdk.java.net/census <https://openjdk.java.net/census>
[5] https://openjdk.java.net/projects/#reviewer-vote

From philip.race at oracle.com  Wed Feb 24 19:08:56 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 24 Feb 2021 11:08:56 -0800
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <a71832b0-6bc9-5587-252a-a7ed4eef1ea4@oracle.com>

Vote: yes.

-phil.


From Alan.Bateman at oracle.com  Wed Feb 24 19:14:33 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Feb 2021 19:14:33 +0000
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <0cd84905-b8fc-2bf0-72b4-5e9ceba4ea49@oracle.com>

Vote: yes

From erik.joelsson at oracle.com  Wed Feb 24 19:24:13 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 24 Feb 2021 11:24:13 -0800
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <e0904b44-91ae-8c30-eede-d314e565f714@oracle.com>

Vote: yes

/Erik

On 2021-02-24 11:08, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer.
>
> Alexey is currently a JDK committer [1], and has been a long time 
> member of the Java client team at Oracle
> previously working on installer technologies and recently has made 
> substantial contributions to the
> development of the jpackage [2] tool from its inception and has 
> continued to work on it and
> has made 43 individual contributions [3]
> In addition he has regularly reviewed changes even without the formal 
> role of reviewer.
>
> Only current JDK Project Reviewers [4] 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 [5].
>
> Votes are due by 20:00 GMT on 10th March 2021.
>
> -Phil.
>
> [1] https://openjdk.java.net/census#asemenyuk
> [2] https://openjdk.java.net/jeps/392
> [3] 
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
> [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [5] https://openjdk.java.net/projects/#reviewer-vote

From alexey.ivanov at oracle.com  Wed Feb 24 19:26:48 2021
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 24 Feb 2021 19:26:48 +0000
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <828a259c-ffa7-4805-d51b-a36894864263@oracle.com>

Vote: yes

-- 
Regards,
Alexey

On 24/02/2021 19:08, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer. 


From andy.herrick at oracle.com  Wed Feb 24 19:27:39 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 24 Feb 2021 14:27:39 -0500
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <bff42f48-acc0-337b-d2a4-19773cd3561b@oracle.com>

vote: yes

On 2/24/2021 2:08 PM, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer.
>
> Alexey is currently a JDK committer [1], and has been a long time 
> member of the Java client team at Oracle
> previously working on installer technologies and recently has made 
> substantial contributions to the
> development of the jpackage [2] tool from its inception and has 
> continued to work on it and
> has made 43 individual contributions [3]
> In addition he has regularly reviewed changes even without the formal 
> role of reviewer.
>
> Only current JDK Project Reviewers [4] 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 [5].
>
> Votes are due by 20:00 GMT on 10th March 2021.
>
> -Phil.
>
> [1] https://openjdk.java.net/census#asemenyuk
> [2] https://openjdk.java.net/jeps/392
> [3] 
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
> [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [5] https://openjdk.java.net/projects/#reviewer-vote

From harold.seigel at oracle.com  Wed Feb 24 19:33:33 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Wed, 24 Feb 2021 14:33:33 -0500
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <d21bc0c4-6921-f731-7724-9ea8723066eb@oracle.com>

Vote: yes

Thanks, Haorld

On 2/24/2021 2:08 PM, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer.
>
> Alexey is currently a JDK committer [1], and has been a long time 
> member of the Java client team at Oracle
> previously working on installer technologies and recently has made 
> substantial contributions to the
> development of the jpackage [2] tool from its inception and has 
> continued to work on it and
> has made 43 individual contributions [3]
> In addition he has regularly reviewed changes even without the formal 
> role of reviewer.
>
> Only current JDK Project Reviewers [4] 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 [5].
>
> Votes are due by 20:00 GMT on 10th March 2021.
>
> -Phil.
>
> [1] https://openjdk.java.net/census#asemenyuk
> [2] https://openjdk.java.net/jeps/392
> [3] 
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
> [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [5] https://openjdk.java.net/projects/#reviewer-vote

From daniel.fuchs at oracle.com  Wed Feb 24 19:35:14 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 24 Feb 2021 19:35:14 +0000
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <b23758d6-cbc6-ac7a-c308-d8e951706dbc@oracle.com>

Vote: yes

best regards,

-- daniel

On 24/02/2021 19:08, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer.

From dmitry.markov at oracle.com  Wed Feb 24 19:37:38 2021
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Wed, 24 Feb 2021 19:37:38 +0000
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <BY5PR10MB380906ED3F99873F8D43C6ED9E9F9@BY5PR10MB3809.namprd10.prod.outlook.com>

Vote: yes

Regards,
Dmitry

From: jdk-dev <jdk-dev-retn at openjdk.java.net> on behalf of Philip Race <philip.race at oracle.com>
Date: Wednesday, 24 February 2021 at 19:08
To: jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
Cc: Alexey Semenyuk <alexey.semenyuk at oracle.com>
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK
Project Reviewer.

Alexey is currently a JDK committer [1], and has been a long time member
of the Java client team at Oracle
previously working on installer technologies and recently has made
substantial contributions to the
development of the jpackage [2] tool from its inception and has
continued to work on it and
has made 43 individual contributions [3]
In addition he has regularly reviewed changes even without the formal
role of reviewer.

Only current JDK Project Reviewers [4] 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 [5].

Votes are due by 20:00 GMT on 10th March 2021.

-Phil.

[1] https://openjdk.java.net/census#asemenyuk
[2] https://openjdk.java.net/jeps/392
[3]
https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
[4] https://openjdk.java.net/census <https://openjdk.java.net/census>
[5] https://openjdk.java.net/projects/#reviewer-vote

From alexander.zvegintsev at oracle.com  Wed Feb 24 19:39:07 2021
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 24 Feb 2021 20:39:07 +0100
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <cf13a224-e7d5-647d-a7e8-61fb46a0db2c@oracle.com>

Vote: yes

--
Thanks,
Alexander.

On 2/24/21 8:08 PM, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer.
>
> Alexey is currently a JDK committer [1], and has been a long time 
> member of the Java client team at Oracle
> previously working on installer technologies and recently has made 
> substantial contributions to the
> development of the jpackage [2] tool from its inception and has 
> continued to work on it and
> has made 43 individual contributions [3]
> In addition he has regularly reviewed changes even without the formal 
> role of reviewer.
>
> Only current JDK Project Reviewers [4] 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 [5].
>
> Votes are due by 20:00 GMT on 10th March 2021.
>
> -Phil.
>
> [1] https://openjdk.java.net/census#asemenyuk
> [2] https://openjdk.java.net/jeps/392
> [3] 
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
> [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [5] https://openjdk.java.net/projects/#reviewer-vote

From roger.riggs at oracle.com  Wed Feb 24 20:17:27 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 24 Feb 2021 15:17:27 -0500
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <1f252c9e-bb1a-25e3-cc78-05fd9c63b219@oracle.com>

Vote: Yes

On 2/24/21 2:08 PM, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer. 


From sean.coffey at oracle.com  Wed Feb 24 20:31:11 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 24 Feb 2021 20:31:11 +0000
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <fde26912-5084-4677-7282-2ab166969ff8@oracle.com>

Vote: yes

regards,
Sean.

On 24/02/2021 19:08, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer.
>
> Alexey is currently a JDK committer [1], and has been a long time 
> member of the Java client team at Oracle
> previously working on installer technologies and recently has made 
> substantial contributions to the
> development of the jpackage [2] tool from its inception and has 
> continued to work on it and
> has made 43 individual contributions [3]
> In addition he has regularly reviewed changes even without the formal 
> role of reviewer.
>
> Only current JDK Project Reviewers [4] 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 [5].
>
> Votes are due by 20:00 GMT on 10th March 2021.
>
> -Phil.
>
> [1] https://openjdk.java.net/census#asemenyuk
> [2] https://openjdk.java.net/jeps/392
> [3] 
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
> [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [5] https://openjdk.java.net/projects/#reviewer-vote

From alexander.zuev at oracle.com  Wed Feb 24 20:36:09 2021
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Wed, 24 Feb 2021 12:36:09 -0800
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <880a2df3-aa07-5212-f386-d0ff9869a48e@oracle.com>

Vote: yes

On 2/24/21 11:08 AM, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer.
>
> Alexey is currently a JDK committer [1], and has been a long time 
> member of the Java client team at Oracle
> previously working on installer technologies and recently has made 
> substantial contributions to the
> development of the jpackage [2] tool from its inception and has 
> continued to work on it and
> has made 43 individual contributions [3]
> In addition he has regularly reviewed changes even without the formal 
> role of reviewer.
>
> Only current JDK Project Reviewers [4] 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 [5].
>
> Votes are due by 20:00 GMT on 10th March 2021.
>
> -Phil.
>
> [1] https://openjdk.java.net/census#asemenyuk
> [2] https://openjdk.java.net/jeps/392
> [3] 
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
> [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [5] https://openjdk.java.net/projects/#reviewer-vote


From brian.burkhalter at oracle.com  Wed Feb 24 20:41:46 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 24 Feb 2021 12:41:46 -0800
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <92351C45-C977-41ED-90BE-F4F93FF09612@oracle.com>

Vote: yes

> On Feb 24, 2021, at 11:08 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK Project Reviewer.
> 
> Alexey is currently a JDK committer [1], and has been a long time member of the Java client team at Oracle
> previously working on installer technologies and recently has made substantial contributions to the
> development of the jpackage [2] tool from its inception and has continued to work on it and
> has made 43 individual contributions [3]
> In addition he has regularly reviewed changes even without the formal role of reviewer.
> 
> Only current JDK Project Reviewers [4] 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 [5].
> 
> Votes are due by 20:00 GMT on 10th March 2021.
> 
> -Phil.
> 
> [1] https://openjdk.java.net/census#asemenyuk
> [2] https://openjdk.java.net/jeps/392
> [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
> [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [5] https://openjdk.java.net/projects/#reviewer-vote


From iris.clark at oracle.com  Wed Feb 24 22:04:55 2021
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 24 Feb 2021 22:04:55 +0000
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <MN2PR10MB43663A3E693F5E9B57E73278FB9F9@MN2PR10MB4366.namprd10.prod.outlook.com>

Vote: yes

Iris

________________________________
From: jdk-dev <jdk-dev-retn at openjdk.java.net> on behalf of Philip Race <philip.race at oracle.com>
Sent: Wednesday, February 24, 2021 11:08 AM
To: jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
Cc: Alexey Semenyuk <alexey.semenyuk at oracle.com>
Subject: CFV: New JDK Reviewer: Alexey Semenyuk

I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK
Project Reviewer.

Alexey is currently a JDK committer [1], and has been a long time member
of the Java client team at Oracle
previously working on installer technologies and recently has made
substantial contributions to the
development of the jpackage [2] tool from its inception and has
continued to work on it and
has made 43 individual contributions [3]
In addition he has regularly reviewed changes even without the formal
role of reviewer.

Only current JDK Project Reviewers [4] 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 [5].

Votes are due by 20:00 GMT on 10th March 2021.

-Phil.

[1] https://openjdk.java.net/census#asemenyuk
[2] https://openjdk.java.net/jeps/392
[3]
https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
[4] https://openjdk.java.net/census <https://openjdk.java.net/census>
[5] https://openjdk.java.net/projects/#reviewer-vote

From david.holmes at oracle.com  Wed Feb 24 22:22:21 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 25 Feb 2021 08:22:21 +1000
Subject: CFV: New JDK Committer: Arno Zeller
In-Reply-To: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <2c7edfa1-bb0a-b3a1-8fe9-286d5b67c45f@oracle.com>

Vote: veto

Sorry but I do not see these as significant enough contributions to meet 
the criteria - most are quite trivial.

David

On 24/02/2021 8:40 pm, Langer, Christoph wrote:
> Hello,
> 
> 
> 
> I hereby nominate Arno Zeller (azeller) to JDK Committer.
> 
> 
> 
> Arno is a long time member of the SapMachine team at SAP. Most of his focus is dedicated to quality engineering for the various JDK releases that the SAP team is maintaining.
> 
> Over time he has cumulated 11 commits in OpenJDK [0] and recently co-authored another one [1]. Above that, he's constantly involved in reporting OpenJDK bugs, contributing to their root cause analysis and reviewing the fixes.
> 
> 
> 
> Votes are due by 12:00 UTC, 10th March 2021.
> 
> 
> 
> Only current JDK Committers [2] 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 [3].
> 
> 
> 
> Best regards
> 
> Christoph
> 
> 
> 
> [0] https://github.com/openjdk/jdk/search?q=author-name%3A%22zeller%22&type=commits
> 
> [1] https://github.com/openjdk/jdk/search?q=co-authored-by%3A%22zeller%22&type=commits
> 
> [2] https://openjdk.java.net/census
> [3] https://openjdk.java.net/projects/#committer-vote
> 

From christoph.langer at sap.com  Wed Feb 24 23:14:15 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 24 Feb 2021 23:14:15 +0000
Subject: CFV: New JDK Committer: Arno Zeller
In-Reply-To: <8f7c13a7-2195-5197-a06b-239a2b9dc44a@oracle.com>
References: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <8f7c13a7-2195-5197-a06b-239a2b9dc44a@oracle.com>
Message-ID: <AM4PR02MB31386AF0C1998888F366A4F28A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Vladimir, David,

I see that you've vetoed Arno's Committer nomination. This is a fair thing to do.

If it wasn't about Arno and his personal record within our team I would probably just take back the CFV and postpone it to a later point in time when more commits have accumulated. But in this case, I'd like to add some pleading before I do that.

First of all, the OpenJDK guidelines say [0]:
"As a rough guide, a Contributor should make at least eight significant contributions to that Project before being nominated." This, of course, leaves some room for interpretation about what "significant" means. In Arno's case we can see 11 commits plus the one he co-authored lately. It is arguable that a lot of the commits look simple, however I guess it is not always easy to judge whether getting to a certain change was as easy as the commit looks tiny. E.g. in a complex testing environment, chasing down problems can be rather hard.

Furthermore, as I said in my nomination statement, Arno is a long time member of SAP's JVM team (actually quite some time longer than my own stay with the team). He is our main Quality Engineer and he is very involved in the OpenJDK project, triaging our tests every day. Owing to his role this doesn't show up so much in commits compared to other developers in the team. But there have been various occasions where he has found bugs and initiated fixes that eventually other people from our team (including myself) have finally brought to review and commit in the OpenJDK. We sometimes did not credit Arno, e.g. with co-authorship, out of convenience which was our fault.

Well, after all, I personally strongly believe that Arno has deserved to become an OpenJDK Committer at this time. But if you stick to your veto after spending a second thought, I'll of course withdraw the nomination.

Best regards
Christoph

[0] https://openjdk.java.net/projects/#project-committer


> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Vladimir
> Kozlov
> Sent: Mittwoch, 24. Februar 2021 18:43
> To: jdk-dev at openjdk.java.net
> Subject: Re: CFV: New JDK Committer: Arno Zeller
> 
> Vote: veto
> 
> I think it is too early for Arno.
> 
> I would like to remind that Committer candidate have to contribute
> *significant* changes:
> 
> "As a rough guide, a Contributor should make at least eight significant
> contributions to that Project before being
> nominated."
> 
> Most of changes on provided list are not significant from my POV. Also based
> dates, he was not active for more then one
> year except latest co-authored change.
> 
> Regards,
> Vladimir K
> 
> On 2/24/21 2:40 AM, Langer, Christoph wrote:
> > Hello,
> >
> >
> >
> > I hereby nominate Arno Zeller (azeller) to JDK Committer.
> >
> >
> >
> > Arno is a long time member of the SapMachine team at SAP. Most of his
> focus is dedicated to quality engineering for the various JDK releases that the
> SAP team is maintaining.
> >
> > Over time he has cumulated 11 commits in OpenJDK [0] and recently co-
> authored another one [1]. Above that, he's constantly involved in reporting
> OpenJDK bugs, contributing to their root cause analysis and reviewing the
> fixes.
> >
> >
> >
> > Votes are due by 12:00 UTC, 10th March 2021.
> >
> >
> >
> > Only current JDK Committers [2] 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 [3].
> >
> >
> >
> > Best regards
> >
> > Christoph
> >
> >
> >
> > [0] https://github.com/openjdk/jdk/search?q=author-
> name%3A%22zeller%22&type=commits
> >
> > [1] https://github.com/openjdk/jdk/search?q=co-authored-
> by%3A%22zeller%22&type=commits
> >
> > [2] https://openjdk.java.net/census
> > [3] https://openjdk.java.net/projects/#committer-vote
> >

From vladimir.kozlov at oracle.com  Thu Feb 25 01:46:40 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Feb 2021 17:46:40 -0800
Subject: [External] : RE: CFV: New JDK Committer: Arno Zeller
In-Reply-To: <AM4PR02MB31386AF0C1998888F366A4F28A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <8f7c13a7-2195-5197-a06b-239a2b9dc44a@oracle.com>
 <AM4PR02MB31386AF0C1998888F366A4F28A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <347ae18e-35b0-05b1-e704-741e6a5a2ec9@oracle.com>

Hi Christoph,

I believe you that Arno is excellent engineer but we have to follow rules (which are based on contribution records) to 
be fair to other nominees.

Regards,
Vladimir K

On 2/24/21 3:14 PM, Langer, Christoph wrote:
> Hi Vladimir, David,
> 
> I see that you've vetoed Arno's Committer nomination. This is a fair thing to do.
> 
> If it wasn't about Arno and his personal record within our team I would probably just take back the CFV and postpone it to a later point in time when more commits have accumulated. But in this case, I'd like to add some pleading before I do that.
> 
> First of all, the OpenJDK guidelines say [0]:
> "As a rough guide, a Contributor should make at least eight significant contributions to that Project before being nominated." This, of course, leaves some room for interpretation about what "significant" means. In Arno's case we can see 11 commits plus the one he co-authored lately. It is arguable that a lot of the commits look simple, however I guess it is not always easy to judge whether getting to a certain change was as easy as the commit looks tiny. E.g. in a complex testing environment, chasing down problems can be rather hard.
> 
> Furthermore, as I said in my nomination statement, Arno is a long time member of SAP's JVM team (actually quite some time longer than my own stay with the team). He is our main Quality Engineer and he is very involved in the OpenJDK project, triaging our tests every day. Owing to his role this doesn't show up so much in commits compared to other developers in the team. But there have been various occasions where he has found bugs and initiated fixes that eventually other people from our team (including myself) have finally brought to review and commit in the OpenJDK. We sometimes did not credit Arno, e.g. with co-authorship, out of convenience which was our fault.
> 
> Well, after all, I personally strongly believe that Arno has deserved to become an OpenJDK Committer at this time. But if you stick to your veto after spending a second thought, I'll of course withdraw the nomination.
> 
> Best regards
> Christoph
> 
> [0] https://openjdk.java.net/projects/#project-committer
> 
> 
>> -----Original Message-----
>> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Vladimir
>> Kozlov
>> Sent: Mittwoch, 24. Februar 2021 18:43
>> To: jdk-dev at openjdk.java.net
>> Subject: Re: CFV: New JDK Committer: Arno Zeller
>>
>> Vote: veto
>>
>> I think it is too early for Arno.
>>
>> I would like to remind that Committer candidate have to contribute
>> *significant* changes:
>>
>> "As a rough guide, a Contributor should make at least eight significant
>> contributions to that Project before being
>> nominated."
>>
>> Most of changes on provided list are not significant from my POV. Also based
>> dates, he was not active for more then one
>> year except latest co-authored change.
>>
>> Regards,
>> Vladimir K
>>
>> On 2/24/21 2:40 AM, Langer, Christoph wrote:
>>> Hello,
>>>
>>>
>>>
>>> I hereby nominate Arno Zeller (azeller) to JDK Committer.
>>>
>>>
>>>
>>> Arno is a long time member of the SapMachine team at SAP. Most of his
>> focus is dedicated to quality engineering for the various JDK releases that the
>> SAP team is maintaining.
>>>
>>> Over time he has cumulated 11 commits in OpenJDK [0] and recently co-
>> authored another one [1]. Above that, he's constantly involved in reporting
>> OpenJDK bugs, contributing to their root cause analysis and reviewing the
>> fixes.
>>>
>>>
>>>
>>> Votes are due by 12:00 UTC, 10th March 2021.
>>>
>>>
>>>
>>> Only current JDK Committers [2] 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 [3].
>>>
>>>
>>>
>>> Best regards
>>>
>>> Christoph
>>>
>>>
>>>
>>> [0] https://urldefense.com/v3/__https://github.com/openjdk/jdk/search?q=author-__;!!GqivPVa7Brio!LAaKw5oglZT5Qck9mIMzB7x10lZ7hwJkpJTuwu1Lfgk73vMLnPu_cHJs8G5FHA9OS2e-5Q$
>> name%3A%22zeller%22&type=commits
>>>
>>> [1] https://urldefense.com/v3/__https://github.com/openjdk/jdk/search?q=co-authored-__;!!GqivPVa7Brio!LAaKw5oglZT5Qck9mIMzB7x10lZ7hwJkpJTuwu1Lfgk73vMLnPu_cHJs8G5FHA-aEtifFg$
>> by%3A%22zeller%22&type=commits
>>>
>>> [2] https://openjdk.java.net/census
>>> [3] https://openjdk.java.net/projects/#committer-vote
>>>

From christoph.langer at sap.com  Thu Feb 25 07:39:18 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 25 Feb 2021 07:39:18 +0000
Subject: Withdrawn: CFV: New JDK Committer: Arno Zeller
Message-ID: <AM4PR02MB313808C931A4A6142D6C82518A9E9@AM4PR02MB3138.eurprd02.prod.outlook.com>

I withdraw this CFV due to veto votes.

From: Langer, Christoph
Sent: Mittwoch, 24. Februar 2021 11:41
To: jdk-dev at openjdk.java.net
Cc: Zeller, Arno <arno.zeller at sap.com>
Subject: CFV: New JDK Committer: Arno Zeller


Hello,



I hereby nominate Arno Zeller (azeller) to JDK Committer.



Arno is a long time member of the SapMachine team at SAP. Most of his focus is dedicated to quality engineering for the various JDK releases that the SAP team is maintaining.

Over time he has cumulated 11 commits in OpenJDK [0] and recently co-authored another one [1]. Above that, he's constantly involved in reporting OpenJDK bugs, contributing to their root cause analysis and reviewing the fixes.



Votes are due by 12:00 UTC, 10th March 2021.



Only current JDK Committers [2] 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 [3].



Best regards

Christoph



[0] https://github.com/openjdk/jdk/search?q=author-name%3A%22zeller%22&type=commits

[1] https://github.com/openjdk/jdk/search?q=co-authored-by%3A%22zeller%22&type=commits

[2] https://openjdk.java.net/census
[3] https://openjdk.java.net/projects/#committer-vote


From christoph.langer at sap.com  Thu Feb 25 07:40:28 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 25 Feb 2021 07:40:28 +0000
Subject: [External] : RE: CFV: New JDK Committer: Arno Zeller
In-Reply-To: <347ae18e-35b0-05b1-e704-741e6a5a2ec9@oracle.com>
References: <AM4PR02MB31380DE3333BB3934C2A5EA78A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <8f7c13a7-2195-5197-a06b-239a2b9dc44a@oracle.com>
 <AM4PR02MB31386AF0C1998888F366A4F28A9F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <347ae18e-35b0-05b1-e704-741e6a5a2ec9@oracle.com>
Message-ID: <AM4PR02MB31380517A31B741B953039778A9E9@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Vladimir,

thanks, I respect that. We'll hopefully come back to this soon backed by some better stats ??

Cheers
Christoph

> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: Donnerstag, 25. Februar 2021 02:47
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-
> dev at openjdk.java.net; David Holmes <david.holmes at oracle.com>
> Cc: Zeller, Arno <arno.zeller at sap.com>
> Subject: Re: [External] : RE: CFV: New JDK Committer: Arno Zeller
> 
> Hi Christoph,
> 
> I believe you that Arno is excellent engineer but we have to follow rules
> (which are based on contribution records) to
> be fair to other nominees.
> 
> Regards,
> Vladimir K
> 
> On 2/24/21 3:14 PM, Langer, Christoph wrote:
> > Hi Vladimir, David,
> >
> > I see that you've vetoed Arno's Committer nomination. This is a fair thing to
> do.
> >
> > If it wasn't about Arno and his personal record within our team I would
> probably just take back the CFV and postpone it to a later point in time when
> more commits have accumulated. But in this case, I'd like to add some
> pleading before I do that.
> >
> > First of all, the OpenJDK guidelines say [0]:
> > "As a rough guide, a Contributor should make at least eight significant
> contributions to that Project before being nominated." This, of course,
> leaves some room for interpretation about what "significant" means. In
> Arno's case we can see 11 commits plus the one he co-authored lately. It is
> arguable that a lot of the commits look simple, however I guess it is not
> always easy to judge whether getting to a certain change was as easy as the
> commit looks tiny. E.g. in a complex testing environment, chasing down
> problems can be rather hard.
> >
> > Furthermore, as I said in my nomination statement, Arno is a long time
> member of SAP's JVM team (actually quite some time longer than my own
> stay with the team). He is our main Quality Engineer and he is very involved
> in the OpenJDK project, triaging our tests every day. Owing to his role this
> doesn't show up so much in commits compared to other developers in the
> team. But there have been various occasions where he has found bugs and
> initiated fixes that eventually other people from our team (including myself)
> have finally brought to review and commit in the OpenJDK. We sometimes
> did not credit Arno, e.g. with co-authorship, out of convenience which was
> our fault.
> >
> > Well, after all, I personally strongly believe that Arno has deserved to
> become an OpenJDK Committer at this time. But if you stick to your veto
> after spending a second thought, I'll of course withdraw the nomination.
> >
> > Best regards
> > Christoph
> >
> > [0] https://openjdk.java.net/projects/#project-committer
> >
> >
> >> -----Original Message-----
> >> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Vladimir
> >> Kozlov
> >> Sent: Mittwoch, 24. Februar 2021 18:43
> >> To: jdk-dev at openjdk.java.net
> >> Subject: Re: CFV: New JDK Committer: Arno Zeller
> >>
> >> Vote: veto
> >>
> >> I think it is too early for Arno.
> >>
> >> I would like to remind that Committer candidate have to contribute
> >> *significant* changes:
> >>
> >> "As a rough guide, a Contributor should make at least eight significant
> >> contributions to that Project before being
> >> nominated."
> >>
> >> Most of changes on provided list are not significant from my POV. Also
> based
> >> dates, he was not active for more then one
> >> year except latest co-authored change.
> >>
> >> Regards,
> >> Vladimir K
> >>
> >> On 2/24/21 2:40 AM, Langer, Christoph wrote:
> >>> Hello,
> >>>
> >>>
> >>>
> >>> I hereby nominate Arno Zeller (azeller) to JDK Committer.
> >>>
> >>>
> >>>
> >>> Arno is a long time member of the SapMachine team at SAP. Most of his
> >> focus is dedicated to quality engineering for the various JDK releases that
> the
> >> SAP team is maintaining.
> >>>
> >>> Over time he has cumulated 11 commits in OpenJDK [0] and recently co-
> >> authored another one [1]. Above that, he's constantly involved in
> reporting
> >> OpenJDK bugs, contributing to their root cause analysis and reviewing the
> >> fixes.
> >>>
> >>>
> >>>
> >>> Votes are due by 12:00 UTC, 10th March 2021.
> >>>
> >>>
> >>>
> >>> Only current JDK Committers [2] 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 [3].
> >>>
> >>>
> >>>
> >>> Best regards
> >>>
> >>> Christoph
> >>>
> >>>
> >>>
> >>> [0]
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/search?q=au
> thor-
> __;!!GqivPVa7Brio!LAaKw5oglZT5Qck9mIMzB7x10lZ7hwJkpJTuwu1Lfgk73vM
> LnPu_cHJs8G5FHA9OS2e-5Q$
> >> name%3A%22zeller%22&type=commits
> >>>
> >>> [1]
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/search?q=co
> -authored-
> __;!!GqivPVa7Brio!LAaKw5oglZT5Qck9mIMzB7x10lZ7hwJkpJTuwu1Lfgk73vM
> LnPu_cHJs8G5FHA-aEtifFg$
> >> by%3A%22zeller%22&type=commits
> >>>
> >>> [2] https://openjdk.java.net/census
> >>> [3] https://openjdk.java.net/projects/#committer-vote
> >>>

From odrotbohm at vmware.com  Thu Feb 25 09:03:13 2021
From: odrotbohm at vmware.com (Oliver Drotbohm)
Date: Thu, 25 Feb 2021 09:03:13 +0000
Subject: Inconsistency in Constructor.getGenericParameterTypes()
Message-ID: <66A26523-6C41-4A11-B9DD-D90B69341E31@vmware.com>

Hi all,

we've just ran into the following issue: for a non-static, generic inner class with a constructor declaring a generic parameter, a call to constructor.getGenericParameterTypes() does not return the enclosing class parameter type. Is that by intention? If so, what's the reasoning behind that?

Here's a the output of a reproducer (below):

static class StaticGeneric<T> - names: value, string
static class StaticGeneric<T> - parameters: [class java.lang.Object, class java.lang.String]
static class StaticGeneric<T> - generic parameters: [T, class java.lang.String]

class NonStaticGeneric<T> - names: this$0, value, String
class NonStaticGeneric<T> - parameters: [class Sample, class java.lang.Object, class java.lang.String]
class NonStaticGeneric<T> - generic parameters: [T, class java.lang.String]

class NonStaticNonGeneric - names: this$0, String
class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String]
class NonStaticNonGeneric - generic parameters: [class Sample, class java.lang.String]

Note how the constructor of the NonStaticGeneric<T> type exposes three parameter names, three parameter types but omits the enclosing class parameter in the list of generic parameter types.

Tested on JDK 8 to 15. Same behavior.

Cheers,
Ollie


class Sample {

	public static void main(String[] args) {

		Constructor<?> first = StaticGeneric.class.getDeclaredConstructors()[0];

		System.out.println("static class StaticGeneric<T> - names: "
				+ Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(", ")));
		System.out.println("static class StaticGeneric<T> - parameters: " + Arrays.toString(first.getParameterTypes()));
		System.out.println(
				"static class StaticGeneric<T> - generic parameters: " + Arrays.toString(first.getGenericParameterTypes()));

		System.out.println();

		Constructor<?> second = NonStaticGeneric.class.getDeclaredConstructors()[0];
		System.out.println("class NonStaticGeneric<T> - names: "
				+ Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(", ")));
		System.out.println("class NonStaticGeneric<T> - parameters: " + Arrays.toString(second.getParameterTypes()));
		System.out
				.println(
						"class NonStaticGeneric<T> - generic parameters: " + Arrays.toString(second.getGenericParameterTypes()));

		System.out.println();

		Constructor<?> third = NonStaticNonGeneric.class.getDeclaredConstructors()[0];
		System.out.println("class NonStaticNonGeneric - names: "
				+ Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(", ")));
		System.out.println("class NonStaticNonGeneric - parameters: " + Arrays.toString(third.getParameterTypes()));
		System.out
				.println(
						"class NonStaticNonGeneric - generic parameters: " + Arrays.toString(third.getGenericParameterTypes()));
	}

	static class StaticGeneric<T> {
		StaticGeneric(T value, String string) {}
	}

	class NonStaticGeneric<T> {
		NonStaticGeneric(T value, String String) {}
	}

	class NonStaticNonGeneric {
		NonStaticNonGeneric(String String) {}
	}
}

From x4e_x4e at protonmail.com  Thu Feb 25 10:06:47 2021
From: x4e_x4e at protonmail.com (x4e_x4e)
Date: Thu, 25 Feb 2021 10:06:47 +0000
Subject: Typo in verifier.cpp error message
Message-ID: <GmajfqXSnBXgdluvBFHVRXSj0m2Yz8XqK7bLE2JhAlRWV3sDVz_2pgmuBRLoggWX84gbZVT_Qzgek8sgVxgyXipI81l28QTVAuHF4q0kYrE=@protonmail.com>

Hi,

Just a quick message to say that I think there is a typo in an error message in verifier.cpp on line 1678 (https://github.com/openjdk/jdk/blob/ea48a0bb5617e0e6e3993995ffff754b5e931c9e/src/hotspot/share/classfile/verifier.cpp#L1678), should probably read "Method does not expect a  return  value". Hopefully someone who is a contributor will be able to submit a small patch.

I hope this is the right mailing list to raise this?

Thanks.

From archana.nogriya at uk.ibm.com  Thu Feb 25 13:09:21 2021
From: archana.nogriya at uk.ibm.com (Archana Nogriya)
Date: Thu, 25 Feb 2021 13:09:21 +0000
Subject: Copyright Issues : JDK16 - GPLv2 is present but Classpath exception is
 missing
Message-ID: <OF2FF7698F.5D3D83B5-ON80258687.00480BBA-80258687.004844EC@notes.na.collabserv.com>

Hi,

Please can someone help to fix the copyright issues in JDK16.
We found these issues in our internal scan.

src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java: 
GPLv2 is present but Classpath exception is missing


Many Thanks & Regards
Archana Nogriya
Java Runtimes Development and Project Manager
IBM Hursley
IBM United Kingdom Ltd
internet email: archana.nogriya at uk.ibm.com 

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


From Alan.Bateman at oracle.com  Thu Feb 25 13:13:20 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 25 Feb 2021 13:13:20 +0000
Subject: Copyright Issues : JDK16 - GPLv2 is present but Classpath
 exception is missing
In-Reply-To: <OF2FF7698F.5D3D83B5-ON80258687.00480BBA-80258687.004844EC@notes.na.collabserv.com>
References: <OF2FF7698F.5D3D83B5-ON80258687.00480BBA-80258687.004844EC@notes.na.collabserv.com>
Message-ID: <3a309180-0a8e-cf3c-37ce-8ddcc1e2b312@oracle.com>

On 25/02/2021 13:09, Archana Nogriya wrote:
> Hi,
>
> Please can someone help to fix the copyright issues in JDK16.
> We found these issues in our internal scan.
>
> src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java:
> GPLv2 is present but Classpath exception is missing
>
This has already been fixed via JDK-8261975 [1] in the main line.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8261975

From archana.nogriya at uk.ibm.com  Thu Feb 25 13:15:43 2021
From: archana.nogriya at uk.ibm.com (Archana Nogriya)
Date: Thu, 25 Feb 2021 13:15:43 +0000
Subject: Copyright Issues : JDK16 - GPLv2 is present but Classpath
 exception is missing
In-Reply-To: <3a309180-0a8e-cf3c-37ce-8ddcc1e2b312@oracle.com>
References: <OF2FF7698F.5D3D83B5-ON80258687.00480BBA-80258687.004844EC@notes.na.collabserv.com>
 <3a309180-0a8e-cf3c-37ce-8ddcc1e2b312@oracle.com>
Message-ID: <OFB172236F.74B38DCB-ON80258687.0048C44A-80258687.0048DA27@notes.na.collabserv.com>

Thank you Alan, I will make a note on this. 
Much appreciated for quick reply on this.


Many Thanks & Regards
Archana Nogriya
Java Runtimes Development and Project Manager
IBM Hursley
IBM United Kingdom Ltd
internet email: archana.nogriya at uk.ibm.com 




From:   Alan Bateman <Alan.Bateman at oracle.com>
To:     Archana Nogriya <archana.nogriya at uk.ibm.com>, 
jdk-dev at openjdk.java.net
Cc:     Peter Shipton <Peter_Shipton at ca.ibm.com>, Anthony Renaud 
<Anthony_Renaud at ca.ibm.com>
Date:   25/02/2021 13:13
Subject:        [EXTERNAL] Re: Copyright Issues : JDK16 - GPLv2 is present 
but Classpath exception is missing



On 25/02/2021 13:09, Archana Nogriya wrote:
> Hi,
>
> Please can someone help to fix the copyright issues in JDK16.
> We found these issues in our internal scan.
>
> src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java:
> GPLv2 is present but Classpath exception is missing
>
This has already been fixed via JDK-8261975 [1] in the main line.

-Alan

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8261975&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=-MGd855q-LKvODp9rnOf8dEjvpiN59orrOxhf9virII&m=BNsm2jHvt37C5dZtPEfoIuX2WIjwZpgAcJpu1LzCfMc&s=WyJ4bTSFCZgCLEhfEbMDjZMuzMEdC6wWTQHnO80Safk&e= 





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


From harold.seigel at oracle.com  Thu Feb 25 13:29:28 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Thu, 25 Feb 2021 08:29:28 -0500
Subject: Typo in verifier.cpp error message
In-Reply-To: <GmajfqXSnBXgdluvBFHVRXSj0m2Yz8XqK7bLE2JhAlRWV3sDVz_2pgmuBRLoggWX84gbZVT_Qzgek8sgVxgyXipI81l28QTVAuHF4q0kYrE=@protonmail.com>
References: <GmajfqXSnBXgdluvBFHVRXSj0m2Yz8XqK7bLE2JhAlRWV3sDVz_2pgmuBRLoggWX84gbZVT_Qzgek8sgVxgyXipI81l28QTVAuHF4q0kYrE=@protonmail.com>
Message-ID: <3f507ad0-50dd-539e-b8ff-d17733b86b03@oracle.com>

Hi,

Thank you for reporting this.? I created bug 
https://bugs.openjdk.java.net/browse/JDK-8262368 to track this issue.

Harold

On 2/25/2021 5:06 AM, x4e_x4e wrote:
> there is a typo in an error message in verifier.cpp on line 1678 (https://github.com/openjdk/jdk/blob/ea48a0bb5617e0e6e3993995ffff754b5e931c9e/src/hotspot/share/classfile/verifier.cpp#L1678), should probably read "Method does not expect a  return  value".

From adinn at redhat.com  Thu Feb 25 13:48:30 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 25 Feb 2021 13:48:30 +0000
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <18c2e207-1064-a5c7-ecc4-568585c83fb2@redhat.com>

Vote: yes

On 24/02/2021 19:08, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer.
> 
> Alexey is currently a JDK committer [1], and has been a long time member 
> of the Java client team at Oracle
> previously working on installer technologies and recently has made 
> substantial contributions to the
> development of the jpackage [2] tool from its inception and has 
> continued to work on it and
> has made 43 individual contributions [3]
> In addition he has regularly reviewed changes even without the formal 
> role of reviewer.
> 
> Only current JDK Project Reviewers [4] 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 [5].
> 
> Votes are due by 20:00 GMT on 10th March 2021.
> 
> -Phil.
> 
> [1] https://openjdk.java.net/census#asemenyuk
> [2] https://openjdk.java.net/jeps/392
> [3] 
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits 
> 
> [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [5] https://openjdk.java.net/projects/#reviewer-vote
> 

-- 
regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From lois.foltan at oracle.com  Thu Feb 25 15:06:50 2021
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 25 Feb 2021 10:06:50 -0500
Subject: CFV: New JDK Reviewer: Alexey Semenyuk
In-Reply-To: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
References: <93fd00ee-68c6-2b82-2cd1-48460848160a@oracle.com>
Message-ID: <b33629f3-5bbb-3f61-a4f3-c0cc557e37e1@oracle.com>

Vote: yes

Lois

On 2/24/2021 2:08 PM, Philip Race wrote:
> I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
> Project Reviewer.
>
> Alexey is currently a JDK committer [1], and has been a long time 
> member of the Java client team at Oracle
> previously working on installer technologies and recently has made 
> substantial contributions to the
> development of the jpackage [2] tool from its inception and has 
> continued to work on it and
> has made 43 individual contributions [3]
> In addition he has regularly reviewed changes even without the formal 
> role of reviewer.
>
> Only current JDK Project Reviewers [4] 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 [5].
>
> Votes are due by 20:00 GMT on 10th March 2021.
>
> -Phil.
>
> [1] https://openjdk.java.net/census#asemenyuk
> [2] https://openjdk.java.net/jeps/392
> [3] 
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
> [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [5] https://openjdk.java.net/projects/#reviewer-vote


From jonathan.gibbons at oracle.com  Thu Feb 25 17:52:07 2021
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 25 Feb 2021 09:52:07 -0800
Subject: CFV: New JDK Committer: Adam Sotona
Message-ID: <6c1af5f7-6d0d-4972-93db-2f7bb015eea9@oracle.com>


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 james.laskey at oracle.com  Thu Feb 25 17:53:50 2021
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 25 Feb 2021 17:53:50 +0000
Subject: CFV: 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: <A8FB5209-8D90-4441-9D3D-33DA90E69E05@oracle.com>

Vote: yes

> On Feb 25, 2021, at 1:52 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> 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 eric.caspole at oracle.com  Thu Feb 25 17:54:00 2021
From: eric.caspole at oracle.com (eric.caspole at oracle.com)
Date: Thu, 25 Feb 2021 12:54:00 -0500
Subject: CFV: 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: <f2a2ce4c-da2e-5fda-d29f-a15da22e9cce@oracle.com>

Vote: yes

Eric


On 2/25/21 12:52 PM, 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 lois.foltan at oracle.com  Thu Feb 25 17:57:03 2021
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 25 Feb 2021 12:57:03 -0500
Subject: CFV: 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: <1b0f2917-29e2-2f15-5db0-ae8d6393070c@oracle.com>

Vote: yes

Lois

On 2/25/2021 12:52 PM, 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 daniel.fuchs at oracle.com  Thu Feb 25 17:59:18 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 25 Feb 2021 17:59:18 +0000
Subject: CFV: 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: <81f84d19-7875-9fc1-bd20-8e164ddd3eca@oracle.com>

Vote: yes

best regards,

-- daniel

On 25/02/2021 17:52, Jonathan Gibbons wrote:
> I hereby nominate Adam Sotona to JDK Committer.


From harold.seigel at oracle.com  Thu Feb 25 18:25:09 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Thu, 25 Feb 2021 13:25:09 -0500
Subject: CFV: 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: <dc37ce5f-bbef-95fe-3538-03812fc0e0c6@oracle.com>

Vote: yes

Harold

On 2/25/2021 12:52 PM, 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 rajan.halade at oracle.com  Thu Feb 25 18:37:48 2021
From: rajan.halade at oracle.com (Rajan Halade)
Date: Thu, 25 Feb 2021 18:37:48 +0000
Subject: New JDK Reviewer: Alexey Semenyuk
Message-ID: <ED7F8013-29DB-41F4-8272-BEAA49D58F5E@oracle.com>

Vote: yes

Thanks,
Rajan

?On 2/24/21, 11:08 AM, "jdk-dev on behalf of Philip Race" <jdk-dev-retn at openjdk.java.net on behalf of philip.race at oracle.com> wrote:

    I hereby nominate Alexey Semenyuk (asemenyuk [1]) to the role of JDK 
    Project Reviewer.

    Alexey is currently a JDK committer [1], and has been a long time member 
    of the Java client team at Oracle
    previously working on installer technologies and recently has made 
    substantial contributions to the
    development of the jpackage [2] tool from its inception and has 
    continued to work on it and
    has made 43 individual contributions [3]
    In addition he has regularly reviewed changes even without the formal 
    role of reviewer.

    Only current JDK Project Reviewers [4] 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 [5].

    Votes are due by 20:00 GMT on 10th March 2021.

    -Phil.

    [1] https://openjdk.java.net/census#asemenyuk
    [2] https://openjdk.java.net/jeps/392
    [3] 
    https://github.com/openjdk/jdk/search?q=author-name%3A%22Alexey+Semenyuk%22&type=commits
    [4] https://openjdk.java.net/census <https://openjdk.java.net/census>
    [5] https://openjdk.java.net/projects/#reviewer-vote


From vladimir.kozlov at oracle.com  Thu Feb 25 19:00:21 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Feb 2021 11:00:21 -0800
Subject: CFV: 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: <59a38c0f-45c0-80f9-f2e6-9ac88ab7760a@oracle.com>

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 alexander.zuev at oracle.com  Thu Feb 25 19:00:55 2021
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Thu, 25 Feb 2021 11:00:55 -0800
Subject: CFV: 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: <f38589e6-1dbb-58b5-23c5-6392b1b70f19@oracle.com>

Vote: yes

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 mark.reinhold at oracle.com  Thu Feb 25 21:27:28 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 25 Feb 2021 13:27:28 -0800 (PST)
Subject: JEP proposed to target JDK 17: 382: New macOS Rendering Pipeline
Message-ID: <20210225212728.1AD393D9641@eggemoggin.niobe.net>

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.

- Mark


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

From alex at nexttypes.com  Thu Feb 25 21:41:18 2021
From: alex at nexttypes.com (Alejandro =?ISO-8859-1?Q?S=E1nchez?=)
Date: Thu, 25 Feb 2021 22:41:18 +0100
Subject: Systems Integration and Raising of the Abstraction Level
Message-ID: <dcd12b985f98b34c01801dcab15c8b1b941440cf.camel@nexttypes.com>

We have highly evolved systems such as SQL, HTTP, HTML, file formats or
high level programming languages such as Java or PHP that allow us to
program many things with little code. Even so a lot of effort is 
invested in the integration of these systems. To try to reduce this
problem libraries and frameworks that help in some ways are created but
the integration is not complete.

It is well known that most of the time when you try to create something
to integrate several incompatible systems what you get in the end is to
have another incompatible system :). Still I think the integration
between the systems mentioned above is something very important that
can mean a great step in the evolution of computing and worth a try.

To explore how this integration can be I have created a framework that
I have called NextTypes and that its main objective is the integration
of data types. For me it is something very illogical that something as
basic as a 16 bits integer receives a different name in each of the
systems ("smallint", "short", "number") and can also be signed or
unsigned. In any moment, due to a mistake from the programmer, the
number of the programming language does not fit in the database column.
Besides these names are little indicative of its characteristics, it
would be clearer for example to use "int16". Whatever names are chosen
the most important thing is to use in all systems the same names for
types of the same characteristics.

Also there is no standard system for defining composite data types of
primitive types and other composite types. From an HTML form to a SQL
table or from one application to another are required multiple
transformations of the data. Lack of integration also lowers the level
of abstraction, making it necessary to do lots of low level stuff for
systems to fit.

NextTypes at this moment is nothing more than another incompatible
system with the others. It simply integrates them quite a bit and
raises the level of abstraction. But what I would like is that the
things that compose NextTypes were included in the systems it
integrates.

Finally I would like to list some examples of improvements in database
managers, SQL, HTTP, HTML, browsers and programming languages that
would help the integration and elevation of the level of abstraction.
Some of these enhancements are already included in NextTypes and other
frameworks.


SQL
---

- Custom metadata in tables and columns.
- Date of creation and modification of the rows.
- Date of creation and modification of the definition of the tables.
- Use of table and column names in prepared statements.

    Example: select # from # where # = ?;

- Use of arrays in prepared statements.

    Example: select # from article where id in (?);

        # = author,title
        ? = 10,24,45

- Standardization of ranges of valid values and resolution for date,
time and datetime types in database managers an HTML time element.


PostgreSQL
----------

- Facilitate access to the definition of full text search indexes with
a function to parse "pg_index.indexprs" column.


Other database managers
-----------------------

- Allow transactional DDL, deferrable constraints and composite types.


JDBC
----

- High level methods that allow queries with the execution of a
single method.

    Example: Tuple [] tuples = query("select author,title from article
where id in (?), ids);

- Integration with java.time data types.


HTTP - Servers
--------------

- Processing of arrays of elements composed of several parameters.

    fields:0:type = string
    fields:0:name = title
    fields:0:parameters = 250
    fields:0:not_null = true
  
    fields:1:type = string
    fields:1:name = author
    fields:1:parameters = 250
    fields:1:not_null = true

   Another possibility is to generate in the browser arrays of JSON
objects from the forms. 
     
    "fields": [
        {
            "type": "string",
            "name": "title",
            "parameters": 250,
            "not_null": true
        }, {
            "type": "string",
            "name": "author",
            "parameters": 250,
            "not_null": true
        }
    ]


XML/HTML - BROWSER
------------------

- Input elements for different types of numbers with min and max
values: 16 bits integer, 32 bits integer, 32 bits float and 64 bits
float.

- Input elements for images, audios and videos with preview.

- Timezone input element.

- Boolean input element with "true" and "false" values.

- Null value in file inputs.

- Clear button in file inputs like in date and time inputs.

- Show size in file inputs.

- Extension of the DOM API with high level and chainable methods.

    Example: paragraph.appendElement("a").setAttribute("href",
"/article");

- Change of the "action" parameter of the forms to "target" to indicate
the URL where to execute the action. The "action" parameter is moved to
the different buttons on the form and allows executing a different
action with each of the the buttons.

    Example:

        <form target="/article">
            <button action="delete">Delete</button>
            <button action="export">Export</button>
        </form>

- "select" elements that change a parameter of the current URL.

    Example:
        <select url-parameter="lang"/>
            <option>en</option>
            <option>es</option>

        URL = https://demo.nexttypes.com/?lang=en

- "content-type" attribute in links and context menu in the browser to
open links with external applications using WEBDAV, similar to a file
manager.

    Example: <a href="" content-
type="application/vnd.oasis.opendocument.text">

    ------------------------------
    | Open link with ...         |
    | Open link with LibreOffice |

- Background submission of forms without using XMLHttpRequest,
display of result in dialog window or file download, and execution of a
Javascript function for subsequent actions.

    Example: <form background show-progress callback=function()>

- Dialog with progress indicator of form submission. Must show total
size, transmitted data and average speed. Possibility to pause or
cancel the submission.

- Dynamic datalist with searchable JSON source. Over data source URL is
added a "search" parameter with input value.

    Example:
        <input list="article-list" name="article" type="text" />
        <datalist id="article-list"
src="/article?lang=en&view=json&names" />

        Example query URL: "/article?lang=en&view=json&names&search=Ne"

- Same appearance and operation of inputs with dynamic datalist in all
browsers.

- Option tags with icons.

    Example: <option icon="/icons/save.svg">Save</option>

- Tabs, Tree, etc widgets

- Mechanism to close HTTPS sessions initiated with client certificate
authentication.


JAVA
----

- Subclasses of String or some system of variants of String that allows
assigning a regular expression or class that limits its valid values
to avoid code injection or values that will crash the system.

    Example: String:Type = "[a-z0-9 _] +"; Or String:Type = TypeChecks;

        String:Type type = "article_language"; -> correct
        String:Type type = "Article-Language"; -> error


We can talk about the characteristics of each system in its mailing
list or group. For the general topic of system integration I have
created a discussion in the github project.

https://github.com/alejsanc/nexttypes/discussions/6

This email has been sent to the following mailing lists and groups:

pgsql-hackers at lists.postgresql.org
pgsql-jdbc at lists.postgresql.org
mozilla.dev.platform at googlegroups.com
public-html at w3.org
jdbc-spec-discuss at openjdk.java.net
jdk-dev at openjdk.java.net
maria-developers at lists.launchpad.net
chromium-dev at chromium.org
https://mysqlcommunity.slack.com/archives/C8R1336M7

Best regards.
Alejandro S?nchez.


From david.holmes at oracle.com  Thu Feb 25 22:10:27 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Feb 2021 08:10:27 +1000
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: <37873d60-8bde-b0c3-9a0f-70505d4e8517@oracle.com>

On 26/02/2021 5:00 am, Vladimir Kozlov wrote:
> Hi Jonathan,
> 
> Please, add links to commits. We need to see changes done by Adam and 
> judge if they are *significant*.

+1

Thanks,
David

> 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 stuart.marks at oracle.com  Thu Feb 25 23:21:18 2021
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 25 Feb 2021 15:21:18 -0800
Subject: CFV: 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: <17e8aecf-cc10-2e2a-91e0-58d9b4a1e725@oracle.com>

Vote: yes

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 tobias.oelgarte at gmail.com  Fri Feb 26 15:58:27 2021
From: tobias.oelgarte at gmail.com (Tobias Oelgarte)
Date: Fri, 26 Feb 2021 16:58:27 +0100
Subject: jpackage does not include extra files from app-image when creating
 Debian package?
Message-ID: <23b446ad-6fdd-f016-a8ba-9f0f482efb82@gmail.com>

I'm creating an app image with the following commands*:

 ? jlink --output runtime --module-path [..] --add-modules [..] --bind-services
 ? jpackage --type app-image --dest image --module [..] --runtime-image runtime --name Name

Now i copy some extra files to the resulting image, which are needed 
during program execution.

After that i can create an MSI installer with the following command*:

 ? jpackage --type msi --dest installer --app-image image --name Name

As the result I get an installer which also includes the extra files 
which I added to the app-image an the extra files are installed along 
with the rest of the image.

But if i do the same, creating a Debian installer package (deb), then 
the extra files are not included.

 ? jpackage --type deb --dest installer --app-image image --name Name

The resulting deb installs just fine, but the files are not included in 
the deb archive and are obviously not written to the installation directory.

Did I miss something, or is this not possible when creating an Debian 
package?

* I removed some trivial parameters like --vendor, --copyright, 
--resource-dir, e.t.c. to keep the commandlines short


From alexey.semenyuk at oracle.com  Fri Feb 26 16:42:15 2021
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 26 Feb 2021 11:42:15 -0500
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <23b446ad-6fdd-f016-a8ba-9f0f482efb82@gmail.com>
References: <23b446ad-6fdd-f016-a8ba-9f0f482efb82@gmail.com>
Message-ID: <ae01958d-1e1b-d25d-fa78-e6cdf5d954d9@oracle.com>

Hi Tobias,

Extra files in deb packaging should work. What is the version of 
jpackage you are using? Where do you put extra files in app image? If 
you put them in the root directory of app image they will not be 
included in the package. Recommended location for extra files is "app" 
subdirectory of app image.

- Alexey

On 2/26/2021 10:58 AM, Tobias Oelgarte wrote:
> I'm creating an app image with the following commands*:
>
> ? jlink --output runtime --module-path [..] --add-modules [..] 
> --bind-services
> ? jpackage --type app-image --dest image --module [..] --runtime-image 
> runtime --name Name
>
> Now i copy some extra files to the resulting image, which are needed 
> during program execution.
>
> After that i can create an MSI installer with the following command*:
>
> ? jpackage --type msi --dest installer --app-image image --name Name
>
> As the result I get an installer which also includes the extra files 
> which I added to the app-image an the extra files are installed along 
> with the rest of the image.
>
> But if i do the same, creating a Debian installer package (deb), then 
> the extra files are not included.
>
> ? jpackage --type deb --dest installer --app-image image --name Name
>
> The resulting deb installs just fine, but the files are not included 
> in the deb archive and are obviously not written to the installation 
> directory.
>
> Did I miss something, or is this not possible when creating an Debian 
> package?
>
> * I removed some trivial parameters like --vendor, --copyright, 
> --resource-dir, e.t.c. to keep the commandlines short
>


From tobias.oelgarte at gmail.com  Fri Feb 26 17:05:48 2021
From: tobias.oelgarte at gmail.com (Tobias Oelgarte)
Date: Fri, 26 Feb 2021 18:05:48 +0100
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <ae01958d-1e1b-d25d-fa78-e6cdf5d954d9@oracle.com>
References: <23b446ad-6fdd-f016-a8ba-9f0f482efb82@gmail.com>
 <ae01958d-1e1b-d25d-fa78-e6cdf5d954d9@oracle.com>
Message-ID: <ba5f4e6a-d9cb-ab51-a99d-b985d9f63673@gmail.com>

I tried JDK 14.0.2 and JDK 16 Build 36. I let Maven put my extra files 
into '/target/image/AppName/*/' and i also tried to put them into 
'target/image/AppName/app/*' but nothing worked. It works perfectly for 
'msi' at all places under AppName, but not for 'deb'.

After some trial an error I added the files to 
"target/image/AppName/bin/*" and surprisingly this worked. But this is 
not really what I expected. At least the path relative to the binary 
stays the same. Maybe it was intended that way?

On 26.02.21 17:42, Alexey Semenyuk wrote:

> Hi Tobias,
>
> Extra files in deb packaging should work. What is the version of 
> jpackage you are using? Where do you put extra files in app image? If 
> you put them in the root directory of app image they will not be 
> included in the package. Recommended location for extra files is "app" 
> subdirectory of app image.
>
> - Alexey
>
> On 2/26/2021 10:58 AM, Tobias Oelgarte wrote:
>> I'm creating an app image with the following commands*:
>>
>> ? jlink --output runtime --module-path [..] --add-modules [..] 
>> --bind-services
>> ? jpackage --type app-image --dest image --module [..] 
>> --runtime-image runtime --name Name
>>
>> Now i copy some extra files to the resulting image, which are needed 
>> during program execution.
>>
>> After that i can create an MSI installer with the following command*:
>>
>> ? jpackage --type msi --dest installer --app-image image --name Name
>>
>> As the result I get an installer which also includes the extra files 
>> which I added to the app-image an the extra files are installed along 
>> with the rest of the image.
>>
>> But if i do the same, creating a Debian installer package (deb), then 
>> the extra files are not included.
>>
>> ? jpackage --type deb --dest installer --app-image image --name Name
>>
>> The resulting deb installs just fine, but the files are not included 
>> in the deb archive and are obviously not written to the installation 
>> directory.
>>
>> Did I miss something, or is this not possible when creating an Debian 
>> package?
>>
>> * I removed some trivial parameters like --vendor, --copyright, 
>> --resource-dir, e.t.c. to keep the commandlines short
>>
>

From alexey.semenyuk at oracle.com  Fri Feb 26 17:25:32 2021
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 26 Feb 2021 12:25:32 -0500
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <ba5f4e6a-d9cb-ab51-a99d-b985d9f63673@gmail.com>
References: <23b446ad-6fdd-f016-a8ba-9f0f482efb82@gmail.com>
 <ae01958d-1e1b-d25d-fa78-e6cdf5d954d9@oracle.com>
 <ba5f4e6a-d9cb-ab51-a99d-b985d9f63673@gmail.com>
Message-ID: <f84b2f5d-6dcd-b4b2-23b9-6f9bbb380438@oracle.com>

Tobias,

If you put your files in 'target/image/AppName/app/' subfolder and they 
are missing in .deb file it is a bug in jpackage. Please go ahead and 
file a bug in JIRA. We will work of the fix.

- Alexey

On 2/26/2021 12:05 PM, Tobias Oelgarte wrote:
> I tried JDK 14.0.2 and JDK 16 Build 36. I let Maven put my extra files 
> into '/target/image/AppName/*/' and i also tried to put them into 
> 'target/image/AppName/app/*' but nothing worked. It works perfectly 
> for 'msi' at all places under AppName, but not for 'deb'.
>
> After some trial an error I added the files to 
> "target/image/AppName/bin/*" and surprisingly this worked. But this is 
> not really what I expected. At least the path relative to the binary 
> stays the same. Maybe it was intended that way?
>
> On 26.02.21 17:42, Alexey Semenyuk wrote:
>
>> Hi Tobias,
>>
>> Extra files in deb packaging should work. What is the version of 
>> jpackage you are using? Where do you put extra files in app image? If 
>> you put them in the root directory of app image they will not be 
>> included in the package. Recommended location for extra files is 
>> "app" subdirectory of app image.
>>
>> - Alexey
>>
>> On 2/26/2021 10:58 AM, Tobias Oelgarte wrote:
>>> I'm creating an app image with the following commands*:
>>>
>>> ? jlink --output runtime --module-path [..] --add-modules [..] 
>>> --bind-services
>>> ? jpackage --type app-image --dest image --module [..] 
>>> --runtime-image runtime --name Name
>>>
>>> Now i copy some extra files to the resulting image, which are needed 
>>> during program execution.
>>>
>>> After that i can create an MSI installer with the following command*:
>>>
>>> ? jpackage --type msi --dest installer --app-image image --name Name
>>>
>>> As the result I get an installer which also includes the extra files 
>>> which I added to the app-image an the extra files are installed 
>>> along with the rest of the image.
>>>
>>> But if i do the same, creating a Debian installer package (deb), 
>>> then the extra files are not included.
>>>
>>> ? jpackage --type deb --dest installer --app-image image --name Name
>>>
>>> The resulting deb installs just fine, but the files are not included 
>>> in the deb archive and are obviously not written to the installation 
>>> directory.
>>>
>>> Did I miss something, or is this not possible when creating an 
>>> Debian package?
>>>
>>> * I removed some trivial parameters like --vendor, --copyright, 
>>> --resource-dir, e.t.c. to keep the commandlines short
>>>
>>


From tobias.oelgarte at gmail.com  Fri Feb 26 19:39:01 2021
From: tobias.oelgarte at gmail.com (Tobias Oelgarte)
Date: Fri, 26 Feb 2021 20:39:01 +0100
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <f84b2f5d-6dcd-b4b2-23b9-6f9bbb380438@oracle.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>
Message-ID: <5b0d5fe2-f9cc-cb86-6c63-605a6b935535@gmail.com>

No luck. If i put my files in 'target/image/AppName/app/' subfolder they 
are not included in the .deb file. The entire app folder is missing 
(even from the jpackage installer --temp directory). If i put them in 
'target/image/AppName/bin/' they are included and also installed.

I can't file a bug report in JIRA. I would if I could, but I have no 
access to it.

BTW is there any reliable way to figure out the path of the 'app/' 
directory after it has been installed from within the running 
application? In JDK 14 (Windows) I got the system property 
'java.launcher.path', but under JDK 16 (Ubuntu 18.04) this property is 
missing and instead I found 'jpackage.app-path' which points to the 
binary inside 'bin/'.

On 26.02.21 18:25, Alexey Semenyuk wrote:
> Tobias,
>
> If you put your files in 'target/image/AppName/app/' subfolder and 
> they are missing in .deb file it is a bug in jpackage. Please go ahead 
> and file a bug in JIRA. We will work of the fix.
>
> - Alexey
>
> On 2/26/2021 12:05 PM, Tobias Oelgarte wrote:
>> I tried JDK 14.0.2 and JDK 16 Build 36. I let Maven put my extra 
>> files into '/target/image/AppName/*/' and i also tried to put them 
>> into 'target/image/AppName/app/*' but nothing worked. It works 
>> perfectly for 'msi' at all places under AppName, but not for 'deb'.
>>
>> After some trial an error I added the files to 
>> "target/image/AppName/bin/*" and surprisingly this worked. But this 
>> is not really what I expected. At least the path relative to the 
>> binary stays the same. Maybe it was intended that way?
>>
>> On 26.02.21 17:42, Alexey Semenyuk wrote:
>>
>>> Hi Tobias,
>>>
>>> Extra files in deb packaging should work. What is the version of 
>>> jpackage you are using? Where do you put extra files in app image? 
>>> If you put them in the root directory of app image they will not be 
>>> included in the package. Recommended location for extra files is 
>>> "app" subdirectory of app image.
>>>
>>> - Alexey
>>>
>>> On 2/26/2021 10:58 AM, Tobias Oelgarte wrote:
>>>> I'm creating an app image with the following commands*:
>>>>
>>>> ? jlink --output runtime --module-path [..] --add-modules [..] 
>>>> --bind-services
>>>> ? jpackage --type app-image --dest image --module [..] 
>>>> --runtime-image runtime --name Name
>>>>
>>>> Now i copy some extra files to the resulting image, which are 
>>>> needed during program execution.
>>>>
>>>> After that i can create an MSI installer with the following command*:
>>>>
>>>> ? jpackage --type msi --dest installer --app-image image --name Name
>>>>
>>>> As the result I get an installer which also includes the extra 
>>>> files which I added to the app-image an the extra files are 
>>>> installed along with the rest of the image.
>>>>
>>>> But if i do the same, creating a Debian installer package (deb), 
>>>> then the extra files are not included.
>>>>
>>>> ? jpackage --type deb --dest installer --app-image image --name Name
>>>>
>>>> The resulting deb installs just fine, but the files are not 
>>>> included in the deb archive and are obviously not written to the 
>>>> installation directory.
>>>>
>>>> Did I miss something, or is this not possible when creating an 
>>>> Debian package?
>>>>
>>>> * I removed some trivial parameters like --vendor, --copyright, 
>>>> --resource-dir, e.t.c. to keep the commandlines short
>>>>
>>>
>

From roger.riggs at oracle.com  Fri Feb 26 21:53:30 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 26 Feb 2021 16:53:30 -0500
Subject: CFV: 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: <26fb0185-4d7f-f9e5-cce7-e69e2d745b42@oracle.com>

Vote: Yes

On 2/25/21 12:52 PM, Jonathan Gibbons wrote:
> I hereby nominate Adam Sotona to JDK Committer. 


From alexey.semenyuk at oracle.com  Fri Feb 26 22:03:53 2021
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 26 Feb 2021 17:03:53 -0500
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <5b0d5fe2-f9cc-cb86-6c63-605a6b935535@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>
Message-ID: <d184eda6-9954-33f3-7837-412514212f33@oracle.com>



On 2/26/2021 2:39 PM, Tobias Oelgarte wrote:
> No luck. If i put my files in 'target/image/AppName/app/' subfolder 
> they are not included in the .deb file. The entire app folder is 
> missing (even from the jpackage installer --temp directory). If i put 
> them in 'target/image/AppName/bin/' they are included and also installed.
Looks like a bug in jpackage.

>
> I can't file a bug report in JIRA. I would if I could, but I have no 
> access to it.
Sorry for misleading you. Please use 
https://bugreport.java.com/bugreport/ tool to file a bug (Component: 
"Tools issues", Subcomponent: "jpackage").

>
> BTW is there any reliable way to figure out the path of the 'app/' 
> directory after it has been installed from within the running 
> application? In JDK 14 (Windows) I got the system property 
> 'java.launcher.path', but under JDK 16 (Ubuntu 18.04) this property is 
> missing and instead I found 'jpackage.app-path' which points to the 
> binary inside 'bin/'.
No, there is no platform independent and reliable way to get the path to 
'app' directory. However you can get location of one of your app's 
classes through Class.getResource(). See 
https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from

- Alexey

>
> On 26.02.21 18:25, Alexey Semenyuk wrote:
>> Tobias,
>>
>> If you put your files in 'target/image/AppName/app/' subfolder and 
>> they are missing in .deb file it is a bug in jpackage. Please go 
>> ahead and file a bug in JIRA. We will work of the fix.
>>
>> - Alexey
>>
>> On 2/26/2021 12:05 PM, Tobias Oelgarte wrote:
>>> I tried JDK 14.0.2 and JDK 16 Build 36. I let Maven put my extra 
>>> files into '/target/image/AppName/*/' and i also tried to put them 
>>> into 'target/image/AppName/app/*' but nothing worked. It works 
>>> perfectly for 'msi' at all places under AppName, but not for 'deb'.
>>>
>>> After some trial an error I added the files to 
>>> "target/image/AppName/bin/*" and surprisingly this worked. But this 
>>> is not really what I expected. At least the path relative to the 
>>> binary stays the same. Maybe it was intended that way?
>>>
>>> On 26.02.21 17:42, Alexey Semenyuk wrote:
>>>
>>>> Hi Tobias,
>>>>
>>>> Extra files in deb packaging should work. What is the version of 
>>>> jpackage you are using? Where do you put extra files in app image? 
>>>> If you put them in the root directory of app image they will not be 
>>>> included in the package. Recommended location for extra files is 
>>>> "app" subdirectory of app image.
>>>>
>>>> - Alexey
>>>>
>>>> On 2/26/2021 10:58 AM, Tobias Oelgarte wrote:
>>>>> I'm creating an app image with the following commands*:
>>>>>
>>>>> ? jlink --output runtime --module-path [..] --add-modules [..] 
>>>>> --bind-services
>>>>> ? jpackage --type app-image --dest image --module [..] 
>>>>> --runtime-image runtime --name Name
>>>>>
>>>>> Now i copy some extra files to the resulting image, which are 
>>>>> needed during program execution.
>>>>>
>>>>> After that i can create an MSI installer with the following command*:
>>>>>
>>>>> ? jpackage --type msi --dest installer --app-image image --name Name
>>>>>
>>>>> As the result I get an installer which also includes the extra 
>>>>> files which I added to the app-image an the extra files are 
>>>>> installed along with the rest of the image.
>>>>>
>>>>> But if i do the same, creating a Debian installer package (deb), 
>>>>> then the extra files are not included.
>>>>>
>>>>> ? jpackage --type deb --dest installer --app-image image --name Name
>>>>>
>>>>> The resulting deb installs just fine, but the files are not 
>>>>> included in the deb archive and are obviously not written to the 
>>>>> installation directory.
>>>>>
>>>>> Did I miss something, or is this not possible when creating an 
>>>>> Debian package?
>>>>>
>>>>> * I removed some trivial parameters like --vendor, --copyright, 
>>>>> --resource-dir, e.t.c. to keep the commandlines short
>>>>>
>>>>
>>


From tobias.oelgarte at gmail.com  Sat Feb 27 07:31:30 2021
From: tobias.oelgarte at gmail.com (Tobias Oelgarte)
Date: Sat, 27 Feb 2021 08:31:30 +0100
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <d184eda6-9954-33f3-7837-412514212f33@oracle.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>
Message-ID: <abae3f37-0458-58da-9e3b-87e09fd12821@gmail.com>

> Sorry for misleading you. Please use 
> https://bugreport.java.com/bugreport/ tool to file a bug (Component: 
> "Tools issues", Subcomponent: "jpackage"). 
I filed a bug report. It's awaiting review to be accepted.

> No, there is no platform independent and reliable way to get the path 
> to 'app' directory. However you can get location of one of your app's 
> classes through Class.getResource(). See 
> https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from
That isn't helpful at all. All i get is either the URL jrt:/<modulename> 
or null, but not the installation directory or something similar.

On 26.02.21 23:03, Alexey Semenyuk wrote:
>
>
> On 2/26/2021 2:39 PM, Tobias Oelgarte wrote:
>> No luck. If i put my files in 'target/image/AppName/app/' subfolder 
>> they are not included in the .deb file. The entire app folder is 
>> missing (even from the jpackage installer --temp directory). If i put 
>> them in 'target/image/AppName/bin/' they are included and also 
>> installed.
> Looks like a bug in jpackage.
>
>>
>> I can't file a bug report in JIRA. I would if I could, but I have no 
>> access to it.
> Sorry for misleading you. Please use 
> https://bugreport.java.com/bugreport/ tool to file a bug (Component: 
> "Tools issues", Subcomponent: "jpackage").
>
>>
>> BTW is there any reliable way to figure out the path of the 'app/' 
>> directory after it has been installed from within the running 
>> application? In JDK 14 (Windows) I got the system property 
>> 'java.launcher.path', but under JDK 16 (Ubuntu 18.04) this property 
>> is missing and instead I found 'jpackage.app-path' which points to 
>> the binary inside 'bin/'.
> No, there is no platform independent and reliable way to get the path 
> to 'app' directory. However you can get location of one of your app's 
> classes through Class.getResource(). See 
> https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from
>
> - Alexey
>
>>
>> On 26.02.21 18:25, Alexey Semenyuk wrote:
>>> Tobias,
>>>
>>> If you put your files in 'target/image/AppName/app/' subfolder and 
>>> they are missing in .deb file it is a bug in jpackage. Please go 
>>> ahead and file a bug in JIRA. We will work of the fix.
>>>
>>> - Alexey
>>>
>>> On 2/26/2021 12:05 PM, Tobias Oelgarte wrote:
>>>> I tried JDK 14.0.2 and JDK 16 Build 36. I let Maven put my extra 
>>>> files into '/target/image/AppName/*/' and i also tried to put them 
>>>> into 'target/image/AppName/app/*' but nothing worked. It works 
>>>> perfectly for 'msi' at all places under AppName, but not for 'deb'.
>>>>
>>>> After some trial an error I added the files to 
>>>> "target/image/AppName/bin/*" and surprisingly this worked. But this 
>>>> is not really what I expected. At least the path relative to the 
>>>> binary stays the same. Maybe it was intended that way?
>>>>
>>>> On 26.02.21 17:42, Alexey Semenyuk wrote:
>>>>
>>>>> Hi Tobias,
>>>>>
>>>>> Extra files in deb packaging should work. What is the version of 
>>>>> jpackage you are using? Where do you put extra files in app image? 
>>>>> If you put them in the root directory of app image they will not 
>>>>> be included in the package. Recommended location for extra files 
>>>>> is "app" subdirectory of app image.
>>>>>
>>>>> - Alexey
>>>>>
>>>>> On 2/26/2021 10:58 AM, Tobias Oelgarte wrote:
>>>>>> I'm creating an app image with the following commands*:
>>>>>>
>>>>>> ? jlink --output runtime --module-path [..] --add-modules [..] 
>>>>>> --bind-services
>>>>>> ? jpackage --type app-image --dest image --module [..] 
>>>>>> --runtime-image runtime --name Name
>>>>>>
>>>>>> Now i copy some extra files to the resulting image, which are 
>>>>>> needed during program execution.
>>>>>>
>>>>>> After that i can create an MSI installer with the following 
>>>>>> command*:
>>>>>>
>>>>>> ? jpackage --type msi --dest installer --app-image image --name Name
>>>>>>
>>>>>> As the result I get an installer which also includes the extra 
>>>>>> files which I added to the app-image an the extra files are 
>>>>>> installed along with the rest of the image.
>>>>>>
>>>>>> But if i do the same, creating a Debian installer package (deb), 
>>>>>> then the extra files are not included.
>>>>>>
>>>>>> ? jpackage --type deb --dest installer --app-image image --name Name
>>>>>>
>>>>>> The resulting deb installs just fine, but the files are not 
>>>>>> included in the deb archive and are obviously not written to the 
>>>>>> installation directory.
>>>>>>
>>>>>> Did I miss something, or is this not possible when creating an 
>>>>>> Debian package?
>>>>>>
>>>>>> * I removed some trivial parameters like --vendor, --copyright, 
>>>>>> --resource-dir, e.t.c. to keep the commandlines short
>>>>>>
>>>>>
>>>
>

From mik3hall at gmail.com  Sat Feb 27 10:22:41 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 27 Feb 2021 04:22:41 -0600
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <abae3f37-0458-58da-9e3b-87e09fd12821@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>
Message-ID: <F7A61173-D10D-4092-B3FC-F43F76B8DBAF@gmail.com>



> On Feb 27, 2021, at 1:31 AM, Tobias Oelgarte <tobias.oelgarte at gmail.com> wrote:
> 
>> 
>> No, there is no platform independent and reliable way to get the path to 'app' directory. However you can get location of one of your app's classes through Class.getResource(). See https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from <https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from>
> That isn't helpful at all. All i get is either the URL jrt:/<modulename> or null, but not the installation directory or something similar.

System property? java.home, java.launcher.path, java.library.path, java.class.path

My application indicates a security policy?
-Djava.security.policy=$APPDIR/all.policy

Which actually gets you into the app directory.
-Djava.security.policy=$APPDIR/all.policy

On virtual box Windows showing...
C:\Program Files\HalfPipe\app/all.policy

From tobias.oelgarte at gmail.com  Sat Feb 27 11:51:05 2021
From: tobias.oelgarte at gmail.com (Tobias Oelgarte)
Date: Sat, 27 Feb 2021 12:51:05 +0100
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <F7A61173-D10D-4092-B3FC-F43F76B8DBAF@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>
Message-ID: <0eba1b31-013b-e717-8d38-aafe46c2c8b8@gmail.com>

On 27.02.21 11:22, Michael Hall wrote:
>
>> On Feb 27, 2021, at 1:31 AM, Tobias Oelgarte <tobias.oelgarte at gmail.com> wrote:
>>
>>> No, there is no platform independent and reliable way to get the path to 'app' directory. However you can get location of one of your app's classes through Class.getResource(). See https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from <https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from>
>> That isn't helpful at all. All i get is either the URL jrt:/<modulename> or null, but not the installation directory or something similar.
> System property? java.home, java.launcher.path, java.library.path, java.class.path
>
> My application indicates a security policy?
> -Djava.security.policy=$APPDIR/all.policy
>
> Which actually gets you into the app directory.
> -Djava.security.policy=$APPDIR/all.policy
>
> On virtual box Windows showing...
> C:\Program Files\HalfPipe\app/all.policy

java.home points to the runtime directory, which is fine, but it is 
placed differently on Windows and Linux. In Windows it is 
'AppName/runtime' with app directory 'AppName/app' and under Linux it is 
'AppName/lib/runtime' with app directory 'AppName/app'. So i have to 
query the operating system first, before deciding where the 'app' 
directory would be. Additionally i can't create a *.deb including the 
app folder, because jpackage fails to include the app directory.

java.launcher.path is not available under Linux with JDK 16. Instead i 
would have to use jpackage.app-path.

java.library.path is a list of paths pointing outside of the application 
directory. For example: 
'/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib'

java.class.path is empty in case of a modular application.

Using a security policy file is also an awkward way, to only get the app 
directory. But at least it is doable.


From andy.herrick at oracle.com  Sat Feb 27 13:42:11 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Sat, 27 Feb 2021 08:42:11 -0500
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <0eba1b31-013b-e717-8d38-aafe46c2c8b8@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>
Message-ID: <7b0d4f30-4d17-ee84-bc9c-ea83f9b4eda2@oracle.com>

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

On 2/27/2021 6:51 AM, Tobias Oelgarte wrote:
> On 27.02.21 11:22, Michael Hall wrote:
>>
>>> On Feb 27, 2021, at 1:31 AM, Tobias Oelgarte 
>>> <tobias.oelgarte at gmail.com> wrote:
>>>
>>>> No, there is no platform independent and reliable way to get the 
>>>> path to 'app' directory. However you can get location of one of 
>>>> your app's classes through Class.getResource(). See 
>>>> https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from 
>>>> <https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from> 
>>>>
>>> That isn't helpful at all. All i get is either the URL 
>>> jrt:/<modulename> or null, but not the installation directory or 
>>> something similar.
>> System property? java.home, java.launcher.path, java.library.path, 
>> java.class.path
>>
>> My application indicates a security policy?
>> -Djava.security.policy=$APPDIR/all.policy
>>
>> Which actually gets you into the app directory.
>> -Djava.security.policy=$APPDIR/all.policy
>>
>> On virtual box Windows showing...
>> C:\Program Files\HalfPipe\app/all.policy
>
> java.home points to the runtime directory, which is fine, but it is 
> placed differently on Windows and Linux. In Windows it is 
> 'AppName/runtime' with app directory 'AppName/app' and under Linux it 
> is 'AppName/lib/runtime' with app directory 'AppName/app'. So i have 
> to query the operating system first, before deciding where the 'app' 
> directory would be. Additionally i can't create a *.deb including the 
> app folder, because jpackage fails to include the app directory.
>
> java.launcher.path is not available under Linux with JDK 16. Instead i 
> would have to use jpackage.app-path.
>
> java.library.path is a list of paths pointing outside of the 
> application directory. For example: 
> '/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib'
>
> java.class.path is empty in case of a modular application.
>
> Using a security policy file is also an awkward way, to only get the 
> app directory. But at least it is doable.
>

From mik3hall at gmail.com  Sat Feb 27 14:37:43 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 27 Feb 2021 08:37:43 -0600
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <0eba1b31-013b-e717-8d38-aafe46c2c8b8@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>
Message-ID: <4F5B3CF5-505B-4B08-80CC-764113BB2039@gmail.com>



> On Feb 27, 2021, at 5:51 AM, Tobias Oelgarte <tobias.oelgarte at gmail.com> wrote:
> 
> On 27.02.21 11:22, Michael Hall wrote:
>> 
>>> On Feb 27, 2021, at 1:31 AM, Tobias Oelgarte <tobias.oelgarte at gmail.com> wrote:
>>> 
>>>> No, there is no platform independent and reliable way to get the path to 'app' directory. However you can get location of one of your app's classes through Class.getResource(). See https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from <https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from>
>>> That isn't helpful at all. All i get is either the URL jrt:/<modulename> or null, but not the installation directory or something similar.
>> System property? java.home, java.launcher.path, java.library.path, java.class.path
>> 
> 
> java.library.path is a list of paths pointing outside of the application directory. For example: '/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib?
> 

Andy?s suggestion seems good.

OSX 
java.library.path=/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/MacOS:/Users/mjh/wekafiles/native

Is all internal to the application. I notice it includes app. I?m not quite sure how it picks up the wekafiles/native.




From tobias.oelgarte at gmail.com  Sat Feb 27 17:05:00 2021
From: tobias.oelgarte at gmail.com (Tobias Oelgarte)
Date: Sat, 27 Feb 2021 18:05:00 +0100
Subject: jpackage does not include extra files from app-image when
 creating Debian package?
In-Reply-To: <7b0d4f30-4d17-ee84-bc9c-ea83f9b4eda2@oracle.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>
Message-ID: <d1aff437-3431-59dd-ceaf-c277516d4ba7@gmail.com>

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
>
> On 2/27/2021 6:51 AM, Tobias Oelgarte wrote:
>> On 27.02.21 11:22, Michael Hall wrote:
>>>
>>>> On Feb 27, 2021, at 1:31 AM, Tobias Oelgarte 
>>>> <tobias.oelgarte at gmail.com> wrote:
>>>>
>>>>> No, there is no platform independent and reliable way to get the 
>>>>> path to 'app' directory. However you can get location of one of 
>>>>> your app's classes through Class.getResource(). See 
>>>>> https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from 
>>>>> <https://stackoverflow.com/questions/227486/find-where-java-class-is-loaded-from> 
>>>>>
>>>> That isn't helpful at all. All i get is either the URL 
>>>> jrt:/<modulename> or null, but not the installation directory or 
>>>> something similar.
>>> System property? java.home, java.launcher.path, java.library.path, 
>>> java.class.path
>>>
>>> My application indicates a security policy?
>>> -Djava.security.policy=$APPDIR/all.policy
>>>
>>> Which actually gets you into the app directory.
>>> -Djava.security.policy=$APPDIR/all.policy
>>>
>>> On virtual box Windows showing...
>>> C:\Program Files\HalfPipe\app/all.policy
>>
>> java.home points to the runtime directory, which is fine, but it is 
>> placed differently on Windows and Linux. In Windows it is 
>> 'AppName/runtime' with app directory 'AppName/app' and under Linux it 
>> is 'AppName/lib/runtime' with app directory 'AppName/app'. So i have 
>> to query the operating system first, before deciding where the 'app' 
>> directory would be. Additionally i can't create a *.deb including the 
>> app folder, because jpackage fails to include the app directory.
>>
>> java.launcher.path is not available under Linux with JDK 16. Instead 
>> i would have to use jpackage.app-path.
>>
>> java.library.path is a list of paths pointing outside of the 
>> application directory. For example: 
>> '/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib'
>>
>> java.class.path is empty in case of a modular application.
>>
>> Using a security policy file is also an awkward way, to only get the 
>> app directory. But at least it is doable.
>>

From j.bachorik at gmail.com  Sun Feb 28 16:58:08 2021
From: j.bachorik at gmail.com (Jaroslav Bachorik)
Date: Sun, 28 Feb 2021 17:58:08 +0100
Subject: CFV: New JDK Committer: Adam Sotona
In-Reply-To: <26fb0185-4d7f-f9e5-cce7-e69e2d745b42@oracle.com>
References: <6c1af5f7-6d0d-4972-93db-2f7bb015eea9@oracle.com>
 <26fb0185-4d7f-f9e5-cce7-e69e2d745b42@oracle.com>
Message-ID: <CAJBAvisg5Fyq4r4VaxQ6CHs4t62yx3Gr+Q8TPKmRea8cXnZjGg@mail.gmail.com>

Vote: Yes

-JB-

On Fri, Feb 26, 2021 at 10:53 PM Roger Riggs <roger.riggs at oracle.com> wrote:

> Vote: Yes
>
> On 2/25/21 12:52 PM, Jonathan Gibbons wrote:
> > I hereby nominate Adam Sotona to JDK Committer.
>
>