On Fri, 19 Jul 2024 14:20:48 GMT, Nizar Benalla wrote:
>> Can I get a review for this change that fixes some broken links in javadoc
>> comments? The new docs are hosted
>> [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/).
>>
>> It's mostly fixing some relative li
On Wed, 4 Sep 2024 15:23:51 GMT, Maurizio Cimadamore
wrote:
> Scoped methods are critical methods in the FFM API where memory is accessed
> in a potentially unsafe way. When closing shared arenas, we look at threads
> in the middle of a scoped operation involving that arena, and if we find one
On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore
wrote:
>> Scoped methods are critical methods in the FFM API where memory is accessed
>> in a potentially unsafe way. When closing shared arenas, we look at threads
>> in the middle of a scoped operation involving that arena, and if we find
On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore
wrote:
>> Scoped methods are critical methods in the FFM API where memory is accessed
>> in a potentially unsafe way. When closing shared arenas, we look at threads
>> in the middle of a scoped operation involving that arena, and if we find
On Fri, 6 Sep 2024 18:45:42 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>>
>> Work was begun in [another PR
On Fri, 6 Sep 2024 18:45:42 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>>
>> Work was begun in [another PR
On Fri, 6 Sep 2024 18:45:42 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>>
>> Work was begun in [another PR
On Mon, 9 Sep 2024 12:59:15 GMT, Maurizio Cimadamore
wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Drop spurious change
>
> src/java.base/share/classes/jdk/internal/access/foreign/MappedMemoryUtilsProxy.j
On Mon, 9 Sep 2024 21:11:32 GMT, Maurizio Cimadamore
wrote:
>> The new test added by https://github.com/openjdk/jdk/pull/20854 fails
>> spuriously.
>> While JNI lookup is now moved into the static initializer of the
>> `MappedMemoryUtils` class, this class might only get initialized while in
On Fri, 1 Jul 2022 08:35:37 GMT, Xue-Lei Andrew Fan wrote:
>> This is a follow up update per comments in [JDK-8287384
>> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
>> open part looks good to me. Please help to run Mach5 just case the closed
>> test cases are i
On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeliński wrote:
>> This patch removes many unused variables and one unused label reported by
>> the compilers when relevant warnings are enabled.
>>
>> The unused code was found by compiling after removing `unused` from the list
>> of disabled warnings
On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart wrote:
> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s)
> when used internally in JDK for per-carrier-thread caches of native
> ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such
> TerminatingThreadLo
On Fri, 5 Aug 2022 09:54:36 GMT, Peter Levart wrote:
>> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s)
>> when used internally in JDK for per-carrier-thread caches of native
>> ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such
>> TerminatingThre
On Wed, 10 Aug 2022 13:52:48 GMT, Sean Coffey wrote:
>> In the broken case where the conf/security/java.security configuration file
>> doesn't exist, the JDK should throw an Error.
>>
>> CSR in progress.
>
> Sean Coffey has updated the pull request incrementally with one additional
> commit s
On Thu, 11 Aug 2022 07:13:34 GMT, Sean Coffey wrote:
>> In the broken case where the conf/security/java.security configuration file
>> doesn't exist, the JDK should throw an Error.
>>
>> CSR in progress.
>
> Sean Coffey has updated the pull request incrementally with one additional
> commit s
On Tue, 30 Aug 2022 07:10:36 GMT, Andrey Turbanov wrote:
> After integration of
> [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields
> were added to `SharedSecrets` class. It make sense to update their reading
> code to use the same idiom.
Surprising that the additio
On Thu, 1 Sep 2022 17:56:03 GMT, Lance Andersen wrote:
>>> It's better. Do you need to explicitly say "For all other cases"?
>>
>> I thought it is worth being specific, but happy to leave it out if you and
>> others prefer
>>>
>>> My original comment was more about explaining `getManifest()`
On Wed, 14 Sep 2022 10:31:41 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Wed, 14 Sep 2022 16:43:43 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Fri, 16 Sep 2022 16:15:44 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 51:
>>
>>> 49: * If {@code META-INF/} is the first entry in the input stream it will
>>> be
>>> 50: * also not be returned by {@link #getNextEntry()} and
>>> 51: * {@
On Fri, 16 Sep 2022 18:33:46 GMT, Lance Andersen wrote:
>> Okay, in which case what would you think about just saying that the
>> getNextEntry/getNextJarEntry method do not return the Manifest when it's at
>> the start of the stream, and it's unspecified whether they return the
>> Manifest whe
On Sat, 17 Sep 2022 14:35:46 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Sun, 18 Sep 2022 20:33:55 GMT, Lance Andersen wrote:
> I can remove, but I am not sure I agree we need to describe main vs attribute
> here given we are pointing to the Jar spec and if there is any discussion of
> Pre-entry attributes, it should be in JarEntry IMHO. I guess the
> clarificat
On Sun, 18 Sep 2022 20:43:25 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Mon, 19 Sep 2022 10:21:30 GMT, Lance Andersen wrote:
> OK, will make another pass at this today
I looked at the latest draft (2bafc00c). I think it would help if the section
"Verifying a JarInputStream" were renamed to "Signed JAR files". The link to
getManifest makes the reader wonder if
On Tue, 20 Sep 2022 10:49:59 GMT, Lance Andersen wrote:
>>> OK, will make another pass at this today
>>
>> I looked at the latest draft (2bafc00c). I think it would help if the
>> section "Verifying a JarInputStream" were renamed to "Signed JAR files".
>> The link to getManifest makes the rea
On Tue, 20 Sep 2022 18:08:21 GMT, Lance Andersen wrote:
> Assuming we are set with the other changes, did you want to add the following
> paragraph (or similar) at line 58 to make it clear that if the Manifest is
> not found, then the JarEntry attributes will not be available:
This is somethin
On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote:
> Now that Thread.stop has been degraded to throw
> `UnsupportedOperationException` (JDK-8299610) the only direct source of async
> exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread`
> code, remove the `stillborn` fie
On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote:
> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
src/java.base/share/native/libzip/zlib/zlib.h line 756:
> 754:If this is done, the old level and strategy will be applied to the
> data
> 755:compressed
On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Fri, 23 Sep 2022 17:45:26 GMT, Sean Mullan wrote:
> Do you also want to say "Otherwise, the method returns `null`."
The method description has that already, it might be too much detail to include
in the class description,.
-
PR: https://git.openjdk.org/jdk/pull/10045
This is a test only change to remove the granting of
RuntimePermission("stopThread") from the tests. With Thread.stop changed to
throw UOE it means there is nothing that requires this permission.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/10577/f
On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman wrote:
> This is a test only change to remove the granting of
> RuntimePermission("stopThread") from the tests. With Thread.stop changed to
> throw UOE it means there is nothing that requires this permission.
This pull r
On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote:
>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains six commits:
>
> - Reinstate t
On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey wrote:
>> New JFR event to record state of initial security properties.
>>
>> Debug output is also now added for these properties via
>> -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional
On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters wrote:
> Some external libraries required by native code are linked via linker
> comments embedded in pragmas. Searching for which libraries are linked can
> then become frustrating and confusing since they may be included in an
> obscure place,
On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote:
> This is a continuation of the effort to update all our URLs to the new
> top-level domain.
>
> This patch updates (most) URLs in testing code. There still exists references
> to openjdk.java.net, but that are not strictly used as no
On 26/10/2022 02:58, Peter Firmstone wrote:
:
Using the existing permission check hooks in the JDK allows us to
significantly speed up our development efforts. Each time a
permission check hook is removed, we will need to replace it with
instrumentation. I was hoping this could be done in
On 26/10/2022 09:02, Peter Firmstone wrote:
:
That's correct, however some parts will bit rot faster than others,
historically some parts of the JDK are very slow to change, unless
someone comes through deliberately removing them, which I would hope
not, but I realise that new methods and
On 26/10/2022 23:53, Peter Firmstone wrote:
The change will have some performance impact, by requiring redundant
parsing.
Just thought I'd mention it, in case it hasn't been thought of. If you
do an internet search there are other implementations of RFC3986 in
java also.
https://github.com/
On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote:
>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
>> to parse or construct any URL.
>>
>> The `java.net.URL` class does not itself encode or decode any URL components
>> according to the escaping mechanism defin
On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote:
> You have jumped through some refactoring hoops to be able to apply the
> deprecation suppression to as little code as possible .. having made such
> changes, then why didn't you just make the recommended change instead ?
>
> Should I presume
On Mon, 31 Oct 2022 13:45:10 GMT, Jim Laskey wrote:
>> Yes, it only occurs to me mid review, that said there is already an
>> implementation in the jdk of a compact immutable that allow null inside the
>> JDK (this implementation is used when stream.toList() is used).
>> Using that implementati
On Tue, 1 Nov 2022 14:22:18 GMT, Daniel Fuchs wrote:
>> To be discussed: I actually wanted the deprecation link ( the link from
>> `@deprecated` ) to lead here because I find that the whole section is
>> relevant for developers who might want to decide whether to actually move
>> away from usi
On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs wrote:
>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
>> to parse or construct any URL.
>>
>> The `java.net.URL` class does not itself encode or decode any URL components
>> according to the escaping mechanism define
On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs wrote:
> When referencing an RFC, it might be good to keep the RFC number in the text
> link. For instance I see that java.net.URL now has this:
I agree and also to add that some RFCs have commas in their titles, the same
separator used when there
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley wrote:
> JEP 429 implementation.
src/hotspot/share/prims/jvm.cpp line 4072:
> 4070: */
> 4071: JVM_ENTRY(void, JVM_EnsureMaterializedForStackWalk_func(JNIEnv* env,
> jobject vthread, jobject value))
> 4072: //asm("nop");
The asm("nop") was comm
On Tue, 15 Nov 2022 14:15:26 GMT, Andrew Haley wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 318:
>>
>>> 316: }
>>> 317: }
>>> 318: @Hidden
>>
>> Can we rename this to runWith(Runnable, Object) in both Thread and
>> VirtualThread to keep the naming con
On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote:
>> NativePRNG SecureRandom doesn’t scale with number of threads. The
>> performance starts dropping as we increase the number of threads. Even going
>> from 1 thread to 2 threads shows significant drop. The bottleneck is the
>> singleton Rand
On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg wrote:
> This PR proposes the introduction of **guarding** of the use of
> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
> Function and Memory access, it is possible to derive Buffer instances that
> are backed by nat
On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg wrote:
> This PR proposes the introduction of **guarding** of the use of
> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
> Function and Memory access, it is possible to derive Buffer instances that
> are backed by nat
On Mon, 21 Nov 2022 11:36:44 GMT, Per Minborg wrote:
>> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:
>>
>>> 250: try {
>>> 251: // 'dst' is guaranteed not to be associated with a
>>> closeable session.
>>> 252: // Hence, there is no need fo
On Mon, 21 Nov 2022 12:16:01 GMT, Maurizio Cimadamore
wrote:
>> Eventually, I hope most of them will be named `_`.
>
> maybe just `bufferLock` and and just `acquireBuffer` ?
Would it be possible to re-examine acquireSession returning Runnable and
acquireSessionAsAutoCloseable returning AutoClo
On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
On Mon, 21 Nov 2022 14:02:38 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
On Mon, 21 Nov 2022 16:08:20 GMT, Per Minborg wrote:
> Although this looks much simpler and concise, it means "a new object is
> created for each invocation"
My comment was actually to see if DirectBuffer could extend AutoCloseable so
that the acquire returns "this" for the non-session case.
On Mon, 21 Nov 2022 17:00:52 GMT, Maurizio Cimadamore
wrote:
>>> Although this looks much simpler and concise, it means "a new object is
>>> created for each invocation"
>>
>> My comment was actually to see if DirectBuffer could extend AutoCloseable so
>> that the acquire returns "this" for
On Mon, 21 Nov 2022 15:29:11 GMT, Per Minborg wrote:
> That is clear to me but I am trying to prevent future redundant guarding.
> Anyway, I will remove the comments.
The faraway use sites look much better now. The performance sensitive usages
need close attention. Can you summarise the change
On Tue, 22 Nov 2022 09:29:14 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rework Acquisition
>
> src/java.base/share/classes/java/nio/Buffer.java line 827:
>
>> 825:
>> 826:
On Tue, 22 Nov 2022 09:38:35 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:
>>
>>> 588: int pos)
>>> 589: throws IOException {
>>> 590: try (var guard = NIO_ACCESS.acqui
On Tue, 22 Nov 2022 16:26:30 GMT, Weijun Wang wrote:
> With the introduction of Virtual Threads, the current subject is no longer
> guaranteed to be inherited in a new thread. Remove this requirement until we
> find another way to implement `Subject::current`.
Just re-reading the javadoc for S
On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote:
>> Please review a "somewhat automated" change to insert `@spec` tags into doc
>> comments, as appropriate, to leverage the recent new javadoc feature to
>> generate a new page listing the references to all external specifications
>> li
On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
On Fri, 25 Nov 2022 06:46:52 GMT, ExE Boss wrote:
> I believe `UnsupportedOperationException` would be better for this.
It would but Per is right that this it is throwing ISE today, it's just that
the PR adds an explicit check and that highlights that the wrong exception is
thrown. Buffers tha
On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which fixes the typos in the test
> packages? @mernst submitted this as a separate PR
> https://github.com/openjdk/jdk/pull/10029 but given the number of areas and
> files that other PR touches, th
On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which fixes the typos in the test
> packages? @mernst submitted this as a separate PR
> https://github.com/openjdk/jdk/pull/10029 but given the number of areas and
> files that other PR touches, th
On Mon, 28 Nov 2022 10:36:40 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
On Mon, 28 Nov 2022 10:47:47 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
On Tue, 29 Nov 2022 16:46:43 GMT, Per Minborg wrote:
> This PR proposes a variety of modernisations to the `jdk.sctp` module.
>
> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several
> improvement areas were identified including:
>
> * Replacing duplicate code segments
> *
On Tue, 29 Nov 2022 19:24:14 GMT, Roger Riggs wrote:
> There could be more sharing of the unsupported implementation if SctpChannel
> was not abstract and its method bodies threw the exception. There would less
> duplication for unsupported platforms.
I think this is accident of history. As I
On Wed, 30 Nov 2022 09:22:00 GMT, Per Minborg wrote:
>> This PR proposes a variety of modernisations to the `jdk.sctp` module.
>>
>> During the fix of https://bugs.openjdk.org/browse/JDK-8296024, several
>> improvement areas were identified including:
>>
>> * Replacing duplicate code segments
On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inte
On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inte
On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inte
On Thu, 1 Dec 2022 23:38:40 GMT, Weijun Wang wrote:
>> I confirmed that the standalone `keytool` did not echo the input, which
>> should be OK for this IMO.
>
> If the console cannot be used anyway inside jshell, then this is good enough.
Naoto has confirmed that the password prompt from keytoo
On Sat, 3 Dec 2022 19:18:48 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inter
On Tue, 6 Dec 2022 07:08:55 GMT, Jaikiran Pai wrote:
> Furthermore, I think in its current form it means that this will
> load/instantiate any `JdkConsoleProvider` implementations that are accessible
> to the thread context classloader but may not have been from the module
> configured through
On Tue, 6 Dec 2022 07:35:44 GMT, Jaikiran Pai wrote:
> So the `Console` instance returned from `System.console()`, thus far, follows
> these semantics. However, with the change proposed in this PR, the default
> implementation will now be the jline backed `JdkConsoleImpl` implementation.
> Fro
On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inter
On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inter
On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inter
On Wed, 7 Dec 2022 17:09:53 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inter
On Wed, 7 Dec 2022 19:19:25 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inter
On Fri, 16 Dec 2022 03:55:29 GMT, Damon Nguyen wrote:
>> Damon Nguyen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert old translation. Fix lang codes
>
> @dfuch Could I get a review from you as well? I believe this translation
>
On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote:
> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated f
On Fri, 6 Jan 2023 14:49:16 GMT, Archie L. Cobbs wrote:
> Sounds reasonable... so I take it you would also be in favor of patching
> `make/modules` instead of adding `@SuppressWarnings` annotations
> everywhere... is that correct?
>
> If this is generally agreed as a better route then let me k
Forwarding to security-dev as that is where issues around signed JARs
are usually discussed.
-Alan.
On 10/01/2023 17:00, Eirik Bjørsnøs wrote:
Hi,
ZipFile.isSignatureRelated currently returns true for paths such as
the following:
META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.
On Mon, 16 Jan 2023 11:44:36 GMT, Eirik Bjorsnos wrote:
> This PR adds test coverage for pending block files in signed JAR files
>
> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes
> before the corresponding signature file [SF] in the JAR.
>
> JarVerifier.processEn
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad wrote:
> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on
> a `byte[]` subrange. It can profitably use the recently introduced
> `ArraysSupport::vectorizedHashCode` method to see a speed-up, which
> translates to a s
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad wrote:
> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on
> a `byte[]` subrange. It can profitably use the recently introduced
> `ArraysSupport::vectorizedHashCode` method to see a speed-up, which
> translates to a s
On Thu, 19 Jan 2023 09:46:12 GMT, Claes Redestad wrote:
> FWIW the micro is derived from the sibling `ZipFileGetEntry` micro in the
> same directory. It's not exactly necessary for this use case to add such a
> benchmark, but I think there's value in verifying that optimizing
> `checkedHash` i
On Mon, 23 Jan 2023 02:59:42 GMT, David Holmes wrote:
> There was one missing update in javac.1 from:
>
> [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate
> -profile option in javac
>
> otherwise the change is limited to dropping the "-ea".
>
> Thanks.
Marked as reviewed
On Fri, 17 Mar 2023 22:01:46 GMT, Mandy Chung wrote:
> `ModuleInfoWriter` is not used by the runtime. Move it to the test library
> as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the
> test library instead. `ModuleInfoWriter` depends on `jdk.internal.module`
> type
On Sat, 18 Mar 2023 19:14:09 GMT, Mandy Chung wrote:
>> `ModuleInfoWriter` is not used by the runtime. Move it to the test library
>> as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the
>> test library instead. `ModuleInfoWriter` depends on `jdk.internal.module`
>>
On Fri, 24 Mar 2023 16:22:33 GMT, Jaikiran Pai wrote:
> I see that Alan suggested that we take up the `jar -i` deprecation in a
> separate PR. I think that simplifies the work in this PR.
Yes, there are options for `jar -i` that include "leave it as is", have the
option create the index and em
On Mon, 27 Mar 2023 17:12:25 GMT, Eirik Bjorsnos wrote:
> > Adding these tests I think will help us verify that these APIs and also
> > exercise the code in these classes where we have checks for
> > `META-INF/INDEX.LIST` entry. Is that something you could consider adding as
> > part of this P
1 - 100 of 398 matches
Mail list logo
