Hi,
May someone please sponsor this patch?
Bug: https://bugs.openjdk.java.net/browse/JDK-8244199
Description:
The test
"test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails
intermittently on a lower release. While investigating the cause for the
failure, I felt
Thank you!
Pushed.
/Jesper
> On 8 May 2020, at 02:41, David Holmes wrote:
>
> Ship it!
>
> (though should have gone to core-libs-dev cc'd)
>
> Thanks,
> David
>
> On 8/05/2020 10:31 am, Jesper Wilhelmsson wrote:
>> Hi.
>> Please review this patch to problemlist WinUpgradeUUIDTest.java that
Ship it!
(though should have gone to core-libs-dev cc'd)
Thanks,
David
On 8/05/2020 10:31 am, Jesper Wilhelmsson wrote:
Hi.
Please review this patch to problemlist WinUpgradeUUIDTest.java that is
currently failing in tier 2. Another change is in review to remove the failure
but it doesn't
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8239383
Its CSR and proposed changeset are located at:
https://bugs.openjdk.java.net/browse/JDK-8239504
https://cr.openjdk.java.net/~naoto/8239383/webrev.00/
This updates java.lang.Character class
> On May 7, 2020, at 7:52 AM, Kumar Srinivasan wrote:
>
> Hi Mikael,
>
> I may have created solinux when the macosx port was merged and in an effort
> to reduce the CPP conditionals.
> solinux = solaris + linux ie. Vanilla unix code vs Darwin code IIRC has
> Objective-C, MacOSX specific
Hi,
currently during ZipFile creation, we create an int[] array of pointers
to META-INF entries. These are then retrieved from three different
places in JarFile.
However, JarFile is only interested in some combination a few things:
the existence of and name of the META-INF/MANIFEST file, the
> On May 6, 2020, at 11:41 PM, Alan Bateman wrote:
>
> On 07/05/2020 05:56, Mikael Vidstedt wrote:
>> :
>>
>> * File follow-up enhancement for the removal of SO_FLOW_SA and
>> jdk.net.SocketFlow
> I've created JDK-8244582 to track this, we should try to this in the same
> release as JEP
What's the failure look like ? I don't see it in the bug report.
-phil.
On 5/7/20, 1:23 PM, Andy Herrick wrote:
please review fix for issue [1] at [2].
/Andy
[1] - https://bugs.openjdk.java.net/browse/JDK-8244620
[2] - http://cr.openjdk.java.net/~herrick/8244620/webrev.01/
Andy,
Is there a plan to properly fix the failing test instead of just
disabling it?
- Alexey
On 5/7/2020 4:23 PM, Andy Herrick wrote:
please review fix for issue [1] at [2].
/Andy
[1] - https://bugs.openjdk.java.net/browse/JDK-8244620
[2] -
please review fix for issue [1] at [2].
/Andy
[1] - https://bugs.openjdk.java.net/browse/JDK-8244620
[2] - http://cr.openjdk.java.net/~herrick/8244620/webrev.01/
> (int)(tokens.countTokens() / 0.75f) + 1
> (tokens.countTokens() * 4 + 2) / 3
if you want A * X / Y, rounded up, you can use (A * X - 1 ) / Y + 1
eg where X/Y = 4/3,
0 => 0
1 => 2
2 => 3
3 => 4
4 => 6
...
Mark
On Tue, May 5, 2020 at 9:48 AM Peter Levart wrote:
> Hi Naoto,
>
> On 4/30/20
I wouldn't worry too much about over 2^29 either.
However, the number of possible valid language tags is much larger than
people think, since any combination of multiple variants can occur). So
even not counting the locale extensions, it is over 2^129 (my rough
calculation).
Mark
On Tue, May
Hi David,
So the issue is that while glibc 2.12 (in OEL6.4) supports
clock_gettime(CLOCK_REALTIME) it requires a runtime dependency on
librt.so, which is an optional runtime dependency, hence the dynamic
lookup you mention. The complexity of dynamic lookup makes this
enhancement unattractive. But
On 5/7/2020 9:03 AM, naoto.s...@oracle.com wrote:
Hi Joe,
Thank you for the review. The removed check was explicitly avoiding
the default chrono/number in the locale overriding the current locale
values, which is exactly what this issue is trying to remove. As
Stephen wrote in another
Looks good, thanks
On 5/7/20 12:06 PM, naoto.s...@oracle.com wrote:
Hi Roger,
Thank you for the review. Wrapped the long lines as suggested, along
with some typo fixes in the comments:
https://cr.openjdk.java.net/~naoto/8244245/webrev.01/
Naoto
On 5/7/20 7:43 AM, Roger Riggs wrote:
Hi
On 5/7/2020 1:14 AM, Stephen Colebourne wrote:
On Thu, 7 May 2020 at 07:38, Joe Wang wrote:
The Javadoc states:
If the locale contains the "ca" (calendar), "nu" (numbering
system), "rg" (region override), and/or "tz" (timezone) Unicode
extensions, the chronology, numbering system
Hi Roger,
Thank you for the review. Wrapped the long lines as suggested, along
with some typo fixes in the comments:
https://cr.openjdk.java.net/~naoto/8244245/webrev.01/
Naoto
On 5/7/20 7:43 AM, Roger Riggs wrote:
Hi Naoto,
Looks fine with a small source edit below.
Hi Joe,
Thank you for the review. The removed check was explicitly avoiding the
default chrono/number in the locale overriding the current locale
values, which is exactly what this issue is trying to remove. As Stephen
wrote in another email, Unicode Extensions are correctly dealt in
I just saw a question on StackOverflow [1] which reports to have the
same issue as in JDK-8226810 [2] - with the same stack trace.
While I could not reproduce the issue, I tried to understand which code
path could lead to that outcome.
While doing so I did come across getEncodingInternal in
Hi,
Please review this OpenJDK 8u fix for an issue where the update version
as configured via --with-update-version=XXX might overflow in internal
JDK structures and thus, will get reported wrong. In particular, only 1
byte is being reserved for the update versions internally. That is, it
works
Hi Mikael,
I may have created solinux when the macosx port was merged and in an effort to
reduce the CPP conditionals.
solinux = solaris + linux ie. Vanilla unix code vs Darwin code IIRC has
Objective-C, MacOSX specific thread initialization etc.
I looked over the launcher related code looks
Hi Naoto,
Looks fine with a small source edit below.
TestUnicodeExtension.java: Please wrap the excessively long lines;
string concatination will put them together for the test.
Thanks, Roger
On 5/6/20 4:44 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following
Hi Aleksei,
If that solves the issue, then LGTM!
best regards,
-- daniel
On 07/05/2020 14:57, Aleks Efimov wrote:
Hi Daniel,
As a follow-up to our off-list discussion, I've updated the
generateUnseenPort method:
a) Added comment to be more specific about the number of times it is called
Hi Daniel,
As a follow-up to our off-list discussion, I've updated the
generateUnseenPort method:
a) Added comment to be more specific about the number of times it is called
b) The port range has been extended to [, PortConfig.getUpper())
Webrev with new version:
On 07/05/2020 12:37, Johannes Kuhn wrote:
:
In the end, I don't know what causes the bug, or how I can replicate it.
I think I did find a likely suspect.
Good sleuthing. I don't what the conditions are for GetLocaleInfo to
fail but it does look like that would return possibly non-terminated
Hi Aleksei,
I agree with the general idea. However, the method:
215 private static int generateUnseenPort() {
216 int port;
217 do {
218 port = + RND.nextInt(1000);
219 } while (SEEN_PORTS.contains(port));
220 SEEN_PORTS.add(port);
221
LGTM as well.
Vyom
On Thu, May 7, 2020 at 3:01 PM Chris Yin wrote:
> +1
>
> Thanks,
> Chris
>
> > On 6 May 2020, at 6:35 PM, Daniel Fuchs wrote:
> >
> > Hi Aleksei,
> >
> > Looks good to me.
> >
> > best regards,
> >
> > -- daniel
> >
> > On 05/05/2020 18:23, Aleks Efimov wrote:
> >> "LDAP
+1
Thanks,
Chris
> On 6 May 2020, at 6:35 PM, Daniel Fuchs wrote:
>
> Hi Aleksei,
>
> Looks good to me.
>
> best regards,
>
> -- daniel
>
> On 05/05/2020 18:23, Aleks Efimov wrote:
>> "LDAP response read timed out, timeout used:-1ms.":
>> https://bugs.openjdk.java.net/browse/JDK-8062947
>>
On Thu, 7 May 2020 at 07:38, Joe Wang wrote:
> The Javadoc states:
> If the locale contains the "ca" (calendar), "nu" (numbering
> system), "rg" (region override), and/or "tz" (timezone) Unicode
> extensions, the chronology, numbering system and/or the zone are overridden.
>
> If you remove
On 07/05/2020 05:56, Mikael Vidstedt wrote:
:
* File follow-up enhancement for the removal of SO_FLOW_SA and
jdk.net.SocketFlow
I've created JDK-8244582 to track this, we should try to this in the
same release as JEP 381.
:
* Get confirmation from Alan that the
Hi Naoto,
The Javadoc states:
If the locale contains the "ca" (calendar), "nu" (numbering
system), "rg" (region override), and/or "tz" (timezone) Unicode
extensions, the chronology, numbering system and/or the zone are overridden.
If you remove the two statements that check whether the
31 matches
Mail list logo
