RE: RFR JDK-8232724: Remove indirection with calling JNU_NewStringPlatform

[Langer, Christoph]

Hi Alexey,

> Please review the following fix which removes indirection in calling
> JNU_NewStringPlatform via NewStringPlatform.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8232724
> webrev: http://cr.openjdk.java.net/~aivanov/8232724/webrev.00/
> 
> It is a follow-up fix to JDK-8232624 and JDK-8231355. It removes
> NewStringPlatform alias as Claes did in JDK-8231355. To call
> JNU_NewStringPlatform, the function pointer to_java_string_fn_t is
> declared with JNICALL (__stdcall); the function is looked up by both the
> undecorated name and the __stdcall-decorated name for Win32.
> 
> Tier 1 and 2 tests are all green.

This looks good to me.

> There are two declarations of the to_java_string_fn_t function pointer:
> in jvm.h and locally in javaClasses. I searched the source code for it
> and didn't find any usages but in
> java_lang_String::create_from_platform_dependent_str. The declaration in
> jvm.h uses "char *" whereas javaClasses uses "const char *".
> 
> Shall I remove one of them? The one in jvm.h because it's unused?

Yes, I would suggest dropping the declaration in jvm.h

Cheers
Christoph

Re: RFR: JDK-8232186: Add verification for pkg and dmg tests

[Alexander Matveev]

Changes since last review:

http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/

- Hello.java combined into one test app and will be used by all tests.
- appOutput.txt will be created in same folder as file used for file 
association.

- Other minor changes.

Thanks,
Alexander

On 10/23/19 10:07 AM, Andy Herrick wrote:

looks ok to me

/ANdy

On 10/22/2019 5:29 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Removed --mac-app-store-category.
- Added Hello.java test app to support file association on OS X.
- Modified Hello.java to write output file to user home location if 
working directory is not writable.
- Fixed MacHelper:getInstallationDirectory(). It was returning extra 
/Applications when --install-dir is specified.
- Fixed SigningPackageTest to use path returned by withExplodedDmg 
correctly.

- Added install/uninstall support for pkg and dmg to manage_packages.sh.
- Fixed replaceFileName(), otherwise on OS X it was not replacing 
file name correctly, since file name does not have extension.

- Added NameWithSpaceTest.
- Removed OptionsTest which is covered by other tests.

[1] https://bugs.openjdk.java.net/browse/JDK-8232186

[2] http://cr.openjdk.java.net/~almatvee/8232186/webrev.02/

Thanks,
Alexander

RFR 8225466 : Optimize matching BMP Slice nodes

[Ivan Gerasimov]

Hello!

When building a Pattern object, the regex parser recognizes "slices" - 
continuous char subsequences, which all have to be matched 
case-sensitively/case-insensitively.  Matching with such a slice is 
implemented as a simple loop over a portion of the input.


In the current implementation, on each iteration of the loop it is 
checked if we have hit the end of the input (which is an uncommon case).


This check can be done only once, before the loop, which will make the 
loop lighter.


Benchmark shows up to +4% to the throughput for the case-insensitive 
matching.


Would you please help review the enhancement?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8225466
WEBREV: http://cr.openjdk.java.net/~igerasim/8225466/00/webrev/


--- benchmark results ---

UNFIXED
Benchmark    Mode  Cnt    Score   Error  Units
PatternBench.sliceIFind  avgt   16  190.612 ? 0.336  ns/op

FIXED
Benchmark    Mode  Cnt    Score   Error  Units
PatternBench.sliceIFind  avgt   16  182.954 ? 0.493  ns/op
---

--
With kind regards,
Ivan Gerasimov

Re: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes generated lambdas

[Paul Sandoz]

> On Oct 28, 2019, at 3:29 PM, mark.reinh...@oracle.com wrote:
> 
> 2019/10/28 11:10:25 -0700, vojin.jovano...@oracle.com:
>> This email proposes a change to the LambdaMetaFactory that allows to
>> disable eager initialization (with Unsafe) of generated lambdas. ...
>> 
>> ...
>> 
>> After the discussion with Brian Goetz, we have trimmed down to the
>> following change:
>> 
>>  
>> https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff
>> 
>> The evolution of this change can be found at the issue: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8232806
> 
> Vojin -- I’d be happy to sponsor this change on your behalf.
> 
> I’ve posted a webrev that incorporates the suggestions that Paul and
> Rémi made in the JBS issue:
> 
>  https://cr.openjdk.java.net/~mr/rev/8232806/
> 
> Paul, Rémi -- please make sure that I understood your suggestions
> correctly

