After a refinement to the checks under development in #5709, the new checks
examine array types of serial fields and warn if the underlying component type
is not serializable. Per the JLS, all array types are serializable, but if the
base component is not serializable, the serialization process
On Wed, 13 Oct 2021 04:49:22 GMT, Joe Darcy wrote:
> After a refinement to the checks under development in
> https://github.com/openjdk/jdk/pull/5709, the new checks examine array types
> of serial fields and warn if the underlying component type is not
> serializable. Per the JLS, all array
> After a refinement to the checks under development in
> https://github.com/openjdk/jdk/pull/5709, the new checks examine array types
> of serial fields and warn if the underlying component type is not
> serializable. Per the JLS, all array types are serializable, but if the base
> component
On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Tue, 12 Oct 2021 20:51:02 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
After a refinement to the checks under development in
https://github.com/openjdk/jdk/pull/5709, the new checks examine array types of
serial fields and warn if the underlying component type is not serializable.
Per the JLS, all array types are serializable, but if the base component is not
On Wed, 13 Oct 2021 04:49:22 GMT, Joe Darcy wrote:
> After a refinement to the checks under development in
> https://github.com/openjdk/jdk/pull/5709, the new checks examine array types
> of serial fields and warn if the underlying component type is not
> serializable. Per the JLS, all array
On Wed, 13 Oct 2021 04:49:22 GMT, Joe Darcy wrote:
> After a refinement to the checks under development in
> https://github.com/openjdk/jdk/pull/5709, the new checks examine array types
> of serial fields and warn if the underlying component type is not
> serializable. Per the JLS, all array
On Tue, 15 Jun 2021 12:15:11 GMT, Сергей Цыпанов wrote:
> In some JDK classes there's still the following hashCode() implementation:
>
> long objNum;
>
> public int hashCode() {
> return (int) objNum;
> }
>
> This outdated expression should be replaced with Long.hashCode(long) as it
>
>
On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore
wrote:
>> This patch overhauls the library loading mechanism used by the Foreign
>> Linker API. We realized that, while handy, the *default* lookup abstraction
>> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>>
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote:
> @prrace notices this here:
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think
> it is the already open issue that this patch is fixing. While the original
> patch added the test in `jdk_other`, Phil
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote:
> @prrace notices this here:
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think
> it is the already open issue that this patch is fixing. While the original
> patch added the test in `jdk_other`, Phil
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote:
> @prrace notices this here:
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think
> it is the already open issue that this patch is fixing. While the original
> patch added the test in `jdk_other`, Phil
On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdated expression should be replaced with Long.hashCode(long) as
On Tue, 12 Oct 2021 13:28:21 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>>
On Tue, 12 Oct 2021 14:10:53 GMT, jmehrens wrote:
>> Ravi Reddy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8193682 : Infinite loop in ZipOutputStream.close()
>
> src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java
On Tue, 12 Oct 2021 13:28:21 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>>
On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov wrote:
> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
This pull request has now been integrated.
Changeset: 7d2633f7
Author:Andrey Turbanov
Committer: Pavel Rappo
URL:
On Mon, 11 Oct 2021 21:07:21 GMT, Andrey Turbanov wrote:
>> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8275002: Remove unused
> This change implements a simple web server that can be run on the
> command-line with `java -m jdk.httpserver`.
>
> This is facilitated by adding an entry point for the `jdk.httpserver` module,
> an implementation class whose main method is run when the above command is
> executed. This is
On Tue, 12 Oct 2021 13:28:21 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>>
On Tue, 12 Oct 2021 14:11:15 GMT, jmehrens wrote:
>> Ravi Reddy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8193682 : Infinite loop in ZipOutputStream.close()
>
> src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java
On Tue, 12 Oct 2021 15:00:11 GMT, Ravi Reddy wrote:
>> the output stream is only closed if an exception is raised though ?
>
> Yes , we are closing the stream only when exception occurs during write
> operation
Yes, we are closing the stream only when an exception occurs during a write
On Fri, 8 Oct 2021 21:45:21 GMT, Cheng Jin wrote:
> That's what I thought to be the only way around but might need to figure out
> the specifics on AIX.
Is `libc.a` loadable on AIX (e.g. with System.loadLibrary) ? (Sorry I don't
have a machine to test readily available). If so, we might just
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the
On Tue, 12 Oct 2021 14:35:17 GMT, Sean Coffey wrote:
>> src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 252:
>>
>>> 250: int len = def.deflate(buf, 0, buf.length);
>>> 251: if (len > 0) {
>>> 252: try {
>>
>> Shouldn't this use try with
On Tue, 12 Oct 2021 15:04:02 GMT, Maurizio Cimadamore
wrote:
> Is libc.a loadable on AIX (e.g. with System.loadLibrary) ?
I tried to load `libc.a` and `libc` this way but neither of them works on AIX.
e.g.
public class StdLibTest {
private static CLinker clinker =
On Mon, 11 Oct 2021 20:55:23 GMT, Mandy Chung wrote:
> Classes compiled prior to the nestmate support will generate
> `REF_invokeSpecial` if the implementation method is a private instance
> method. Since a lambda proxy class is a hidden class, a nestmate of the
> host class, it can invoke
I have some questions for JDK-4947890。
One of app’s JVM was upgraded from JDK11 to JDK17.
Then the working behavior was changed on Windows 10 Multilingual User
Interface (MUI).
(Base was Japanese Windows 10, display language setting was English
(United States))
In my investigation, the
On Tue, 12 Oct 2021 14:46:33 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java line 256:
>>
>>> 254: } catch (Exception e) {
>>> 255: def.end();
>>> 256: out.close();
>>
>> out.close not needed with try
This PR contains the API and implementation changes for JEP-419 [1]. A more
detailed description of such changes, to avoid repetitions during the review
process, is included as a separate comment.
[1] - https://openjdk.java.net/jeps/419
-
Commit messages:
- Fix issues with
On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore
wrote:
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] -
On Thu, 7 Oct 2021 14:05:19 GMT, Evgeny Astigeevich
wrote:
> The change completes the fix of
> [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has
> added normalisation in a constructor but not removed it from the get method.
This pull request has now been integrated.
On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore
wrote:
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] -
On Tue, 12 Oct 2021 15:24:41 GMT, Cheng Jin wrote:
> I tried to load `libc.a` and `libc` this way but neither of them works on AIX.
Sorry - what I meant is - `System::load`, which accepts a full path and
extension. E.g.
System.load("/usr/lib/libc.a");
-
PR:
> This change implements a new service provider interface for host name and
> address resolution, so that java.net.InetAddress API can make use of
> resolvers other than the platform's built-in resolver.
>
> The following API classes are added to `java.net.spi` package to facilitate
> this:
>
> Classes compiled prior to the nestmate support will generate
> `REF_invokeSpecial` if the implementation method is a private instance
> method. Since a lambda proxy class is a hidden class, a nestmate of the
> host class, it can invoke the private implementation method but it has to use
>
On Tue, 12 Oct 2021 10:22:07 GMT, Alan Bateman wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove filelist which was added accidentally
>
> filelist line 1:
>
>> 1:
>>
On Thu, 23 Sep 2021 15:43:08 GMT, Athijegannathan Sundararajan
wrote:
>> I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt
>> terminal (see JDK-8270943), and to generally use a newer version of the
>> library. This patch is basically a application of relevant parts of the
Hi Ichiroh,
This behavioral change is not intentional. It's a bug introduced in
JDK-4947890. I create https://bugs.openjdk.java.net/browse/JDK-8275145
for this issue.
Thanks for the investigation.
Mandy
On 10/12/21 2:44 AM, Ichiroh Takiguchi wrote:
I have some questions for JDK-4947890。
On Tue, 12 Oct 2021 17:42:01 GMT, Peter Levart wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix left-over assignment
>
>
On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Tue, 12 Oct 2021 17:44:08 GMT, Peter Levart wrote:
>> src/java.base/share/classes/jdk/internal/reflect/MethodHandleCharacterFieldAccessorImpl.java
>> line 137:
>>
>>> 135: {
>>> 136: if (isReadOnly()) {
>>> 137: ensureObj(obj); // throw NPE if obj is null on
>>>
On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
> StringBuffer is a legacy synchronized class. There are more modern
> alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have
> better performance
>
> In
On Mon, 11 Oct 2021 21:05:46 GMT, Andrey Turbanov wrote:
>> src/java.base/share/classes/java/lang/Character.java line 123:
>>
>>> 121: * than U+ are called supplementary characters. The Java
>>> 122: * platform uses the UTF-16 representation in {@code char} arrays and
>>> 123: * in the
On Tue, 12 Oct 2021 18:11:56 GMT, Cheng Jin wrote:
> Just tried with `System.load()` but still ended up with pretty much the same
> failure given both of them eventually invokes `ClassLoader.loadLibrary` to
> load the library in which case there is no big difference at this point.
Yes and no.
On Tue, 12 Oct 2021 20:39:13 GMT, Andrey Turbanov wrote:
>> StringBuffer is a legacy synchronized class. There are more modern
>> alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
On Tue, 12 Oct 2021 20:33:20 GMT, Naoto Sato wrote:
>> reverted changes in this spec.
>
> Did you modify the PR? I am unable to locate the revert.
Oops. Forgot to push
-
PR: https://git.openjdk.java.net/jdk/pull/5432
On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore
wrote:
>> This patch overhauls the library loading mechanism used by the Foreign
>> Linker API. We realized that, while handy, the *default* lookup abstraction
>> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>>
On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore
wrote:
>> This patch overhauls the library loading mechanism used by the Foreign
>> Linker API. We realized that, while handy, the *default* lookup abstraction
>> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>>
52 matches
Mail list logo
