Re: Querstion about ForkJoinPool / SecurityManager interoperability

Hi Martin, In my simplified test, I managed to reproduce the execution in the main thread, when I did not wait for a start and directly called get()... as in your test here: 99 await(taskStarted); -Patrick Am 14.12.18 um 16:11 schrieb Martin Buchholz: > > > On Thu, Dec 13, 2018 at

Re: JDK-8165199: UUID.fromString(str) compliance checking?

Yes, this was my concern, source compatibility... With the current implementation it is not too harmful to "sloppy" app code. If it's not causing any other underlying "bug" then I would be tempted to leave this "sleeping dog..." Andrew Leonard Java Runtimes Development IBM Hursley IBM United

Re: RFR: 8215412: Optimize PrintStream.println methods

Hi, On 2018-12-14 19:06, Roger Riggs wrote: Hi Claes, 611: Can't the loop break after finding the first \n? shouldn't have been a loop there at all (and yes, in the pre-existing version breaking after finding the first \n should be ok) 916: I'd probably call writeln(String.valueOf(x))

Re: The meaning of the java.vendor property?

Martin, Volker, Many things for quickly providing these clarifying words! Going forward, I will be assuming that "vendor" means whoever built the distribution and that there is some intended differentiation in the values of "java.vendor" and "java.vm.vendor". Bernd From: Martin Buchholz

Using jpacakge with a mixed-modularity app

Say I have an app with both modular and non-modular dependencies. With jlink, I can generate a runnable image for the app by linking the modular dependencies and placing the non-modular dependencies on the classpath using a custom launch script. Can jpackage take this mixed-modularity image and

Re: jpackage EA Build 0

> On Dec 14, 2018, at 12:05 PM, Phil Race wrote: > > See Kevin's last reply. > > -phil. > > On 12/14/18 10:03 AM, Michael Hall wrote: >> OK fair enough, got that. This just made me wonder though, would JDK 12 be >> the only JRE that can be targeted for packaging? >> It can only make JDK 12

Re: jpackage EA Build 0

See Kevin's last reply. -phil. On 12/14/18 10:03 AM, Michael Hall wrote: OK fair enough, got that. This just made me wonder though, would JDK 12 be the only JRE that can be targeted for packaging? It can only make JDK 12 executables?

Re: RFR: 8215412: Optimize PrintStream.println methods

Hi Claes, 611: Can't the loop break after finding the first \n? 916: I'd probably call writeln(String.valueOf(x)) and skip the extra method call. Is there any benefit of doing the String conversions before the synchronized block? As is in the old code for println(Object x). There isn't

Re: jpackage EA Build 0

On 12/14/2018 10:03 AM, Michael Hall wrote: On Dec 14, 2018, at 11:58 AM, Phil Race wrote: "Incomplete" meant "JDK 12 is not yet completed". Perhaps that could have been worded differently like "a non-final version of JDK12". I think the intent was to make it clear what JDK version this

Re: jpackage EA Build 0

> On Dec 14, 2018, at 11:58 AM, Phil Race wrote: > > "Incomplete" meant "JDK 12 is not yet completed". > Perhaps that could have been worded differently like "a non-final version of > JDK12". > I think the intent was to make it clear what JDK version this was. Eg it is > not built on top >

Re: jpackage EA Build 0

"Incomplete" meant "JDK 12 is not yet completed". Perhaps that could have been worded differently like "a non-final version of JDK12". I think the intent was to make it clear what JDK version this was. Eg it is not built on top of 11 GA. It is built on top of the current JDK development branch

Re: jpackage EA Build 0

> On Dec 14, 2018, at 11:53 AM, Kevin Rushforth > wrote: > > > So I could say drop the jpackage command into my app’s current earlier JRE > > bin directory and it might work? > > No. You need to run jpackage from the JDK 12 ea build that you downloaded. > jpackage isn't something you drop

Re: jpackage EA Build 0

> So I could say drop the jpackage command into my app’s current earlier JRE bin directory and it might work? No. You need to run jpackage from the JDK 12 ea build that you downloaded. jpackage isn't something you drop into your application, it's a tool you run to package up your application

Re: jpackage EA Build 0

> On Dec 14, 2018, at 11:30 AM, Kevin Rushforth > wrote: > > Correct. jpackage will be delivered as a tool that is part of the JDK. Future > EA builds will likely include an EA of JDK 13. > > -- Kevin > > On 12/14/2018 9:26 AM, Michael Hall wrote: >>> Warning: This build is based on an

Re: jpackage EA Build 0

Correct. jpackage will be delivered as a tool that is part of the JDK. Future EA builds will likely include an EA of JDK 13. -- Kevin On 12/14/2018 9:26 AM, Michael Hall wrote: Warning: This build is based on an incomplete version of JDK 12 . So

Re: jpackage EA Build 0

> > Warning: This build is based on an incomplete version of JDK 12 > . > So when I download (OS X) it appears it is included with a entire jdk 12 build?

RFR: 8215412: Optimize PrintStream.println methods

