src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java
367 /** 368 * called from vm to generate MethodHandle holder classes 369
* @return @code { Object[] } if holder classes can be generated. 370 *
@param lines the output lines from @code { VM.cdsTraceResolve } 371 */
On Mon, 14 Sep 2020 22:18:34 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix.
This pull request has now been integrated.
Changeset: 57f92d23
Author:Naoto Sato
URL: https://git.openjdk.java.net/jdk/commit/57f92d23
Stats: 2 lines in 1 file changed: 0 ins; 2
Note that we've had the javac warning about equals and hashCode
overriding as a fatal build condition since at least JDK 9.
-Joe
On 9/15/2020 12:36 PM, Brian Burkhalter wrote:
Hello,
The override of hashCode() looks like it is still there in JDK 15 [1]. I don’t
know however why it does not
On 15/09/2020 22:02, Pavel Rappo wrote:
On 15 Sep 2020, at 20:50, Brian Burkhalter wrote:
On Sep 15, 2020, at 12:38 PM, Kevin Rushforth
wrote:
I see this in DecimalFormatSymbols:
/**
* Override hashCode.
*/
private volatile int hashCode;
@Override
public
HI, all
Please review changes for 8247536: Support for pre-generated
java.lang.invoke classes in CDS static archive.
What happened:
I pushed with commit comment:
8247536: Support for pre-generated java.lang.invoke classes in CDS static
archive
When created pullrequest, the
On Tue, 15 Sep 2020 16:43:01 GMT, Daniil Titov wrote:
> The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes()
> when the current thread is in the middle
> of redefining the same class. The change is based on the fix [1] suggested in
> the Jira issue [2] comment.
> [1]
> On 15 Sep 2020, at 20:50, Brian Burkhalter
> wrote:
>
>> On Sep 15, 2020, at 12:38 PM, Kevin Rushforth
>> wrote:
>>
>> I see this in DecimalFormatSymbols:
>>
>>
>> /**
>> * Override hashCode.
>> */
> private volatile int hashCode;
>> @Override
>> public int
On Tue, 15 Sep 2020 16:59:59 GMT, Lance Andersen wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove "final"
>
> I am fine with this as well. I will pull over the change and just sanity
> check it via mach5
> On Sep 15, 2020, at 12:38 PM, Kevin Rushforth
> wrote:
>
> I see this in DecimalFormatSymbols:
>
>
> /**
> * Override hashCode.
> */
> >>>private volatile int hashCode;
> @Override
> public int hashCode() {
>
> Although, I'm not sure why the intervening
Hmm, I could have sworn I checked
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/text/DecimalFormatSymbols.java
and didn't find it...
I guess it's a false positive then.
On 15/09/2020 21:36, Brian Burkhalter wrote:
Hello,
The override of hashCode() looks like
On Tue, 15 Sep 2020 10:04:49 GMT, Conor Cleary wrote:
> This issue relates to JDK-8250639 '☂ Address reliance on default constructors
> in the java.desktop module'. The
> following classes have had an explicit no-arg constructor added, with a
> protected access modifier and accompanying API
>
I see this in DecimalFormatSymbols:
/**
* Override hashCode.
*/
>>> private volatile int hashCode;
@Override
public int hashCode() {
Although, I'm not sure why the intervening private field would prevent
javadoc from generating at least a method with an empty
Hello,
The override of hashCode() looks like it is still there in JDK 15 [1]. I don’t
know however why it does not appear as such in the javadoc [2].
Brian
[1]
http://hg.openjdk.java.net/jdk/jdk15/file/fb7064dc63f9/src/java.base/share/classes/java/text/DecimalFormatSymbols.java#l760
[2]
On Tue, 15 Sep 2020 19:13:55 GMT, Vipin Sharma wrote:
>> I've only looked at the management files. They look good in general.
>>
>> src/java.management/share/classes/java/lang/management/ClassLoadingMXBean.java
>>
>> 108 * @throws java.lang.SecurityException if a security manager
>> 109
On Tue, 15 Sep 2020 18:14:58 GMT, Serguei Spitsyn wrote:
>> Updated @exception with @throws for core-libs, it fixes all open sub-tasks
>> of JDK-8252536.
>>
>> Open Subtasks part of this fix are:
>> 1. JDK-8252537
>> 2. JDK-8252539
>> 3. JDK-8252540
>> 4. JDK-8252541
>>
>> Previous
In Java 14 and before, DecimalFormatSymbols had overrides for both
equals and hashCode. In Java 15, the override for hashCode has
disappeared, and it now inherits hashCode from java.lang.Object. That
means it now violates the contract for equals + hashCode: two equal
DecimalFormatSymbols
This patch is reorganized after 8252725, which is separated from this patch to
refactor jlink glugin code. The previous
webrev with hg can be found at:
http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
integrated, the
regeneration of holder classes is simply to call the new
> Related to [JDK-8252730 jlink does not create reproducible builds on different
> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces
> ordering based on `Archive` module names to
> ensure stable files (and file signatures) across generated JDK images by
> jlink.
Ian Graves
On Wed, 9 Sep 2020 19:29:30 GMT, Vipin Sharma wrote:
> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of
> JDK-8252536.
>
> Open Subtasks part of this fix are:
> 1. JDK-8252537
> 2. JDK-8252539
> 3. JDK-8252540
> 4. JDK-8252541
>
> Previous conversation on this:
>
Hi,
This has probably been brought up at some point. When we need to find an
item in a collection based on its properties, we can either do it in a
loop, testing each item, or in a stream with filter and findFirst/Any.
I would think that a method in Iterable be useful, along the lines of:
On Tue, 15 Sep 2020 12:39:11 GMT, Jaikiran Pai wrote:
>> Can I please get a review and a sponsor for this patch which fixes the issue
>> reported in
>> https://bugs.openjdk.java.net/browse/JDK-8244706?
>> The commit here sets the `OS` header flag to `255` (which represents
>> `unknown`) as
The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes()
when the current thread is in the middle
of redefining the same class. The change is based on the fix [1] suggested in
the Jira issue [2] comment.
[1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/
[2]
On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote:
> Revert changes made by JDK-8249643, removing the implNote.
This pull request has now been integrated.
Changeset: 5191f315
Author:Joe Wang
URL: https://git.openjdk.java.net/jdk/commit/5191f315
Stats: 25 lines in 1 file changed:
On Tue, 15 Sep 2020 12:39:11 GMT, Jaikiran Pai wrote:
>> Can I please get a review and a sponsor for this patch which fixes the issue
>> reported in
>> https://bugs.openjdk.java.net/browse/JDK-8244706?
>> The commit here sets the `OS` header flag to `255` (which represents
>> `unknown`) as
On Tue, 15 Sep 2020 11:31:58 GMT, Joel Borggrén-Franck
wrote:
>> Pre-git review thread here:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067049.html
>
> @raphw test is missing imports and doesn't compile, other than that looks
> good.
Bad copy paste. Fixed on the
On Tue, 15 Sep 2020 15:45:05 GMT, Jaikiran Pai wrote:
> As for this:
>
>> As long as the input stream close() method is idem potent this should be
>> safe, and AFAICS that is the case for the two
>> input stream subclasses that can be returned by ZipFile::getInputStream.
>
> I'm curious, in
On Tue, 15 Sep 2020 15:45:05 GMT, Jaikiran Pai wrote:
> I'm curious, in the context of this change, why idempotency would be a
> necessity. Would there be a "double close"
> somehow on this `InputStream` instance?
My bad - I hadn't realised closing the input stream would also remove it from
On Tue, 15 Sep 2020 15:33:51 GMT, Daniel Fuchs wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove "final"
>
> Hi Jaikiran,
>
> This is not an area I know too well - so I won't review formally, but the
>
On Tue, 15 Sep 2020 15:29:44 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove "final"
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 428:
>
>> 426: try
> This patch assures that an annotation on a type bound is placed on the
> correct bound index.
Rafael Winterhalter has refreshed the contents of this pull request, and
previous commits have been removed. The
incremental views will show differences compared to the previous content of the
PR.
On Tue, 15 Sep 2020 13:40:29 GMT, Ian Graves wrote:
>> Related to [JDK-8252730 jlink does not create reproducible builds on
>> different
>> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces
>> ordering based on `Archive` module names to
>> ensure stable files (and file
On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote:
> There are some little flaws in LdapDNSProvider and auxilliary classes, mostly
> in Javadoc.
>
> In detail:
> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
> Unnecessary import
>
> Related to [JDK-8252730 jlink does not create reproducible builds on different
> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces
> ordering based on `Archive` module names to
> ensure stable files (and file signatures) across generated JDK images by
> jlink.
Ian Graves
On Tue, 15 Sep 2020 09:32:33 GMT, Daniel Fuchs wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Merging streams
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java
> line 41:
>
>> 39:
On Tue, 15 Sep 2020 12:56:13 GMT, Erik Joelsson wrote:
>> This pull request is identical with the RFR previously sent for the
>> Mercurial repository:
>>
>> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
>>
>> I'm copy-pasting the comments from the original RFR
On Tue, 15 Sep 2020 09:10:54 GMT, Hannes Wallnöfer wrote:
> This pull request is identical with the RFR previously sent for the Mercurial
> repository:
>
> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
>
> I'm copy-pasting the comments from the original RFR
On Tue, 15 Sep 2020 11:30:09 GMT, Jan Lahoda wrote:
>> This pull request is identical with the RFR previously sent for the
>> Mercurial repository:
>>
>> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
>>
>> I'm copy-pasting the comments from the original RFR
> Can I please get a review and a sponsor for this patch which fixes the issue
> reported in
> https://bugs.openjdk.java.net/browse/JDK-8244706?
> The commit here sets the `OS` header flag to `255` (which represents
> `unknown`) as noted in [1]. A new test has been
> included in this commit to
On Sun, 13 Sep 2020 02:22:54 GMT, Jaikiran Pai wrote:
>> Hi Jaikiran,
>>
>> The change seems fine an inline with the RFC. I can sponsor this once we
>> have another review.
>>
>> I have run the JCK tests for Zip/Gzip/Jar and Mach5 JDK tier1, tier2 and
>> tier3
>
> Thank you Lance for the
> Can I please get a review and a sponsor for this patch which fixes the issue
> reported in
> https://bugs.openjdk.java.net/browse/JDK-8244706?
> The commit here sets the `OS` header flag to `255` (which represents
> `unknown`) as noted in [1]. A new test has been
> included in this commit to
> Can I please get a review and a sponsor for this patch which fixes the issue
> reported in
> https://bugs.openjdk.java.net/browse/JDK-8244706?
> The commit here sets the `OS` header flag to `255` (which represents
> `unknown`) as noted in [1]. A new test has been
> included in this commit to
On Tue, 15 Sep 2020 08:10:00 GMT, Joel Borggrén-Franck
wrote:
>> This patch assures that an annotation on a type bound is placed on the
>> correct bound index.
>
> Pre-git review thread here:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067049.html
@raphw test is missing
On Tue, 15 Sep 2020 09:10:54 GMT, Hannes Wallnöfer wrote:
> This pull request is identical with the RFR previously sent for the Mercurial
> repository:
>
> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
>
> I'm copy-pasting the comments from the original RFR
This issue relates to JDK-8250639 '☂ Address reliance on default constructors
in the java.desktop module'. The
following classes have had an explicit no-arg constructor added, with a
protected access modifier and accompanying API
description:
- Default ctor on
On Tue, 15 Sep 2020 10:04:49 GMT, Conor Cleary wrote:
> This issue relates to JDK-8250639 '☂ Address reliance on default constructors
> in the java.desktop module'. The
> following classes have had an explicit no-arg constructor added, with a
> protected access modifier and accompanying API
>
On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote:
> There are some little flaws in LdapDNSProvider and auxilliary classes, mostly
> in Javadoc.
>
> In detail:
> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
> Unnecessary import
>
On Tue, 15 Sep 2020 09:39:29 GMT, Daniel Fuchs wrote:
>> There are some little flaws in LdapDNSProvider and auxilliary classes,
>> mostly in Javadoc.
>>
>> In detail:
>> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
>> Unnecessary import
>>
On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote:
> There are some little flaws in LdapDNSProvider and auxilliary classes, mostly
> in Javadoc.
>
> In detail:
> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
> Unnecessary import
>
On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote:
> There are some little flaws in LdapDNSProvider and auxilliary classes, mostly
> in Javadoc.
>
> In detail:
> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
> Unnecessary import
>
On Mon, 14 Sep 2020 22:57:44 GMT, Ian Graves wrote:
>> Related to [JDK-8252730 jlink does not create reproducible builds on
>> different
>> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces
>> ordering based on `Archive` module names to
>> ensure stable files (and file
This pull request is identical with the RFR previously sent for the Mercurial
repository:
https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
I'm copy-pasting the comments from the original RFR below.
Most of the new code is added to the Extern class where it fits in
Hi Christoph,
Changes look ok to me.
On Tue, Sep 15, 2020 at 1:26 PM Christoph Langer
wrote:
> There are some little flaws in LdapDNSProvider and auxilliary classes,
> mostly in Javadoc.
>
> In detail:
> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
> Unnecessary
On Mon, 14 Sep 2020 19:49:08 GMT, Rafael Winterhalter
wrote:
> This patch assures that an annotation on a type bound is placed on the
> correct bound index.
Pre-git review thread here:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067049.html
-
PR:
On Mon, 14 Sep 2020 22:54:34 GMT, Ian Graves wrote:
>> Looks good to me.
>
> Updated to merge streams in line with @stuart-marks suggestion.
There are several existing jlink tests that check that generated lib/modules is
reproducible. Can we do more in these
tests or add a new test that would
There are some little flaws in LdapDNSProvider and auxilliary classes, mostly
in Javadoc.
In detail:
src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
Unnecessary import
src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java:
typo
55 matches
Mail list logo
