Re: possible problem with JNI GetStringUTFChars

The reason to change is that returning UTF-8 is useful and returning “modified UTF-8” is apparently not (as no one has explained why it is useful). Why not deprecate it? It would be nice to get a warning. Alan > On Jan 25, 2019, at 6:40 PM, David Holmes wrote: > > On 26/01/2019 3:29 am,

Re: possible problem with JNI GetStringUTFChars

On 26/01/2019 3:29 am, Alan Snyder wrote: My question was not about why it does what it does, but why it still does that. Is there a valid use of this primitive that depends upon it returning something other than true UTF-8? It still does what it does because that was how it was specified

jpackage OS X $APP_ROOT vs. $APPDIR also LSEnvironment in the plist

Just to note a few last other differences between legacy/manually built applications and jpackage ones. I notice in the .cfg file that jpackage supports the $APPDIR variable for… app.runtime=$APPDIR/PlugIns/Java.runtime With AppBundler this used to be $APP_ROOT. So I could do something like

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

I don't mind if Intellij is happier :-) -Joe On 1/25/2019 12:05 PM, Lance Andersen wrote: While this works fine in the generated javadoc {@linkplain map map} This makes intellij a bit happier : {@linkplain Attributes#map map} - $ hg diff diff -r 6130409b923e

Re: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException

Thanks Lance! -Joe On 1/25/19, 12:09 PM, Lance Andersen wrote: all good still On Jan 25, 2019, at 2:34 PM, Joe Wang > wrote: Hi Daniel, True, Objects.equals is better. While the default setting generally won't be null, it's always good to cover all the bases.

Re: jpackage windows 32 bit jre

Ok, thanks, I'm not expecting this sort of backward support, I have special case were I need the 32 bit and figured since I had all the infrastructure in place, what the heck, what have I got to lose ;) I will dig up my old java8 build and use that for this, thanks again! wbr Kusti > On 25 Jan

Re: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException

all good still > On Jan 25, 2019, at 2:34 PM, Joe Wang wrote: > > Hi Daniel, > > True, Objects.equals is better. While the default setting generally won't be > null, it's always good to cover all the bases. > > Updated: > http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev02/ > >

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

While this works fine in the generated javadoc {@linkplain map map} This makes intellij a bit happier : {@linkplain Attributes#map map} - $ hg diff diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java ---

[13] RFR: 8217609: New era placeholder not recognized by java.text.SimpleDateFormat

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8217609 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8217609/webrev.00/ Although the behavior described in the issue is the expected one (i.e., CLDR currently does not

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

Hi Joe yes I checked it in my local build and it does take me to map field via the link Best Lance > On Jan 25, 2019, at 2:49 PM, Joe Darcy wrote: > > Hi Lance, > > Assuming the javadoc renders as expected, the new version looks good to me :-) > > Thanks, > -Joe > On 1/25/2019 11:44 AM,

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

Hi Lance, Assuming the javadoc renders as expected, the new version looks good to me :-) Thanks, -Joe On 1/25/2019 11:44 AM, Lance Andersen wrote: Thank you Joe. So the change is (see bolded change): $ hg diff diff -r 6130409b923e

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

Thank you Joe. So the change is (see bolded change): $ hg diff diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 +++

Re: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException

Hi Daniel, True, Objects.equals is better. While the default setting generally won't be null, it's always good to cover all the bases. Updated: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev02/ Previous: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev01/ Thanks, Joe On

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

To clarify the CSR comments, for "underlying map" I meant for "map" to be a link to the protected field named "map". Thanks, -Joe On 1/25/2019 11:24 AM, Roger Riggs wrote: Looks fine, Lance Roger On 01/25/2019 02:22 PM, Lance Andersen wrote: The CSR review suggested a slight update to the

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

Looks fine, Lance Roger On 01/25/2019 02:22 PM, Lance Andersen wrote: The CSR review suggested a slight update to the proposed wording: ——— $ hg diff diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java ---

Re: RFR: JDK8U JDK-8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8

+1 On 01/25/2019 02:12 PM, naoto.s...@oracle.com wrote: Looks good to me. Naoto On 1/25/19 10:37 AM, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216396 Webrev: HYPERLINK

Re: RFR: JDK11U JDK-8216546: Support new Japanese era in java.lang.Character for Java SE 11

+1 On 01/25/2019 02:11 PM, naoto.s...@oracle.com wrote: Looks good to me. Naoto On 1/25/19 10:35 AM, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216546 Webrev: HYPERLINK

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

The CSR review suggested a slight update to the proposed wording: ——— $ hg diff diff -r 6130409b923e src/java.base/share/classes/java/util/jar/Attributes.java --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 24 10:57:31 2019 -0800 +++

