On Tue, 24 Sep 2024 06:19:12 GMT, David Holmes wrote:
> > It is outside the scope of the javadoc text to state exactly why each
> > restricted method is marked as such.
>
> I don't agree. I think restricted methods should document why they are
> restricted if it is not patently obvious.
I thi
On Mon, 23 Sep 2024 12:06:51 GMT, Jorn Vernee wrote:
>>> I think "can not be determined" just begs questions. Is this a JDK
>>> limitation, something I'm doing wrong, or something else, ... if you see
>>> what I mean.
>>
>> I think saying 'no caller class on the stack' has the same effect thou
On Mon, 23 Sep 2024 23:23:12 GMT, Shaojin Wen wrote:
>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into
>> primitive arrays by combining values into larger stores.
>>
>> This PR rewrites the code of appendNull and append(boolean) methods so that
>> these two meth
On 23/09/2024 20:35, Rafael Winterhalter wrote:
So I tracked down the discrepancy to a changing default for
URLClassLoader compared to JarFile. URLClassLoader resolves resources
to the "versions" folder for Java 9 and later, even without code
changes. This is not the case for JarFile where the
On Mon, 23 Sep 2024 10:35:44 GMT, Maurizio Cimadamore
wrote:
> It is outside the scope of the javadoc text to state exactly why each
> restricted method is marked as such.
I don't agree. I think restricted methods should document why they are
restricted if it is not patently obvious.
--
On Mon, 23 Sep 2024 17:33:16 GMT, Ioi Lam wrote:
>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> Add the following command-line options as specified in JEP 483:
>>
>>
>> - `-XX:AOTMode=off/record/create/auto/on`
On Fri, 20 Sep 2024 18:16:57 GMT, Calvin Cheung wrote:
>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS
>> archive;
>> during run time, full module graph will not be used.
>>
>> With this patc
> A small optimization of processMethod, by using local variables and
> extracting exception methods, reduces codeSize from 326 to 283
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
reduce getFrame
-
Changes:
- all: h
On Tue, 24 Sep 2024 04:49:51 GMT, Jaikiran Pai wrote:
>> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java`
>> on s390x. This change should be reverted while fixing
>> [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).
>
> Hello Amit, following the process note
On Thu, 12 Sep 2024 05:12:18 GMT, Amit Kumar wrote:
> This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java`
> on s390x. This change should be reverted while fixing
> [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216).
Hello Amit, following the process noted at
ht
On Tue, 24 Sep 2024 01:22:25 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
Can I please get a review of this cleanup to the launcher code to remove
declarations of unused functions?
The `ValidateModules` function appears to be a left-over from
https://bugs.openjdk.org/browse/JDK-8340717.
The `SetApplicationClassPath` and `PrintMachineDependentOptions` appear to have
On Mon, 1 Jul 2024 18:22:48 GMT, Chen Liang wrote:
> Clarify that `ParameterizedType.getOwnerType()` always return `null` in a few
> scenarios.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/19977
On Mon, 1 Jul 2024 19:20:48 GMT, Chen Liang wrote:
> Clarify that only `Class` is returned for core reflection implementation, and
> the return type is `Type` to support other implementations, such as ones
> modeling unloaded or remote types.
This pull request has been closed without being int
On Mon, 23 Sep 2024 19:24:51 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.tanh() using libm
>>
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
On Tue, 24 Sep 2024 01:01:54 GMT, Vladimir Kozlov wrote:
> My testing passed.
Thank You Vladimir!
-
PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2370044599
On Tue, 24 Sep 2024 00:21:57 GMT, Lei Zhu wrote:
> 8340553: ZipEntry field validation does not take into account the size of a
> CEN header
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/21147
On Tue, 24 Sep 2024 02:06:56 GMT, Jaikiran Pai wrote:
> Hello @Korov, Lance is already working on this change and is planning to open
> a PR for the change shortly.
OK, thanks for replay!
-
PR Comment: https://git.openjdk.org/jdk/pull/21147#issuecomment-2370010562
On Mon, 23 Sep 2024 05:11:34 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial change which removes dead code from
> the `RequiresSetenv()` function?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8340596 this appears to be a
> left-over from the changes in https://bugs
On Mon, 23 Sep 2024 05:11:34 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial change which removes dead code from
> the `RequiresSetenv()` function?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8340596 this appears to be a
> left-over from the changes in https://bugs
On Tue, 24 Sep 2024 01:51:56 GMT, Lei Zhu wrote:
>> 8340553: ZipEntry field validation does not take into account the size of a
>> CEN header
>
> Lei Zhu has updated the pull request incrementally with one additional commit
> since the last revision:
>
> 8340553: ZipEntry field validation do
On Mon, 23 Sep 2024 16:29:15 GMT, Brian Burkhalter wrote:
>> Add some verbiage stating that two buffered readers or input streams should
>> not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one
> addition
> 8340553: ZipEntry field validation does not take into account the size of a
> CEN header
Lei Zhu has updated the pull request incrementally with one additional commit
since the last revision:
8340553: ZipEntry field validation does not take into account the size of a
CEN header
--
On Fri, 13 Sep 2024 12:29:26 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to remove the
> (internal) `SelectVersion()` function from the java launcher and also update
> the code comments in the launcher to match the current implementation?
>
> As noted in
On Mon, 23 Sep 2024 04:53:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
> A small optimization of processMethod, by using local variables and
> extracting exception methods, reduces codeSize from 326 to 291
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
suggestion from @liach
-
Changes:
-
On Mon, 23 Sep 2024 00:20:09 GMT, Shaojin Wen wrote:
>> For clarity, I think using Integer.toUnsignedLong on the shift result is
>> better
>
> If minorVersion > 0x, the result of using Integer.toUnsignedLong will be
> wrong. I guess this is the reason why the previous version build failed
On Mon, 23 Sep 2024 00:33:26 GMT, Chen Liang wrote:
>> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
>>
>> 1. DirectClassBuilder::build codeSize 361 -> 315
>> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
>> 3. BufWriterImpl::writeIndex codeSize 62
On Sun, 22 Sep 2024 05:30:43 GMT, Shaojin Wen wrote:
> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
>
> 1. DirectClassBuilder::build codeSize 361 -> 315
> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
> 3. BufWriterImpl::writeIndex codeSize 62 ->
> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> The implementation of java.lang.invoke uses SoftReferences so that unused
> MethodHandles, LambdaForms, etc, can be garbage collected.
>
> However, if we want to store j
On Mon, 23 Sep 2024 13:53:13 GMT, Shaojin Wen wrote:
> A small optimization of processMethod, by using local variables and
> extracting exception methods, reduces codeSize from 326 to 286
@wenshao Can you change the method to call generatorError? The ClassFormatError
was a bug.
-
On Sun, 22 Sep 2024 17:04:24 GMT, ExE Boss wrote:
>> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
>>
>> 1. DirectClassBuilder::build codeSize 361 -> 315
>> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
>> 3. BufWriterImpl::writeIndex codeSize 62 -
On Sun, 22 Sep 2024 05:30:43 GMT, Shaojin Wen wrote:
> Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
>
> 1. DirectClassBuilder::build codeSize 361 -> 315
> 2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
> 3. BufWriterImpl::writeIndex codeSize 62 ->
On Sun, 22 Sep 2024 20:48:08 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
>> line 207:
>>
>>> 205:
>>> 206: // Now we can make the head
>>> 207: head.writeLong(((long) ClassFile.MAGIC_NUMBER) << 32 |
>>> minorVersion
Do some refactoring so that the code can be inlined by the C1/C2 optimizer.
1. DirectClassBuilder::build codeSize 361 -> 315
2. DirectCodeBuilder::writeExceptionHandlers codeSize 183 -> 31
3. BufWriterImpl::writeIndex codeSize 62 -> 37 (forceinline)
4. BufWriterImpl::writeU2 (forceinline)
5. Util:
On Mon, 23 Sep 2024 19:24:51 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.tanh() using libm
>>
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
On Mon, 23 Sep 2024 15:27:06 GMT, Chen Liang wrote:
>> A small optimization of processMethod, by using local variables and
>> extracting exception methods, reduces codeSize from 326 to 286
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
> line 432:
>
>> 430:
On Mon, 23 Sep 2024 13:53:13 GMT, Shaojin Wen wrote:
> A small optimization of processMethod, by using local variables and
> extracting exception methods, reduces codeSize from 326 to 286
src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
line 432:
> 430:
A small optimization of processMethod, by using local variables and extracting
exception methods, reduces codeSize from 326 to 286
-
Commit messages:
- Update
src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
- optimize processMethod
Changes: https://
> 8340553: ZipEntry field validation does not take into account the size of a
> CEN header
Lei Zhu has updated the pull request with a new target base due to a merge or a
rebase. The pull request now contains one commit:
8340553: ZipEntry field validation does not take into account the size o
8340553: ZipEntry field validation does not take into account the size of a CEN
header
-
Commit messages:
- 8340553: ZipEntry field validation does not take into account the size of a
CEN header
- 8340553: ZipEntry field validation does not take into account the size of a
CEN hea
On Thu, 19 Sep 2024 23:37:38 GMT, Alexey Semenyuk wrote:
> Move `resource.wxl-file-name` property from `WinResources.properties` files
> to the new `WinResourcesNoL10N.properties` files. The later are supposed to
> be excluded from automatic translations.
This pull request has now been integra
> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into
> primitive arrays by combining values into larger stores.
>
> This PR rewrites the code of appendNull and append(boolean) methods so that
> these two methods can be optimized by C2.
Shaojin Wen has updated the pul
> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through
> `ClassDesc` comparison and reusing descriptor hash to calculate internal name
> hash if possible. No suitable device to run benchmarks so need to find
> something to run the new benchmark to ensure things work as intended
On Tue, 2 Jul 2024 12:20:17 GMT, Yasumasa Suenaga wrote:
> We cannot pass GNU style options like `--enable-preview` to `jlink
> --add-option`. It is hard to use for complex application.
>
> We have workaround for this issue (see JBS), but I think it is better to fix
> on JDK side.
This pull r
On Mon, 23 Sep 2024 21:42:11 GMT, Chen Liang wrote:
>> Many constants are cluttered in `ClassFile`. However, only a few of them are
>> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
>> constants. All other constants are specific and should live in more local
>> loca
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
On Mon, 23 Sep 2024 21:03:08 GMT, Maurizio Cimadamore
wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.bas
> This PR moves the section on restricted methods from the the javadoc of
> `java.lang.foreign` package into a standalone static [javadoc
> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>
> This is
>
> But do those two use cases really need an abstraction? Is there really
> value in a Range interface?
> Given the two classes above, which are IMO candidates for the JDK, they
> work fine as isolated value types without a generalized abstraction.
I see this a bit differently. In the examples y
So I tracked down the discrepancy to a changing default for URLClassLoader
compared to JarFile. URLClassLoader resolves resources to the "versions"
folder for Java 9 and later, even without code changes. This is not the
case for JarFile where the relevant version needs to be passed to a new
constru
On Mon, 23 Sep 2024 19:14:10 GMT, Vladimir Kozlov wrote:
> Looks good. I have only one nitpick. I will start testing.
Thank you Vladimir!
> src/hotspot/share/c1/c1_Compiler.cpp line 170:
>
>> 168: case vmIntrinsics::_dcos:
>> 169: case vmIntrinsics::_dtan:
>> 170: #if defined(X86)
>
> U
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.tanh() using libm
>
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x
Srinivas Vamsi Parasa has updated the pull request incrementally with
On Mon, 23 Sep 2024 19:03:53 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
On Thu, 19 Sep 2024 21:15:11 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.tanh() using libm
>>
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
Hi Viktor
Thanks for bearing with me.
> [...] are you suggesting that we add a section in the Gatherer (and
> Collector) in the form of "Implementor Notes" that are a bit more high-level
> than the specification?
Yes, exactly, explicitly mentioning reusability (I actually read through the
Jav
On Wed, 18 Sep 2024 05:18:13 GMT, Chen Liang wrote:
>> Ioi Lam has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains eight additional commits
>> since
On Wed, 18 Sep 2024 12:15:08 GMT, Claes Redestad wrote:
> How does archiving and resolution of the linked `MethodType` instances work?
> In particular how does archiving fill up the `MethodType::internTable` to
> ensure `MethodType` uniqueness?
The details are in the next PR (https://github.co
> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> The implementation of java.lang.invoke uses SoftReferences so that unused
> MethodHandles, LambdaForms, etc, can be garbage collected.
>
> However, if we want to store j
On Wed, 18 Sep 2024 07:21:52 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> for following new two vector permutation APIs.
>>
>>
>> Declaration:-
>> Vector.selectFrom(Vector v1, Vector v2)
>>
>>
>> Semantics:-
>>
> This PR support a -k, --keep options like tar that allows jar to avoid
> override existing files.
Henry Jen has updated the pull request incrementally with one additional commit
since the last revision:
Fix the long option
-
Changes:
- all: https://git.openjdk.org/jdk/pull/2
Hello, Markus.
API is not limited to timespans. It was a sample implementation for Range
interface back when it was not refactored into abstract class, which, by
the way, was removed from PR as for now.
My initial motivation was to provide a range for date and time values, so I
based general shap
Hello! Thanks for your comments
The start() and end() be should be specifiable as either inclusive or
> exclusive, otherwise open bounds are not possible. For example, how would
> one express the range of all Strings strictly less than "zzz"? (note every
> element in the infinite sequence "zzy", "
On Mon, 23 Sep 2024 17:43:35 GMT, Alan Bateman wrote:
> Thanks for the update, having this paragraph be an apiNote seems much better.
You're welcome. I will update the CSR with this version.
-
PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2368988258
On Fri, 20 Sep 2024 22:45:57 GMT, Alexey Semenyuk wrote:
>> Move `resource.wxl-file-name` property from `WinResources.properties` files
>> to the new `WinResourcesNoL10N.properties` files. The later are supposed to
>> be excluded from automatic translations.
>
> Alexey Semenyuk has updated the
On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reword doce
Marked as reviewed by jvernee (Re
On Mon, 23 Sep 2024 16:29:15 GMT, Brian Burkhalter wrote:
>> Add some verbiage stating that two buffered readers or input streams should
>> not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one
> addition
This PR support a -k, --keep options like tar that allows jar to avoid override
existing files.
-
Commit messages:
- Add simple test
- Support legacy mode
- 8335912: Add an operation mode to the jar command when extracting to not
overwriting existing files
Changes: https://git.o
On Fri, 20 Sep 2024 01:17:14 GMT, David Holmes wrote:
>> Okay both ways are valid, you could also remove the other "!= 0", the mixing
>> was confusing
>
> Hotspot style rule is "no implicit booleans" so the check for `!= 0` should
> be used in all cases.
Fixed.
-
PR Review Commen
> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> Add the following command-line options as specified in JEP 483:
>
>
> - `-XX:AOTMode=off/record/create/auto/on`
> - `-XX:AOTConfiguration=.aotconfig`
> - `-XX:AOTCache=.
On Thu, 19 Sep 2024 21:43:54 GMT, Mat Carter wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c
>
> src/hotspot/share/cds/cds_globals.hpp line 102:
>
On Mon, 23 Sep 2024 17:22:02 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>> line 225:
>>
>>> 223: // check elements are not all padding layouts and for trailing
>>> padding
>>> 224: private void checkGroup(GroupLayout gl, long max
On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reword doce
Marked as reviewed by mcimadamore
On Mon, 23 Sep 2024 16:40:08 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reword doce
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line
> 225:
>
>> 223:
Hi Viktor,
Thanks for the response. I concur with all of your points below - nice
summary/analysis. Looking forward to this new use case.
-Archie
On Mon, Sep 23, 2024 at 10:38 AM Viktor Klang
wrote:
> Hi Archie!
>
> >I recently encountered a real-world use case for Stream Gatherers and
> thoug
On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reword doce
src/java.base/share/classes/jdk/i
On Sat, 21 Sep 2024 15:01:06 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8336895: " Doing" -> " Doing" and add some {@code} tags
>
> src/java.base/share/classes/java/io/BufferedInputStrea
On Thu, 19 Sep 2024 21:15:11 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.tanh() using libm
>>
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
> This PR prevents sequence layout with padding to be used with the Linker.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Reword doce
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21041/files
- new: https://git
On Mon, 23 Sep 2024 14:43:37 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/java/lang/foreign/Linker.java line 265:
>>
>>> 263: * its non-padding layout elements, or to satisfy (2), and
>>> 264: * {@code G} is {@code G.memberLayouts().isEmpty()} or (at the
>>> same time) not all
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
> with JavaFX instead.
>
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
> openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX.
> That PR describes the needed test scenarios
> Add some verbiage stating that two buffered readers or input streams should
> not be used to read from the same reader or input stream, respectively.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8336895: Modify "More than on
On Fri, 13 Sep 2024 17:40:21 GMT, Lance Andersen wrote:
> Please review the following PR which addresses that ZipOutputStream should
> validate the CEN header fields similar to what was done via
> [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>
> As part of this change, the javado
On Mon, 23 Sep 2024 11:04:24 GMT, Lance Andersen wrote:
>> Please review the following PR which addresses that ZipOutputStream should
>> validate the CEN header fields similar to what was done via
>> [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>>
>> As part of this change, the j
Hi Archie!
>I recently encountered a real-world use case for Stream Gatherers and thought
>I'd mention it (apologies if you've seen these ideas already). These might
>even be worth considering including as standard offerings.
No need to preface your email with an apology 🙂 I'm happy to get thou
On Mon, 23 Sep 2024 04:53:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
On Thu, 19 Sep 2024 18:02:07 GMT, Chen Liang wrote:
>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through
>> `ClassDesc` comparison and reusing descriptor hash to calculate internal
>> name hash if possible. No suitable device to run benchmarks so need to find
>> something
On Mon, 23 Sep 2024 15:15:15 GMT, Adam Sotona wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 14 commits:
>>
>> - Merge branch 'master' of https://github.com/openjdk/jdk into
>> fix/constant-moving
>> - omi
Hi Anthony,
>The idea is to collect feedback, to see how many people report their Gatherers
>being broken (i.e. their Gatherers being non-compliant without realizing it),
>so enforcing it in `Stream::gather` is sufficient for this purpose.
Even if this is well-intentioned, my experience tells m
On Tue, 10 Sep 2024 21:18:19 GMT, Chen Liang wrote:
>> Many constants are cluttered in `ClassFile`. However, only a few of them are
>> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
>> constants. All other constants are specific and should live in more local
>> loca
On Fri, 20 Sep 2024 21:47:08 GMT, Alexander Matveev
wrote:
>> Alexey Semenyuk has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Redo removal of `resource.wxl-file-name` property
>> - Revert "8338918: Remove non translated file name fro
On Mon, 23 Sep 2024 14:40:40 GMT, Jorn Vernee wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add to specification and refine detection of PL GLs
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 26
On Mon, 23 Sep 2024 13:54:52 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add to specification and refine detection of P
On Mon, 23 Sep 2024 13:54:52 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add to specification and refine detection of P
> This PR prevents sequence layout with padding to be used with the Linker.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Add to specification and refine detection of PL GLs
-
Changes:
- all: https://git.openjdk.org/j
On Mon, 23 Sep 2024 13:37:07 GMT, Vladimir Kozelkov wrote:
>> Per Minborg has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains nine additional
>> com
On Mon, 23 Sep 2024 09:54:55 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in
On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote:
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
> with JavaFX instead.
>
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
> openjdk/jfx#1529 for the JavaFX PR that will include the module
On Mon, 23 Sep 2024 11:15:08 GMT, Maurizio Cimadamore
wrote:
>> Previously, the check threw an `IllegalArgumentException` when presented
>> with the above (or other) group layout with only padding layouts, but the
>> actual message differed. So, this change only changes the exception message
On Mon, 23 Sep 2024 11:45:23 GMT, Jorn Vernee wrote:
>> It is documented by the CS JEP: https://openjdk.org/jeps/176
>>
>>> It discovers its caller's class by invoking the
>>> sun.reflect.Reflection.getCallerClass method.
>>
>> CS set the precedent here and the terminology.
>
>> I think "can n
1 - 100 of 124 matches
Mail list logo
