Re: RFR: 8276700: Improve java.lang.ref.Cleaner javadocs
On Tue, 9 Nov 2021 00:31:36 GMT, Brent Christian wrote: >> A cleaner can/should be shared within some scope and purpose, in this case >> the example class . >> Each cleaner has a dedicated Thread so its not a lightweight object and >> should not be proliferated. >> (Loom may be able to use Virtual Threads). >> >> The reasons to not share are a Cleaner are based on possible interference >> between the cleanup callbacks. >> If they share a thread and are non-trivial, it might slow other cleaners. If >> the cleaner is created and shared >> for a particular purpose it will share the thread resource and still be >> efficient. > > The new example Cleaner instance _is_ shared, though on a pretty small scale > (just among instances of CleaningExample). A demonstration of larger scale > sharing of a Cleaner instance would be out of scope for this example. Let me add, why I have raised this issue. I was going to migrate some older code which uses the `finalize()` method to the `Cleaner` mechanism. New it it, there seemed to be two pitfalls: 1. Understanding the whole "don't capture an instance reference in your state object" 2. Copying the example (which was in a non-working state, due to pseudo code) and making it work for me With the improvement suggestions, I was trying help people who *only* read the code sample (many do), to become aware of 1. and help them getting going with 2, simply because it's something they can copy and run. - PR: https://git.openjdk.java.net/jdk/pull/6076
Re: RFR: 8276700: Improve java.lang.ref.Cleaner javadocs
On Tue, 9 Nov 2021 08:59:32 GMT, Hendrik Schreiber
wrote:
>> The new example Cleaner instance _is_ shared, though on a pretty small scale
>> (just among instances of CleaningExample). A demonstration of larger scale
>> sharing of a Cleaner instance would be out of scope for this example.
>
> Let me add, why I have raised this issue.
>
> I was going to migrate some older code which uses the `finalize()` method to
> the `Cleaner` mechanism. New it it, there seemed to be two pitfalls:
>
> 1. Understanding the whole "don't capture an instance reference in your state
> object"
> 2. Copying the example (which was in a non-working state, due to pseudo code)
> and making it work for me
>
> With the improvement suggestions, I was trying help people who *only* read
> the code sample (many do), to become aware of 1. and help them getting going
> with 2, simply because it's something they can copy and run.
> When I see ``, I'm just wondering what those <> type operators are
> good for here...
What about just replacing `` with `...` then? The `State` constructor
and its invocation also have an ellipsis.
> BUT, at least it's a working example and not some pseudo code.
The example is still not compilable due to the remaining ellipses.
> We do want to move to working example code long term, don't we?
I agree that examples should be compilable *in the raw Javadoc*. However, in
the rendered Javadoc, using ellipses is a well-understood way to keep examples
concise and devoid of irrelevant and/or usecase-dependent code. Moreover, when
developers copy-paste the example, they'll immediately be pointed to all the
places where they need to fill in the blanks, make a choice for a trade-off,
etc. On the other hand, by hard-coding a (suboptimal) choice, developers who
merely copy-paste the example are unlikely to reconsider the trade-off.
> The new example Cleaner instance _is_ shared, though on a pretty small scale
> (just among instances of CleaningExample).
True, but my point was that the comment says "shared *within a library*". So to
me it's confusing to have a comment saying "it's preferred to do A", and then
have the code do B on the next line.
So I propose to either:
* revert the current change & simply replace `` with `...`
* update the comment to say: "A cleaner (preferably one shared within a
library, but for the sake of example, a new one is created here)"
Actually, to have the line be compilable, and at the same time (attempt to)
force developers to consider the trade-off, it could be changed to something
like:
private static final Cleaner cleaner = createCleaner();
private static Cleaner createCleaner() {
// A cleaner, preferably one shared within a library
throw new UnsupportedOperationException("TBD");
}
-
PR: https://git.openjdk.java.net/jdk/pull/6076
Re: RFR: 8276220: Reduce excessive allocations in DateTimeFormatter [v10]
On Wed, 3 Nov 2021 22:55:23 GMT, Claes Redestad wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove accidentally committed experimental @Stable (no effect on micros) > > Thanks, Naoto! @cl4es For `DateTimeFormatterBuilder ` spec, I propose changing the existing wording slightly If the field value in the date-time to be printed is invalid it cannot be printed and an exception will be thrown. to If the field value in the date-time to be printed is outside the range of valid values then an exception will be thrown. - PR: https://git.openjdk.java.net/jdk/pull/6188
Integrated: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
On Fri, 24 Sep 2021 11:28:09 GMT, Masanori Yano wrote: > Could you please review the 8250678 bug fixes? > > The `parse` method of ModuleDescriptor.Version class behaves incorrectly when > the input string contains consecutive delimiters. > > The `parse` method treats strings as three sections, but the parsing method > differs between the method for the version sections and the ones for others. > In version sections, the `parse` method takes a single character in a loop > and determines whether it is a delimiter. In pre and build sections, the > parse method takes two characters in a loop and determines whether the second > character is the delimiter. Therefore, if the string contains a sequence of > delimiters in pre or build section, the `parse` method treats character at > the odd-numbered position as a token and the one at even-numbered as a > delimiter. > > A string containing consecutive delimiters is an incorrect version string, > but this behavior does not follow the API specification. > https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html > > Therefore, I propose to fix the parsing method of pre and build section in > the same way as the version. This pull request has now been integrated. Changeset: e1985947 Author:Masanori Yano Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/e198594753b0b0653256923586c7f4ec9e3cfac3 Stats: 26 lines in 2 files changed: 11 ins; 14 del; 1 mod 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Reviewed-by: mchung, alanb - PR: https://git.openjdk.java.net/jdk/pull/5679
Re: RFR: 8276700: Improve java.lang.ref.Cleaner javadocs
On Fri, 22 Oct 2021 08:03:34 GMT, Hendrik Schreiber wrote: > Trivial improvement. > > Explicitly show how to create a `Cleaner` instance using `Cleaner.create()`. > Repeat (again) in the code example that the `State` `Runnable `should be > implemented as static class and not reference the instance to be cleaned, to > make the point even more clear to those people who never read the javadoc > *prose*. > > I have signed the OCA a while back as > [hschreiber](https://openjdk.java.net/census#hschreiber). As for compilable code, this may be a good place to use Snippets. [JEP 413: Code Snippets in Java API Documentation](https://openjdk.java.net/jeps/413) They are new but may offer some value add here. Good standalone examples aren't always good programming practice. - PR: https://git.openjdk.java.net/jdk/pull/6076
Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales
On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote: > Please review the subject fix. In light of JEP400, Java runtime can/should > start in UTF-8 charset if the underlying native encoding is not supported. LGTM - Marked as reviewed by mamadal...@github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/6282
RFR: 8276609: Invalid system property `jdk.serialFilter` set on the commd d line should cause `ExceptionInInitializerError`
When set on the command line `jdk.serialFilter` to an invalid value, the invalid value is logged but the application is allowed to start without setting the filter. This leaves the application without the protections of the serial filter. The specification should be clarify that an `ExceptionInInitializerError` is thrown. - Commit messages: - 8276609: Invalid system property `jdk.serialFilter` set on the command line should cause `ExceptionInInitializerError` Changes: https://git.openjdk.java.net/jdk/pull/6317/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6317&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276609 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6317.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6317/head:pull/6317 PR: https://git.openjdk.java.net/jdk/pull/6317
RFR: 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary
The java/lang/RuntimeTests/exec/ExecWithDir test forks 500 subprocesses hoping to trigger an intermittent problem fixed in 2002. The test can be removed, it does not exercise the condition it was created for. - Commit messages: - 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary Changes: https://git.openjdk.java.net/jdk/pull/6318/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6318&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276880 Stats: 61 lines in 1 file changed: 0 ins; 61 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6318.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6318/head:pull/6318 PR: https://git.openjdk.java.net/jdk/pull/6318
Re: RFR: 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary
On Tue, 9 Nov 2021 16:05:52 GMT, Roger Riggs wrote: > The java/lang/RuntimeTests/exec/ExecWithDir test forks 500 subprocesses > hoping to trigger an intermittent problem fixed in 2002. > > The test can be removed, it does not exercise the condition it was created > for. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6318
Re: RFR: 8276141: XPathFactory set/getProperty method [v7]
On Tue, 9 Nov 2021 06:31:06 GMT, Joe Wang wrote:
>> Add setProperty/getProperty methods to the XPath API so that properties can
>> be supported in the future.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> javadoc clarification for setFeature and setProperty
src/java.xml/share/classes/javax/xml/xpath/XPathFactory.java line 377:
> 375: * Sets a property for this {@code XPathFactory}. A property set on
> the
> 376: * factory is effective to the {@code XPath} object created
> thereafter, but
> 377: * not ones that may have been created beforehand.
It might be clear to say something like "The property has no impact on XPath
object that are already created".
-
PR: https://git.openjdk.java.net/jdk/pull/6215
Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]
> Please review the subject fix. In light of JEP400, Java runtime can/should > start in UTF-8 charset if the underlying native encoding is not supported. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Emit a warning on unsupported jnu encoding - Changes: - all: https://git.openjdk.java.net/jdk/pull/6282/files - new: https://git.openjdk.java.net/jdk/pull/6282/files/0b9f6df3..d3c240c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=00-01 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282
Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales
On Mon, 8 Nov 2021 09:44:34 GMT, Alan Bateman wrote: > There may be an argument that the JDK should emit a warning at startup. Updated to emit a warning, if `sun.jnu.encoding` is not supported. - PR: https://git.openjdk.java.net/jdk/pull/6282
Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]
On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should >> start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Emit a warning on unsupported jnu encoding Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6282
Integrated: 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary
On Tue, 9 Nov 2021 16:05:52 GMT, Roger Riggs wrote: > The java/lang/RuntimeTests/exec/ExecWithDir test forks 500 subprocesses > hoping to trigger an intermittent problem fixed in 2002. > > The test can be removed, it does not exercise the condition it was created > for. This pull request has now been integrated. Changeset: d7012fbd Author:Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/d7012fbd604fc1a54a2d7364a6ca4a32f47ffc7c Stats: 61 lines in 1 file changed: 0 ins; 61 del; 0 mod 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/6318
Re: RFR: 8276141: XPathFactory set/getProperty method [v8]
> Add setProperty/getProperty methods to the XPath API so that properties can > be supported in the future. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: Update as commented - Changes: - all: https://git.openjdk.java.net/jdk/pull/6215/files - new: https://git.openjdk.java.net/jdk/pull/6215/files/901ebc0e..56ede26e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6215&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6215&range=06-07 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6215.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6215/head:pull/6215 PR: https://git.openjdk.java.net/jdk/pull/6215
Re: RFR: 8276141: XPathFactory set/getProperty method [v7]
On Tue, 9 Nov 2021 19:34:50 GMT, Alan Bateman wrote:
>> Joe Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> javadoc clarification for setFeature and setProperty
>
> src/java.xml/share/classes/javax/xml/xpath/XPathFactory.java line 377:
>
>> 375: * Sets a property for this {@code XPathFactory}. A property set on
>> the
>> 376: * factory is effective to the {@code XPath} object created
>> thereafter, but
>> 377: * not ones that may have been created beforehand.
>
> It might be clear to say something like "The property has no impact on XPath
> object that are already created".
Thanks Alan. Updated accordingly.
-
PR: https://git.openjdk.java.net/jdk/pull/6215
Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2]
On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should >> start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Emit a warning on unsupported jnu encoding Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6282
RFR: 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893
Simple doc clarification where the `toString()` output only conforms to ISO 8601 if the seconds in the offset are zero. - Commit messages: - 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893 Changes: https://git.openjdk.java.net/jdk/pull/6321/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6321&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276775 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6321/head:pull/6321 PR: https://git.openjdk.java.net/jdk/pull/6321
Re: RFR: 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893
On Tue, 9 Nov 2021 22:29:12 GMT, Naoto Sato wrote: > Simple doc clarification where the `toString()` output only conforms to ISO > 8601 if the seconds in the offset are zero. Hi Naoto, I would probably file a CSR to track this minor update - PR: https://git.openjdk.java.net/jdk/pull/6321
Re: RFR: 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893
On Tue, 9 Nov 2021 22:29:12 GMT, Naoto Sato wrote: > Simple doc clarification where the `toString()` output only conforms to ISO > 8601 if the seconds in the offset are zero. Absolutely. Will file a CSR. - PR: https://git.openjdk.java.net/jdk/pull/6321
Re: RFR: 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893
On Tue, 9 Nov 2021 22:29:12 GMT, Naoto Sato wrote: > Simple doc clarification where the `toString()` output only conforms to ISO > 8601 if the seconds in the offset are zero. CSR also Reviewed. - Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6321
Re: RFR: 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893
On Tue, 9 Nov 2021 22:29:12 GMT, Naoto Sato wrote: > Simple doc clarification where the `toString()` output only conforms to ISO > 8601 if the seconds in the offset are zero. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6321
RFR: 8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766
Please review this PR to update the TimeZoneNames files. @naotoj @coffeys Some short name changes are not integrated to the JDK. It was detected by the change made in JDK-8275766. - Africa/Juba change was done by 2017c - Africa/Windhoek changes were done by 2018e - Antarctica/Macquarie change was done by 2017a - Commit messages: - Update affected long timezone names with its English name - Fix full timezone names of Antarctica/Macquarie - 8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766 Changes: https://git.openjdk.java.net/jdk/pull/6226/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6226&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276536 Stats: 88 lines in 11 files changed: 22 ins; 0 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/6226.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6226/head:pull/6226 PR: https://git.openjdk.java.net/jdk/pull/6226
Re: RFR: 8276609: Document setting property `jdk.serialFilter` to an invalid value throws `ExceptionInInitializerError`
On Tue, 9 Nov 2021 15:48:22 GMT, Roger Riggs wrote:
> When set on the command line `jdk.serialFilter` to an invalid value, the
> invalid value is logged but the application is allowed to start without
> setting the filter.
> This leaves the application without the protections of the serial filter.
> The specification should be clarify that an `ExceptionInInitializerError` is
> thrown when the `jdk.serialFilter` system property is set on the command line
> to an invalid value.
src/java.base/share/classes/java/io/ObjectInputFilter.java line 528:
> 526: * The filter is created as if {@link #createFilter(String)
> createFilter} is called;
> 527: * if the filter string is invalid, an {@link
> ExceptionInInitializerError} is thrown.
> 528: * Otherwise, the filter is not configured during initialization and
Hello Roger, the new line looks good to me. However, with this new line now
staying between the "If the Java virtual machine ..." and the "Otherwise, ..."
lines, I had to re-read this "Otherwise, the filter is not ..." line a few
times to see which "if" it corresponds to, because there's a "if the filter
string is invalid" on the previous line.
Do you think these lines might have to be rearranged?
-
PR: https://git.openjdk.java.net/jdk/pull/6317
Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales
On Tue, 9 Nov 2021 19:38:46 GMT, Naoto Sato wrote:
>>> If this issue is not a part of JEP-400, I think UTF_8 may not be only
>>> solution for sun/nio/fs/Util.java.
>>> Please explain why UTF_8 is better than ISO_8859_1.
>>
>> Just to add to Naoto's comment. When the JDK starts in unusual/unsupported
>> configurations then it needs a default for the stdout/stderr print streams,
>> for encoding/decoding files paths in java.io, and for encoding/decoding
>> files paths in the java.nio.file implementation. It's important that the
>> latter two are the same, having one be UTF-8 and the other be 8859-1 won't
>> work.
>>
>> There may be an argument that the JDK should emit a warning at startup.
>
>> There may be an argument that the JDK should emit a warning at startup.
>
> Updated to emit a warning, if `sun.jnu.encoding` is not supported.
Hello @naotoj .
I appreciate your code update.
I'd like to confirm one thing.
If you could not recreate this issue on your test machine, please ignore this
message.
I tested your code on my CentOS7 x86_64.
I saw following exception.
$ git log --oneline | head
e91e9d85327 8276721: G1: Refine G1EvacFailureObjectsSet::iterate
8822d41fdcc 8274736: Concurrent read/close of SSLSockets causes SSLSessions to
be invalidated unnecessarily
c1e41fe38bb 8276842: G1: Only calculate size in bytes from words when needed
c8b0ee6b8a0 8276833: G1: Make G1EvacFailureRegions::par_iterate const
0699220830a 8268882: C2: assert(n->outcnt() != 0 || C->top() == n ||
n->is_Proj()) failed: No dead instructions after post-alloc
d7012fbd604 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as
unnecessary
f9024d0606e 8230130: javadoc search result dialog shows cut off headers for
long results
055de6f5662 8223358: Incorrect HTML structure in annotation pages
a60e91259ba 8198626:
java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac
dde959dfcef 8276808: java/nio/channels/Channels/TransferTo.java timed out
$ cat Hello.java
public class Hello {
public static void main(String[] args) throws Exception {
System.out.println("Hello");
}
}
$ env LC_ALL=kk_KZ.pt154 locale
LANG=ja_JP.UTF-8
LC_CTYPE="kk_KZ.pt154"
LC_NUMERIC="kk_KZ.pt154"
LC_TIME="kk_KZ.pt154"
LC_COLLATE="kk_KZ.pt154"
LC_MONETARY="kk_KZ.pt154"
LC_MESSAGES="kk_KZ.pt154"
LC_PAPER="kk_KZ.pt154"
LC_NAME="kk_KZ.pt154"
LC_ADDRESS="kk_KZ.pt154"
LC_TELEPHONE="kk_KZ.pt154"
LC_MEASUREMENT="kk_KZ.pt154"
LC_IDENTIFICATION="kk_KZ.pt154"
LC_ALL=kk_KZ.pt154
$ env LC_ALL=kk_KZ.pt154
./build/linux-x86_64-server-release/images/jdk/bin/java Hello.java
WARNING: The encoding of the underlying platform's file system is not supported
by the JVM: PT154
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.util.ServiceConfigurationError:
java.nio.charset.spi.CharsetProvider: Unable to load
sun.nio.cs.ext.ExtendedCharsets
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586)
at
java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:861)
at
java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1084)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
at
java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:428)
at
java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:422)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at
java.base/java.nio.charset.Charset$ExtendedProviderHolder.extendedProviders(Charset.java:422)
at
java.base/java.nio.charset.Charset$ExtendedProviderHolder.(Charset.java:418)
at
java.base/java.nio.charset.Charset.lookupExtendedCharset(Charset.java:442)
at java.base/java.nio.charset.Charset.lookup2(Charset.java:472)
at java.base/java.nio.charset.Charset.lookup(Charset.java:460)
at java.base/java.nio.charset.Charset.isSupported(Charset.java:501)
at
java.base/sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:891)
Caused by: java.lang.ExceptionInInitializerError
at java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:51)
at java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39)
at
java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46)
at
java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39)
at
java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider.java:55)
at
java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvider.java:41)
at
java.base/sun.nio.fs.DefaultFileSystemProvider.(DefaultFileSystemProvider.java:35)
at
java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.ja
Re: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales
On Wed, 10 Nov 2021 03:31:11 GMT, Ichiroh Takiguchi wrote: > I tested your code on my CentOS7 x86_64. I saw following exception. This doesn't surprise me. It would be be useful if you could do the same experiment with main line and JDK 17 too. There have been several reports of NPE when trying to startup in environments where the locale does not map to a charset that the JDK supports. In your output I see "WARNING: The encoding of the underlying platform's file system is not supported by the JVM: PT154". Thereafter what you are seeing a recursive initialisation issue. To break this cycle we need jnuEncoding to be set before initialising the file system. - PR: https://git.openjdk.java.net/jdk/pull/6282
Re: RFR: 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893
On Tue, 9 Nov 2021 22:29:12 GMT, Naoto Sato wrote: > Simple doc clarification where the `toString()` output only conforms to ISO > 8601 if the seconds in the offset are zero. Marked as reviewed by scolebourne (Author). - PR: https://git.openjdk.java.net/jdk/pull/6321