Looks good to me.

I don’t know of an easy way to test when the new sys property is true that the 
implementing class is not initialized. Seems to require an explicit call to 
LMF, cracking open the calls site’s target, and calling 
Unsafe.shouldBeInitialized (presuming initialization is not tickled before that 
call and the call works!).  Perhaps a future exercise if someone wanna takes 
that on.

Paul.

Re: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes generated lambdas

[mark . reinhold]

2019/10/28 11:10:25 -0700, vojin.jovano...@oracle.com:
> This email proposes a change to the LambdaMetaFactory that allows to
> disable eager initialization (with Unsafe) of generated lambdas. ...
>
> ...
> 
> After the discussion with Brian Goetz, we have trimmed down to the
> following change:
> 
>   
> https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff
> 
> The evolution of this change can be found at the issue: 
> 
>  https://bugs.openjdk.java.net/browse/JDK-8232806

Vojin -- I’d be happy to sponsor this change on your behalf.

I’ve posted a webrev that incorporates the suggestions that Paul and
Rémi made in the JBS issue:

  https://cr.openjdk.java.net/~mr/rev/8232806/

Paul, Rémi -- please make sure that I understood your suggestions
correctly.

- Mark

RFR: jsr166 integration 2019-11

[Martin Buchholz]

https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration-2019-11/overview.html

8231592: Clarify that ConcurrentHashMap compute methods mapping functions
execute at most once
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration-2019-11/compute-once/index.html
https://bugs.openjdk.java.net/browse/JDK-8231592

8231026: Miscellaneous changes imported from jsr166 CVS 2019-11
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration-2019-11/miscellaneous/index.html
https://bugs.openjdk.java.net/browse/JDK-8231026

Re: Question about String.toUpperCase behaviour

[Florian Weimer]

* Сергей Цыпанов:

> Hello,
>
> current implementation of e.g. String.toUpperCase() returns the object
> it was called on in case all code points are in upper case.
>
> E.g. this test 
>
> @Test
> public void upperCase() {
>   String str = "AZ";// English
>   assert str == str.toUpperCase();
>   
>   str = "АЯ";   // Russian
>   assert str == str.toUpperCase();
> }
>
> passes for both Latin-1 and UTF-16. This assumption allows to simplify this:
>
> boolean isUpperCase = str.toUpperCase().equals(str); 
>
> to
>
> boolean isUpperCase = str.toUpperCase() == str;
>
> Could this transformation be legal assuming that existing behaviour of
> String.toUpperCase is not documented?

Valid for whom?  For the JDK itself, sure.  But programmers really
should not assume such undocumented behavior when writing Java
programs, and neither shoud external tools targeting the JVM.

RFR JDK-8232724: Remove indirection with calling JNU_NewStringPlatform

[Alexey Ivanov]

Hello,

Please review the following fix which removes indirection in calling 
JNU_NewStringPlatform via NewStringPlatform.


bug: https://bugs.openjdk.java.net/browse/JDK-8232724
webrev: http://cr.openjdk.java.net/~aivanov/8232724/webrev.00/

It is a follow-up fix to JDK-8232624 and JDK-8231355. It removes 
NewStringPlatform alias as Claes did in JDK-8231355. To call 
JNU_NewStringPlatform, the function pointer to_java_string_fn_t is 
declared with JNICALL (__stdcall); the function is looked up by both the 
undecorated name and the __stdcall-decorated name for Win32.


Tier 1 and 2 tests are all green.

There are two declarations of the to_java_string_fn_t function pointer: 
in jvm.h and locally in javaClasses. I searched the source code for it 
and didn't find any usages but in 
java_lang_String::create_from_platform_dependent_str. The declaration in 
jvm.h uses "char *" whereas javaClasses uses "const char *".


Shall I remove one of them? The one in jvm.h because it's unused?


Thank you in advance.

https://bugs.openjdk.java.net/browse/JDK-8232624
https://bugs.openjdk.java.net/browse/JDK-8231355

--
Regards,
Alexey

Re: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes generated lambdas

[Brian Goetz]

The patch seems suitably minimal to me to meet the goals and not cause 
difficulty for future evolution of LMF (for which we have some plans, 
once some other VM work finishes up.)   Essentially, the 
disable-eager-initialization case disables the caching optimization for 
non-capturing lambdas, and we then just revert to the main 
lambda-capture path, which makes this fairly low risk.




