Integrated: 8280470: Confusing instanceof check in HijrahChronology.range
On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote: > Parameter `ChronoField field` is checked by `if (field instanceof > ChronoField)`. Such check is confusing, because only one case, when this > could be `false` is when `field == null`. > But if condition is not satisfied we will get immediate NullPointerException > anyway in `return field.range();`. This pull request has now been integrated. Changeset: 53804720 Author:Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/53804720a04b5b314701de82eddf1a55798eba00 Stats: 13 lines in 1 file changed: 0 ins; 4 del; 9 mod 8280470: Confusing instanceof check in HijrahChronology.range Reviewed-by: rriggs, naoto, dfuchs, iris - PR: https://git.openjdk.java.net/jdk/pull/7118
Re: RFR: JDK-8280168: Add Objects.toIdentityString [v7]
On Mon, 24 Jan 2022 21:31:37 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, >> at times it is the least-bad alternative. When that alternative needs to be >> used, it would be helpful to have the implementation already available, such >> as in Objects.toDefaultString(). This method is analagous to >> System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy 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 > the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8280168 > - Merge branch 'master' into JDK-8280168 > - Appease jcheck. > - Add toIdentityString > - Respond to review feedback to augment test. > - Respond to review feedback. > - JDK-8280168 Add Objects.toDefaultString Updated proposal and naming looks okay. - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7139
Re: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 [v2]
> After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java > getAbsoluteURI to what has been done in 8270492 to > src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add header - Changes: - all: https://git.openjdk.java.net/jdk/pull/7155/files - new: https://git.openjdk.java.net/jdk/pull/7155/files/666fdee0..8f2169cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7155&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7155&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7155.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7155/head:pull/7155 PR: https://git.openjdk.java.net/jdk/pull/7155
Re: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492
On Thu, 20 Jan 2022 23:32:33 GMT, Joe Wang wrote: > Thanks Alan for the reminder. The change looks good. Please add a copyright > header and the LastModified tag as the other class did. Hi, I added the header and LastModified. Best regards, Matthias - PR: https://git.openjdk.java.net/jdk/pull/7155
Re: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 [v3]
> After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java > getAbsoluteURI to what has been done in 8270492 to > src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add LastModified - Changes: - all: https://git.openjdk.java.net/jdk/pull/7155/files - new: https://git.openjdk.java.net/jdk/pull/7155/files/8f2169cb..69584e8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7155&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7155&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7155.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7155/head:pull/7155 PR: https://git.openjdk.java.net/jdk/pull/7155
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8]
> Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS > (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) > authentication scheme. When enabled, the implementation preemptively includes > a CBT with authentication requests over Kerberos. The feature is enabled as > follows: > > A system property "jdk.spnego.cbt" is defined which can have the values > "never" (default), which means the feature is disabled, "always", which means > the CBT is included for all https Negotiate authentications, or it can take > the form "domain:a,b.c,*.d.com" which is a comma separated list of > domains/hosts where the feature is enabled, and disabled everywhere else. In > the given example, the CBT would be included in authentication requests for > hosts "a", "b.c" and all hosts under the domain "d.com" and all of its > sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: final review update (pre CSR) - Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/0d529f9d..004466ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=06-07 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065
Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote:
> Please review,
> When jlink with --compress=2, zip is used to compress the files while doing
> copy. The user case failed to load zip.dll, since zip.dll is not set in PATH.
> This failure is after we get NULL from GetModuleHandle("zip.dll"), then do
> LoadLibrary("zip.dll") will have same result.
> The fix is calling load_zip_library of ClassLoader first --- if zip library
> already loaded just return the cached handle for following usage, if not,
> load zip library and cached the handle.
>
> Tests: tier1,4,7 in test
>Manually tested user case, and checked output of jimage list for
> jlinked files using --compress=2.
>
> Thanks
> Yumin
I'm curious, under what circumstances would, before
https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary
in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where
the JVM was not involved and hence the zip.dll was not loaded already?
For me, the code looks good unless I miss a scenario where we don't have the
JVM loaded already at this point.
-
Marked as reviewed by stuefe (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7206
RFR: 8266974: duplicate property key in java.sql.rowset resource bundle
I have removed the duplicate property keys. Could you please review the fix? - Commit messages: - 8266974: duplicate property key in java.sql.rowset resource bundle Changes: https://git.openjdk.java.net/jdk/pull/7212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7212&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266974 Stats: 22 lines in 11 files changed: 0 ins; 11 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7212/head:pull/7212 PR: https://git.openjdk.java.net/jdk/pull/7212
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8]
On Tue, 25 Jan 2022 10:30:20 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively includes a CBT with authentication requests over Kerberos. The >> feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values >> "never" (default), which means the feature is disabled, "always", which >> means the CBT is included for all https Negotiate authentications, or it can >> take the form "domain:a,b.c,*.d.com" which is a comma separated list of >> domains/hosts where the feature is enabled, and disabled everywhere else. In >> the given example, the CBT would be included in authentication requests for >> hosts "a", "b.c" and all hosts under the domain "d.com" and all of its >> sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one > additional commit since the last revision: > > final review update (pre CSR) The new version LGTM. - Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7065
Re: RFR: 8266974: duplicate property key in java.sql.rowset resource bundle
On Tue, 25 Jan 2022 10:47:41 GMT, Masanori Yano wrote: > I have removed the duplicate property keys. > Could you please review the fix? Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7212
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8]
On Tue, 25 Jan 2022 10:30:20 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively includes a CBT with authentication requests over Kerberos. The >> feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values >> "never" (default), which means the feature is disabled, "always", which >> means the CBT is included for all https Negotiate authentications, or it can >> take the form "domain:a,b.c,*.d.com" which is a comma separated list of >> domains/hosts where the feature is enabled, and disabled everywhere else. In >> the given example, the CBT would be included in authentication requests for >> hosts "a", "b.c" and all hosts under the domain "d.com" and all of its >> sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one > additional commit since the last revision: > > final review update (pre CSR) src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150: > 148: * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f > and any of its subdomains). This is > 149: * a comma separated list of arbitrary length with no white-space > allowed. > 150: * If enabled (for a particular destination) then SPNEGO > authentication requests will include Previously `Negotiate` was used, now `SPNEGO`? - PR: https://git.openjdk.java.net/jdk/pull/7065
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8]
On Tue, 25 Jan 2022 11:34:57 GMT, Michael Osipov wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> final review update (pre CSR) > > src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150: > >> 148: * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain >> e.f and any of its subdomains). This is >> 149: * a comma separated list of arbitrary length with no white-space >> allowed. >> 150: * If enabled (for a particular destination) then SPNEGO >> authentication requests will include > > Previously `Negotiate` was used, now `SPNEGO`? "Negotiate" is the name of the HTTP authentication scheme which uses the SPNEGO mechanism. Possibly makes more sense to refer to Negotiate here. - PR: https://git.openjdk.java.net/jdk/pull/7065
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8]
On Tue, 25 Jan 2022 12:47:26 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150: >> >>> 148: * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain >>> e.f and any of its subdomains). This is >>> 149: * a comma separated list of arbitrary length with no white-space >>> allowed. >>> 150: * If enabled (for a particular destination) then SPNEGO >>> authentication requests will include >> >> Previously `Negotiate` was used, now `SPNEGO`? > > "Negotiate" is the name of the HTTP authentication scheme which uses the > SPNEGO mechanism. Possibly makes more sense to refer to Negotiate here. Yes, I know. That's the point. Clearly differentiate between GSS-API mech and HTTP auth scheme. - PR: https://git.openjdk.java.net/jdk/pull/7065
Re: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v3]
On Mon, 24 Jan 2022 23:18:41 GMT, Mandy Chung wrote: >> The MethodHandle of a default method should be made as a fixed arity method >> handle because it is invoked via Proxy's invocation handle with a non-vararg >> array of arguments. On the other hand, the >> `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a >> default method of a proxy instance. This patch simply converts the >> implementation to call `InvocationHandle::invokeDefault` instead. > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > fix accident argument ordering after edit Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/jdk/internal/access/JavaLangReflectAccess.java line 107: > 105: > 106: public Object invokeDefault(Object proxy, Method method, Object[] > args, Class caller) > 107: throws Throwable; Minor nit: add a comment to the method so that it's consistent with the other JLRA methods. - PR: https://git.openjdk.java.net/jdk/pull/7185
Re: RFR: JDK-8280168: Add Objects.toIdentityString [v7]
On Mon, 24 Jan 2022 21:31:37 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, >> at times it is the least-bad alternative. When that alternative needs to be >> used, it would be helpful to have the implementation already available, such >> as in Objects.toDefaultString(). This method is analagous to >> System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy 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 > the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8280168 > - Merge branch 'master' into JDK-8280168 > - Appease jcheck. > - Add toIdentityString > - Respond to review feedback to augment test. > - Respond to review feedback. > - JDK-8280168 Add Objects.toDefaultString Looks good - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7139
Re: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v2]
On Mon, 24 Jan 2022 23:13:24 GMT, Mandy Chung wrote: > To invoke the default method, the caller will need access to the declaring > interface of the default method (via bytecode invocation or reflection). The > bug I had was because java.base (the module of the invocation handler) does > not have access to the interface even though the caller has. So invokeDefault is moved to Proxy with an optional access check, and you've made it callable from MHProxies by way of JLRA. I think that is okay. - PR: https://git.openjdk.java.net/jdk/pull/7185
[jdk18] RFR: 8280592: Small javadoc tweaks to foreign API
This patch fixes some inconsistencies in the foreign API javadoc. The main fix is to make javadoc of all predicate methods consistent, and to use the `@return` tag where appropriate, as to avoid duplication. There were also minor fixes in the package-level javadoc (one typo) and in `ValueLayout` (where hyphenation in *bit-alignment* has been dropped). - Commit messages: - Initial push Changes: https://git.openjdk.java.net/jdk18/pull/113/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=113&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280592 Stats: 91 lines in 12 files changed: 0 ins; 42 del; 49 mod Patch: https://git.openjdk.java.net/jdk18/pull/113.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/113/head:pull/113 PR: https://git.openjdk.java.net/jdk18/pull/113
Re: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3]
On Fri, 21 Jan 2022 17:07:37 GMT, Mark Sheppard wrote: >> Good point. I think its better to deal with the casts at the edges since the >> timeout handling will use long by default. > > yes a redeclaration of timeout with a type long across the component would > be a consistent approach, also so just to clarify, we're not taking the approach to homogenise the timeout declarations, throughout the component, to be of type long? which would see LdapClientFactory constructor take a long timeout and timeout member varaiables be redefined as long - PR: https://git.openjdk.java.net/jdk/pull/6568
Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v4]
On Mon, 24 Jan 2022 21:32:16 GMT, Peter Levart wrote: > This looks good, although I don't know whether the additional check for > strongReferent != null is needed in clearStrong(). This is all racy code and > you have already got a non-null return from getStrong() in case you are > calling clearStrong()... This seems like a standard thing to do to avoid multi-threaded write contention under the race. By the time one thread calls `clearStrong`, some other thread might have already cleared it, and we don't have to clear again. Granted, that is a micro-optimization, but I'd like to avoid surprises on this path :) - PR: https://git.openjdk.java.net/jdk/pull/7092
Re: RFR: 8280041: Retry loop issues in java.io.ClassCache
On Tue, 18 Jan 2022 20:07:10 GMT, Roger Riggs wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two >> issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the >> accidental passing of `null` value; in that case, the retry loop would spin >> indefinitely; >> - If retry loop would spin several times, every time discovering a cleared >> SoftReference, it would create and register new SoftReference on the >> ReferenceQueue. However, it would not *drain* the RQ in the loop; in that >> case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > It may not be worth it. If not, add the label "noreg-hard". > > It is possible for add to the test description the modules to be opened: > > * @modules java.base/java.io:open > > jtreg will add the appropriate command line args when it is compiled and run. > There are various examples in existing test/jdk/java/io... tests. @RogerRiggs, are you happy with tests? - PR: https://git.openjdk.java.net/jdk/pull/7092
Re: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases [v3]
On Tue, 18 Jan 2022 19:36:18 GMT, Chris Plummer wrote:
>> Aleksey Shipilev 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 four additional
>> commits since the last revision:
>>
>> - Update copyright dates
>> - Merge branch 'master' into JDK-8280166-getobjectsize
>> - Merge branch 'master' into JDK-8280166-getobjectsize
>> - Fix
>
> test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java line 326:
>
>> 324:
>> 325: public static void main(String[] args)throws Throwable {
>> 326: new GetObjectSizeIntrinsicsTest(args[0], (args.length >= 2 ?
>> args[1] : "")).runTest();
>
> Shouldn't this be `args.length == 2`?
@plummercj This does not look like a review-blocking comment, so I am going to
proceed with integration, if there are no other comments.
-
PR: https://git.openjdk.java.net/jdk/pull/7132
Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v5]
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two > issues with it: > - The cache cannot disambiguate between cleared SoftReference and the > accidental passing of `null` value; in that case, the retry loop would spin > indefinitely; > - If retry loop would spin several times, every time discovering a cleared > SoftReference, it would create and register new SoftReference on the > ReferenceQueue. However, it would not *drain* the RQ in the loop; in that > case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` Aleksey Shipilev 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 ten additional commits since the last revision: - Drop unnecessary null check in clearStrong - Merge branch 'master' into JDK-8280041-classcache-problems - Guarantee progress for at least one thread - Merge branch 'master' into JDK-8280041-classcache-problems - Test summary - GC sanity test - NullValueTest - Merge branch 'master' into JDK-8280041-classcache-problems - Fix - Changes: - all: https://git.openjdk.java.net/jdk/pull/7092/files - new: https://git.openjdk.java.net/jdk/pull/7092/files/0f2dcd0d..17073ef2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=03-04 Stats: 330 lines in 51 files changed: 159 ins; 70 del; 101 mod Patch: https://git.openjdk.java.net/jdk/pull/7092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7092/head:pull/7092 PR: https://git.openjdk.java.net/jdk/pull/7092
Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v4]
On Tue, 25 Jan 2022 16:12:11 GMT, Aleksey Shipilev wrote: > > This looks good, although I don't know whether the additional check for > > strongReferent != null is needed in clearStrong(). This is all racy code > > and you have already got a non-null return from getStrong() in case you are > > calling clearStrong()... > > This seems like a standard thing to do to avoid multi-threaded write > contention under the race. By the time one thread calls `clearStrong`, some > other thread might have already cleared it, and we don't have to clear again. > Granted, that is a micro-optimization, but I'd like to avoid surprises on > this path :) Actually, the window after the first `strongVal != null` check is not that large that a second null check would matter. Dropped the null check in `clearStrong` for simplicity. (IIRC, it mattered a bit in prior internal iterations of my patch). - PR: https://git.openjdk.java.net/jdk/pull/7092
Re: [jdk18] RFR: 8280592: Small javadoc tweaks to foreign API
On Tue, 25 Jan 2022 15:22:30 GMT, Maurizio Cimadamore
wrote:
> This patch fixes some inconsistencies in the foreign API javadoc. The main
> fix is to make javadoc of all predicate methods consistent, and to use the
> `@return` tag where appropriate, as to avoid duplication.
>
> There were also minor fixes in the package-level javadoc (one typo) and in
> `ValueLayout` (where hyphenation in *bit-alignment* has been dropped).
Marked as reviewed by psandoz (Reviewer).
src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java
line 43:
> 41:
> 42: /**
> 43: * {@return the {@linkplain MemoryAddress memory address} associated
> with this addressable}
Oh, i just learnt a new JavaDoc trick!
-
PR: https://git.openjdk.java.net/jdk18/pull/113
Re: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v2]
On Tue, 25 Jan 2022 05:25:12 GMT, Joe Darcy wrote: >> Making the exception message friendlier to users. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respond to review feedback. There is another `newIllegalAccessException(Class memberClass, int modifiers)` method that also needs to be updated. - PR: https://git.openjdk.java.net/jdk/pull/7208
Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v5]
On Tue, 25 Jan 2022 16:33:10 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two >> issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the >> accidental passing of `null` value; in that case, the retry loop would spin >> indefinitely; >> - If retry loop would spin several times, every time discovering a cleared >> SoftReference, it would create and register new SoftReference on the >> ReferenceQueue. However, it would not *drain* the RQ in the loop; in that >> case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev 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 ten additional > commits since the last revision: > > - Drop unnecessary null check in clearStrong > - Merge branch 'master' into JDK-8280041-classcache-problems > - Guarantee progress for at least one thread > - Merge branch 'master' into JDK-8280041-classcache-problems > - Test summary > - GC sanity test > - NullValueTest > - Merge branch 'master' into JDK-8280041-classcache-problems > - Fix Looks good, thanks for the tests. - Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7092
Re: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v3]
On Tue, 25 Jan 2022 14:36:26 GMT, Alan Bateman wrote: >> Mandy Chung has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix accident argument ordering after edit > > src/java.base/share/classes/jdk/internal/access/JavaLangReflectAccess.java > line 107: > >> 105: >> 106: public Object invokeDefault(Object proxy, Method method, Object[] >> args, Class caller) >> 107: throws Throwable; > > Minor nit: add a comment to the method so that it's consistent with the other > JLRA methods. What about this: /** Invokes the given default method if the method's declaring interface is * accessible to the given caller. Otherwise, IllegalAccessException will * be thrown. If the caller is null, no access check is performed. */ public Object invokeDefault(Object proxy, Method method, Object[] args, Class caller) throws Throwable; - PR: https://git.openjdk.java.net/jdk/pull/7185
Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call
On Tue, 25 Jan 2022 10:29:48 GMT, Thomas Stuefe wrote:
> I'm curious, under what circumstances would, before
> https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary
> in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where
> the JVM was not involved and hence the zip.dll was not loaded already?
>
> For me, the code looks good unless I miss a scenario where we don't have the
> JVM loaded already at this point.
Thanks for review. Before 8237750, the zip library is always loaded so jimage
just get the handle of the loaded zip by calling . After that, zip is loaded at
need, so if jvm does not use zip, it will not be loaded. Unfortunately, it does
not realize that jimage is using this zip, so it failed to get the handle. But
there exists a case, if the zip is in PATH, the following fix 8244495 used
LoadLibrary("zip.dll") for a rescue. If zip.dll is not in PATH, the call still
failed to load zip. This is the current issue.
So far, if user loaded zip from native code before jimage code is executed ( I
could not image a scenario how it can happen), the GetModuleHandle("zip.dll")
may return the handle to it, but it does not surely it is for the "zip.dll" ---
if multiple instances exist, the returned handle is not guaranteed the one you
want.
With this change, if user loads zip from native code (with different version),
JVM does not sense that, it will still load zip from $JDK or $JRE, and jimage
still uses handle returned from JVM. The only case is JVM failed to load zip
library:
if (_zip_handle == NULL) {
vm_exit_during_initialization("Unable to load zip library", path);
}
You cannot make any progress on the failure.
-
PR: https://git.openjdk.java.net/jdk/pull/7206
Re: RFR: JDK-8280168: Add Objects.toIdentityString [v8]
> While it is strongly recommend to not use the default toString for a class, > at times it is the least-bad alternative. When that alternative needs to be > used, it would be helpful to have the implementation already available, such > as in Objects.toDefaultString(). This method is analagous to > System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyright, remove author tag. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7139/files - new: https://git.openjdk.java.net/jdk/pull/7139/files/b7ef3017..2cf7a54d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7139/head:pull/7139 PR: https://git.openjdk.java.net/jdk/pull/7139
Integrated: JDK-8280168: Add Objects.toIdentityString
On Tue, 18 Jan 2022 23:15:20 GMT, Joe Darcy wrote: > While it is strongly recommend to not use the default toString for a class, > at times it is the least-bad alternative. When that alternative needs to be > used, it would be helpful to have the implementation already available, such > as in Objects.toDefaultString(). This method is analagous to > System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 This pull request has now been integrated. Changeset: cbe8395a Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/cbe8395ace3230dc599c7f082e3524a861b2da8e Stats: 61 lines in 3 files changed: 56 ins; 1 del; 4 mod 8280168: Add Objects.toIdentityString Reviewed-by: alanb, mchung, rriggs, smarks - PR: https://git.openjdk.java.net/jdk/pull/7139
Re: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v3]
> Making the exception message friendlier to users. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7208/files - new: https://git.openjdk.java.net/jdk/pull/7208/files/1885c04a..9cff95dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=01-02 Stats: 25 lines in 1 file changed: 10 ins; 12 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7208/head:pull/7208 PR: https://git.openjdk.java.net/jdk/pull/7208
Re: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v4]
> Making the exception message friendlier to users. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7208/files - new: https://git.openjdk.java.net/jdk/pull/7208/files/9cff95dc..d0011e41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7208/head:pull/7208 PR: https://git.openjdk.java.net/jdk/pull/7208
Re: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v2]
On Tue, 25 Jan 2022 17:10:33 GMT, Mandy Chung wrote: > There is another `newIllegalAccessException(Class memberClass, int > modifiers)` method that also needs to be updated. Updated accordingly and refactored slightly to pull out the string suffix construction into a new method. - PR: https://git.openjdk.java.net/jdk/pull/7208
Re: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 [v3]
On Tue, 25 Jan 2022 08:33:21 GMT, Matthias Baesken wrote: >> After 8270492 >> https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 >> has been pushed, we should adjust >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java >> getAbsoluteURI to what has been done in 8270492 to >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Add LastModified Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7155
Re: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v4]
On Tue, 25 Jan 2022 18:25:14 GMT, Joe Darcy wrote: >> Making the exception message friendlier to users. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Fix typo. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7208
Re: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v4]
On Tue, 25 Jan 2022 18:25:14 GMT, Joe Darcy wrote: >> Making the exception message friendlier to users. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Fix typo. Looks good. - Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7208
Re: RFR: 8280041: Retry loop issues in java.io.ClassCache [v5]
On Tue, 25 Jan 2022 16:33:10 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two >> issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the >> accidental passing of `null` value; in that case, the retry loop would spin >> indefinitely; >> - If retry loop would spin several times, every time discovering a cleared >> SoftReference, it would create and register new SoftReference on the >> ReferenceQueue. However, it would not *drain* the RQ in the loop; in that >> case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev 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 ten additional > commits since the last revision: > > - Drop unnecessary null check in clearStrong > - Merge branch 'master' into JDK-8280041-classcache-problems > - Guarantee progress for at least one thread > - Merge branch 'master' into JDK-8280041-classcache-problems > - Test summary > - GC sanity test > - NullValueTest > - Merge branch 'master' into JDK-8280041-classcache-problems > - Fix All right, we seem to be good to go. - PR: https://git.openjdk.java.net/jdk/pull/7092
Integrated: 8280041: Retry loop issues in java.io.ClassCache
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote: > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two > issues with it: > - The cache cannot disambiguate between cleared SoftReference and the > accidental passing of `null` value; in that case, the retry loop would spin > indefinitely; > - If retry loop would spin several times, every time discovering a cleared > SoftReference, it would create and register new SoftReference on the > ReferenceQueue. However, it would not *drain* the RQ in the loop; in that > case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` This pull request has now been integrated. Changeset: cebaad1c Author:Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/cebaad1c94c301304fd146526cac95bfeaac66bf Stats: 202 lines in 5 files changed: 190 ins; 0 del; 12 mod 8280041: Retry loop issues in java.io.ClassCache Co-authored-by: Peter Levart Reviewed-by: rkennke, rriggs, plevart - PR: https://git.openjdk.java.net/jdk/pull/7092
Integrated: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases
On Tue, 18 Jan 2022 18:33:29 GMT, Aleksey Shipilev wrote: > While working on JDK-8280003, I noticed that > java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays > with more than 1-byte size elements, and no large arrays (past 4G limit) are > tested either. It would be better to add those test cases. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test still passes > - [x] Linux AArch64 fastdebug, affected test still passes > - [x] Linux PPC64 fastdebug, affected test still passes This pull request has now been integrated. Changeset: 76fe03fe Author:Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752 Stats: 89 lines in 1 file changed: 62 ins; 0 del; 27 mod 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases Reviewed-by: sspitsyn, lmesnik - PR: https://git.openjdk.java.net/jdk/pull/7132
Re: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v5]
> Making the exception message friendlier to users. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Improve formatting. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7208/files - new: https://git.openjdk.java.net/jdk/pull/7208/files/d0011e41..f92b8f78 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7208/head:pull/7208 PR: https://git.openjdk.java.net/jdk/pull/7208
Integrated: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement
On Tue, 25 Jan 2022 02:42:45 GMT, Joe Darcy wrote: > Making the exception message friendlier to users. This pull request has now been integrated. Changeset: 295c0474 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/295c0474c43484e793b67a70af316aaae49fe361 Stats: 19 lines in 1 file changed: 10 ins; 6 del; 3 mod 8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement Reviewed-by: iris, dholmes, mchung - PR: https://git.openjdk.java.net/jdk/pull/7208
Re: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v3]
On Tue, 25 Jan 2022 17:20:50 GMT, Mandy Chung wrote: > What about this: Looks okay, main thing is to have it be consistent with the existing methods. - PR: https://git.openjdk.java.net/jdk/pull/7185
Re: RFR: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread
On Tue, 18 Jan 2022 15:57:58 GMT, Roger Riggs wrote: > The thread factory used to create the process reaper threads unnecessarily > inherits the callers thread context classloader. > The result is retention of the class loader. > > The thread factory used for the pool of process reaper threads is modified to > use an InnocuousThread with a given stacksize. > The test verifies that the process reaper threads have a null context > classloader. @AlanBateman Can you take a look at this use of InnocuousThread. Thanks - PR: https://git.openjdk.java.net/jdk/pull/7131
Re: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v4]
> The MethodHandle of a default method should be made as a fixed arity method > handle because it is invoked via Proxy's invocation handle with a non-vararg > array of arguments. On the other hand, the `InvocationHandle::invokeDefault` > method was added in Java 16 to invoke a default method of a proxy instance. > This patch simply converts the implementation to call > `InvocationHandle::invokeDefault` instead. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: add comment - Changes: - all: https://git.openjdk.java.net/jdk/pull/7185/files - new: https://git.openjdk.java.net/jdk/pull/7185/files/30f1a05e..3f31d379 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7185&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7185&range=02-03 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7185/head:pull/7185 PR: https://git.openjdk.java.net/jdk/pull/7185
Re: [jdk18] RFR: 8280592: Small javadoc tweaks to foreign API
On Tue, 25 Jan 2022 17:00:34 GMT, Paul Sandoz wrote:
>> This patch fixes some inconsistencies in the foreign API javadoc. The main
>> fix is to make javadoc of all predicate methods consistent, and to use the
>> `@return` tag where appropriate, as to avoid duplication.
>>
>> There were also minor fixes in the package-level javadoc (one typo) and in
>> `ValueLayout` (where hyphenation in *bit-alignment* has been dropped).
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java
> line 43:
>
>> 41:
>> 42: /**
>> 43: * {@return the {@linkplain MemoryAddress memory address} associated
>> with this addressable}
>
> Oh, i just learnt a new JavaDoc trick!
heh - me too - hat tip to @pavelrappo :-)
-
PR: https://git.openjdk.java.net/jdk18/pull/113
RFR: JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly
Update the java.lang.{Math, StrictMath} regression test helper library to
accept method references. This allows the test programs to be DRY-er as the
inputs to the method under test don't have to be repeated. The float test
method were not updated due to limitations in type inference if both float and
double methods with functional interface parameters are present.
Also did some general tidying up for the test code.
-
Commit messages:
- Appease jcheck.
- Further refactoring.
- Update copyright year, remove author tags.
- JDK-8270476: Make floating-point test infrastructure more lambda and method
reference friendly
Changes: https://git.openjdk.java.net/jdk/pull/7216/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7216&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8270476
Stats: 455 lines in 27 files changed: 118 ins; 145 del; 192 mod
Patch: https://git.openjdk.java.net/jdk/pull/7216.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7216/head:pull/7216
PR: https://git.openjdk.java.net/jdk/pull/7216
Re: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v4]
On Tue, 25 Jan 2022 21:35:27 GMT, Mandy Chung wrote: >> The MethodHandle of a default method should be made as a fixed arity method >> handle because it is invoked via Proxy's invocation handle with a non-vararg >> array of arguments. On the other hand, the >> `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a >> default method of a proxy instance. This patch simply converts the >> implementation to call `InvocationHandle::invokeDefault` instead. > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > add comment My question was for when a library wants to implement something similar to `MethodHandleProxies.asInterfaceInstace`, and for example supports Interfaces with more than a single abstract method. Currently, such a library would also have to call `ReflectAccess.invokeDefault`, as the interface may not be accessible by the `InvocationHandler` (as it could be the case with `MethodHandleProxies.asInterfaceInstace` But this might be a discussion for an other time. Patch looks good. - PR: https://git.openjdk.java.net/jdk/pull/7185
Re: Additional Date-Time Formats
Hi Joe,
On 1/24/22 5:50 PM, Joe Wang wrote:
The 2nd and 3rd statements defined the requestedTemplate, does
it imply the characters listed in the snippet are the only ones that are
valid, in other words, can other characters under the Patterns section
be used? It may be helpful to elaborate on the snippet a bit more.
Those symbols represent each field, so other symbols are considered
illegal as a template symbol. Added some explanation there.
Also, the range implies a valid range for a particular symbol,
if that's the case, y and w feel like they are unbound. If I do that
with ofPettern, I get ArrayIndexOutOfBoundsException.
The spec of 'year' and 'number' presentations do not have any upper
limit number of letters, thus I added the '*' quantifier. Not exactly
sure why AIOOBE is thrown with ofPattern(), could be a separate bug? It
should be zero-padded or sign-padded.
For the sample code, it might be helpful to put them in a code snippet
and with the actual java code. If "yMMM" formats to 'Jun 2020', that
might require some explanation too since that would be the same as
ofPattern("MMM y") for the default(US) locale, or was it a typo?. (I'm
not familiar with the use of DTF, just printed out
date.format(DTF.ofPattern("yMMM" and "MMM y") :-))
Well, it is not a typo and `ofLocalizedPattern("yMMM", Locale.US)` and
`ofPattern("MMM y", Locale.US)` both generating the same result is
exactly what this API is aiming at. Users don't need to pay attention to
locale specific format pattern with this API.
HTH,
Naoto
Re: Additional Date-Time Formats
Hi Naoto,
Looks good to me, and thanks for the explanation. I agree, AIOOBE would
be a separate bug with ofPattern.
Thanks,
Joe
On 1/25/22 2:30 PM, Naoto Sato wrote:
Hi Joe,
On 1/24/22 5:50 PM, Joe Wang wrote:
The 2nd and 3rd statements defined the requestedTemplate,
does it imply the characters listed in the snippet are the only ones
that are valid, in other words, can other characters under the
Patterns section be used? It may be helpful to elaborate on the
snippet a bit more.
Those symbols represent each field, so other symbols are considered
illegal as a template symbol. Added some explanation there.
Also, the range implies a valid range for a particular
symbol, if that's the case, y and w feel like they are unbound. If I
do that with ofPettern, I get ArrayIndexOutOfBoundsException.
The spec of 'year' and 'number' presentations do not have any upper
limit number of letters, thus I added the '*' quantifier. Not exactly
sure why AIOOBE is thrown with ofPattern(), could be a separate bug?
It should be zero-padded or sign-padded.
For the sample code, it might be helpful to put them in a code
snippet and with the actual java code. If "yMMM" formats to 'Jun
2020', that might require some explanation too since that would be
the same as ofPattern("MMM y") for the default(US) locale, or was it
a typo?. (I'm not familiar with the use of DTF, just printed out
date.format(DTF.ofPattern("yMMM" and "MMM y") :-))
Well, it is not a typo and `ofLocalizedPattern("yMMM", Locale.US)` and
`ofPattern("MMM y", Locale.US)` both generating the same result is
exactly what this API is aiming at. Users don't need to pay attention
to locale specific format pattern with this API.
HTH,
Naoto
Re: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v4]
On Tue, 25 Jan 2022 22:01:22 GMT, Johannes Kuhn wrote: > My question was for when a library wants to implement something similar to > `MethodHandleProxies.asInterfaceInstace`, and for example supports Interfaces > with more than a single abstract method. Currently, such a library would also > have to call `ReflectAccess.invokeDefault`, as the interface may not be > accessible by the `InvocationHandler` (as it could be the case with > `MethodHandleProxies.asInterfaceInstace` > > But this might be a discussion for an other time. Patch looks good. They will probably accept a `MethodHandles.Lookup` object to define a class for such a single-interface instance plus calling the default methods beyond the restrictions. - PR: https://git.openjdk.java.net/jdk/pull/7185
Re: RFR: JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly [v2]
> Update the java.lang.{Math, StrictMath} regression test helper library to
> accept method references. This allows the test programs to be DRY-er as the
> inputs to the method under test don't have to be repeated. The float test
> method were not updated due to limitations in type inference if both float
> and double methods with functional interface parameters are present.
>
> Also did some general tidying up for the test code.
Joe Darcy 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 six additional commits since the
last revision:
- Use consistent syntax for main method.
- Merge branch 'master' into JDK-8270476
- Appease jcheck.
- Further refactoring.
- Update copyright year, remove author tags.
- JDK-8270476: Make floating-point test infrastructure more lambda and method
reference friendly
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7216/files
- new: https://git.openjdk.java.net/jdk/pull/7216/files/e040a8ea..789782ce
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7216&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7216&range=00-01
Stats: 2042 lines in 266 files changed: 1058 ins; 227 del; 757 mod
Patch: https://git.openjdk.java.net/jdk/pull/7216.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7216/head:pull/7216
PR: https://git.openjdk.java.net/jdk/pull/7216
Integrated: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor
On Thu, 16 Dec 2021 17:44:04 GMT, Vicente Romero wrote: > Hi, > > Please review this change that is fixing a bug in reflection in particular in > `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the > current code is assuming that for inner class constructors, there are only > type annotations on parameters, but it is also invoked to extract type > annotations applied to exception types for example. This bug affects the > behavior of method: > `java.lang.reflect.Executable::getAnnotatedExceptionTypes` which is not > behaving according to its specification. Given that this fix affects the > behavior of a method belonging to our API a CSR has been filed too. Please > review it at [JDK-8278926](https://bugs.openjdk.java.net/browse/JDK-8278926). > > TIA This pull request has now been integrated. Changeset: 2eab86b5 Author:Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/2eab86b513a9e4566b3f5989f899ae44280d3834 Stats: 16 lines in 2 files changed: 11 ins; 1 del; 4 mod 8213905: reflection not working for type annotations applied to exception types in the inner class constructor Reviewed-by: jlahoda - PR: https://git.openjdk.java.net/jdk/pull/6869
RFR: 8279598: Provide adapter from RandomGenerator to Random
Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 - Commit messages: - No need to synchronize setSeed nextGaussian - No need to synchronize setSeed - Fix whitespace and tab - Rewrite javadoc - Add copyright notice - Make use of the new wrapper function - Add static method to create wrapper - implement RandomGenerator interface - Fix imports - Create asRandom() method in RandomGenerator - ... and 1 more: https://git.openjdk.java.net/jdk/compare/d47af74e...fbdf4969 Changes: https://git.openjdk.java.net/jdk/pull/7001/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279598 Stats: 171 lines in 2 files changed: 171 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001
Re: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v4]
On Wed, 26 Jan 2022 00:06:25 GMT, liach wrote: > They will probably accept a MethodHandles.Lookup object to define a class for > such a single-interface instance plus calling the default methods beyond the > restrictions. Yes, that's one option. Such library should take a Lookup parameter to find the method handle for the default method as in the previous `MethodHandleProxies` implementation. Alternatively, the module of the target interface will need to be open to the library's module for deep reflection and the library can use `MethodHandles::privateLookupIn` to lookup the default method then. - PR: https://git.openjdk.java.net/jdk/pull/7185
[jdk18] Integrated: 8280592: Small javadoc tweaks to foreign API
On Tue, 25 Jan 2022 15:22:30 GMT, Maurizio Cimadamore wrote: > This patch fixes some inconsistencies in the foreign API javadoc. The main > fix is to make javadoc of all predicate methods consistent, and to use the > `@return` tag where appropriate, as to avoid duplication. > > There were also minor fixes in the package-level javadoc (one typo) and in > `ValueLayout` (where hyphenation in *bit-alignment* has been dropped). This pull request has now been integrated. Changeset: ef08e2c6 Author:Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk18/commit/ef08e2c63b040cef6ca5f71dbce49f3d7647fdd8 Stats: 91 lines in 12 files changed: 0 ins; 42 del; 49 mod 8280592: Small javadoc tweaks to foreign API Reviewed-by: psandoz - PR: https://git.openjdk.java.net/jdk18/pull/113
Integrated: 8280377: MethodHandleProxies does not correctly invoke default methods with varags
On Fri, 21 Jan 2022 22:49:38 GMT, Mandy Chung wrote: > The MethodHandle of a default method should be made as a fixed arity method > handle because it is invoked via Proxy's invocation handle with a non-vararg > array of arguments. On the other hand, the `InvocationHandle::invokeDefault` > method was added in Java 16 to invoke a default method of a proxy instance. > This patch simply converts the implementation to call > `InvocationHandle::invokeDefault` instead. This pull request has now been integrated. Changeset: a183bfb4 Author:Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/a183bfb436a7dd998e602c2d16486e88c390fca1 Stats: 358 lines in 12 files changed: 292 ins; 63 del; 3 mod 8280377: MethodHandleProxies does not correctly invoke default methods with varags Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/7185
RFR: JDK-8280550: SplittableRandom#nextDouble(double,double) can return result >= bound
Use floating-point library methods to nudge down the result if needed. The nextAfter(r, origin) call return the next value in the direction of origin, handling cases for negative values, etc. Changing to call nextDown for the origin is bounded at zero is just a refactoring that is clearer to read IMO. The regression test fails on an unpatched JDK. - Commit messages: - Appease jcheck - JDK-8280550: SplittableRandom#nextDouble(double,double) can return result >= bound Changes: https://git.openjdk.java.net/jdk/pull/7221/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7221&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280550 Stats: 54 lines in 2 files changed: 52 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7221.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7221/head:pull/7221 PR: https://git.openjdk.java.net/jdk/pull/7221
Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call
On Tue, 25 Jan 2022 17:22:54 GMT, Yumin Qi wrote:
>> I'm curious, under what circumstances would, before
>> https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the
>> LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a
>> scenario where the JVM was not involved and hence the zip.dll was not loaded
>> already?
>>
>> For me, the code looks good unless I miss a scenario where we don't have the
>> JVM loaded already at this point.
>
>> I'm curious, under what circumstances would, before
>> https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the
>> LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a
>> scenario where the JVM was not involved and hence the zip.dll was not loaded
>> already?
>>
>> For me, the code looks good unless I miss a scenario where we don't have the
>> JVM loaded already at this point.
>
> Thanks for review. Before 8237750, the zip library is always loaded so
> jimage just get the handle of the loaded zip by calling . After that, zip is
> loaded at need, so if jvm does not use zip, it will not be loaded.
> Unfortunately, it does not realize that jimage is using this zip, so it
> failed to get the handle. But there exists a case, if the zip is in PATH, the
> following fix 8244495 used LoadLibrary("zip.dll") for a rescue. If zip.dll
> is not in PATH, the call still failed to load zip. This is the current issue.
>
> So far, if user loaded zip from native code before jimage code is executed (
> I could not image a scenario how it can happen), the
> GetModuleHandle("zip.dll") may return the handle to it, but it does not
> surely it is for the "zip.dll" --- if multiple instances exist, the returned
> handle is not guaranteed the one you want.
>
> With this change, if user loads zip from native code (with different
> version), JVM does not sense that, it will still load zip from $JDK or $JRE,
> and jimage still uses handle returned from JVM. The only case is JVM failed
> to load zip library:
>
> if (_zip_handle == NULL) {
> vm_exit_during_initialization("Unable to load zip library", path);
> }
>
> You cannot make any progress on the failure.
Thanks for the explanation, @yminqi. Change looks good.
-
PR: https://git.openjdk.java.net/jdk/pull/7206
Integrated: 8280531: Remove unused DeferredCloseInputStream
On Tue, 18 Jan 2022 20:51:06 GMT, Andrey Turbanov wrote: > Class DeferredCloseInputStream is unused since removing of Solaris support > https://github.com/openjdk/jdk/blob/9fe4b69c1a1120e1d761730495c3cfac8f179d13/src/java.base/unix/classes/java/lang/ProcessImpl.java#L80-L81 This pull request has now been integrated. Changeset: e72eefd9 Author:Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/e72eefd9f66e63a1e11d582e4916374840111928 Stats: 106 lines in 1 file changed: 0 ins; 104 del; 2 mod 8280531: Remove unused DeferredCloseInputStream Reviewed-by: bpb, rriggs, iris - PR: https://git.openjdk.java.net/jdk/pull/7135
