8276084: Linux DEB Bundler: release number in outputted .deb file should be
optional
-
Commit messages:
- Bugfix
- Bugfix
- Bugfix
- 8276084: Linux DEB Bundler: release number in outputted .deb file should be
optional
Changes: https://git.openjdk.java.net/jdk/pull/6345/files
On Wed, 10 Nov 2021 20:51:20 GMT, Lance Andersen wrote:
> Hi all,
>
> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where
> you can no longer access a file entry contained within a Zip file when there
> is also a directory entry with the same name via
On Wed, 3 Nov 2021 07:05:08 GMT, Yoshiki Sato wrote:
> 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
> -
On Wed, 10 Nov 2021 19:46:09 GMT, Alan Bateman wrote:
> If there is resistance to fixing the tools then we might have to re-visit
> this.
It's not just the JDK tools that are an issue. I think that wrapping some
PrintStream into a PrintWriter is a common enough idiom that it is not
On Wed, 10 Nov 2021 20:00:39 GMT, Alan Bateman wrote:
> > 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`
> > should be redefined so that they internally check if the stream arg is a
> > PrintStream, in which case they use the encoding from the `PrinStream`
> >
On Wed, 10 Nov 2021 21:32:32 GMT, Claes Redestad wrote:
>> Hi all,
>>
>> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where
>> you can no longer access a file entry contained within a Zip file when there
>> is also a directory entry with the same name via
On Wed, 10 Nov 2021 20:51:20 GMT, Lance Andersen wrote:
> Hi all,
>
> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where
> you can no longer access a file entry contained within a Zip file when there
> is also a directory entry with the same name via
On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with
On Wed, 3 Nov 2021 07:05:08 GMT, Yoshiki Sato wrote:
> 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
> -
Hi all,
This patch addresses a regression introduced in JDK 15 via JDK-8242959 where
you can no longer access a file entry contained within a Zip file when there is
also a directory entry with the same name via ZipFile:getEntry().
Once fixed, the behavior will be consistent with earlier JDK
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.
This pull request has now been integrated.
Changeset: bce35ac1
Author:Naoto Sato
URL:
On Thu, 4 Nov 2021 16:07:01 GMT, Naoto Sato wrote:
> This fix is to require to include `Locale.ROOT` in the returned arrays/set
> from `getAvailableLocales()` methods in various locale-sensitive classes. The
> implementation has been including `Locale.ROOT` since its inception, it is
> simply
On Wed, 10 Nov 2021 19:41:29 GMT, Jonathan Gibbons wrote:
> 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`
> should be redefined so that they internally check if the stream arg is a
> PrintStream, in which case they use the encoding from the `PrinStream`
> instead of
On Wed, 10 Nov 2021 19:05:17 GMT, Naoto Sato wrote:
>> This fix is to require to include `Locale.ROOT` in the returned arrays/set
>> from `getAvailableLocales()` methods in various locale-sensitive classes.
>> The implementation has been including `Locale.ROOT` since its inception, it
>> is
On Wed, 10 Nov 2021 19:16:58 GMT, Jonathan Gibbons wrote:
> Generally, the issue is related to the fact that we wrap a PrintStream in a
> PrintWriter ... and, if I understand correctly, the writer ends up with the
> wrong character encoding. Is it possible to change PrintWriter and/or
>
On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with
On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with
Here are the old details I can dig up when we ran into this on JavaMail:
https://bugs.openjdk.java.net/browse/JDK-6995537
https://github.com/javaee/javamail/commit/145d18c1738d3cf33b52bc005835980ff78ce4af
I recall digging through the code years ago and I don't recall if adding
w.write("");
On Wed, 10 Nov 2021 19:05:17 GMT, Naoto Sato wrote:
>> This fix is to require to include `Locale.ROOT` in the returned arrays/set
>> from `getAvailableLocales()` methods in various locale-sensitive classes.
>> The implementation has been including `Locale.ROOT` since its inception, it
>> is
On Wed, 10 Nov 2021 18:29:06 GMT, Pavel Rappo wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Using @code tag for `Set`.
>
> src/java.base/share/classes/java/time/format/DecimalStyle.java line 118:
>
>> 116: *
> This fix is to require to include `Locale.ROOT` in the returned arrays/set
> from `getAvailableLocales()` methods in various locale-sensitive classes. The
> implementation has been including `Locale.ROOT` since its inception, it is
> simply a doc clarification (+ a test case verifying it).
On Thu, 4 Nov 2021 16:07:01 GMT, Naoto Sato wrote:
> This fix is to require to include `Locale.ROOT` in the returned arrays/set
> from `getAvailableLocales()` methods in various locale-sensitive classes. The
> implementation has been including `Locale.ROOT` since its inception, it is
> simply
On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote:
> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to
> the state previous to JDK-8160768, where an authentication failure stops from
> trying other LDAP servers with the same credentials [1]. After JDK-8160768 we
>
On Wed, 3 Nov 2021 07:05:08 GMT, Yoshiki Sato wrote:
> 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
> -
This is a microbenchmarks to demonstrate `Thread.onSpinWait` can be used to
avoid heavy locks.
The microbenchmark differs from [Gil's original
benchmark](https://github.com/giltene/GilExamples/tree/master/SpinWaitTest) and
[Dmitry's
I would suggest that we hold this patch until the string interpolation
JEP lands. It will offer both better readability *and* better
performance, and probably better to have one round of "replace all the
toString implementations" than two?
On 11/10/2021 1:04 PM, Eamonn McManus wrote:
Use
Use string concatenation instead of `String.format`.
-
Commit messages:
- 8276904: Optional.toString() is unnecessarily expensive
Changes: https://git.openjdk.java.net/jdk/pull/6337/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6337=00
Issue:
On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad wrote:
> This changes the specification of `DateTimeFormatterBuilder.appendFraction`
> to more clearly specify that the formatter will throw an exception if you
> attempt to print a value outside of the value range of the given field.
> Changes
On Wed, 10 Nov 2021 11:26:11 GMT, Alan Bateman wrote:
>> Yes. Made a clarification to the javadoc, and while we are here, to
>> setFeature method as well.
>
> One other suggestion for wording is to change:
> "A property set on the factory is effective to the XPath object created
> thereafter"
> 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:
adjust wording
-
Changes:
- all:
On Wed, 10 Nov 2021 03:31:11 GMT, Ichiroh Takiguchi
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.
>
> Hello @naotoj .
> I appreciate your code update.
> I'd like to confirm one thing.
On Wed, 10 Nov 2021 12:58:13 GMT, Aleksei Efimov wrote:
>> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to
>> the state previous to JDK-8160768, where an authentication failure stops
>> from trying other LDAP servers with the same credentials [1]. After
>>
On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad wrote:
> This changes the specification of `DateTimeFormatterBuilder.appendFraction`
> to more clearly specify that the formatter will throw an exception if you
> attempt to print a value outside of the value range of the given field.
> Changes
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 rriggs (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6321
On Wed, 10 Nov 2021 09:22:32 GMT, Сергей Цыпанов wrote:
> Looking into `File.pathSeparator` I've found out that currently we initialize
> it as
>
> public static final String separator = "" + separatorChar;
>
> Which after compilation turns into
>
> NEW java/lang/StringBuilder
> DUP
>
(I thought this was discussed a while back on a OpenJDK mailing list, but I
can’t find it. So apologies if this is a duplicate, but I might have seen it on
Apache Commons-io instead - which fixed a similar issue on reader side)
The problem: I have code using a OutputStreamWriter with a
This changes the specification of `DateTimeFormatterBuilder.appendFraction` to
more clearly specify that the formatter will throw an exception if you attempt
to print a value outside of the value range of the given field. Changes
suggested by @jodastephen in #6188.
-
Commit
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the
On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote:
> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to
> the state previous to JDK-8160768, where an authentication failure stops from
> trying other LDAP servers with the same credentials [1]. After JDK-8160768 we
>
On Wed, 10 Nov 2021 09:22:32 GMT, Сергей Цыпанов wrote:
> Looking into `File.pathSeparator` I've found out that currently we initialize
> it as
>
> public static final String separator = "" + separatorChar;
>
> Which after compilation turns into
>
> NEW java/lang/StringBuilder
> DUP
>
On Wed, 10 Nov 2021 09:22:32 GMT, Сергей Цыпанов wrote:
> Looking into `File.pathSeparator` I've found out that currently we initialize
> it as
>
> public static final String separator = "" + separatorChar;
>
> Which after compilation turns into
>
> NEW java/lang/StringBuilder
> DUP
>
On Wed, 10 Nov 2021 09:22:32 GMT, Сергей Цыпанов wrote:
> Looking into File.pathSeparator I've found out that currently we initialize
> them as
>
> public static final String separator = "" + separatorChar;
>
> Which after compilation turns into
>
> NEW java/lang/StringBuilder
> DUP
>
Hi Andrew,
I've logged a JBS bug for your change:
https://bugs.openjdk.java.net/browse/JDK-8276939
You can use it to update your PR title to address the following jcheck error:
The commit message does not reference any issue. To add an issue reference to
this PR, edit the title to be of the
On Wed, 10 Nov 2021 09:22:32 GMT, Сергей Цыпанов wrote:
> Looking into File.pathSeparator I've found out that currently we initialize
> them as
>
> public static final String separator = "" + separatorChar;
>
> Which after compilation turns into
>
> NEW java/lang/StringBuilder
> DUP
>
On Wed, 10 Nov 2021 11:40:28 GMT, Anthony Vanelverdinghe
wrote:
>> This is getting too complicated...
>>
>> It's a code *example* with a very clear comment that explains a best
>> practice:
>>
>> // A cleaner, preferably one shared within a library
>> private static final Cleaner cleaner =
> 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
On Wed, 10 Nov 2021 09:43:58 GMT, Hendrik Schreiber
wrote:
>>> 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
On Wed, 10 Nov 2021 10:36:37 GMT, Michael Bien wrote:
> it should compile into invokedynamic makeConcatWithConstants on later JDKs
As far as I understand `StringConcatFactory` is not available on bootstrap
stage and `StringBuilder` is used instead. See
On Tue, 9 Nov 2021 06:27:15 GMT, Joe Wang wrote:
>> src/java.xml/share/classes/javax/xml/xpath/XPathFactory.java line 375:
>>
>>> 373: /**
>>> 374: * Sets a property for this {@code XPathFactory} and {@code XPath}
>>> 375: * created by this factory.
>>
>> Are properties inherited
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 lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6321
On Wed, 10 Nov 2021 09:22:32 GMT, Сергей Цыпанов wrote:
> Looking into File.pathSeparator I've found out that currently we initialize
> them as
>
> public static final String separator = "" + separatorChar;
>
> Which after compilation turns into
>
> NEW java/lang/StringBuilder
> DUP
>
On Wed, 10 Nov 2021 09:41:44 GMT, Alan Bateman wrote:
>> Hendrik Schreiber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update src/java.base/share/classes/java/lang/ref/Cleaner.java
>>
>> Making the comment even clearer.
>>
> 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
On Wed, 10 Nov 2021 09:30:07 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
On Tue, 9 Nov 2021 11:14:37 GMT, Anthony Vanelverdinghe
wrote:
>> 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
On Mon, 8 Nov 2021 23:21:49 GMT, Brent Christian wrote:
>> This is what I suggested and makes it clear that *must hold no reference to
>> the instance being cleaned*. Maybe you didn't notice it's still there?
>>
>>
>> *// State class captures information necessary for cleanup.
>>
Looking into File.pathSeparator I've found out that currently we initialize
them as
public static final String separator = "" + separatorChar;
Which after compilation turns into
NEW java/lang/StringBuilder
DUP
INVOKESPECIAL java/lang/StringBuilder. ()V
LDC ""
INVOKEVIRTUAL
> 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
58 matches
Mail list logo