On 10/28/2019 2:10 PM, Vojin Jovanovic wrote:

Hi all,

This email proposes a change to the LambdaMetaFactory that allows to disable 
eager initialization (with Unsafe) of generated lambdas. This is needed by the 
GraalVM Native Image, as initialization of lambdas during AOT compilation 
breaks our heap snapshotting (via initialization of interfaces with default 
methods that are super-types of a lambda). We have started from the original 
proposal that stores lambda instances in the static fields

   
https://github.com/graalvm/labs-openjdk-11/commit/00b9ecd85dedd0411837eee33635dd83e8b7def8

and initializes them with Unsafe as an optimization


https://github.com/graalvm/labs-openjdk-11/commit/273e8590a7b57c0c10d9213ca9e0ba581e2817b8

After the discussion with Brian Goetz, we have trimmed down to the following 
change:

   
https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff

The evolution of this change can be found at the issue:

  https://bugs.openjdk.java.net/browse/JDK-8232806
  
Cheers,

- Vojin

RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes generated lambdas

[Vojin Jovanovic]

Hi all, 

This email proposes a change to the LambdaMetaFactory that allows to disable 
eager initialization (with Unsafe) of generated lambdas. This is needed by the 
GraalVM Native Image, as initialization of lambdas during AOT compilation 
breaks our heap snapshotting (via initialization of interfaces with default 
methods that are super-types of a lambda). We have started from the original 
proposal that stores lambda instances in the static fields

  
https://github.com/graalvm/labs-openjdk-11/commit/00b9ecd85dedd0411837eee33635dd83e8b7def8

and initializes them with Unsafe as an optimization 

   
https://github.com/graalvm/labs-openjdk-11/commit/273e8590a7b57c0c10d9213ca9e0ba581e2817b8

After the discussion with Brian Goetz, we have trimmed down to the following 
change:

  
https://bugs.openjdk.java.net/secure/attachment/85247/lambda-disable-initialization.diff

The evolution of this change can be found at the issue: 

 https://bugs.openjdk.java.net/browse/JDK-8232806
 
Cheers,
- Vojin

Re: RFR: 8232161 Unexpected 1-way trip conversion entries on MS950 charset

[naoto . sato]

Hi Takiguchi-san,

On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:

Hello.

I have no idea about compatibility impact.

But according to ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
These are BOX DRAWINGS characters.

2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;N;FORMS DOUBLE 
HORIZONTAL
255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE;So;0;ON;N;FORMS 
VERTICAL SINGLE AND RIGHT DOUBLE
2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;N;FORMS 
VERTICAL SINGLE AND LEFT DOUBLE
256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
DOUBLE;So;0;ON;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE


I don't think it was used as valuable data until now.
I think it's necessary to evaluate compatibility.


What do you mean by "until now"? Are there customers claiming that it 
should be corrected? Since the current JDK's mapping is not incorrect 
per se (not just "best match"), I would like to know why this needs to 
be fixed now.


Naoto



To Sato-san,
if you have any question and suggestion, please let me know.

To other reviewers,
please let me know if you have any question and concern.

Thanks,
Ichiroh Takiguchi

On 2019-10-19 16:36, Alan Bateman wrote:

On 14/10/2019 16:53, Ichiroh Takiguchi wrote:

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8232161
Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/

I have a concern about 1-way trip conversion entries (4 entries) on 
MS950 charset.

The detail information is in JDK-8232161 [1]


Do you know any sense on the compatibility impact of changing this? I
think Naoto has the same question and we aren't sure if this one with
need a compatibility property. I think it will need a CSR.

-Alan

Re: fx:deploy is not available in this JDK

[Kevin Rushforth]

> Error:Java FX Packager: fx:deploy task has failed.

The 'fx:deploy' task was part of the ant plugin that was formerly 
distributed in ant-javafx.jar as part of javapackager. This ant plugin 
is not included in jpacakge, so you will need to find some other way to 
integrate jpacakge into IntelliJ.


-- Kevin


On 10/28/2019 9:18 AM, Olga Klisho wrote:

Hello,

JavaFX application successfully compiles in IntelliJ IDEA 2019.3
 with the use of:
