From attila.kelemen85 at gmail.com Sun May 1 22:04:09 2022 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Mon, 2 May 2022 00:04:09 +0200 Subject: JEP 425 (Virtual Threads) - Cancellation Message-ID: Hi, Since the virtual threads API is currently incubating, I do support that it should be released (as incubating in Java 19). However, I would like to propose that a better, more robust cancellation mechanism is to be provided with it (as some kind of companion JEP) in future releases before the non-incubating release. I've always considered the interrupt based cancellation to be very fragile for various reasons, and I think that the new virtual thread release would be a very safe time to fix the lack of proper cancellation mechanism in Java. If it is not fixed before the official release of this JEP, then I fear that it is less likely to be fixed, due to more compatibility issues. Or if a new cancellation mechanism will not be released with it, then at least define the way it is planned to be added in the future to ensure that there won't be any issues adding it later. The only document I have found referring to this topic was: https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html but it doesn't attempt to address it. While the cheapness of virtual threads does somewhat solve the issue of canceling only subtasks by allowing me to start a virtual thread with little cost, and interrupt it separately, it does not solve other issues. One big pain of mine is that blocking I/O is often uninterruptible (and not even cancelable by other means), and as far as I understand, this won't change. One solution would be of course is to allow providing the virtual threads a cancellation token upon creation, and let the virtual thread scheduler to throw a `VirtualThreadCancelledException` (or something similar) in some well defined cases (definitely not just at any safepoint). Of course, this exception has to be unchecked, and preferably not extend `Exception` to avoid people wrapping it left and right. With this the current interruption mechanism could be deprecated as well. Can we expect a similar cancellation mechanism to be considered? Thanks, Attila From david.holmes at oracle.com Mon May 2 05:17:28 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 2 May 2022 15:17:28 +1000 Subject: JEP 425 (Virtual Threads) - Cancellation In-Reply-To: References: Message-ID: On 2/05/2022 8:04 am, Attila Kelemen wrote: > Hi, > > Since the virtual threads API is currently incubating, I do support that > it should be released (as incubating in Java 19). However, I would > like to propose that a better, more robust cancellation mechanism is to > be provided with it (as some kind of companion JEP) in future releases > before the non-incubating release. > > I've always considered the interrupt based cancellation to be very fragile > for various reasons, and I think that the new virtual thread release would > be a very safe time to fix the lack of proper cancellation mechanism in > Java. If it is not fixed before the official release of this JEP, then I fear > that it is less likely to be fixed, due to more compatibility issues. Or if a > new cancellation mechanism will not be released with it, then at least > define the way it is planned to be added in the future to ensure that there > won't be any issues adding it later. The only document I have found > referring to this topic was: > https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html > but it doesn't attempt to address it. > > While the cheapness of virtual threads does somewhat solve the issue > of canceling only subtasks by allowing me to start a virtual thread with little > cost, and interrupt it separately, it does not solve other issues. One big > pain of mine is that blocking I/O is often uninterruptible (and not even > cancelable by other means), and as far as I understand, this won't change. The issue with interruptible I/O has little to do with the interrupt-mechanism per-se. While traditional thread use of blocking I/O operations can not be "interrupted" this is because the underlying I/O primitives do not support cancellation. With virtual threads using non-blocking I/O operations under the covers it would be trivial to provide a means to unblock threads blocked on I/O - but that is the not hard part of "interruptible I/O". The hard part is "what does cancelling an I/O operation do to the underlying file/stream/device?". When the NIO API's were introduced they had to consider this question when InterruptibleChannels were defined - and the answer was "interrupting a thread blocked on a channel I/O operation closes the channel". It was the only reasonably sane thing to do. So the issue with interruptible I/O is not the interrupt mechanism as such, nor the use of platform versus virtual threads, but whether the I/O API actually supports a model of cancellation itself - which the core API's (non-NIO) do not.** **InterruptibleIOException was a failed attempt to provide this but it only handled the unblocking of the thread, not the effects on the underlying I/O object. And it could only be implemented on platforms that provided a low-level I/O cancellation mechanism - which was only Solaris at the time. I think Loom's "structured concurrency" (future JEP) may provide more support in this area but I'll let the Loom folk speak to that. Cheers, David > One solution would be of course is to allow providing the virtual threads > a cancellation token upon creation, and let the virtual thread scheduler to > throw a `VirtualThreadCancelledException` (or something similar) in some > well defined cases (definitely not just at any safepoint). Of course, this > exception has to be unchecked, and preferably not extend `Exception` > to avoid people wrapping it left and right. With this the current interruption > mechanism could be deprecated as well. > > Can we expect a similar cancellation mechanism to be considered? > > Thanks, > Attila From Alan.Bateman at oracle.com Mon May 2 07:42:14 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 May 2022 08:42:14 +0100 Subject: JEP 425 (Virtual Threads) - Cancellation In-Reply-To: References: Message-ID: On 01/05/2022 23:04, Attila Kelemen wrote: > While the cheapness of virtual threads does somewhat solve the issue > of canceling only subtasks by allowing me to start a virtual thread with little > cost, and interrupt it separately, it does not solve other issues. One big > pain of mine is that blocking I/O is often uninterruptible (and not even > cancelable by other means), and as far as I understand, this won't change. Search for the sentence "To allow for interruption and cancellation, the blocking I/O methods ..." in the Networking section of the JEP as it deals with this topic. > One solution would be of course is to allow providing the virtual threads > a cancellation token upon creation, and let the virtual thread scheduler to > throw a `VirtualThreadCancelledException` (or something similar) in some > well defined cases (definitely not just at any safepoint). Of course, this > exception has to be unchecked, and preferably not extend `Exception` > to avoid people wrapping it left and right. With this the current interruption > mechanism could be deprecated as well. > > Can we expect a similar cancellation mechanism to be considered? As David said, this is more in the area of the (still in draft) Structured Concurrency JEP. There have been several prototypes that explored the cancellation space. The draft JEP has an explicit non-goal to provide a new cancellation mechanism but leaves the door open to re-visiting in a future JEP. -Alan From attila.kelemen85 at gmail.com Mon May 2 09:15:52 2022 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Mon, 2 May 2022 11:15:52 +0200 Subject: JEP 425 (Virtual Threads) - Cancellation In-Reply-To: References: Message-ID: Alan Bateman ezt ?rta (id?pont: 2022. m?j. 2., H, 9:42): > > Search for the sentence "To allow for interruption and cancellation, the > blocking I/O methods ..." in the Networking section of the JEP as it > deals with this topic. That part seems to be only about sockets, while I would like to see the other most common I/O operations to address the problem. Sure, as David mentioned in a previous email, it is not a trivial change (I'm not even proposing that this JEP should include it, just that this would be a good time to release a cancellation JEP building on this virtual thread JEP), but still the current state is a major inconvenience. In fact, I just recently learned that, there can be a scenario where if you block on an `InputStream` (stdout/stderr of started process) of a started `Process`, then you will be trapped in the blocking call forever (even destroy/destroyForcibly of the process won't help), unless you steal and close the underlying `FileChannel` via reflection. > As David said, this is more in the area of the (still in draft) > Structured Concurrency JEP. There have been several prototypes that > explored the cancellation space. The draft JEP has an explicit non-goal > to provide a new cancellation mechanism but leaves the door open to > re-visiting in a future JEP. I looked up the Structured Concurrency JEP, but the only one I have found is this draft: https://openjdk.java.net/jeps/8277129 However, this explicitly states that it will not address the current cancellation issues. That is, there are a lot of blocking APIs not declaring a thrown `InterruptedException`, and as far as I can see a JEP addressing cancellation should consider these cases as well. Can you point me to JEPs / discussion where cancellation issues were / are being considered? Thanks, Attila From xueleifan at tencent.com Mon May 2 15:12:14 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 2 May 2022 15:12:14 +0000 Subject: Interesting in DTLS 1.3 Message-ID: <15CAF7B8-A506-4105-91DE-8B6D65A5E6D5@Tencent.Com> Hi, The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 (DTLS 1.3) has been published on April 2022. The specification describes the most current version of the DTLS protocol as a delta from TLS 1.3 and obsoletes DTLS 1.2. In JDK, the Java specifications for DTLS 1.0 and DTLS 1.2 are defined and implemented. For DTLS 1.3, there may be three different choices for JDK. The 1st one is doing nothing, and JDK will not support DTLS 1.3 in the future. The 2nd one is define the specification in JDK, but without the implementation. Third party?s provider could have the implementation if this feature is required in some circumstances. The 3rd one, as DTLS 1.0 and DTLS 1.2, is to have an implementation in JDK. Are you using DTLS protocols in your applications? Is anyone interested in have DTLS 1.3 in JDK? Which option is best for you? Thanks, Xuelei From alex.buckley at oracle.com Mon May 2 16:32:01 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 2 May 2022 09:32:01 -0700 Subject: JEP 425 (Virtual Threads) - Cancellation In-Reply-To: References: Message-ID: <9d56c689-b3fc-c18f-84c8-fb53ac9b5de6@oracle.com> On 5/1/2022 3:04 PM, Attila Kelemen wrote: > Since the virtual threads API is currently incubating, I do support that > it should be released (as incubating in Java 19). Virtual Threads are proposed as a preview API in Java 19, not an incubating API. Preview APIs live in java.* packages and are much more mature than incubating APIs, which live in jdk.incubator.* packages. The incubating API you may have seen recently is the Vector API. See https://openjdk.java.net/projects/jdk/19/ Alex From hboehm at google.com Mon May 2 23:25:23 2022 From: hboehm at google.com (Hans Boehm) Date: Mon, 2 May 2022 16:25:23 -0700 Subject: Finalization "interaction with memory model" (12.6.2) Message-ID: It seems like once a year or so, I try to decode https://docs.oracle.com/javase/specs/jls/se18/html/jls-12.html#jls-12.6.2 There seem to be two particularly confusing consecutive paragraphs here, in a confusing section. I always seem to get stuck here. Arbitrarily picking on the second one: An object B is definitely reachable from A at di if there is a write w1 to an element v of A such that the value written by w1 is a reference to B and there does not exist a write w2 to v such that hb(w2, w1) is not true and both w1 and w2 come-before di. I always have trouble parsing this. I think it's because the syntactic position of "both w1 and w2 come-before di" suggests it's a constraint on w2 (which must not exist), but in fact half of it is a constraint on w1, which must exist. I don't think we normally mix up mathematical constraints this way. Could we possibly rephrase this as something like: An object B is definitely reachable from A at di if: a) There is a write w1 to an element v of A such that the value written by w1 is a reference to B, and w1 comes-before di. b) There does not exist a write that might overwrite w1 before di. That is, there does not exist a write w2 to v such that hb(w2, w1) is false and w2 also comes-before di. ? This is unfortunately longer. But I think the intended meaning is the same. And my current feeling is that I might still be able to parse this next year, without having to again spend time decoding it. I think the preceding paragraph could use essentially the same treatment. Hans From alex.buckley at oracle.com Tue May 3 00:05:49 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 2 May 2022 17:05:49 -0700 Subject: Finalization "interaction with memory model" (12.6.2) In-Reply-To: References: Message-ID: The JSR 133 spec available from jcp.org as Proposed Final Draft 2 is fractionally clearer than JLS 12.6.2 because of a comma before the "both w1 and w2" clause: ----- An object B is definitely reachable from A at di if there is a write w1 to an element v of A such that the value written by w1 is a reference to B and there does not exist a write w2 to v s.t. ?(w2 ==hb==> w1), and both w1 and w2 come-before di. ----- (The PFD2 document is dated May 28, 2004; I have a version dated August 24, 2004 with slightly different section numbering, though the text above is identical. I do not remember where I obtained it from.) The proposal below is an improvement because of its "might overwrite" narration, but the treatment of (the non-existent) w2 is still confusing. If I was spending time on it, I would try very hard to find an hb(...) clause that is true rather than false. However, 12.6.2 is slated for removal when finalization is removed, so it's not a priority. Alex On 5/2/2022 4:25 PM, Hans Boehm wrote: > It seems like once a year or so, I try to decode > https://docs.oracle.com/javase/specs/jls/se18/html/jls-12.html#jls-12.6.2 > > There seem to be two particularly confusing consecutive paragraphs here, in > a confusing section. I always seem to get stuck here. Arbitrarily picking > on the second one: > > An object B is definitely reachable from A at di if there is a write w1 to > an element v of A such that the value written by w1 is a reference to B and > there does not exist a write w2 to v such that hb(w2, w1) is not true and > both w1 and w2 come-before di. > > I always have trouble parsing this. I think it's because the syntactic > position of "both w1 and w2 come-before di" suggests it's a constraint on > w2 (which must not exist), but in fact half of it is a constraint on w1, > which must exist. I don't think we normally mix up mathematical constraints > this way. > > Could we possibly rephrase this as something like: > > An object B is definitely reachable from A at di if: > a) There is a write w1 to an element v of A such that the value written by > w1 is a reference to B, and w1 comes-before di. > b) There does not exist a write that might overwrite w1 before di. That is, > there does not exist a write w2 to v such that hb(w2, w1) is false and w2 > also comes-before di. > > ? > > This is unfortunately longer. But I think the intended meaning is the same. > And my current feeling is that I might still be able to parse this next > year, without having to again spend time decoding it. > > I think the preceding paragraph could use essentially the same treatment. > > Hans From david.holmes at oracle.com Tue May 3 00:48:30 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 May 2022 10:48:30 +1000 Subject: JEP 425 (Virtual Threads) - Cancellation In-Reply-To: References: Message-ID: <1df05e83-3451-a978-bc8b-701c944a8857@oracle.com> On 2/05/2022 7:15 pm, Attila Kelemen wrote: > Alan Bateman ezt ?rta (id?pont: 2022. m?j. > 2., H, 9:42): >> >> Search for the sentence "To allow for interruption and cancellation, the >> blocking I/O methods ..." in the Networking section of the JEP as it >> deals with this topic. > > That part seems to be only about sockets, while I would like to see the other > most common I/O operations to address the problem. Sure, as David mentioned > in a previous email, it is not a trivial change (I'm not even > proposing that this JEP > should include it, just that this would be a good time to release a cancellation > JEP building on this virtual thread JEP), but still the current state is a major > inconvenience. In fact, I just recently learned that, there can be a > scenario where > if you block on an `InputStream` (stdout/stderr of started process) of a started > `Process`, then you will be trapped in the blocking call forever (even > destroy/destroyForcibly of the process won't help), unless you steal and close > the underlying `FileChannel` via reflection. On the surface that seems like a bug in the Process API. Termination of the child process should be detected and the captured streams closed. David >> As David said, this is more in the area of the (still in draft) >> Structured Concurrency JEP. There have been several prototypes that >> explored the cancellation space. The draft JEP has an explicit non-goal >> to provide a new cancellation mechanism but leaves the door open to >> re-visiting in a future JEP. > > I looked up the Structured Concurrency JEP, but the only one I have found > is this draft: https://openjdk.java.net/jeps/8277129 However, this explicitly > states that it will not address the current cancellation issues. That is, there > are a lot of blocking APIs not declaring a thrown `InterruptedException`, and > as far as I can see a JEP addressing cancellation should consider these > cases as well. Can you point me to JEPs / discussion where cancellation > issues were / are being considered? > > > Thanks, > Attila From hboehm at google.com Tue May 3 05:00:51 2022 From: hboehm at google.com (Hans Boehm) Date: Mon, 2 May 2022 22:00:51 -0700 Subject: Finalization "interaction with memory model" (12.6.2) In-Reply-To: References: Message-ID: On Mon, May 2, 2022 at 5:05 PM Alex Buckley wrote: > ... > > The proposal below is an improvement because of its "might overwrite" > narration, but the treatment of (the non-existent) w2 is still > confusing. If I was spending time on it, I would try very hard to find > an hb(...) clause that is true rather than false. However, 12.6.2 is > slated for removal when finalization is removed, so it's not a priority. > I'm very surprised by that last statement. This section is phrased in terms of finalization since, AFAIK, the JLS doesn't talk about References. But the problem it addresses is not at all specific to finalization; it's basically the same for PhantomReferences and thus Cleaners. As far as I can tell, there are basically two options here, with or without finalization: 1) Keep some version of this text, or 2) Provide reachability guarantees only through reachabilityFence(), allowing references to be cleared immediately for code that doesn't use reachabilityFence(), and thus clearly breaking all code that uses References or Cleaners without reachabilityFence. I actually think (2) is a lot cleaner, and I personally wouldn't object to it, but it seems like a rather dramatic change that's not really tied to finalizers. And to be honest, I wouldn't have expected it to fly. Hans From alex.buckley at oracle.com Tue May 3 06:04:45 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 2 May 2022 23:04:45 -0700 Subject: [External] : Re: Finalization "interaction with memory model" (12.6.2) In-Reply-To: References: Message-ID: <4f9df8ed-96ea-2df3-9f96-a0b5bf959d77@oracle.com> On 5/2/2022 10:00 PM, Hans Boehm wrote: > On Mon, May 2, 2022 at 5:05 PM Alex Buckley > wrote: > > The proposal below is an improvement because of its "might overwrite" > narration, but the treatment of (the non-existent) w2 is still > confusing. If I was spending time on it, I would try very hard to find > an hb(...) clause that is true rather than false. However, 12.6.2 is > slated for removal when finalization is removed, so it's not a priority. > > I'm very surprised by that last statement. This section is phrased > in terms of finalization since, AFAIK, the JLS doesn't talk about > References. But the problem it addresses is not at all specific to > finalization; it's basically the same for PhantomReferences and thus > Cleaners. > > As far as I can tell, there are basically two options here, with or without > finalization: > > 1) Keep some version of this text, or > 2) Provide reachability guarantees only through reachabilityFence(), > allowing references to be cleared immediately for code that doesn't > use reachabilityFence(), and thus clearly breaking all code that uses > References or Cleaners without reachabilityFence. > > I actually think (2) is a lot cleaner, and I personally wouldn't > object to it, but it seems like a rather dramatic change that's not > really tied to finalizers. And to be honest, I wouldn't have expected > it to fly. It may be that removing finalization will require more resources to look at JLS 12.6 and figure out if it has JMM rules which need to be kept in some fashion. However, removing finalization isn't on the cards for 19, so it's not an immediate priority. Alex From roger.riggs at oracle.com Tue May 3 13:40:51 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 3 May 2022 09:40:51 -0400 Subject: JEP 425 (Virtual Threads) - Cancellation In-Reply-To: <1df05e83-3451-a978-bc8b-701c944a8857@oracle.com> References: <1df05e83-3451-a978-bc8b-701c944a8857@oracle.com> Message-ID: Hi, It might be worth filing a separate issue on the Process API issue. Note that the Process stream implementations take pains to NOT close the streams until the parent has a chance to read any pending input. When the process dies the OS should close the stream from the child side, causing? EOF to the parent. But there may be more to look at there. Regards, Roger On 02/05/2022 20:48, David Holmes wrote: >> >> That part seems to be only about sockets, while I would like to see >> the other >> most common I/O operations to address the problem. Sure, as David >> mentioned >> in a previous email, it is not a trivial change (I'm not even >> proposing that this JEP >> should include it, just that this would be a good time to release a >> cancellation >> JEP building on this virtual thread JEP), but still the current state >> is a major >> inconvenience. In fact, I just recently learned that, there can be a >> scenario where >> if you block on an `InputStream` (stdout/stderr of started process) >> of a started >> `Process`, then you will be trapped in the blocking call forever (even >> destroy/destroyForcibly of the process won't help), unless you steal >> and close >> the underlying `FileChannel` via reflection. > > On the surface that seems like a bug in the Process API. Termination > of the child process should be detected and the captured streams closed. > > David From Alan.Bateman at oracle.com Wed May 4 13:43:33 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2022 14:43:33 +0100 Subject: JEP 425 will attempt to integrate this weekend, can we hold off on integrating other big changes until next week? Message-ID: Committers, JEP 425 is currently proposed to target JDK 19. If targeted on Friday, and no blocking issues come up this week, then we'll attempt to integrate over the weekend (May 7/8). This is a big integration and the openjdk/jdk repo is a moving target. It would be unfortunate if a "refactor the world" commit, or something that required significant re-work, were to integrate ahead of this JEP.? We are doing merging + testing each day but we need something that is nearly final by Friday so as to leave time to run long running stress tests on the merged bits. Is anyone planning to integrate (or sponsor) any big changes in the next few days that might significantly conflict with the changes in this JEP? It's non-trivial changes in the runtime + GC areas that are most likely to conflict. If so, would it be possible to hold off until next week so as to improve our chances of getting this feature in? Thank you, -Alan From mark.reinhold at oracle.com Wed May 4 22:15:22 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 4 May 2022 15:15:22 -0700 (PDT) Subject: JEP proposed to target JDK 19: 424: Foreign Function & Memory API (Preview) Message-ID: <20220504221522.B4180535CCC@eggemoggin.niobe.net> The following JEP is proposed to target JDK 19: 424: Foreign Function & Memory API (Preview) https://openjdk.java.net/jeps/424 Summary: Introduce an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI. This is a preview 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 Wednesday, 11 May, 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 19. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Fri May 6 00:11:44 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 05 May 2022 17:11:44 -0700 Subject: JEP proposed to target JDK 19: 425: Virtual Threads (Preview) In-Reply-To: <20220428184623.CFA6A535243@eggemoggin.niobe.net> References: <20220428184623.CFA6A535243@eggemoggin.niobe.net> Message-ID: <20220505171144.420457718@eggemoggin.niobe.net> 2022/4/28 11:46:23 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 19: > > 425: Virtual Threads (Preview) > https://openjdk.java.net/jeps/425 > > Summary: Introduce virtual threads to the Java Platform. Virtual > threads are lightweight threads that dramatically reduce the effort > of writing, maintaining, and observing high-throughput concurrent > applications. This is a preview 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, 5 May, 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 19. Hearing no objections, I?ve targeted this JEP to JDK 19. - Mark From tobias.hartmann at oracle.com Fri May 6 08:56:40 2022 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 6 May 2022 10:56:40 +0200 Subject: CFV: New JDK Committer: Tobias Holenstein Message-ID: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Hi, I hereby nominate Tobias Holenstein to JDK Committer. Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel and High Performance Computing and Compiler Design. Some of his project work included parallel algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae Votes are due by Friday, 20 May 2022 at 09:00 UTC. 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, Tobias [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein [2] https://openjdk.java.net/census [3] https://openjdk.java.net/projects/#committer-vote From tobias.hartmann at oracle.com Fri May 6 08:56:51 2022 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 6 May 2022 10:56:51 +0200 Subject: CFV: New JDK Committer: Emanuel Peter Message-ID: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Hi, I hereby nominate Emanuel Peter to JDK Committer. Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. At ETH, Emanuel did significant study and project work with system-level technologies with a focus on algorithms and performance including High Performance Computing. Some of his project work included C++ and Python development for distributed applications. Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 Votes are due by Friday, 20 May 2022 at 09:00 UTC. 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, Tobias [1] https://github.com/openjdk/jdk/commits?author=eme64 [2] https://openjdk.java.net/census [3] https://openjdk.java.net/projects/#committer-vote From tobias.hartmann at oracle.com Fri May 6 08:57:29 2022 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 6 May 2022 10:57:29 +0200 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: Vote: Yes. Best regards, Tobias On 06.05.22 10:56, Tobias Hartmann wrote: > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From tobias.hartmann at oracle.com Fri May 6 08:57:40 2022 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 6 May 2022 10:57:40 +0200 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: <0f216b94-81bc-32d6-266a-a9d2e5efad2d@oracle.com> Vote: Yes. Best regards, Tobias On 06.05.22 10:56, Tobias Hartmann wrote: > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From roberto.castaneda.lozano at oracle.com Fri May 6 09:35:16 2022 From: roberto.castaneda.lozano at oracle.com (=?UTF-8?Q?Roberto_Casta=c3=b1eda_Lozano?=) Date: Fri, 6 May 2022 11:35:16 +0200 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: Vote: yes On 2022-05-06 10:56, Tobias Hartmann wrote: > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From roberto.castaneda.lozano at oracle.com Fri May 6 09:37:05 2022 From: roberto.castaneda.lozano at oracle.com (=?UTF-8?Q?Roberto_Casta=c3=b1eda_Lozano?=) Date: Fri, 6 May 2022 11:37:05 +0200 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: Vote: yes On 2022-05-06 10:56, Tobias Hartmann wrote: > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From harold.seigel at oracle.com Fri May 6 13:11:59 2022 From: harold.seigel at oracle.com (Harold Seigel) Date: Fri, 6 May 2022 09:11:59 -0400 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: <935766a5-1a29-c7e5-0650-a13be3115baa@oracle.com> Vote: Yes Harold On 5/6/2022 4:56 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From harold.seigel at oracle.com Fri May 6 13:12:19 2022 From: harold.seigel at oracle.com (Harold Seigel) Date: Fri, 6 May 2022 09:12:19 -0400 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: Vote: Yes Harold On 5/6/2022 4:56 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From eric.caspole at oracle.com Fri May 6 13:41:52 2022 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Fri, 6 May 2022 09:41:52 -0400 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: Vote: yes Eric On 5/6/22 4:56 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From eric.caspole at oracle.com Fri May 6 13:45:39 2022 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Fri, 6 May 2022 09:45:39 -0400 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: <1d84e677-b8cf-2c4e-1242-2b0b3ec724fe@oracle.com> Vote: yes Eric On 5/6/22 4:56 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From jesper.wilhelmsson at oracle.com Fri May 6 14:10:32 2022 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 6 May 2022 14:10:32 +0000 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: <23F80000-6735-4E1F-85D9-456708C7C81B@oracle.com> Vote: Yes /Jesper > On 6 May 2022, at 10:56, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From roger.riggs at oracle.com Fri May 6 14:13:21 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 6 May 2022 10:13:21 -0400 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: Vote: Yes On 06/05/2022 04:56, Tobias Hartmann wrote: > I hereby nominate Tobias Holenstein to JDK Committer. From roger.riggs at oracle.com Fri May 6 14:14:36 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 6 May 2022 10:14:36 -0400 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: <6b8cf001-6abd-8502-9d87-9ff34179ea01@oracle.com> Vote: Yes On 06/05/2022 04:56, Tobias Hartmann wrote: > I hereby nominate Emanuel Peter to JDK Committer. From jesper.wilhelmsson at oracle.com Fri May 6 14:14:44 2022 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 6 May 2022 14:14:44 +0000 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: <66558055-0730-4EA9-A5D8-7CBFFCF2489F@oracle.com> Vote: Yes /Jesper > On 6 May 2022, at 10:56, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From daniel.fuchs at oracle.com Fri May 6 16:02:00 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 6 May 2022 17:02:00 +0100 Subject: CFV: New JDK Reviewer: Jaikiran Pai Message-ID: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Hi, I hereby nominate Jaikiran Pai [1] to JDK Reviewer. Jaikiran is a member of the Java Core Libraries team at Oracle and has already contributed 63 changesets [2] to the openjdk repository. More importantly Jaikiran has helped reviewing many PRs where his reviews have been both helpful and very thorough Votes are due by 17:00 UTC May 20th, 2022. Only current JDK Reviewers [3] 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 [4]. Best regards, -- daniel [1] https://openjdk.java.net/census#jpai [2] https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits [3] http://openjdk.java.net/census [4] http://openjdk.java.net/bylaws#lazy-consensus From chegar999 at gmail.com Fri May 6 16:03:22 2022 From: chegar999 at gmail.com (Chris Hegarty) Date: Fri, 6 May 2022 17:03:22 +0100 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <09eb004e-f5da-6fb9-0ab8-ad68ce237e11@gmail.com> Vote: YES. -Chris. On 06/05/2022 17:02, Daniel Fuchs wrote: > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > From lance.andersen at oracle.com Fri May 6 16:05:03 2022 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 6 May 2022 16:05:03 +0000 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <1176F1EA-1E4C-42CE-B472-AFE436A61B02@oracle.com> Vote: Yes On May 6, 2022, at 12:02 PM, Daniel Fuchs > wrote: Hi, I hereby nominate Jaikiran Pai [1] to JDK Reviewer. Jaikiran is a member of the Java Core Libraries team at Oracle and has already contributed 63 changesets [2] to the openjdk repository. More importantly Jaikiran has helped reviewing many PRs where his reviews have been both helpful and very thorough Votes are due by 17:00 UTC May 20th, 2022. Only current JDK Reviewers [3] 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 [4]. Best regards, -- daniel [1] https://openjdk.java.net/census#jpai [2] https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits [3] http://openjdk.java.net/census [4] http://openjdk.java.net/bylaws#lazy-consensus [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Fri May 6 16:05:09 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 May 2022 17:05:09 +0100 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: yes From brian.burkhalter at oracle.com Fri May 6 16:06:09 2022 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 6 May 2022 16:06:09 +0000 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: yes On May 6, 2022, at 9:02 AM, Daniel Fuchs > wrote: I hereby nominate Jaikiran Pai [1] to JDK Reviewer. From adinn at redhat.com Fri May 6 16:06:10 2022 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 6 May 2022 17:06:10 +0100 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: yes On 06/05/2022 17:02, Daniel Fuchs wrote: > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > > Jaikiran is a member of the Java Core Libraries team at > Oracle and has already contributed 63 changesets [2] > to the openjdk repository. More importantly Jaikiran has > helped reviewing many PRs where his reviews have been both > helpful and very thorough > > Votes are due by 17:00 UTC May 20th, 2022. > > Only current JDK Reviewers [3] 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 [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#jpai > [2] > https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits > > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus > -- 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 vladimir.kozlov at oracle.com Fri May 6 16:06:15 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 6 May 2022 09:06:15 -0700 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: Vote: yes Thanks, Vladimir K On 5/6/22 1:56 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From vladimir.kozlov at oracle.com Fri May 6 16:07:05 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 6 May 2022 09:07:05 -0700 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: Vote: yes Thanks, Vladimir K On 5/6/22 1:56 AM, Tobias Hartmann wrote: > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From sean.coffey at oracle.com Fri May 6 16:08:01 2022 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 6 May 2022 17:08:01 +0100 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <6dc9dc5e-f3e5-e3c8-b125-f7a22cf28682@oracle.com> Vote: yes regards, Sean. On 06/05/2022 17:02, Daniel Fuchs wrote: > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > > Jaikiran is a member of the Java Core Libraries team at > Oracle and has already contributed 63 changesets [2] > to the openjdk repository. More importantly Jaikiran has > helped reviewing many PRs where his reviews have been both > helpful and very thorough > > Votes are due by 17:00 UTC May 20th, 2022. > > Only current JDK Reviewers [3] 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 [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#jpai > [2] > https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus > From naoto.sato at oracle.com Fri May 6 16:12:53 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 6 May 2022 09:12:53 -0700 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: yes Naoto From sgehwolf at redhat.com Fri May 6 16:21:22 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 06 May 2022 18:21:22 +0200 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: yes. On Fri, 2022-05-06 at 17:02 +0100, Daniel Fuchs wrote: > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. From roger.riggs at oracle.com Fri May 6 16:23:21 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 6 May 2022 12:23:21 -0400 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <26b6e9f8-6800-3b0d-09ce-10b1c5a14da0@oracle.com> Vote: Yes On 06/05/2022 12:02, Daniel Fuchs wrote: > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. From daniel.daugherty at oracle.com Fri May 6 16:24:19 2022 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 6 May 2022 12:24:19 -0400 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <71dae394-135d-a391-74e5-dd3409df9a6e@oracle.com> Vote: yes Dan On 5/6/22 12:02 PM, Daniel Fuchs wrote: > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > > Jaikiran is a member of the Java Core Libraries team at > Oracle and has already contributed 63 changesets [2] > to the openjdk repository. More importantly Jaikiran has > helped reviewing many PRs where his reviews have been both > helpful and very thorough > > Votes are due by 17:00 UTC May 20th, 2022. > > Only current JDK Reviewers [3] 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 [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#jpai > [2] > https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus > From joe.darcy at oracle.com Fri May 6 16:24:56 2022 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 6 May 2022 09:24:56 -0700 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <6200010e-0c18-1df3-3728-f1ff599f9066@oracle.com> Vote: yes -Joe On 5/6/2022 9:02 AM, Daniel Fuchs wrote: > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > > Jaikiran is a member of the Java Core Libraries team at > Oracle and has already contributed 63 changesets [2] > to the openjdk repository. More importantly Jaikiran has > helped reviewing many PRs where his reviews have been both > helpful and very thorough > > Votes are due by 17:00 UTC May 20th, 2022. > > Only current JDK Reviewers [3] 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 [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#jpai > [2] > https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus > From mandy.chung at oracle.com Fri May 6 16:44:57 2022 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 May 2022 09:44:57 -0700 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <3d7b42fb-c3a2-0c83-e618-c1b8f3a81be7@oracle.com> Vote: yes Mandy From vladimir.x.ivanov at oracle.com Fri May 6 18:00:45 2022 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2022 11:00:45 -0700 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: <4732492e-efda-5d82-6c11-fd64c6132809@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 5/6/22 01:56, Tobias Hartmann wrote: > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From vladimir.x.ivanov at oracle.com Fri May 6 18:01:11 2022 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2022 11:01:11 -0700 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 5/6/22 01:56, Tobias Hartmann wrote: > I hereby nominate Emanuel Peter to JDK Committer. From weijun.wang at oracle.com Fri May 6 18:44:10 2022 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Fri, 6 May 2022 18:44:10 +0000 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: YES --weijun > On May 6, 2022, at 12:02 PM, Daniel Fuchs wrote: > > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > > Jaikiran is a member of the Java Core Libraries team at > Oracle and has already contributed 63 changesets [2] > to the openjdk repository. More importantly Jaikiran has > helped reviewing many PRs where his reviews have been both > helpful and very thorough > > Votes are due by 17:00 UTC May 20th, 2022. > > Only current JDK Reviewers [3] 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 [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#jpai > [2] https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus > From brent.christian at oracle.com Fri May 6 18:45:41 2022 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 6 May 2022 11:45:41 -0700 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <57e9879f-fd95-ec79-7f9a-144c48da915c@oracle.com> Vote: Yes On 5/6/22 9:02 AM, Daniel Fuchs wrote: > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > From stuart.marks at oracle.com Fri May 6 19:30:12 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 6 May 2022 12:30:12 -0700 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <27422555-ba52-ede1-e1c6-56e868bed960@oracle.com> Vote: yes On 5/6/22 9:02 AM, Daniel Fuchs wrote: > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > > Jaikiran is a member of the Java Core Libraries team at > Oracle and has already contributed 63 changesets [2] > to the openjdk repository. More importantly Jaikiran has > helped reviewing many PRs where his reviews have been both > helpful and very thorough > > Votes are due by 17:00 UTC May 20th, 2022. > > Only current JDK Reviewers [3] 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 [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#jpai > [2] > https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits > > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus > From lihuaming3 at huawei.com Sat May 7 00:51:33 2022 From: lihuaming3 at huawei.com (lihuaming (A)) Date: Sat, 7 May 2022 00:51:33 +0000 Subject: =?utf-8?B?562U5aSNOiBOZXcgSkRLIFJldmlld2VyOiBKYWlraXJhbiBQYWk=?= In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: yes Hamlin -----????----- ???: jdk-dev [mailto:jdk-dev-retn at openjdk.java.net] ?? Daniel Fuchs ????: 2022?5?7? 0:02 ???: jdk-dev ??: CFV: New JDK Reviewer: Jaikiran Pai Hi, I hereby nominate Jaikiran Pai [1] to JDK Reviewer. Jaikiran is a member of the Java Core Libraries team at Oracle and has already contributed 63 changesets [2] to the openjdk repository. More importantly Jaikiran has helped reviewing many PRs where his reviews have been both helpful and very thorough Votes are due by 17:00 UTC May 20th, 2022. Only current JDK Reviewers [3] 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 [4]. Best regards, -- daniel [1] https://openjdk.java.net/census#jpai [2] https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits [3] http://openjdk.java.net/census [4] http://openjdk.java.net/bylaws#lazy-consensus From johnsjiang at tencent.com Sat May 7 01:44:40 2022 From: johnsjiang at tencent.com (=?utf-8?B?am9obnNqaWFuZyjmsZ/ojo4p?=) Date: Sat, 7 May 2022 01:44:40 +0000 Subject: CFV: New JDK Reviewer: Jaikiran Pai Message-ID: Vote: yes Best regards, John Jiang ?? 2022/5/7 ??12:03??jdk-dev ?? Daniel Fuchs? ??: Hi, I hereby nominate Jaikiran Pai [1] to JDK Reviewer. Jaikiran is a member of the Java Core Libraries team at Oracle and has already contributed 63 changesets [2] to the openjdk repository. More importantly Jaikiran has helped reviewing many PRs where his reviews have been both helpful and very thorough Votes are due by 17:00 UTC May 20th, 2022. Only current JDK Reviewers [3] 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 [4]. Best regards, -- daniel [1] https://openjdk.java.net/census#jpai [2] https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits [3] http://openjdk.java.net/census [4] http://openjdk.java.net/bylaws#lazy-consensus From juriad at gmail.com Sat May 7 13:58:24 2022 From: juriad at gmail.com (Adam Juraszek) Date: Sat, 7 May 2022 15:58:24 +0200 Subject: TemplatedString feedback and extension - logging use-case, lazy values, blocks Message-ID: The TemplatedString proposal is amazing; I can see using it in many places. I have a few comments that I have not seen addressed. Logging ======= One place where some kind of string templating is often used is logging. Most logging frameworks use a pair of braces {}. TemplatedStrings have the potential to revolutionize it. Log record usually consists of the following parts that the programmer needs to provide: * log level (such as error, info) * message (such as "Oh no, the value {} is negative") * parameters (such as -42) * exception/throwable (only sometimes) Let's assume that TemplatedString is performant and virtually free, then these options would be possible. I cannot say which syntax the logging frameworks would choose: logger.error."Oh no, the value \{value} is negative\{ex}"; logger.error("Oh no, the value \{value} is negative", ex); logger."Oh no, the value \{value} is negative".error(ex); Versus the existing: logger.error("Oh no, the value {} is negative", value, ex); Lazy Logging ============ Some logging frameworks such as Log4j2 allow lazy evaluation for example: logger.trace("Number is {}", () -> getRandomNumber()); I must admit that doing the same using TemplatedStrings is ugly and the 6 distinct characters introducing a lazily evaluated value are impractical: logger.trace("Number is \{() -> getRandomNumber()}"); Can we offer something better using TemplatedStrings? The JEP already talks about evaluation. For example, this is valid: int index; String data = STR."\{index=0}, \{index++}"; and mentions that the TemplatedString provides a list of values: TemplatedString ts = "\{x} plus \{y} equals \{x + y}"; List values = ts.values(); I want to propose an additional syntax. The escape sequence \( would denote a lazily computed value - probably stored as a Supplier. Because the value may not be evaluated, it must only refer to effectively final variables (the same rules as for lambda expressions apply). The following should be illegal: int index; String data = STR."\(index=0), \(index++)"; The logging use-case could be expressed more naturally: logger.trace("Number is \(getRandomNumber())"); I personally can see a parallel between \(...) and ()-> as both use parentheses. This unfortunately is the exact opposite of the syntax of closures in Groovy, where {123} is "lazy" and (123) produces the value immediately. Different languages, different choices. When should this lazy expression be evaluated, and who is responsible for it? It can either be: * when ts.values() is called; * when the value is accessed (via ts.get(N) or .next() on the List's Iterator); * manually when it is consumed by the author of the policy using an instanceof check for Supplier. I keep this as an open question (first we need to find out if this is even a useful feature). It also remains open what to do when a user provides a Supplier manually: Supplier s = () -> 123 logger.trace("Number is \{s} \(s)"); Another way to express a Supplier is via a method reference, which should also be supported and would suggest the equivalence of the following: logger.trace("Number is \{this::getRandomNumber}"); logger.trace("Number is \(this.getRandomNumber())"); Blocks ====== What if the computation of the value requires multiple statements? STR."The intersection of \{a} and \{b} is \{((Supplier) ()-> {var c = new HashSet<>(a); c.retainAll(b); return c;}).get()}" STR."The intersection of \{a} and \{b} is \{switch(1){default:var c = new HashSet<>(a); c.retainAll(b); yield c;}}" These are (as far as my imagination goes) the easiest ways to turn a block into an expression. What if we introduced a special syntax for blocks? One option would be simply doubling the braces: STR."The intersection of \{a} and \{b} is \{{var c = new HashSet<>(a); c.retainAll(b); yield c;}}" The last closing brace is probably not needed but keeping them balanced will help dumb editors with highlighting. This could be a more general syntax useful even outside TemplatedStrings (especially in final field initialization): var intersection = {var c = new HashSet<>(a); c.retainAll(b); yield c;}; Lazy Blocks =========== We may want to combine the two proposed features and compute the intersection lazily when logging: logger.trace("The intersection of \{a} and \{b} is \({var c = new HashSet<>(a); c.retainAll(b); return c;})") which would be equivalent to this already supported syntax provided that the policy understands Supplier values: logger.trace("The intersection of \{a} and \{b} is \{() -> {var c = new HashSet<>(a); c.retainAll(b); return c;}}") If we introduce \( as described in Lazy Logging above and say that \(expression) is equivalent to \{() -> expression}, then \({statements}) would naturally be equivalent to \{() -> {statements}}. Literals ======== It was already mentioned in the JEP that it is possible to create a policy returning a JSON object. We can also think of them as a way to express literals. Some Java types already have a way to parse a String. Some examples are: DURATION."PT20.345S" Duration.from("PT20.345S") COMPLEX."1+3i" Complex.from(1, 3) US_DATE."7/4/2022" LocalDate.of(2022, 7, 4) This is almost as powerful as what C++ offers ( https://en.cppreference.com/w/cpp/language/user_literal). Conclusion ========== I am very happy with the current proposal and tried to explore some possible extensions. I proposed a syntax for lazy evaluation of values, blocks as values, and a combination thereof. I would like to hear from you, whether this is something worth considering, and whether there is demand for it. Regards Adam From james.laskey at oracle.com Sat May 7 14:52:33 2022 From: james.laskey at oracle.com (Jim Laskey) Date: Sat, 7 May 2022 14:52:33 +0000 Subject: TemplatedString feedback and extension - logging use-case, lazy values, blocks In-Reply-To: References: Message-ID: [OOTO] I?ve already done examples of all of the items in your list (all good), but i?m glad you brought these topics up for open discussion. I?ll sit back a see what others have to say. However, I would like to point out that deferred evaluation requires an agreement from the policy to special case suppliers (or futures). This is something we don?t really want to bake in. Every policy should be free to pick and choose what it does. Another approach is to use policy chaining where one policy in the chain evaluates suppliers and futures to produce a new TemplatedString to be processed by the next policy in the chain. The ugliness of lambdas in an embedded expression is made worse by the fact it has to be cast to Supplier or Future since the default type for embedded expressions is Object. In all my examples, I?ve out of lined these types of expressions and used a local or better yet a global constant variable (ex., TIME_STAMP) to use in the embedded expression. I think this technique makes the string template read better. When I?m back the end of next week I can post some examples. Cheers, ?Jim After this response we should move the discussion to the amber-dev mailing list. ?? > On May 7, 2022, at 10:58 AM, Adam Juraszek wrote: > > ?The TemplatedString proposal is amazing; I can see using it in many places. > I have a few comments that I have not seen addressed. > > Logging > ======= > > One place where some kind of string templating is often used is logging. > Most logging frameworks use a pair of braces {}. TemplatedStrings have the > potential to revolutionize it. > > Log record usually consists of the following parts that the programmer > needs to provide: > * log level (such as error, info) > * message (such as "Oh no, the value {} is negative") > * parameters (such as -42) > * exception/throwable (only sometimes) > > Let's assume that TemplatedString is performant and virtually free, then > these options would be possible. I cannot say which syntax the logging > frameworks would choose: > > logger.error."Oh no, the value \{value} is negative\{ex}"; > logger.error("Oh no, the value \{value} is negative", ex); > logger."Oh no, the value \{value} is negative".error(ex); > > Versus the existing: > > logger.error("Oh no, the value {} is negative", value, ex); > > Lazy Logging > ============ > > Some logging frameworks such as Log4j2 allow lazy evaluation for example: > > logger.trace("Number is {}", () -> getRandomNumber()); > > I must admit that doing the same using TemplatedStrings is ugly and the 6 > distinct characters introducing a lazily evaluated value are impractical: > > logger.trace("Number is \{() -> getRandomNumber()}"); > > Can we offer something better using TemplatedStrings? The JEP already talks > about evaluation. For example, this is valid: > > int index; > String data = STR."\{index=0}, \{index++}"; > > and mentions that the TemplatedString provides a list of values: > > TemplatedString ts = "\{x} plus \{y} equals \{x + y}"; > List values = ts.values(); > > I want to propose an additional syntax. The escape sequence \( would denote > a lazily computed value - probably stored as a Supplier. Because the value > may not be evaluated, it must only refer to effectively final variables > (the same rules as for lambda expressions apply). > > The following should be illegal: > > int index; > String data = STR."\(index=0), \(index++)"; > > The logging use-case could be expressed more naturally: > > logger.trace("Number is \(getRandomNumber())"); > > I personally can see a parallel between \(...) and ()-> as both use > parentheses. This unfortunately is the exact opposite of the syntax of > closures in Groovy, where {123} is "lazy" and (123) produces the value > immediately. Different languages, different choices. > > When should this lazy expression be evaluated, and who is responsible for > it? It can either be: > * when ts.values() is called; > * when the value is accessed (via ts.get(N) or .next() on the List's > Iterator); > * manually when it is consumed by the author of the policy using an > instanceof check for Supplier. > > I keep this as an open question (first we need to find out if this is even > a useful feature). It also remains open what to do when a user provides a > Supplier manually: > > Supplier s = () -> 123 > logger.trace("Number is \{s} \(s)"); > > Another way to express a Supplier is via a method reference, which should > also be supported and would suggest the equivalence of the following: > > logger.trace("Number is \{this::getRandomNumber}"); > logger.trace("Number is \(this.getRandomNumber())"); > > Blocks > ====== > > What if the computation of the value requires multiple statements? > > STR."The intersection of \{a} and \{b} is \{((Supplier) ()-> {var c = new > HashSet<>(a); c.retainAll(b); return c;}).get()}" > STR."The intersection of \{a} and \{b} is \{switch(1){default:var c = new > HashSet<>(a); c.retainAll(b); yield c;}}" > > These are (as far as my imagination goes) the easiest ways to turn a block > into an expression. > > What if we introduced a special syntax for blocks? One option would be > simply doubling the braces: > > STR."The intersection of \{a} and \{b} is \{{var c = new HashSet<>(a); > c.retainAll(b); yield c;}}" > > The last closing brace is probably not needed but keeping them balanced > will help dumb editors with highlighting. > > This could be a more general syntax useful even outside TemplatedStrings > (especially in final field initialization): > > var intersection = {var c = new HashSet<>(a); c.retainAll(b); yield c;}; > > Lazy Blocks > =========== > > We may want to combine the two proposed features and compute the > intersection lazily when logging: > > logger.trace("The intersection of \{a} and \{b} is \({var c = new > HashSet<>(a); c.retainAll(b); return c;})") > > which would be equivalent to this already supported syntax provided that > the policy understands Supplier values: > > logger.trace("The intersection of \{a} and \{b} is \{() -> {var c = new > HashSet<>(a); c.retainAll(b); return c;}}") > > If we introduce \( as described in Lazy Logging above and say that > \(expression) is equivalent to \{() -> expression}, then \({statements}) > would naturally be equivalent to \{() -> {statements}}. > > Literals > ======== > > It was already mentioned in the JEP that it is possible to create a policy > returning a JSON object. We can also think of them as a way to express > literals. Some Java types already have a way to parse a String. Some > examples are: > > DURATION."PT20.345S" > Duration.from("PT20.345S") > > COMPLEX."1+3i" > Complex.from(1, 3) > > US_DATE."7/4/2022" > LocalDate.of(2022, 7, 4) > > This is almost as powerful as what C++ offers ( > https://en.cppreference.com/w/cpp/language/user_literal). > > Conclusion > ========== > > I am very happy with the current proposal and tried to explore some > possible extensions. I proposed a syntax for lazy evaluation of values, > blocks as values, and a combination thereof. I would like to hear from you, > whether this is something worth considering, and whether there is demand > for it. > > Regards > Adam From attila.kelemen85 at gmail.com Sat May 7 15:39:40 2022 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Sat, 7 May 2022 17:39:40 +0200 Subject: TemplatedString feedback and extension - logging use-case, lazy values, blocks In-Reply-To: References: Message-ID: Hi, Just giving my two cents :) Logging: While of course you could use such a feature in a log message. However, that wouldn't be so good for two reasons: 1. It would not prevent the string concatenation in case of no logging, which is one reason why these things were invented in the first place. 2. If a logging framework interprets the log message (before resolving the template), then that would be like an SQL injection. Blocks: In my opinion, blocks of code kinda defeats the purpose of string interpolation to make string concatenation look more readable. In fact, I have created my own implementation (https://github.com/kelemen/jdk/tree/string_interpolation) of string interpolation about two years ago (though only rebased my code to a one year old state of the JDK), and in this implementation I even explicitly disallowed line breaks in these expressions. Mainly, because it raises questions in text blocks. Lazy evaluation: I think this could only work, if we had a new type like GString in Groovy, because otherwise the lambda expression has to be evaluated immediately anyway, since the type is `java.lang.String` which can't be expected to carry around the lazy expressions. Attila Adam Juraszek ezt ?rta (id?pont: 2022. m?j. 7., Szo, 15:58): > > The TemplatedString proposal is amazing; I can see using it in many places. > I have a few comments that I have not seen addressed. > > Logging > ======= > > One place where some kind of string templating is often used is logging. > Most logging frameworks use a pair of braces {}. TemplatedStrings have the > potential to revolutionize it. > > Log record usually consists of the following parts that the programmer > needs to provide: > * log level (such as error, info) > * message (such as "Oh no, the value {} is negative") > * parameters (such as -42) > * exception/throwable (only sometimes) > > Let's assume that TemplatedString is performant and virtually free, then > these options would be possible. I cannot say which syntax the logging > frameworks would choose: > > logger.error."Oh no, the value \{value} is negative\{ex}"; > logger.error("Oh no, the value \{value} is negative", ex); > logger."Oh no, the value \{value} is negative".error(ex); > > Versus the existing: > > logger.error("Oh no, the value {} is negative", value, ex); > > Lazy Logging > ============ > > Some logging frameworks such as Log4j2 allow lazy evaluation for example: > > logger.trace("Number is {}", () -> getRandomNumber()); > > I must admit that doing the same using TemplatedStrings is ugly and the 6 > distinct characters introducing a lazily evaluated value are impractical: > > logger.trace("Number is \{() -> getRandomNumber()}"); > > Can we offer something better using TemplatedStrings? The JEP already talks > about evaluation. For example, this is valid: > > int index; > String data = STR."\{index=0}, \{index++}"; > > and mentions that the TemplatedString provides a list of values: > > TemplatedString ts = "\{x} plus \{y} equals \{x + y}"; > List values = ts.values(); > > I want to propose an additional syntax. The escape sequence \( would denote > a lazily computed value - probably stored as a Supplier. Because the value > may not be evaluated, it must only refer to effectively final variables > (the same rules as for lambda expressions apply). > > The following should be illegal: > > int index; > String data = STR."\(index=0), \(index++)"; > > The logging use-case could be expressed more naturally: > > logger.trace("Number is \(getRandomNumber())"); > > I personally can see a parallel between \(...) and ()-> as both use > parentheses. This unfortunately is the exact opposite of the syntax of > closures in Groovy, where {123} is "lazy" and (123) produces the value > immediately. Different languages, different choices. > > When should this lazy expression be evaluated, and who is responsible for > it? It can either be: > * when ts.values() is called; > * when the value is accessed (via ts.get(N) or .next() on the List's > Iterator); > * manually when it is consumed by the author of the policy using an > instanceof check for Supplier. > > I keep this as an open question (first we need to find out if this is even > a useful feature). It also remains open what to do when a user provides a > Supplier manually: > > Supplier s = () -> 123 > logger.trace("Number is \{s} \(s)"); > > Another way to express a Supplier is via a method reference, which should > also be supported and would suggest the equivalence of the following: > > logger.trace("Number is \{this::getRandomNumber}"); > logger.trace("Number is \(this.getRandomNumber())"); > > Blocks > ====== > > What if the computation of the value requires multiple statements? > > STR."The intersection of \{a} and \{b} is \{((Supplier) ()-> {var c = new > HashSet<>(a); c.retainAll(b); return c;}).get()}" > STR."The intersection of \{a} and \{b} is \{switch(1){default:var c = new > HashSet<>(a); c.retainAll(b); yield c;}}" > > These are (as far as my imagination goes) the easiest ways to turn a block > into an expression. > > What if we introduced a special syntax for blocks? One option would be > simply doubling the braces: > > STR."The intersection of \{a} and \{b} is \{{var c = new HashSet<>(a); > c.retainAll(b); yield c;}}" > > The last closing brace is probably not needed but keeping them balanced > will help dumb editors with highlighting. > > This could be a more general syntax useful even outside TemplatedStrings > (especially in final field initialization): > > var intersection = {var c = new HashSet<>(a); c.retainAll(b); yield c;}; > > Lazy Blocks > =========== > > We may want to combine the two proposed features and compute the > intersection lazily when logging: > > logger.trace("The intersection of \{a} and \{b} is \({var c = new > HashSet<>(a); c.retainAll(b); return c;})") > > which would be equivalent to this already supported syntax provided that > the policy understands Supplier values: > > logger.trace("The intersection of \{a} and \{b} is \{() -> {var c = new > HashSet<>(a); c.retainAll(b); return c;}}") > > If we introduce \( as described in Lazy Logging above and say that > \(expression) is equivalent to \{() -> expression}, then \({statements}) > would naturally be equivalent to \{() -> {statements}}. > > Literals > ======== > > It was already mentioned in the JEP that it is possible to create a policy > returning a JSON object. We can also think of them as a way to express > literals. Some Java types already have a way to parse a String. Some > examples are: > > DURATION."PT20.345S" > Duration.from("PT20.345S") > > COMPLEX."1+3i" > Complex.from(1, 3) > > US_DATE."7/4/2022" > LocalDate.of(2022, 7, 4) > > This is almost as powerful as what C++ offers ( > https://en.cppreference.com/w/cpp/language/user_literal). > > Conclusion > ========== > > I am very happy with the current proposal and tried to explore some > possible extensions. I proposed a syntax for lazy evaluation of values, > blocks as values, and a combination thereof. I would like to hear from you, > whether this is something worth considering, and whether there is demand > for it. > > Regards > Adam From goetz.lindenmaier at sap.com Mon May 9 05:59:58 2022 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 May 2022 05:59:58 +0000 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: yes Best, Goetz > -----Original Message----- > From: jdk-dev On Behalf Of Daniel Fuchs > Sent: Friday, May 6, 2022 6:02 PM > To: jdk-dev > Subject: CFV: New JDK Reviewer: Jaikiran Pai > > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > > Jaikiran is a member of the Java Core Libraries team at > Oracle and has already contributed 63 changesets [2] > to the openjdk repository. More importantly Jaikiran has > helped reviewing many PRs where his reviews have been both > helpful and very thorough > > Votes are due by 17:00 UTC May 20th, 2022. > > Only current JDK Reviewers [3] 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 [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#jpai > [2] > https://github.com/search?q=author- > name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&ty > pe=Commits > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus From christoph.langer at sap.com Mon May 9 06:43:50 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 9 May 2022 06:43:50 +0000 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Daniel Fuchs > Sent: Freitag, 6. Mai 2022 18:02 > To: jdk-dev > Subject: CFV: New JDK Reviewer: Jaikiran Pai > > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > > Jaikiran is a member of the Java Core Libraries team at Oracle and has already > contributed 63 changesets [2] to the openjdk repository. More importantly > Jaikiran has helped reviewing many PRs where his reviews have been both > helpful and very thorough > > Votes are due by 17:00 UTC May 20th, 2022. > > Only current JDK Reviewers [3] 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 [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#jpai > [2] > https://github.com/search?q=author- > name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&ty > pe=Commits > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus From christian.hagedorn at oracle.com Mon May 9 09:17:16 2022 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Mon, 9 May 2022 11:17:16 +0200 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: <835be9d1-c3b2-4f40-498d-66985c64a815@oracle.com> Vote: yes Best regards, Christian On 06.05.22 10:56, Tobias Hartmann wrote: > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From christian.hagedorn at oracle.com Mon May 9 09:17:37 2022 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Mon, 9 May 2022 11:17:37 +0200 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: <67c3f81c-ded3-9996-8229-1c7e23f42d19@oracle.com> Vote: yes Best regards, Christian On 06.05.22 10:56, Tobias Hartmann wrote: > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From magnus.ihse.bursie at oracle.com Mon May 9 12:08:15 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 9 May 2022 14:08:15 +0200 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: yes /Magnus On 2022-05-06 18:02, Daniel Fuchs wrote: > Hi, > > I hereby nominate Jaikiran Pai [1] to JDK Reviewer. > > Jaikiran is a member of the Java Core Libraries team at > Oracle and has already contributed 63 changesets [2] > to the openjdk repository. More importantly Jaikiran has > helped reviewing many PRs where his reviews have been both > helpful and very thorough > > Votes are due by 17:00 UTC May 20th, 2022. > > Only current JDK Reviewers [3] 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 [4]. > > Best regards, > > -- daniel > > [1] https://openjdk.java.net/census#jpai > [2] > https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/bylaws#lazy-consensus > From hohensee at amazon.com Mon May 9 12:17:22 2022 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 9 May 2022 12:17:22 +0000 Subject: CFV: New JDK Reviewer: Jaikiran Pai Message-ID: Vote: yes ?-----Original Message----- From: jdk-dev on behalf of Daniel Fuchs Date: Friday, May 6, 2022 at 9:02 AM To: jdk-dev Subject: CFV: New JDK Reviewer: Jaikiran Pai Hi, I hereby nominate Jaikiran Pai [1] to JDK Reviewer. Jaikiran is a member of the Java Core Libraries team at Oracle and has already contributed 63 changesets [2] to the openjdk repository. More importantly Jaikiran has helped reviewing many PRs where his reviews have been both helpful and very thorough Votes are due by 17:00 UTC May 20th, 2022. Only current JDK Reviewers [3] 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 [4]. Best regards, -- daniel [1] https://openjdk.java.net/census#jpai [2] https://github.com/search?q=author-name%3A%22Jaikiran+Pai%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&type=Commits [3] http://openjdk.java.net/census [4] http://openjdk.java.net/bylaws#lazy-consensus From martin.doerr at sap.com Mon May 9 15:19:03 2022 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 9 May 2022 15:19:03 +0000 Subject: CFV: New JDK Committer: Tyler Steele Message-ID: Hi, I hereby nominate Tyler Steele to JDK Committer. Tyler works for IBM and he has taken responsibility for the AIX OS. He has already contributed 10 changes to the jdk repository [1]. One of his changes was quite complex: https://github.com/openjdk/jdk/commit/c0275e18b7cb4a01385b79ced46560322aeacc97 Some other ones are small but were not easy to find or require good knowledge of the VM and how the tests work. I guess such changes will be typical for his role. In addition, he?s contributing to the jdk-updates projects focusing on AIX. He has also helped to review and test PPC64 and s390 changes. Votes are due by Tuesday, 24 May 2022 at 09:00 UTC. 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, Martin [1] https://github.com/openjdk/jdk/commits?author=backwaterred [2] https://openjdk.java.net/census [3] https://openjdk.java.net/projects/#committer-vote From thomas.stuefe at gmail.com Mon May 9 15:21:54 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 9 May 2022 17:21:54 +0200 Subject: CFV: New JDK Committer: Tyler Steele In-Reply-To: References: Message-ID: Vote: yes! On Mon, May 9, 2022 at 5:20 PM Doerr, Martin wrote: > Hi, > > > > I hereby nominate Tyler Steele to JDK Committer. > > > > Tyler works for IBM and he has taken responsibility for the AIX OS. He has > already contributed 10 changes to the jdk repository [1]. > > > > One of his changes was quite complex: > > > https://github.com/openjdk/jdk/commit/c0275e18b7cb4a01385b79ced46560322aeacc97 > > > > Some other ones are small but were not easy to find or require good > knowledge of the VM and how the tests work. > > I guess such changes will be typical for his role. > > > > In addition, he?s contributing to the jdk-updates projects focusing on > AIX. He has also helped to review and test PPC64 and s390 changes. > > > > Votes are due by Tuesday, 24 May 2022 at 09:00 UTC. > > > > 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, > > Martin > > > > [1] https://github.com/openjdk/jdk/commits?author=backwaterred< > https://github.com/openjdk/jdk/commits?author=eme64> > > [2] https://openjdk.java.net/census > > [3] https://openjdk.java.net/projects/#committer-vote > > From richard.reingruber at sap.com Mon May 9 15:38:49 2022 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Mon, 9 May 2022 15:38:49 +0000 Subject: CFV: New JDK Committer: Tyler Steele In-Reply-To: References: Message-ID: Vote: yes Richard. From: jdk-dev on behalf of Doerr, Martin Date: Monday, 9. May 2022 at 17:20 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Tyler Steele Hi, I hereby nominate Tyler Steele to JDK Committer. Tyler works for IBM and he has taken responsibility for the AIX OS. He has already contributed 10 changes to the jdk repository [1]. One of his changes was quite complex: https://github.com/openjdk/jdk/commit/c0275e18b7cb4a01385b79ced46560322aeacc97 Some other ones are small but were not easy to find or require good knowledge of the VM and how the tests work. I guess such changes will be typical for his role. In addition, he?s contributing to the jdk-updates projects focusing on AIX. He has also helped to review and test PPC64 and s390 changes. Votes are due by Tuesday, 24 May 2022 at 09:00 UTC. 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, Martin [1] https://github.com/openjdk/jdk/commits?author=backwaterred [2] https://openjdk.java.net/census [3] https://openjdk.java.net/projects/#committer-vote From christoph.langer at sap.com Tue May 10 16:43:21 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 10 May 2022 16:43:21 +0000 Subject: CFV: New JDK Committer: Tyler Steele In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Doerr, Martin > Sent: Montag, 9. Mai 2022 17:19 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Tyler Steele > > Hi, > > > > I hereby nominate Tyler Steele to JDK Committer. > > > > Tyler works for IBM and he has taken responsibility for the AIX OS. He has > already contributed 10 changes to the jdk repository [1]. > > > > One of his changes was quite complex: > > https://github.com/openjdk/jdk/commit/c0275e18b7cb4a01385b79ced465603 > 22aeacc97 > > > > Some other ones are small but were not easy to find or require good > knowledge of the VM and how the tests work. > > I guess such changes will be typical for his role. > > > > In addition, he?s contributing to the jdk-updates projects focusing on AIX. He > has also helped to review and test PPC64 and s390 changes. > > > > Votes are due by Tuesday, 24 May 2022 at 09:00 UTC. > > > > 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, > > Martin > > > > [1] > https://github.com/openjdk/jdk/commits?author=backwaterred .com/openjdk/jdk/commits?author=eme64> > > [2] https://openjdk.java.net/census > > [3] https://openjdk.java.net/projects/#committer-vote From yan at azul.com Wed May 11 07:23:11 2022 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 11 May 2022 10:23:11 +0300 Subject: CFV: New JDK Committer: Tyler Steele In-Reply-To: References: Message-ID: <5ca735ab-5d62-ca99-1128-d6f6d52594d1@azul.com> Vote: yes --yan On 09.05.2022 18:19, Doerr, Martin wrote: > Hi, > > > > I hereby nominate Tyler Steele to JDK Committer. > > > > Tyler works for IBM and he has taken responsibility for the AIX OS. He has already contributed 10 changes to the jdk repository [1]. > > > > One of his changes was quite complex: > > https://github.com/openjdk/jdk/commit/c0275e18b7cb4a01385b79ced46560322aeacc97 > > > > Some other ones are small but were not easy to find or require good knowledge of the VM and how the tests work. > > I guess such changes will be typical for his role. > > > > In addition, he?s contributing to the jdk-updates projects focusing on AIX. He has also helped to review and test PPC64 and s390 changes. > > > > Votes are due by Tuesday, 24 May 2022 at 09:00 UTC. > > > > 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, > > Martin > > > > [1] https://github.com/openjdk/jdk/commits?author=backwaterred > > [2] https://openjdk.java.net/census > > [3] https://openjdk.java.net/projects/#committer-vote > From matthias.baesken at sap.com Wed May 11 07:32:49 2022 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 11 May 2022 07:32:49 +0000 Subject: CFV: New JDK Committer: Tyler Steele In-Reply-To: <5ca735ab-5d62-ca99-1128-d6f6d52594d1@azul.com> References: <5ca735ab-5d62-ca99-1128-d6f6d52594d1@azul.com> Message-ID: Vote: yes On 09.05.2022 18:19, Doerr, Martin wrote: > Hi, > > > > I hereby nominate Tyler Steele to JDK Committer. > > > > Tyler works for IBM and he has taken responsibility for the AIX OS. He has already contributed 10 changes to the jdk repository [1]. > > > > One of his changes was quite complex: > > https://github.com/openjdk/jdk/commit/c0275e18b7cb4a01385b79ced46560322aeacc97 > > > > Some other ones are small but were not easy to find or require good knowledge of the VM and how the tests work. > > I guess such changes will be typical for his role. > > > > In addition, he?s contributing to the jdk-updates projects focusing on AIX. He has also helped to review and test PPC64 and s390 changes. > > > > Votes are due by Tuesday, 24 May 2022 at 09:00 UTC. > > > > 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, > > Martin > > > > [1] https://github.com/openjdk/jdk/commits?author=backwaterred > > [2] https://openjdk.java.net/census > > [3] https://openjdk.java.net/projects/#committer-vote > From sgehwolf at redhat.com Wed May 11 08:32:35 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 11 May 2022 10:32:35 +0200 Subject: CFV: New JDK Committer: Tyler Steele In-Reply-To: References: Message-ID: Vote: yes On Mon, 2022-05-09 at 15:19 +0000, Doerr, Martin wrote: > Hi, > I hereby nominate Tyler Steele to JDK Committer. From magnus.ihse.bursie at oracle.com Thu May 12 10:50:05 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 May 2022 12:50:05 +0200 Subject: VS Code plugin for OpenJDK development Message-ID: <2abb3bc0-5f1e-4b66-3617-4e3672647a00@oracle.com> Hi all, I've been using Visual Studio Code for most of my OpenJDK development needs for quite some time now, and grown very fond of it. A year ago or so, I wrote a plugin to support me in my daily tasks. It is available here: https://marketplace.visualstudio.com/items?itemName=magicus.openjdk-devel After a year of testing, I think it has proven its worth (to me, at least), and I feel ready to recommend it to my fellow developers. The plugin currently gives you a separate view with Github integration, showing your notifications for OpenJDK projects, your personal PRs, and open PRs for a set of chosen tags (i.e. areas you want to watch). My initial idea was to add support for JBS integration as well, but that part is stalled until our Jira instance gets proper support for access tokens. :-( If you have suggestions or improvements, feel free to open an issue or PR here: https://github.com/magicus/vscode-openjdk-devel /Magnus From maurizio.cimadamore at oracle.com Thu May 12 11:12:07 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 12 May 2022 12:12:07 +0100 Subject: VS Code plugin for OpenJDK development In-Reply-To: <2abb3bc0-5f1e-4b66-3617-4e3672647a00@oracle.com> References: <2abb3bc0-5f1e-4b66-3617-4e3672647a00@oracle.com> Message-ID: Hi Magnus, this is great news. While I've been working on IntelliJ support for quite a bit, I was too thinking about VSCode, especially for the ability to work with Java and CPP simultaneously. There's already some support to work on VM code with VsCode. The Java support is missing AFAIK, as well as ability to run and debug jtreg tests, which we have with IntelliJ. But I welcome any initiative to make OpenJDK more accessible to more IDEs! Maurizio On 12/05/2022 11:50, Magnus Ihse Bursie wrote: > Hi all, > > I've been using Visual Studio Code for most of my OpenJDK development > needs for quite some time now, and grown very fond of it. A year ago > or so, I wrote a plugin to support me in my daily tasks. It is > available here: > > https://marketplace.visualstudio.com/items?itemName=magicus.openjdk-devel > > After a year of testing, I think it has proven its worth (to me, at > least), and I feel ready to recommend it to my fellow developers. The > plugin currently gives you a separate view with Github integration, > showing your notifications for OpenJDK projects, your personal PRs, > and open PRs for a set of chosen tags (i.e. areas you want to watch). > > My initial idea was to add support for JBS integration as well, but > that part is stalled until our Jira instance gets proper support for > access tokens. :-( > > If you have suggestions or improvements, feel free to open an issue or > PR here: > https://github.com/magicus/vscode-openjdk-devel > > /Magnus From goetz.lindenmaier at sap.com Thu May 12 13:46:02 2022 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 12 May 2022 13:46:02 +0000 Subject: CFV: New JDK Committer: Tyler Steele In-Reply-To: References: Message-ID: Vote: yes Best, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Doerr, Martin > Sent: Monday, May 9, 2022 5:19 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Tyler Steele > > Hi, > > > > I hereby nominate Tyler Steele to JDK Committer. > > > > Tyler works for IBM and he has taken responsibility for the AIX OS. He has > already contributed 10 changes to the jdk repository [1]. > > > > One of his changes was quite complex: > > https://github.com/openjdk/jdk/commit/c0275e18b7cb4a01385b79ced46560 > 322aeacc97 > > > > Some other ones are small but were not easy to find or require good > knowledge of the VM and how the tests work. > > I guess such changes will be typical for his role. > > > > In addition, he's contributing to the jdk-updates projects focusing on AIX. He > has also helped to review and test PPC64 and s390 changes. > > > > Votes are due by Tuesday, 24 May 2022 at 09:00 UTC. > > > > 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, > > Martin > > > > [1] > https://github.com/openjdk/jdk/commits?author=backwaterred hub.com/openjdk/jdk/commits?author=eme64> > > [2] https://openjdk.java.net/census > > [3] https://openjdk.java.net/projects/#committer-vote From mark.reinhold at oracle.com Thu May 12 15:33:15 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 May 2022 08:33:15 -0700 Subject: JEP proposed to target JDK 19: 424: Foreign Function & Memory API (Preview) In-Reply-To: <20220504221522.B4180535CCC@eggemoggin.niobe.net> References: <20220504221522.B4180535CCC@eggemoggin.niobe.net> Message-ID: <20220512083315.136492762@eggemoggin.niobe.net> 2022/5/4 15:15:22 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 19: > > 424: Foreign Function & Memory API (Preview) > https://openjdk.java.net/jeps/424 > > Summary: Introduce an API by which Java programs can interoperate with > code and data outside of the Java runtime. By efficiently invoking > foreign functions (i.e., code outside the JVM), and by safely accessing > foreign memory (i.e., memory not managed by the JVM), the API enables > Java programs to call native libraries and process native data without > the brittleness and danger of JNI. This is a preview 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 Wednesday, 11 May, 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 19. Hearing no objections, I?ve targeted this JEP to JDK 19. - Mark From mark.reinhold at oracle.com Thu May 12 21:07:26 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 May 2022 14:07:26 -0700 (PDT) Subject: JEP proposed to target JDK 19: 405: Record Patterns (Preview) Message-ID: <20220512210726.E34E3536B2F@eggemoggin.niobe.net> The following JEP is proposed to target JDK 19: 405: Record Patterns (Preview) https://openjdk.java.net/jeps/405 Summary: Enhance the Java programming language with record patterns to deconstruct record values. Record patterns and type patterns can be nested to enable a powerful, declarative, and composable form of data navigation and processing. This is a preview language feature. 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, 19 May, 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 19. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mikael.vidstedt at oracle.com Thu May 12 21:12:51 2022 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 12 May 2022 21:12:51 +0000 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: <990D2089-30EB-40E4-AC57-C2788E7E0A90@oracle.com> Vote: yes Cheers, Mikael > On May 6, 2022, at 1:56 AM, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From mikael.vidstedt at oracle.com Thu May 12 21:14:08 2022 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 12 May 2022 21:14:08 +0000 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: Vote: yes Cheers, Mikael > On May 6, 2022, at 1:56 AM, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From martin.doerr at sap.com Thu May 12 21:15:03 2022 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 12 May 2022 21:15:03 +0000 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: Vote: yes Best regards, Martin Von: jdk-dev im Auftrag von Tobias Hartmann Datum: Freitag, 6. Mai 2022 um 10:57 An: jdk-dev Betreff: CFV: New JDK Committer: Tobias Holenstein Hi, I hereby nominate Tobias Holenstein to JDK Committer. Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel and High Performance Computing and Compiler Design. Some of his project work included parallel algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae Votes are due by Friday, 20 May 2022 at 09:00 UTC. 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, Tobias [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein [2] https://openjdk.java.net/census [3] https://openjdk.java.net/projects/#committer-vote From mark.yagnatinsky at barclays.com Thu May 12 22:58:27 2022 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Thu, 12 May 2022 22:58:27 +0000 Subject: can't run jshell 32-bit Windows in bleeding edge JDK Message-ID: Not sure if this is the right email list for this particular complaint, but I tried downloading this JDK a day or two ago (in the hopes of playing with Loom): https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-windows-x86_32-server-release-msvc2019.zip And when I try to run jshell it hangs for 20 seconds or so and then exits with some timeout exception. Any advice? This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __________________________________________________________________________________ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __________________________________________________________________________________ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __________________________________________________________________________________ From david.holmes at oracle.com Thu May 12 23:23:12 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 May 2022 09:23:12 +1000 Subject: can't run jshell 32-bit Windows in bleeding edge JDK In-Reply-To: References: Message-ID: Hi Mark, On 13/05/2022 8:58 am, mark.yagnatinsky at barclays.com wrote: > Not sure if this is the right email list for this particular complaint, but I tried downloading this JDK a day or two ago (in the hopes of playing with Loom): > https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-windows-x86_32-server-release-msvc2019.zip > And when I try to run jshell it hangs for 20 seconds or so and then exits with some timeout exception. No not the right mailing list for Aleksey's personal build farm. Anything downloaded from: https://builds.shipilev.net/ is a matter for Aleksey. But also note that AFAICS there is no Loom support in any Windows 32-bit builds at this time. Cheers, David > Any advice? > > This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. > > For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. > __________________________________________________________________________________ > If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. > __________________________________________________________________________________ > For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. > __________________________________________________________________________________ From mark.yagnatinsky at barclays.com Thu May 12 23:28:05 2022 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Thu, 12 May 2022 23:28:05 +0000 Subject: can't run jshell 32-bit Windows in bleeding edge JDK In-Reply-To: References: Message-ID: Thanks! Any idea roughly how soon 32-bit support is likely to land? A few weeks? A few days? A few months? -----Original Message----- From: David Holmes Sent: Thursday, May 12, 2022 7:23 PM To: Yagnatinsky, Mark : Markets Pre Trade ; jdk-dev at openjdk.java.net Subject: Re: can't run jshell 32-bit Windows in bleeding edge JDK CAUTION: This email originated from outside our organisation - david.holmes at oracle.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Hi Mark, On 13/05/2022 8:58 am, mark.yagnatinsky at barclays.com wrote: > Not sure if this is the right email list for this particular complaint, but I tried downloading this JDK a day or two ago (in the hopes of playing with Loom): > https://clicktime.symantec.com/36vLTs4QrDwpCTRVYG8SPoT6H4?u=https%3A%2 > F%2Fbuilds.shipilev.net%2Fopenjdk-jdk%2Fopenjdk-jdk-windows-x86_32-ser > ver-release-msvc2019.zip And when I try to run jshell it hangs for 20 > seconds or so and then exits with some timeout exception. No not the right mailing list for Aleksey's personal build farm. Anything downloaded from: https://clicktime.symantec.com/38UXqd5ke9jpoe1u2HAMngU6H4?u=https%3A%2F%2Fbuilds.shipilev.net%2F is a matter for Aleksey. But also note that AFAICS there is no Loom support in any Windows 32-bit builds at this time. Cheers, David > Any advice? > > This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://clicktime.symantec.com/3XWxBj2gBUZqiGonXN11tqW6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fweb-and-email-disclaimer.html. > > For important disclosures, please see: https://clicktime.symantec.com/3BM3qqsVRr2kfTm6HhX3pJB6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fsales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://clicktime.symantec.com/33RgL1WY1xCTcqmHz9g8pEG6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fbarclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://clicktime.symantec.com/3WGAzyFJQdj2xPRhnxCFoh86H4?u=http%3A%2F%2Fpublicresearch.barclays.com. > ______________________________________________________________________ > ____________ If you are incorporated or operating in Australia, read > these important disclosures: https://clicktime.symantec.com/3BLriWAwKBXjUKWDQU1Uyfg6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fimportant-disclosures-asia-pacific.html. > ______________________________________________________________________ > ____________ For more details about how we use personal information, > see our privacy notice: https://clicktime.symantec.com/36J7KDteteRmW6z6MUEkheH6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fpersonal-information-use.html. > ______________________________________________________________________ > ____________ This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __________________________________________________________________________________ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __________________________________________________________________________________ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __________________________________________________________________________________ From mark.reinhold at oracle.com Fri May 13 01:00:59 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 May 2022 18:00:59 -0700 Subject: JEP proposed to target JDK 19: 427: Pattern Matching for switch (Third Preview) In-Reply-To: <20220428231205.0DF4E535279@eggemoggin.niobe.net> References: <20220428231205.0DF4E535279@eggemoggin.niobe.net> Message-ID: <20220512180059.81637490@eggemoggin.niobe.net> 2022/4/28 16:12:05 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 19: > > 427: Pattern Matching for switch (Third Preview) > https://openjdk.java.net/jeps/427 > > Summary: Enhance the Java programming language with pattern matching > for switch expressions and statements. Extending pattern matching to > switch allows an expression to be tested against a number of patterns, > each with a specific action, so that complex data-oriented queries can > be expressed concisely and safely. This is a preview language feature. > > 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, 5 May, 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 19. Hearing no objections, I?ve targeted this JEP to JDK 19. - Mark From david.holmes at oracle.com Fri May 13 02:22:16 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 May 2022 12:22:16 +1000 Subject: can't run jshell 32-bit Windows in bleeding edge JDK In-Reply-To: References: Message-ID: <15060f95-ad5b-6d01-9485-adaf2c5679f3@oracle.com> On 13/05/2022 9:28 am, mark.yagnatinsky at barclays.com wrote: > Thanks! Any idea roughly how soon 32-bit support is likely to land? > A few weeks? A few days? A few months? No idea sorry. I'm not even sure 32-bit Windows is on anyone's release radar, but keep an eye on: https://bugs.openjdk.java.net/browse/JDK-8286642 Cheers, David > -----Original Message----- > From: David Holmes > Sent: Thursday, May 12, 2022 7:23 PM > To: Yagnatinsky, Mark : Markets Pre Trade ; jdk-dev at openjdk.java.net > Subject: Re: can't run jshell 32-bit Windows in bleeding edge JDK > > > CAUTION: This email originated from outside our organisation - david.holmes at oracle.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. > Hi Mark, > > On 13/05/2022 8:58 am, mark.yagnatinsky at barclays.com wrote: >> Not sure if this is the right email list for this particular complaint, but I tried downloading this JDK a day or two ago (in the hopes of playing with Loom): >> https://clicktime.symantec.com/36vLTs4QrDwpCTRVYG8SPoT6H4?u=https%3A%2 >> F%2Fbuilds.shipilev.net%2Fopenjdk-jdk%2Fopenjdk-jdk-windows-x86_32-ser >> ver-release-msvc2019.zip And when I try to run jshell it hangs for 20 >> seconds or so and then exits with some timeout exception. > > No not the right mailing list for Aleksey's personal build farm. > Anything downloaded from: > > https://clicktime.symantec.com/38UXqd5ke9jpoe1u2HAMngU6H4?u=https%3A%2F%2Fbuilds.shipilev.net%2F > > is a matter for Aleksey. > > But also note that AFAICS there is no Loom support in any Windows 32-bit builds at this time. > > Cheers, > David > >> Any advice? >> >> This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://clicktime.symantec.com/3XWxBj2gBUZqiGonXN11tqW6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fweb-and-email-disclaimer.html. >> >> For important disclosures, please see: https://clicktime.symantec.com/3BM3qqsVRr2kfTm6HhX3pJB6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fsales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://clicktime.symantec.com/33RgL1WY1xCTcqmHz9g8pEG6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fbarclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://clicktime.symantec.com/3WGAzyFJQdj2xPRhnxCFoh86H4?u=http%3A%2F%2Fpublicresearch.barclays.com. >> ______________________________________________________________________ >> ____________ If you are incorporated or operating in Australia, read >> these important disclosures: https://clicktime.symantec.com/3BLriWAwKBXjUKWDQU1Uyfg6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fimportant-disclosures-asia-pacific.html. >> ______________________________________________________________________ >> ____________ For more details about how we use personal information, >> see our privacy notice: https://clicktime.symantec.com/36J7KDteteRmW6z6MUEkheH6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fpersonal-information-use.html. >> ______________________________________________________________________ >> ____________ > > This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. > > For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. > __________________________________________________________________________________ > If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. > __________________________________________________________________________________ > For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. > __________________________________________________________________________________ From mark.yagnatinsky at barclays.com Fri May 13 03:46:49 2022 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Fri, 13 May 2022 03:46:49 +0000 Subject: can't run jshell 32-bit Windows in bleeding edge JDK In-Reply-To: <15060f95-ad5b-6d01-9485-adaf2c5679f3@oracle.com> References: <15060f95-ad5b-6d01-9485-adaf2c5679f3@oracle.com> Message-ID: Wow, nice timing. That ticket was literally created just half a day before I sent my email! Thanks! -----Original Message----- From: David Holmes Sent: Thursday, May 12, 2022 10:22 PM To: Yagnatinsky, Mark : Markets Pre Trade ; jdk-dev at openjdk.java.net Subject: Re: can't run jshell 32-bit Windows in bleeding edge JDK CAUTION: This email originated from outside our organisation - david.holmes at oracle.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. On 13/05/2022 9:28 am, mark.yagnatinsky at barclays.com wrote: > Thanks! Any idea roughly how soon 32-bit support is likely to land? > A few weeks? A few days? A few months? No idea sorry. I'm not even sure 32-bit Windows is on anyone's release radar, but keep an eye on: https://clicktime.symantec.com/3GEVrzHiMb1WzxUut7cRBVE6Gi?u=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8286642 Cheers, David > -----Original Message----- > From: David Holmes > Sent: Thursday, May 12, 2022 7:23 PM > To: Yagnatinsky, Mark : Markets Pre Trade > ; jdk-dev at openjdk.java.net > Subject: Re: can't run jshell 32-bit Windows in bleeding edge JDK > > > CAUTION: This email originated from outside our organisation - david.holmes at oracle.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. > Hi Mark, > > On 13/05/2022 8:58 am, mark.yagnatinsky at barclays.com wrote: >> Not sure if this is the right email list for this particular complaint, but I tried downloading this JDK a day or two ago (in the hopes of playing with Loom): >> https://clicktime.symantec.com/3BrVosoELgUE29suy7q4QrK6Gi?u=https%3A% >> 2F%2Fclicktime.symantec.com%2F36vLTs4QrDwpCTRVYG8SPoT6H4%3Fu%3Dhttps% >> 253A%252 >> F%2Fbuilds.shipilev.net%2Fopenjdk-jdk%2Fopenjdk-jdk-windows-x86_32-se >> r ver-release-msvc2019.zip And when I try to run jshell it hangs for >> 20 seconds or so and then exits with some timeout exception. > > No not the right mailing list for Aleksey's personal build farm. > Anything downloaded from: > > https://clicktime.symantec.com/38UXqd5ke9jpoe1u2HAMngU6H4?u=https%3A%2 > F%2Fbuilds.shipilev.net%2F > > is a matter for Aleksey. > > But also note that AFAICS there is no Loom support in any Windows 32-bit builds at this time. > > Cheers, > David > >> Any advice? >> >> This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://clicktime.symantec.com/3XWxBj2gBUZqiGonXN11tqW6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fweb-and-email-disclaimer.html. >> >> For important disclosures, please see: https://clicktime.symantec.com/3BM3qqsVRr2kfTm6HhX3pJB6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fsales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://clicktime.symantec.com/33RgL1WY1xCTcqmHz9g8pEG6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fbarclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://clicktime.symantec.com/3WGAzyFJQdj2xPRhnxCFoh86H4?u=http%3A%2F%2Fpublicresearch.barclays.com. >> _____________________________________________________________________ >> _ ____________ If you are incorporated or operating in Australia, >> read these important disclosures: >> https://clicktime.symantec.com/3BLriWAwKBXjUKWDQU1Uyfg6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fimportant-disclosures-asia-pacific.html. >> _____________________________________________________________________ >> _ ____________ For more details about how we use personal >> information, see our privacy notice: >> https://clicktime.symantec.com/36J7KDteteRmW6z6MUEkheH6H4?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fpersonal-information-use.html. >> _____________________________________________________________________ >> _ >> ____________ > > This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://clicktime.symantec.com/3UYXVnTL3bd8fSmz8kn27bT6Gi?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fweb-and-email-disclaimer.html. > > For important disclosures, please see: https://clicktime.symantec.com/37z8W6SmnbEwQ1YmqGGAtSR6Gi?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fsales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://clicktime.symantec.com/3x5hn3PH2Ri6jtGiWzBR4S6Gi?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fbarclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://clicktime.symantec.com/3G4gEr2JtemqZmzCcYB8CV26Gi?u=http%3A%2F%2Fpublicresearch.barclays.com. > ______________________________________________________________________ > ____________ If you are incorporated or operating in Australia, read > these important disclosures: https://clicktime.symantec.com/39b98pCgXU6yq88Fdw2Czow6Gi?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fimportant-disclosures-asia-pacific.html. > ______________________________________________________________________ > ____________ For more details about how we use personal information, > see our privacy notice: https://clicktime.symantec.com/3W4WD6DcZRWCTeJT4BQcT7j6Gi?u=https%3A%2F%2Fwww.cib.barclays%2Fdisclosures%2Fpersonal-information-use.html. > ______________________________________________________________________ > ____________ This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __________________________________________________________________________________ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __________________________________________________________________________________ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __________________________________________________________________________________ From dean.long at oracle.com Fri May 13 07:20:13 2022 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 13 May 2022 00:20:13 -0700 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: <4d30628e-5f3e-d5d7-ab65-63fc4f10e463@oracle.com> Vote: yes From dean.long at oracle.com Fri May 13 07:20:25 2022 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 13 May 2022 00:20:25 -0700 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <990D2089-30EB-40E4-AC57-C2788E7E0A90@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> <990D2089-30EB-40E4-AC57-C2788E7E0A90@oracle.com> Message-ID: <6a9f1dd1-b8d3-4088-07b9-b1acae6a5c15@oracle.com> Vote: yes From igor.veresov at oracle.com Fri May 13 21:29:48 2022 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 13 May 2022 21:29:48 +0000 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: <9AA584A5-1C73-4AE7-9223-D98F7D4D61EA@oracle.com> Vote: yes Igor > On May 6, 2022, at 1:56 AM, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From igor.veresov at oracle.com Fri May 13 21:30:01 2022 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 13 May 2022 21:30:01 +0000 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: <41777F5E-A16E-46B8-850C-1F0189B83EDD@oracle.com> Vote: yes Igor > On May 6, 2022, at 1:56 AM, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From kim.barrett at oracle.com Sat May 14 16:51:04 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 14 May 2022 16:51:04 +0000 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: vote: yes > On May 6, 2022, at 4:56 AM, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From kim.barrett at oracle.com Sat May 14 16:51:46 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 14 May 2022 16:51:46 +0000 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: <1DECB48A-8731-466C-A835-19319F5CD79A@oracle.com> vote: yes > On May 6, 2022, at 4:56 AM, Tobias Hartmann wrote: > > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level technologies with a focus > on algorithms and performance including High Performance Computing. Some of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the following eight are significant: > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote From thomas.stuefe at gmail.com Sat May 14 18:57:05 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 14 May 2022 20:57:05 +0200 Subject: CFV: New JDK Committer: Tobias Holenstein In-Reply-To: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> References: <77044a2e-51eb-e677-f3b7-665a5d3c337c@oracle.com> Message-ID: Vote: yes On Fri, May 6, 2022 at 10:57 AM Tobias Hartmann wrote: > Hi, > > I hereby nominate Tobias Holenstein to JDK Committer. > > Tobias is a member of the HotSpot Compiler Team at Oracle and located in > Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on > Distributed Systems, Parallel > and High Performance Computing and Compiler Design. Some of his project > work included parallel > algorithms for subgraph isomorphism and a LLIR interpreter backend for > PyPy's tracing JIT. > > Tobias contributed 15 changes to HotSpot [1] of which at least the > following eight are significant: > > https://github.com/openjdk/jdk/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb > > https://github.com/openjdk/jdk/commit/ebb1363e5d6b47daf1badad93490580fedcb0572 > > https://github.com/openjdk/jdk/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b > > https://github.com/openjdk/jdk/commit/1f101b04f4d7c166cc0a830383e4e08025df5c74 > > https://github.com/openjdk/jdk/commit/1b14157677b34891385f643a76a7aa19d7003acf > > https://github.com/openjdk/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71 > > https://github.com/openjdk/jdk/commit/165f516101016e84ebea1444fbac9b3880a940f3 > > https://github.com/openjdk/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=tobiasholenstein > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote > From thomas.stuefe at gmail.com Sat May 14 18:57:25 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 14 May 2022 20:57:25 +0200 Subject: CFV: New JDK Committer: Emanuel Peter In-Reply-To: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> References: <9b29f715-d81c-7dbd-8e2f-6efaf4bb8938@oracle.com> Message-ID: Vote: yes On Fri, May 6, 2022 at 10:57 AM Tobias Hartmann wrote: > Hi, > > I hereby nominate Emanuel Peter to JDK Committer. > > Emanuel is a member of the HotSpot Compiler Team at Oracle and located in > Zurich, Switzerland. He > holds a Masters degree in Computer Science from ETH Zurich focusing on > Sequence-to-Graph Alignment. > At ETH, Emanuel did significant study and project work with system-level > technologies with a focus > on algorithms and performance including High Performance Computing. Some > of his project work > included C++ and Python development for distributed applications. > > Emanuel contributed 15 changes to HotSpot [1] of which at least the > following eight are significant: > > https://github.com/openjdk/jdk/commit/68b40ec28658a2dd829c77281b0025e16095c170 > > https://github.com/openjdk/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 > > https://github.com/openjdk/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 > > https://github.com/openjdk/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 > > https://github.com/openjdk/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0 > > https://github.com/openjdk/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef > > https://github.com/openjdk/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68 > > https://github.com/openjdk/jdk/commit/4a5e7a1ada611cfdefdc3b9a6fada05494e07390 > > Votes are due by Friday, 20 May 2022 at 09:00 UTC. > > 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, > Tobias > > [1] https://github.com/openjdk/jdk/commits?author=eme64 > [2] https://openjdk.java.net/census > [3] https://openjdk.java.net/projects/#committer-vote > From rajan.halade at oracle.com Tue May 17 17:48:32 2022 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 17 May 2022 17:48:32 +0000 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: Vote: Yes Thanks, Rajan From: jdk-dev on behalf of Daniel Fuchs Date: Friday, May 6, 2022 at 9:02 AM To: jdk-dev Subject: CFV: New JDK Reviewer: Jaikiran Pai I hereby nominate Jaikiran Pai [1] to JDK Reviewer. From dean.long at oracle.com Tue May 17 21:04:31 2022 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 17 May 2022 14:04:31 -0700 Subject: CFV: New JDK Reviewer: Jaikiran Pai In-Reply-To: References: <841b5f76-f5db-551a-1a96-8f0e05a23fe4@oracle.com> Message-ID: <7cea26a5-f6bd-9e36-280c-ae913e96976d@oracle.com> Vote: yes From mark.reinhold at oracle.com Tue May 17 21:50:20 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 17 May 2022 14:50:20 -0700 (PDT) Subject: New candidate JEP: 428: Structured Concurrency (Incubator) Message-ID: <20220517215020.3DD9F5372B6@eggemoggin.niobe.net> https://openjdk.java.net/jeps/428 Summary: Simplify multithreaded programming by introducing a library for structured concurrency. Structured concurrency treats multiple tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is an incubating API. - Mark From joe.darcy at oracle.com Thu May 19 15:43:48 2022 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 19 May 2022 08:43:48 -0700 Subject: Reminder: file JDK 19 CSRs well ahead of June 9, 2022 rampdown 1 start In-Reply-To: <83f5189e-f6a3-3afa-e4f8-5d04e68981f8@oracle.com> References: <83f5189e-f6a3-3afa-e4f8-5d04e68981f8@oracle.com> Message-ID: <752cca34-d614-15a9-18a3-ed73dd92376f@oracle.com> Only three weeks remaining until JDK 19 rampdown 1; get any remaining large CSRs submitted without delay, -Joe On 4/21/2022 3:56 PM, Joseph D. Darcy wrote: > Hello, > > Per the JDK 19 schedule (http://openjdk.java.net/projects/jdk/19/), > rampdown 1 for that release starts on June 9, 2022. > > An advanced reminder to factor in sufficient review time for any > projects needing CSR review before getting pushed into JDK 19. Large > projects, including JEPs, should often use the two-phase CSR process > (https://wiki.openjdk.java.net/display/csr/Main) rather than the > one-phase process. The nominal SLA for each CSR phase is one week. To > accommodate the possibility of needing to respond to feedback from the > CSR, I recommend a large project budget for at least three weeks of > CSR review time ahead of a planned integration date. > > Cheers, > > -Joe > CSR Lead > From tobias.hartmann at oracle.com Fri May 20 10:32:20 2022 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 20 May 2022 12:32:20 +0200 Subject: Result: New JDK Committer: Emanuel Peter Message-ID: <3f064925-b476-0e9c-9bd8-eec2235d5b30@oracle.com> Voting for Emanuel Peter [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Tobias [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-May/006551.html From tobias.hartmann at oracle.com Fri May 20 10:32:19 2022 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 20 May 2022 12:32:19 +0200 Subject: Result: New JDK Committer: Tobias Holenstein Message-ID: <42c61f27-2ce5-7c04-da10-9192e7c92f1e@oracle.com> Voting for Tobias Holenstein [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Tobias [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-May/006550.html From martin.doerr at sap.com Mon May 23 09:26:38 2022 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 May 2022 09:26:38 +0000 Subject: CFV: New JDK Committer: Tyler Steele In-Reply-To: References: Message-ID: Vote: yes Voting will end tomorrow. Best regards, Martin Von: Doerr, Martin Datum: Montag, 9. Mai 2022 um 17:19 An: jdk-dev at openjdk.java.net Betreff: CFV: New JDK Committer: Tyler Steele Hi, I hereby nominate Tyler Steele to JDK Committer. Tyler works for IBM and he has taken responsibility for the AIX OS. He has already contributed 10 changes to the jdk repository [1]. One of his changes was quite complex: https://github.com/openjdk/jdk/commit/c0275e18b7cb4a01385b79ced46560322aeacc97 Some other ones are small but were not easy to find or require good knowledge of the VM and how the tests work. I guess such changes will be typical for his role. In addition, he?s contributing to the jdk-updates projects focusing on AIX. He has also helped to review and test PPC64 and s390 changes. Votes are due by Tuesday, 24 May 2022 at 09:00 UTC. 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, Martin [1] https://github.com/openjdk/jdk/commits?author=backwaterred [2] https://openjdk.java.net/census [3] https://openjdk.java.net/projects/#committer-vote From martin.doerr at sap.com Tue May 24 09:35:25 2022 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 24 May 2022 09:35:25 +0000 Subject: Result: New JDK Committer: Tyler Steele In-Reply-To: References: Message-ID: Voting for Tyler Steele [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Martin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-May/006595.html From mark.reinhold at oracle.com Tue May 24 19:28:19 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 May 2022 12:28:19 -0700 Subject: JEP proposed to target JDK 19: 405: Record Patterns (Preview) In-Reply-To: <20220512210726.E34E3536B2F@eggemoggin.niobe.net> References: <20220512210726.E34E3536B2F@eggemoggin.niobe.net> Message-ID: <20220524122819.45791222@eggemoggin.niobe.net> 2022/5/12 14:07:26 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 19: > > 405: Record Patterns (Preview) > https://openjdk.java.net/jeps/405 > > Summary: Enhance the Java programming language with record patterns > to deconstruct record values. Record patterns and type patterns can be > nested to enable a powerful, declarative, and composable form of data > navigation and processing. This is a preview language feature. > > 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, 19 May, 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 19. Hearing no objections, I?ve targeted this JEP to JDK 19. - Mark From daniel.fuchs at oracle.com Wed May 25 08:45:39 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 25 May 2022 09:45:39 +0100 Subject: Result: New JDK Reviewer: Jaikiran Pai Message-ID: Hi, Voting for Jaikiran Pai (jpai) [1] is now closed. Yes: 23 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. best regards, -- daniel [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-May/006564.html From mark.reinhold at oracle.com Thu May 26 19:05:05 2022 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 26 May 2022 12:05:05 -0700 (PDT) Subject: JEP proposed to target JDK 19: 428: Structured Concurrency (Incubator) Message-ID: <20220526190505.B8C0753818F@eggemoggin.niobe.net> The following JEP is proposed to target JDK 19: 428: Structured Concurrency (Incubator) https://openjdk.java.net/jeps/428 Summary: Simplify multithreaded programming by introducing a library for structured concurrency. Structured concurrency treats multiple tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is an incubating 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, 2 June, 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 19. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From aph-open at littlepinkcloud.com Fri May 27 14:05:49 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 27 May 2022 15:05:49 +0100 Subject: What should the relationship between ports and developers of large projects be? Message-ID: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> In the discussion about Porting JEP 425 (virtual threads preview), I see that some ports only just started, and we're less than a couple of weeks out from RDP 1. I understand why no one likes to start early: it's not at all easy to port a feature before it's in its final form. But given that some of the responses were of the form "fix crashes after..." I assume that some porters were taken by surprise. [ I may have misunderstood the situation, in which case I apologize, and please ignore this email. ] Full disclosure: I was aware that Loom was targeting virtual threads for JDK 19, but I'd failed to notice the significance of Virtual Threads being a Preview, not an Incubator: all ports *must* implement a Preview. So, it's going to be something of a rush. I hope that JDK 19 won't be blighted by broken or absent ports because of this. This would be a great shame. It's been pointed out to me that The Virtual Threads patch was in review for a month, and that porters were notified in September last year that Virtual Threads were coming, so ports should start looking at their patches. I don't know if any ports did. Perhaps there has not been enough communication between owners of ports and developers of big-ticket new items such as Loom. Perhaps, also, given the shock of Virtual Threads dropping when it did, people will be more aware when the next big-ticket item (JEP 424?) drops. One thing which has been suggested to me is the that new features should be introduced earlier in the release cycle. I'm not sure how practical that is. Also, it can be quite difficult to reach port owners: once a port has going into mainline, it might not be clear even who they are. I would be nice if out of this came an invigorated two-way flow of information between new projects and port maintainers, so that everyone understands where they are. I don't know how to make that happen, but perhaps we can come up with something. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From maurizio.cimadamore at oracle.com Fri May 27 14:59:07 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 27 May 2022 15:59:07 +0100 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> Message-ID: Hi Andrew, JEP 424 has already been integrated into mainline. As far as I know there were no issues as a result of that integration, as the code for the foreign API already has the required stubs so that it will compile in all the ports (even though the `Linker` might not run, but that's ok, at least until some effort is put into providing an implementation of the `Linker` class in those ports). Cheers Maurizio On 27/05/2022 15:05, Andrew Haley wrote: > Perhaps, also, > given the shock of Virtual Threads dropping when it did, people will > be more aware when the next big-ticket item (JEP 424?)? drops. From aph-open at littlepinkcloud.com Fri May 27 15:24:17 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 27 May 2022 16:24:17 +0100 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> Message-ID: <7ace94c2-a3f1-6429-ec05-a2f999b86fb9@littlepinkcloud.com> On 5/27/22 15:59, Maurizio Cimadamore wrote: > JEP 424 has already been integrated into mainline. As far as I know > there were no issues as a result of that integration, as the code for > the foreign API already has the required stubs so that it will compile > in all the ports (even though the `Linker` might not run, but that's ok, > at least until some effort is put into providing an implementation of > the `Linker` class in those ports). Yes, I see. So, it's up to the porters to set their own schedule for implementing the Linker class. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph-open at littlepinkcloud.com Fri May 27 16:28:19 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 27 May 2022 17:28:19 +0100 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> Message-ID: <621d8e57-6b67-f839-d708-fd71e6b0ec8a@littlepinkcloud.com> On 5/27/22 15:05, Andrew Haley wrote: > > So, it's going to be something of a rush. I hope that JDK 19 won't be > blighted by broken or absent ports because of this. This would be a > great shame. I see that Alan Bateman just posted in https://github.com/openjdk/jdk/pull/8919 that there will hopefully soon be an alternative implementation of virtual threads backed by platform threads, that allows ports to pass conformance tests, although the result clearly won't scale like real virtual threads do. The rest of my message about communicating with porters still stands, I think. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jesper.wilhelmsson at oracle.com Fri May 27 19:33:31 2022 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 27 May 2022 19:33:31 +0000 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: <621d8e57-6b67-f839-d708-fd71e6b0ec8a@littlepinkcloud.com> References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> <621d8e57-6b67-f839-d708-fd71e6b0ec8a@littlepinkcloud.com> Message-ID: > On 27 May 2022, at 18:28, Andrew Haley wrote: > > On 5/27/22 15:05, Andrew Haley wrote: > >> So, it's going to be something of a rush. I hope that JDK 19 won't be >> blighted by broken or absent ports because of this. This would be a >> great shame. > > I see that Alan Bateman just posted in https://github.com/openjdk/jdk/pull/8919 > that there will hopefully soon be an alternative implementation of virtual > threads backed by platform threads, that allows ports to pass conformance > tests, although the result clearly won't scale like real virtual threads do. > > The rest of my message about communicating with porters still stands, I think. A good start would be a list of contacts for each port. Is there any such list and is it kept up to date? Or would it be enough for a project lead of a soon to be integrated project to send an email to the porters-dev list and assume that all active ports are represented there? /Jesper > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Sat May 28 07:21:48 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 28 May 2022 09:21:48 +0200 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> <621d8e57-6b67-f839-d708-fd71e6b0ec8a@littlepinkcloud.com> Message-ID: On Fri, May 27, 2022 at 9:34 PM Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > > On 27 May 2022, at 18:28, Andrew Haley > wrote: > > > > On 5/27/22 15:05, Andrew Haley wrote: > > > >> So, it's going to be something of a rush. I hope that JDK 19 won't be > >> blighted by broken or absent ports because of this. This would be a > >> great shame. > > > > I see that Alan Bateman just posted in > https://github.com/openjdk/jdk/pull/8919 > > that there will hopefully soon be an alternative implementation of > virtual > > threads backed by platform threads, that allows ports to pass conformance > > tests, although the result clearly won't scale like real virtual threads > do. > > > > The rest of my message about communicating with porters still stands, I > think. > > A good start would be a list of contacts for each port. Is there any such > list and is it kept up to date? > Or would it be enough for a project lead of a soon to be integrated > project to send an email to the porters-dev list and assume that all active > ports are represented there? > > /Jesper > > Yes, a list of contacts would help. E.g. I am not sure who maintains the various BSDs. The list could also contain special configurations like Zero or Alpine. Is there a common understanding about which platforms are "first tier"? When finishing a large feature, it can help to have a few online meetings in addition to ML discussions. Some people find it easier to speak than write. Especially if a feature is developed within one organization, where a lot of information flows internally. For JEP387 we had such meetings in the review phase, and they worked quite well. Stating the obvious, it helps if large patches were split up into smaller ones. The loom patch brought my browser to its knees. For that, maybe lower the bar for introducing patches whose sole purpose is to prepare a larger integration or make merging side projects with mainline easier. I had preparatory patches like these rejected in the past, understandingly, on the ground that they had no merit on their own. Since porters are very few, it can be helpful to be able to delay start porting until the dust has settled and the kinks worked out. For that, a feature would have to be switchable. But I understand that is not always possible. Thanks, Thomas From lgxbslgx at gmail.com Sat May 28 10:26:08 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 28 May 2022 18:26:08 +0800 Subject: Fwd: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: <34217bf3-f5a7-c8d2-40e9-b73176fa46ec@oracle.com> <84917f66-907a-7172-3e14-984a8e94c579@oracle.com> Message-ID: > @lgxbslgx - JEP has been targeted, but the JEP action seems to be blocking this - what should we do? This issue [1] was solved yesterday. Erik's comment in the issue states the reason. cc'ing jdk-dev to inform other developers that the jep command can be used. [1] https://bugs.openjdk.java.net/browse/SKARA-1454 From aph-open at littlepinkcloud.com Sat May 28 18:55:46 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Sat, 28 May 2022 19:55:46 +0100 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> <621d8e57-6b67-f839-d708-fd71e6b0ec8a@littlepinkcloud.com> Message-ID: <5770a682-5b27-7977-daa4-d3370f8230c0@littlepinkcloud.com> On 5/28/22 08:21, Thomas St?fe wrote: > > Yes, a list of contacts would help. E.g. I am not sure who maintains the various BSDs. FreeBSD Arm is Greg Lewis . See https://github.com/battleblow . That's a small start. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph-open at littlepinkcloud.com Sun May 29 08:45:07 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Sun, 29 May 2022 09:45:07 +0100 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> <621d8e57-6b67-f839-d708-fd71e6b0ec8a@littlepinkcloud.com> Message-ID: <19cad970-8476-f2f8-d456-bd39d1537f9f@littlepinkcloud.com> On 5/28/22 08:21, Thomas St?fe wrote: > Stating the obvious, it helps if large patches were split up into smaller?ones.?The loom patch brought my?browser to its?knees. For that, maybe lower the bar for introducing patches whose sole purpose is to prepare a larger integration or make merging side projects with mainline easier. I had preparatory patches like these rejected in the past, understandingly, on the ground that they had no merit on their own. Interesting. From what I know of the virtual threads patch, there's a tremendous amount of interdependence, from the VM to the JVMTI to to the library code, and so on. I believe it would have been very costly to split up the patch, and it would have been impossible to test any of it until it was all in. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From peter.tribble at gmail.com Sun May 29 17:21:47 2022 From: peter.tribble at gmail.com (Peter Tribble) Date: Sun, 29 May 2022 18:21:47 +0100 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: <5770a682-5b27-7977-daa4-d3370f8230c0@littlepinkcloud.com> References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> <621d8e57-6b67-f839-d708-fd71e6b0ec8a@littlepinkcloud.com> <5770a682-5b27-7977-daa4-d3370f8230c0@littlepinkcloud.com> Message-ID: On Sat, May 28, 2022 at 7:56 PM Andrew Haley wrote: > On 5/28/22 08:21, Thomas St?fe wrote: > > > > Yes, a list of contacts would help. E.g. I am not sure who maintains the > various BSDs. > > FreeBSD Arm is Greg Lewis . See > https://github.com/battleblow . > > That's a small start. > Even smaller, I'm maintaining the unofficial illumos/Solaris port (gcc+amd64). Some history: https://ptribble.blogspot.com/2021/12/keeping-java-alive-on-illumos.html Generally the illumos distributions build their own jdk packages rather than having a separate cross-distro package, but I try to keep close enough so that every weekly tag will build and basically work, but having the resources to even test let alone fix something like loom is challenging. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From Alan.Bateman at oracle.com Mon May 30 09:05:19 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 May 2022 10:05:19 +0100 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> Message-ID: <2f095d83-618e-4fe0-e706-4eff8832d5f7@oracle.com> We have discussed ports, the suggestion of a "Maintainers" file to list the owners of ports and features, and also putting ports into tiers at a number of OpenJDK Committers' Workshops. As I recall, it was just discussion and there wasn't any proposals to decide or vote on. It's been a few years and there are a few additional ports added to the OpenJDK project with JEPs. These JEPs have/had owners so there is at least a starting point there. As we've seen from the replies, there are also a few ports that are maintained in downstream repos. In the early days of OpenJDK, the Porters Group was created to help create porting projects. The porters-dev mailing list still exists and maybe that is another starting point. As regards JEP 425. I agree with your comment that monster features like this should try to integrate early in a release. A big change will usually result in a few surprises and follow-up issues to address after their initial integration. In this case, we had really hoped to have it integrated much earlier but it wasn't to be. These big integrations aren't easy to do, esp. with a moving target that is the main line and the constant merging and rework to keep the code working and tests passing. It's also impossible to know how long the code review and the PR for such a feature might take. You mentioned not noticing the significance of JEP 425 being a preview feature and that preview features are not optional. That's a good discussion topic as I think several people were surprised by this.? Every feature release since Java 14 has had preview features but it's been preview language features that didn't have a big impact on the runtime. Sealed classes and records required some support in the runtime when in preview but it wasn't anything that required porting work. JEP 424 and JEP 425 are the first preview APIs to include big changes to the runtime and require porting work to platforms beyond x64 and aarch64. It's okay for a port to sit out a release but it might not be necessary for 19. For JEP 424, an implementation of the native Linker is optional as Maurizio mentioned. For JEP 425 we hope to integrate a non-scalable implementation of virtual threads that ports can use in the interim. So what can we do better? I don't disagree that communication could have been better in this case. We did send a heads-up to porters-dev, as you noted, but there could have been more communication before the JEP was proposed to target and a reminder that preview features are not optional. This goes both ways too. If a port is actively maintained then it would be helpful to start before the code is final and before the feature integrates. I don't know how practical it would to have a "ready for porting" milestone in some projects, maybe it would but more likely it would be dealing with at least some code shimmer right up to integration. Thomas St?fe's suggestion to run a few online meetings with maybe design/code walk though is good idea. If we had JVMLS then there would have been recorded sessions and probably a few in-person meetings too. Thomas also brings up the suggestion to split up large patches into smaller chunks. We did try in this case but it was weighted more on the libraries side where it was possible to integrate a lot preparatory changes and 3 JEPs in advance of the main event. We didn't identify significant chunks for the hotspot code that could have integrated in advance, maybe we should have tried harder there. With Project Jigsaw (JDK 9) we were able to split the project into 3 big integrations/milestones and >1000 bite size pieces to prepare the code base but we didn't have anything like this here. -Alan. From jorn.vernee at oracle.com Mon May 30 10:19:05 2022 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Mon, 30 May 2022 12:19:05 +0200 Subject: What should the relationship between ports and developers of large projects be? In-Reply-To: <7ace94c2-a3f1-6429-ec05-a2f999b86fb9@littlepinkcloud.com> References: <8f69d679-8ce3-94cd-7243-9b999eb65b6a@littlepinkcloud.com> <7ace94c2-a3f1-6429-ec05-a2f999b86fb9@littlepinkcloud.com> Message-ID: On 27/05/2022 17:24, Andrew Haley wrote: > On 5/27/22 15:59, Maurizio Cimadamore wrote: >> JEP 424 has already been integrated into mainline. As far as I know >> there were no issues as a result of that integration, as the code for >> the foreign API already has the required stubs so that it will compile >> in all the ports (even though the `Linker` might not run, but that's ok, >> at least until some effort is put into providing an implementation of >> the `Linker` class in those ports). > > Yes, I see. So, it's up to the porters to set their own schedule for > implementing the Linker class. > Yes, that's right. The platform dependent parts of the linker API are currently specified to throw an UnsupportedOperationException on unsupported native platforms. The methods in question are: ?- Linker::nativeLinker [1] ?- VaList::empty [2] ?- VaList::make [3] ?- VaList::ofAddress [4] There is also the Linker::defaultLookup method [5], but it can just return an empty lookup as well. (although, it might already just work due to the way it's implemented). The intent is to keep things like that for the time being. We might be able to provide a fallback implementation of Linker based on libffi as well (I've started on a POC [6], but didn't get that far yet). That won't cover VaList though. As far as I can see libffi doesn't implement that. In the future we will likely make these APIs required on all platforms though (i.e. remove the UOE from the specification). Jorn [1]: https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/lang/foreign/Linker.html#nativeLinker() [2]: https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/lang/foreign/VaList.html#empty() [3]: https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/lang/foreign/VaList.html#make(java.util.function.Consumer,java.lang.foreign.MemorySession) [4]: https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/lang/foreign/VaList.html#ofAddress(java.lang.foreign.MemoryAddress,java.lang.foreign.MemorySession) [5]: https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/lang/foreign/Linker.html#defaultLookup() [6]: https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:Zero_Linker From yakavets at google.com Tue May 31 22:59:37 2022 From: yakavets at google.com (Eugene Yakavets) Date: Tue, 31 May 2022 15:59:37 -0700 Subject: FastThrow breaks Throwable.addSuppressed ? Message-ID: Throwable#addSuppressed is used for combining exceptions when two independent exceptions can be thrown from the same code block. Typical case is try-with-resources where one exception is from try block, and another from closing resource. #addSuppressed internally verifies that suppressed exception and current exception are not the same. That is a reasonable condition to check, but it doesn't seem to work well with fast throw optimization when exceptions are being replaced with the same class instance, and that condition starts to fail. Consider the example below: it finishes successfully with -XX:-OmitStackTraceInFastThrow flag, and fails with IllegalArgumentException "Self-suppression not permitted" if optimization is enabled. public class Test { static class SomeCloseable implements AutoCloseable { @Override public void close() { throwsNPE(); } } static void throwsNPE() { ((Object) null).getClass(); } //run with and without -XX:-OmitStackTraceInFastThrow public static void main(String[] args) { for (int i = 0; i < 100_000; i++) { try (SomeCloseable c = new SomeCloseable()) { throwsNPE(); } catch (NullPointerException expectedException) { assert expectedException.getSuppressed().length == 1; } } } } Could self match be no-op instead of exception in Throwable#addSuppressed? Thanks, Eugene