Re: RFR: JDK8U JDK-8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8

Looks good to me. Naoto On 1/25/19 10:37 AM, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216396 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216396/"http://cr.openjdk.java.net/~rpatil/8216396/ Summary: As per previous communication

Re: RFR: JDK11U JDK-8216546: Support new Japanese era in java.lang.Character for Java SE 11

Looks good to me. Naoto On 1/25/19 10:35 AM, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216546 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216546/"http://cr.openjdk.java.net/~rpatil/8216546/ Summary: As per previous communication

Re: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException

Hi Joe, I was wondering whether: return Objects.equals(uri, defaultNamespace) would be more appropriate (or not) - given the action taken by setDefaultNamespace above? I mean - what if both uri and defaultNamespace are null? Just double checking - as I have no idea what would be the right

Re: jpackage windows 32 bit jre

Packing JDK8 runtime, or packaging app with JDK8 runtime is not supported by jpackage. It is recommended to package JDK8 apps using the javafxpackager in JDK8. It is interesting you got this far. I tried this myself and get a 32 bit jre8 installed (by default in the wrong place, C:\Program

Re: jpackage windows 32 bit jre

jpackage will only support JDK 11 and later. It is not a goal to be able to embed a JRE from JDK 8. For that you should continue to use the old javapackager tool that ships with JDK 8. So the fact that it "seems to work" up to a point is an accident. We should probably check for that case and

RFR: JDK8U JDK-8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8

Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216396 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216396/"http://cr.openjdk.java.net/~rpatil/8216396/ Summary: As per previous communication from Iris[0], a maintenance review for Java SE 8 is planned. JDK-8216396

RFR: JDK11U JDK-8216546: Support new Japanese era in java.lang.Character for Java SE 11

Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216546 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216546/"http://cr.openjdk.java.net/~rpatil/8216546/ Summary: As per previous communication from Iris[0], a maintenance review for Java SE 11 is planned.

Re: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false)

Please review an updated webrev for this change. In the update, the change to XMLDocumentFragmentScannerImpl was to add the default value when calling getFeature at line 606 that allowed the previous commented tests to pass properly. The other change was to LSSerializerTest. Refer to the

jpackage windows 32 bit jre

I tried and succeeded in using the jpackage from jdk13 (not really) to package 32 bit java8 for Windows. Everything goes nicely at build time and when I double click the .exe an install is performed, however the resulting installed .exe fails with "Failed to find library C:\Program

Re: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException

+1 > On Jan 25, 2019, at 12:47 PM, Joe Wang wrote: > > Please review a fix for XMLStreamWriter.setDefaultNamespace that throws > NullPointerException when the value is null. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8216408 > webrevs:

RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException

Please review a fix for XMLStreamWriter.setDefaultNamespace that throws NullPointerException when the value is null. JBS: https://bugs.openjdk.java.net/browse/JDK-8216408 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev/ Thanks, Joe

Re: possible problem with JNI GetStringUTFChars

My question was not about why it does what it does, but why it still does that. Is there a valid use of this primitive that depends upon it returning something other than true UTF-8? It may not have been an issue to you, but it was to me when I discovered my program could not handle certain

Re: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module

> On Jan 25, 2019, at 3:55 AM, Alan Bateman wrote: > > > > On 25/01/2019 00:11, Lance Andersen wrote: >>> On Jan 24, 2019, at 6:20 PM, Mandy Chung wrote: >>> >>> >>> >>> On 1/24/19 1:55 PM, Lance Andersen wrote: > Alternatively you can simply do: >

Re: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

+1, Thanks, Roger On 01/25/2019 11:21 AM, Steve Groeger wrote: Hi Roger, Thanks. Have included the bug number to the @bug line and have included the expected and actual output when there is an error. Have generated a new webrev here: http://cr.openjdk.java.net/~sgroeger/821/webrev.01/

Re: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

Hi Roger, Thanks. Have included the bug number to the @bug line and have included the expected and actual output when there is an error. Have generated a new webrev here: http://cr.openjdk.java.net/~sgroeger/821/webrev.01/ Hope this is now OK. Thanks Steve Groeger IBM Runtime

Re: Anonymous class

On 1/25/19 5:37 AM, David Holmes wrote: > The class name is com.google.common.collect.Iterators$3, and it is an > anonymous class.     I'm confused. Are you talking about Java level anonymous classes or VM     anonymous classes as created by Unsafe.defineAnonymousClass? Only VM

Re: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