- *Build 14-jpackage+1-35 (2019/8/29)* (http://jdk.java.net/jpackage);
- Early-Access builds for JavaFX 14 (https://gluonhq.com/products/javafx).

The same project fails to compile with* Build 14-jpackage+1-49 (2019/10/2)*
with exception attached.

JavaFX artifacts can't be built with both mentioned jpackage builds.
Please see the sample project where the issue is reproduced attached to the
issue:
https://youtrack.jetbrains.com/issue/IDEA-200721

In case of any questions or if more details are needed please feel free to
contact me. Thank you

Olga Klisho
IDEA Support Engineer
JetBrains
http://www.jetbrains.com
The Drive to Develop

Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception

[Adam Farley8]

Hi All,

I'm asking for reviewers, sponsors, and opinions on the changes proposed 
below.

Right now, there are four files in OpenJDK 8 that have a GPL V2 License, 
with no Classpath Exception.

Based on the conversation so far, here's a summary of the proposed 
actions:

1) Remove this file, along with all the other JObjC files, in a new bug:

- jdk/src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser

2) Add the ClassPath Exception to the licence for this file, because later 
versions of OpenJDK have made this change:

- 
jdk/make/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java 


3) Add the ClassPath Exception to the licence for these files, because it 
seems the code is used in the final build despite the directory implying 
otherwise.

- jdk/make/src/native/add_gnu_debuglink/add_gnu_debuglink.c 
- jdk/make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c 

Best Regards

Adam Farley 
IBM Runtimes


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Question about String.toUpperCase behaviour

[Сергей Цыпанов]

Hello,

current implementation of e.g. String.toUpperCase() returns the object it was 
called on in case all code points are in upper case.

E.g. this test 

@Test
public void upperCase() {
  String str = "AZ";// English
  assert str == str.toUpperCase();
  
  str = "АЯ";   // Russian
  assert str == str.toUpperCase();
}

passes for both Latin-1 and UTF-16. This assumption allows to simplify this:

boolean isUpperCase = str.toUpperCase().equals(str); 

to

boolean isUpperCase = str.toUpperCase() == str;

Could this transformation be legal assuming that existing behaviour of 
String.toUpperCase is not documented?

Regards,
Sergey Tsypanov

Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

[Lance Andersen]

Hi Christoph,
> On Oct 28, 2019, at 6:19 AM, Langer, Christoph  
> wrote:
> 
> Hi Lance,
> 
> thanks for reworking the test. That definitely improves coverage.
> 
> The comment for the test method (line 56/57) could be improved like: "Verify 
> all write methods of an OutputStream that can be used to write to an entry of 
> Zip Filesystem by exercising all of them when creating an archive and then 
> traversing the archive with ZipFile, ZipInputStream and the Zip Filesystem”.

I think I am going to leave it as it is for now.
> 
> Other than that, it's good to go for mw.

OK, thank you.
> 
> BTW, I think meanwhile all these zipfs tests have quite some duplicate 
> infrastructure classes and methods (e.g. Entry) that could be shared. Maybe 
> we should try to carve out some stuff into a library or some Auxillary helper 
> class. What do you think?

Yes it is on my todo list.  There is an issue that needs addressed 1st then 
that will follow on.

Best
Lance
> 
> Thanks
> Christoph
> 
>> -Original Message-
>> From: core-libs-dev  On Behalf
>> Of Lance Andersen
>> Sent: Samstag, 26. Oktober 2019 04:42
>> To: Jaikiran Pai 
>> Cc: core-libs-dev@openjdk.java.net
>> Subject: Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
>> leads to a CRC failure in the generated jar file
>> 
>> 
>>> On Oct 25, 2019, at 10:10 PM, Jaikiran Pai 
>> wrote:
>>> 
>>> Thank you for the review, Lance.
>>> 
>> 
>> You are very welcome Jaikiran.
>>> On 26/10/19 4:25 AM, Lance Andersen wrote:
 
 The change to Zip FS looks good.  I re-worked the test so that it also runs
>> against ZipFile (which uses the CEN vs the LOC) and Zip FS in addition to
>> ZipInputStream for extra coverage.
 
 The webrev can be found at:
>> http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html
>> Looks
>> fine. A very minor note about
>> http://cr.openjdk.java.net/~lancea/8232879/webrev.00/test/jdk/jdk/nio/zip
>> fs/CRCWriteTest.java.html
>> > pfs/CRCWriteTest.java.html>
>>> 136 while ((ze = zis.getNextEntry()) != null) {
>>> 137 assertNotNull(ze);
>>> 
>>> Looks like an oversight - that assertNotNull(ze) on 137 isn't needed due to
>> the != null check on 1
>> 
>> Yep, not needed.  Sometimes you do things on auto pilot ;-)
>> 
>> Will remove before I push the change.
>>> 36.
>>> 
>>> -Jaikiran
>>> 
>> 
>> 
>> 
>> 
>> Lance Andersen|
>> Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> lance.ander...@oracle.com 
>> 
>> 
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: 8232161 Unexpected 1-way trip conversion entries on MS950 charset