Hi, the various PrintStream.println methods are inefficient: nested synchronization, multiple flushes and a scan of the input string for newlines that in the end is pointless in this context since newLine will always flush anyway (if autoflush is enabled). While performance of printing to

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Hi, here's the new webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.02/ I solved the issue by incrementally doubling the new table, before adding new elements. This solution has no such performance boost as first buggy one, it's still measurable for case when adding big

Re: JDK-8165199: UUID.fromString(str) compliance checking?

Hello, Note that a fix to this issue would require a CSR (https://wiki.openjdk.java.net/display/csr/Main) to either assess the behavioral compatibility impact of changing the existing behavior or to review a new API added for stricter parsing. Cheers, -Joe On 12/14/2018 8:42 AM, Claes

Re: JDK-8165199: UUID.fromString(str) compliance checking?

Hi, a stricter implementation could also be (much) more performant. I've been meaning to propose a patch that makes strict mode default and adds a configuration option to fall back to the current, relaxed implementation. Adding such compatibility options always feel a bit like a dirty hack,

JDK-8165199: UUID.fromString(str) compliance checking?

hi, So i'm just taking a look at what appears quite a simple bug : https://bugs.openjdk.java.net/browse/JDK-8165199 , at least the fix is simple to make UUID.fromString(str) strictly uuid bnf compliant. However, I wanted to get community opinion on potential "compliance" issues with doing such

Re: Querstion about ForkJoinPool / SecurityManager interoperability

On Thu, Dec 13, 2018 at 4:37 AM Patrick Reinhart wrote: > Even if the security manager is enabled before the initialize of the > ForkJoinPool not all work is delegated to InnocuousForkJoinWorkerThread > instances (sometimes it picks the main thread instead, that has not the > restrictions, what

Re: RFR: 8215380: Backout accidental change to String::length

Thanks everyone for reviewing! I have pushed this to jdk/jdk12 /Claes On 2018-12-14 15:06, Roger Riggs wrote: +1 On 12/13/2018 06:43 PM, Stuart Marks wrote: Hi Claes, Thank for catching this. Looks good. Note that the original changeset (JDK-8215281) went into JDK 12 before the RDP1 fork,

Re: The meaning of the java.vendor property?

That's my understanding also. Vendor is the entity that builds and releases the bundle. Regards, Roger On 12/14/2018 03:12 AM, Volker Simonis wrote: Hi Bernd, from my understanding you can choose to freely set the following properties (and we do that for SapMachine, as you can see):

Re: RFR: 8215380: Backout accidental change to String::length

+1 On 12/13/2018 06:43 PM, Stuart Marks wrote: Hi Claes, Thank for catching this. Looks good. Note that the original changeset (JDK-8215281) went into JDK 12 before the RDP1 fork, so this fix should also go into JDK 12. That's a different repo now. It will then be auto-propagated to the JDK

Re: Querstion about ForkJoinPool / SecurityManager interoperability

Wow - nice :-) On 2018-12-14 13:43, Doug Lea wrote: On 12/13/18 2:34 PM, Patrick Reinhart wrote: Should I prepare a webrev for this change? No, I think we are all set (thanks Martin!) https://bugs.openjdk.java.net/browse/JDK-8215359

jpackage EA Build 0

I am pleased to announce that the first EA build of jpackage is now available at : https://jdk.java.net/jpackage/ This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, This build is intended for

Re: Querstion about ForkJoinPool / SecurityManager interoperability

On 12/13/18 2:34 PM, Patrick Reinhart wrote: > Should I prepare a webrev for this change? No, I think we are all set (thanks Martin!) https://bugs.openjdk.java.net/browse/JDK-8215359 > > -Patrick > > Am 13.12.18 um 15:15 schrieb Doug Lea: >> On 12/13/18 8:44 AM, Patrick Reinhart wrote: >>>

Re: RFR 8215372: test/jdk/java/nio/file/DirectoryStream/Basic.java not correct for validating the use of a glob

On 13/12/2018 20:30, Lance Andersen wrote: Hi all, Attached is the patch for https://bugs.openjdk.java.net/browse/JDK-8215372 that addresses the test DirectoyStream/Basic.java which was not correctly validating newDirectoryStream using a glob: The test update looks good to me. -Alan

Re: RFR: 8214533 IBM-29626C is required for AIX default charset

Hello Alan. I opened JDK-8215333 for Charset filtering issue [1]. I cannot wait until JDK-8215333 is closed. Is it possible to put IBM-29626C charset with standard way ? [1] https://bugs.openjdk.java.net/browse/JDK-8215333 Thanks, Ichiroh Takiguchi On 2018-12-10 21:21, Ichiroh Takiguchi

Re: The meaning of the java.vendor property?

Hi Bernd, from my understanding you can choose to freely set the following properties (and we do that for SapMachine, as you can see): java.vendor = SAP SE java.vendor.url = https://sapmachine.io java.vendor.url.bug = https://github.com/SAP/SapMachine/issues/new java.vm.vendor =