Hi Steve, Add 821 to the @bug line; it helps track and run tests that fixed bugs  (jtreg -bug:821) +1 printing the expected and actual (when a failure occurs). Looks fine overall. Thanks, Roger On 01/25/2019 09:57 AM, Steve Groeger wrote: Hi Christoph, Thanks for looking at

RE: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

Hi Christoph, Thanks for looking at this. These lines 43 //System.out.print(baos.toString()); 44 //System.out.print(expectedResult); were commented out in the current code but if you think displaying this info would be good then I can un-comment them. I think only

RE: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

Hi Steve, in general this change looks reasonable to me. I think in case there is an error, it would be useful to get a printout of the expected/vs actual strings like these lines: 43 //System.out.print(baos.toString()); 44 //System.out.print(expectedResult); I'll take the

RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hi Matthias, thanks for bringing this enhancement into the OpenJDK. I have a few wishes, though. First of all, I think this method fits perfectly well to jli_util. It does not really have to do with the logic of parsing manifests but it is rather an enhanced open function. So you should

Re: Anonymous class

On 25/01/2019 11:06 pm, yumin qi wrote: Hi, David I am confused here. As you pointed out:    Java anonymous classes are not VM anonymous classes.    VM anonymous classes are created by Unsafe_DefineAnonymousClass only. Is my understanding right? All all lambda classes are vm anonymous? I

Re: Anonymous class

Hi, David I am confused here. As you pointed out: Java anonymous classes are not VM anonymous classes. VM anonymous classes are created by Unsafe_DefineAnonymousClass only. Is my understanding right? All all lambda classes are vm anonymous? Thanks Yumin On Fri, Jan 25, 2019 at 7:18 PM

Re: High memory usage / leaks was: Best mailing list for JVM embedding

On 1/24/19 11:05 AM, Sean Mullan wrote: On 1/24/19 8:25 AM, Robert Marcano wrote: On 1/23/19 8:59 AM, Sean Mullan wrote: On 1/22/19 8:50 PM, Bernd Eckenfels wrote: I don’t think the launcher is doing this, it is the class loader, that’s nothing new. You can turn on verbose security debug to

RFR: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

Hi all, I have found an issue with the jdk/java/util/prefs/ExportSubtree.java test. Using jtreg to run this test the test passes no matter what happens within the test. Have raised an issue for this: https://bugs.openjdk.java.net/browse/JDK-821 I think the issue is 2 fold: 1) the test

Re: Anonymous class

On 25/01/2019 6:52 pm, yumin qi wrote: Hi, I have a question of anonymous class. We know the anonymous class with a host_klass, and the flag is set when the InstanceKlass is created after the class parsed. In case of a regular java class file, the flag will be set correctly but for the

RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system

Hi Alan, thanks for your view on this backport request even though you aren't involved in jdk11u any longer. > The support for zip files located in file systems created by custom > providers was essentially a new feature in JDK 12 so it may not have got > a lot of usage yet. There has been a

RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system

Hi Goetz, > > And I see much more differences if I compare the diffs. > > Please explain. > unfortunately, the udiffs of the webrev look different in quite some parts to what you see when you look at the commit on the hg web server (http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5),

Re: [testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive

Hi Martin, On 24/01/2019 18:19, Martin Buchholz wrote: I don't understand your test, but: typo: bootsrap Thanks! Fixed. Consider copying in gcAwait from a concurrency test, e.g. ArrayBlockingQueue/WhiteBox.java:229:static void gcAwait(BooleanSupplier s) { Interesting. The main

Re: RFR: 8210469: Missing doPriviledged block and permission for jdk.zipfs module

On 25/01/2019 00:11, Lance Andersen wrote: On Jan 24, 2019, at 6:20 PM, Mandy Chung wrote: On 1/24/19 1:55 PM, Lance Andersen wrote: Alternatively you can simply do: PrivilegedExceptionAction pea = () -> tempPath.toRealPath(); return

Anonymous class

Hi, I have a question of anonymous class. We know the anonymous class with a host_klass, and the flag is set when the InstanceKlass is created after the class parsed. In case of a regular java class file, the flag will be set correctly but for the case it is not set:

Re: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system

On 25/01/2019 08:01, Lindenmaier, Goetz wrote: Hi Christoph, This is a big change, and it seems a lot more changed than resolving Hunks. The support for zip files located in file systems created by custom providers was essentially a new feature in JDK 12 so it may not have got a lot of usage

RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system

Hi Christoph, This is a big change, and it seems a lot more changed than resolving Hunks. Some hunks are missing altogether. For example, http://hg.openjdk.java.net/jdk/jdk/rev/ba51515b64e5, ZipFileSystem 2341 2.341-IndexNode inode = new IndexNode(cen, nlen, pos); 2.342+