[Ichiroh Takiguchi]

Hello.

I have no idea about compatibility impact.

But according to ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
These are BOX DRAWINGS characters.

2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;N;FORMS DOUBLE 
HORIZONTAL
255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE;So;0;ON;N;FORMS 
VERTICAL SINGLE AND RIGHT DOUBLE
2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;N;FORMS 
VERTICAL SINGLE AND LEFT DOUBLE
256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
DOUBLE;So;0;ON;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE


I don't think it was used as valuable data until now.
I think it's necessary to evaluate compatibility.

To Sato-san,
if you have any question and suggestion, please let me know.

To other reviewers,
please let me know if you have any question and concern.

Thanks,
Ichiroh Takiguchi

On 2019-10-19 16:36, Alan Bateman wrote:

On 14/10/2019 16:53, Ichiroh Takiguchi wrote:

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8232161
Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/

I have a concern about 1-way trip conversion entries (4 entries) on 
MS950 charset.

The detail information is in JDK-8232161 [1]


Do you know any sense on the compatibility impact of changing this? I
think Naoto has the same question and we aren't sure if this one with
need a compatibility property. I think it will need a CSR.

-Alan

fx:deploy is not available in this JDK

[Olga Klisho]

Hello,

JavaFX application successfully compiles in IntelliJ IDEA 2019.3
 with the use of:
- *Build 14-jpackage+1-35 (2019/8/29)* (http://jdk.java.net/jpackage);
- Early-Access builds for JavaFX 14 (https://gluonhq.com/products/javafx).

The same project fails to compile with* Build 14-jpackage+1-49 (2019/10/2)*
with exception attached.

JavaFX artifacts can't be built with both mentioned jpackage builds.
Please see the sample project where the issue is reproduced attached to the
issue:
https://youtrack.jetbrains.com/issue/IDEA-200721

In case of any questions or if more details are needed please feel free to
contact me. Thank you

Olga Klisho
IDEA Support Engineer
JetBrains
http://www.jetbrains.com
The Drive to Develop
Exception in Application start method
Exception in thread "main" java.lang.RuntimeException: Exception in Application 
start method
at 
javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:900)
at 
javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: java.lang.IllegalAccessError: superclass access check failed: class 
com.sun.javafx.sg.prism.web.NGWebView (in unnamed module @0x1da413f1) cannot 
access class com.sun.javafx.sg.prism.NGGroup (in module javafx.graphics) 
because module javafx.graphics does not export com.sun.javafx.sg.prism to 
unnamed module @0x1da413f1
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at 
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:151)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:821)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:719)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:642)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:600)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:420)
at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.checkForClass(PlatformImpl.java:619)
at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupportedImpl(PlatformImpl.java:896)
at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupported(PlatformImpl.java:627)
at 
javafx.graphics/javafx.application.Platform.isSupported(Platform.java:252)
at 
javafx.fxml/javafx.fxml.JavaFXBuilderFactory.(JavaFXBuilderFactory.java:105)
at 
javafx.fxml/javafx.fxml.JavaFXBuilderFactory.(JavaFXBuilderFactory.java:90)
at javafx.fxml/javafx.fxml.FXMLLoader.(FXMLLoader.java:1828)
at sample.Main.start(Main.java:13)
at 
javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846)
at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:455)
at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427)
at 
javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)

Re: [14] RFR: 8231273: Upgrade CLDR to v36

[Roger Riggs]

Hi Naoto,

Looks good

Thanks for the clarification, Roger

On 10/25/19 7:31 PM, naoto.s...@oracle.com wrote:

Hi Roger,

Thanks for the review.

On 10/25/2019 AD 11:57 午前, Roger Riggs wrote:

HI Naoto,

cldrconverter/Bundle.java:

233-246:  If there is a parent list, it seems to ignore/drop patterns 
greater than plist.size().
This would be clearer if it always processed all the patterns and 
used the parent
if the pattern[i] was empty and i < plist.size().  Switching around 
the range size leads to confusion.

(Or I misunderstand the intent).


The code assumed that parents' lists are always longer than self, 
which is true, but you are right that it can be more readable. 
Corrected as follows:


http://cr.openjdk.java.net/~naoto/8231273/webrev.01/

Bundle:233-246 is the only change since 00.



Is the algorithm intended to produce the longest list (parent and 
pattern)?


Since at runtime, there's no way to fallback element by element basis, 
the array should always contain all the elements (i.e., longest) 
possible.


Naoto



Otherwise, looks fine.

Thanks, Roger



On 10/9/19 6:39 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8231273

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8231273/webrev.00/

The webrev is huge, but majority of the changes is just to replace 
the CLDR source locale data from version 35.1 to 36. The real code 
changes are under make/jdk/src/classes/build/tools/cldrconverter, 
where it now handles aliases for currency/percent formats, and 
retrieves per-element fallback strings for compact number patterns. 
Also relevant tests are modified accordingly.


Naoto

RE: RFR 8231451: ZipFileInputStream::skip handling of negative values with STORED entries

[Langer, Christoph]

Hi Lance,

I looked at this patch as well and it seems good to me.

Cheers
Christoph

> -Original Message-
> From: core-libs-dev  On Behalf
> Of Lance Andersen
> Sent: Freitag, 25. Oktober 2019 20:42
> To: Alan Bateman 
> Cc: core-libs-dev 
> Subject: Re: RFR 8231451: ZipFileInputStream::skip handling of negative
> values with STORED entries
> 
> 
> > On Oct 23, 2019, at 4:58 PM, Alan Bateman 
> wrote:
> >
> > On 23/10/2019 19:06, Lance Andersen wrote:
> >>
> >>> On Oct 22, 2019, at 2:37 PM, Alan Bateman  > wrote:
> >>>
> >>> I assume skip(Long.MAX_VALUE) will cause n+pos to overflow and it will
> skip backwards rather than to the end.
> >>
> >> That is correct.  If you prefer it to skip to the end, I will adjust 
> >> accordingly.
> > It would be surprising to specify a positive value and have it skip 
> > backwards
> so I think this should be fixed.
> 
> I have updated the patch per your suggestion.
> 
> The updated webrev can be found at:
> http://cr.openjdk.java.net/~lancea/8231451/webrev.02/index.html
> 
> 
> mach5 jdk-tier1 through jdk-tier3 are clean.
> 
> Best
> Lance
> >
> > -Alan
> 
>  
>  
> 
>  Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> lance.ander...@oracle.com 
> 
> 

RE: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

[Langer, Christoph]

Hi Lance,

thanks for reworking the test. That definitely improves coverage.

The comment for the test method (line 56/57) could be improved like: "Verify 
all write methods of an OutputStream that can be used to write to an entry of 
Zip Filesystem by exercising all of them when creating an archive and then 
traversing the archive with ZipFile, ZipInputStream and the Zip Filesystem".

Other than that, it's good to go for mw.

BTW, I think meanwhile all these zipfs tests have quite some duplicate 
infrastructure classes and methods (e.g. Entry) that could be shared. Maybe we 
should try to carve out some stuff into a library or some Auxillary helper 
class. What do you think?

Thanks
Christoph

> -Original Message-
> From: core-libs-dev  On Behalf
> Of Lance Andersen
> Sent: Samstag, 26. Oktober 2019 04:42
> To: Jaikiran Pai 
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem
> leads to a CRC failure in the generated jar file
> 
> 
> > On Oct 25, 2019, at 10:10 PM, Jaikiran Pai 
> wrote:
> >
> > Thank you for the review, Lance.
> >
> 
> You are very welcome Jaikiran.
> > On 26/10/19 4:25 AM, Lance Andersen wrote:
> >>
> >> The change to Zip FS looks good.  I re-worked the test so that it also runs
> against ZipFile (which uses the CEN vs the LOC) and Zip FS in addition to
> ZipInputStream for extra coverage.
> >>
> >> The webrev can be found at:
> http://cr.openjdk.java.net/~lancea/8232879/webrev.00/index.html
> Looks
> fine. A very minor note about
> http://cr.openjdk.java.net/~lancea/8232879/webrev.00/test/jdk/jdk/nio/zip
> fs/CRCWriteTest.java.html
>  pfs/CRCWriteTest.java.html>
> > 136 while ((ze = zis.getNextEntry()) != null) {
> >  137 assertNotNull(ze);
> >
> > Looks like an oversight - that assertNotNull(ze) on 137 isn't needed due to
> the != null check on 1
> 
> Yep, not needed.  Sometimes you do things on auto pilot ;-)
> 
> Will remove before I push the change.
> > 36.
> >
> > -Jaikiran
> >
> 
>  
>  
> 
>  Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> lance.ander...@oracle.com 
> 
>