Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

On 25/08/2017 3:26 PM, Martin Buchholz wrote: On Thu, Aug 24, 2017 at 7:49 PM, David Holmes > wrote: I have no further comments on the actual spec. Here's my suggestion for the timed-wait example :) while (true) {   if (!condition)     wait

Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

On Thu, Aug 24, 2017 at 7:49 PM, David Holmes wrote: > I have no further comments on the actual spec. > > Here's my suggestion for the timed-wait example :) > > while (true) { > if (!condition) > wait(timeout, nanos); > else > break; // condition holds > > if (timeout <= 0 && !co

Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

I have no further comments on the actual spec. Here's my suggestion for the timed-wait example :) while (true) { if (!condition) wait(timeout, nanos); else break; // condition holds if (timeout <= 0 && !condition) throw new TimedOutException(); } // Perform action appropriat

Re: JDK8: Unloading native JNI library

And what is the name of the library? Thanks, David On 25/08/2017 12:18 PM, David Holmes wrote: Hi Vemund, What OS do you see this on? Are you able to test different OS? Thanks, David On 24/08/2017 10:37 PM, Vemund Ostgaard wrote: Hello, I am struggling with a problem related to unloading (

Re: JDK8: Unloading native JNI library

Hi Vemund, What OS do you see this on? Are you able to test different OS? Thanks, David On 24/08/2017 10:37 PM, Vemund Ostgaard wrote: Hello, I am struggling with a problem related to unloading (and reloading) a native JNI library that has been loaded with System.load(). I have been referre

Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

On 24/08/2017 11:30 PM, Adam Farley8 wrote: Hi Alan, David, and Tom, First, thanks again for your efforts on this. As a new guy to OpenJDK contributions, it means a lot to see so much progress on this so quickly. :) All I see is discussion :) Progress would be something else entirely. >On

Re: ISO-8859-16 charset/decoder/encoder

Finally got around to opening an issue for this. https://bugs.openjdk.java.net/browse/JDK-8186751 I'm happy to do the requisite work to bring this patch to fruition, but since this is my first patch I'm not sure of the process. - Charlie On Fri, Nov 22, 2013 at 5:06 AM Charles Oliver Nutter wro

Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

On 8/20/17 6:32 PM, David Holmes wrote: You're a brave man :) "It's a dirty job, but somebody's gotta do it." :-) I have a personal interest in this, as back in the 1.3 days I was trying to nail down some multi-threaded code, and I found the wait() docs to be quite lacking. In particular,

RFR(jdk10/jaxp) 8186675: Javadoc of SAXSource contains implementation detail

Hi, Removing an implementation detail from the javadoc of SAXSource, please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8186675 webrev: http://cr.openjdk.java.net/~joehw/jdk10/8186675/webrev/ Thanks, Joe

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

Looks good to me. On Wed, Aug 23, 2017 at 4:02 PM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > Removed ArrayDeque from patch. > Updated webrev and API > > Webrev: http://cr.openjdk.java.net/~jjg/8186684/webrev.01/index.html > API: http://cr.openjdk.java.net/~jjg/8186684/api.01/overvi

Re: RFR(XXXS): 8186613: remove ClassFileInstaller from jdk/test/lib/testlibrary

On 8/23/17 8:58 PM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8186613/webrev.00/index.html 58 lines changed: 0 ins; 57 del; 1 mod; 64 unchg Hi all, could you please review this tiny patch which removes ClassFileInstaller from jdk/test/lib/testlibrary and updates the tests to

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

On 8/24/17 1:26 PM, Jonathan Gibbons wrote: Fixed broken link in Configuration.java Webrev: http://cr.openjdk.java.net/~jjg/8186684/webrev.02/index.html API: http://cr.openjdk.java.net/~jjg/8186684/api.02/overview-summary.html The fix looks good.  On the other hand, as we discussed offline, w

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

Fixed broken link in Configuration.java Webrev: http://cr.openjdk.java.net/~jjg/8186684/webrev.02/index.html API: http://cr.openjdk.java.net/~jjg/8186684/api.02/overview-summary.html -- Jon On 08/23/2017 04:16 PM, mandy chung wrote: On 8/23/17 4:02 PM, Jonathan Gibbons wrote: Removed ArrayD

Re: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

> On 24 Aug 2017, at 11:51, John Rose wrote: > > On Aug 24, 2017, at 1:13 PM, Paul Sandoz > wrote: >> >> >>> There seems to be one more issue: Collect the trailing elements (there are {@code N-M+1} of them) from the logical argument list into a single

Re: [10] RFR JDK-8186713: Document default rounding mode in NumberFormat

A few minor comments: L178-195: Is a list necessary here? L186: I don’t think “Rounding: " is necessary. L187: s/the numbers/numbers/ L188: s/uses/uses the/ L191: s/its/the/ Thanks, Brian On Aug 24, 2017, at 12:06 AM, Nishit Jain wrote: > Webrev:http://cr.openjdk.java.net/~nishjain/818671

Re: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

On Aug 24, 2017, at 1:13 PM, Paul Sandoz wrote: > > >> There seems to be one more issue: >>> Collect the trailing elements (there are {@code N-M+1} of them) >>> from the logical argument list into a single array of >>> type {@code A[]}, using {@code asType} conversions to >>> convert each traili

Re: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

> On 23 Aug 2017, at 23:49, stanislav lukyanov > wrote: > > Thanks for the updates, Paul! >>> Second, it's unfortunate that varargs collection has to be re-implemented >>> in the spec >>> for `invokeWithArguments` instead of reusing what `asVarargsCollector` has. >> I think this was always th

Re: [10] RFR JDK-8186713: Document default rounding mode in NumberFormat

Looks good. Naoto On 8/24/17 12:06 AM, Nishit Jain wrote: Hi, Please review the fix for JDK-8186713 Bug: https://bugs.openjdk.java.net/browse/JDK-8186713 Webrev: http://cr.openjdk.java.net/~nishjain/8186713/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8185777 Fix: Updated the spe

Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

Hi Alan, David, and Tom, First, thanks again for your efforts on this. As a new guy to OpenJDK contributions, it means a lot to see so much progress on this so quickly. :) >On 24/08/2017 07:33, David Holmes wrote: >> Hi Adam, >> >> cc'ing hotspot runtime dev as runtime own JNI and the invocatio

JDK8: Unloading native JNI library

Hello, I am struggling with a problem related to unloading (and reloading) a native JNI library that has been loaded with System.load(). I have been referred to this mailing list as the right place to ask, so seeking your advice on the issue. My goal was to load a JNI library from a JVM proc

Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

On 24/08/2017 07:33, David Holmes wrote: Hi Adam, cc'ing hotspot runtime dev as runtime own JNI and the invocation API - and some of the problematic code resides in the VM. Yeah, the hotspot mailing list would be a better place to discuss this as there are several issues here and several place

Executors.newScheduledThreadPool()

I recently fell into the trap of misusing the method Executors.newScheduledThreadPool() despite having read the Javadoc: /** * Creates a thread pool that can schedule commands to run after a * given delay, or to execute periodically. * @param corePoolSize the number of threads t

Re: Manifest Add-Exports vs. command line --add-exports

Hi, On 08/23/2017 11:24 PM, Tom Hood wrote: The CLI options to export or open packages can be specified in JNLP file, you shouldn't need to ask user to add them via the control panel. You can predicate on the Java SE version too, i.e. The issue is the limit on the *number* of args we can

Re: RFR 8173715: Remove Flat Profiler

On 24/08/2017 2:20 AM, Gerard Ziemski wrote: Thank you David. Do I need a second reviewer here? Yes any launcher changes should be signed off by launcher folk - so I've directly cc'd Kumar, who is hopefully around :) David cheers On Aug 22, 2017, at 9:15 PM, David Holmes wrote: Hi

Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

On 24/08/2017 4:59 PM, Thomas Stüfe wrote: Hi David, our mails crossed :) And unfortunately we each added in a different hotspot mailing list. :) PS3: We should replace these annoying exit(0) calls with code that returns "JNI_SILENT_EXIT", so the C++ code has a cha

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

On 08/24/2017 12:31 AM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8186500/jdk.04/ Looks good! -Aleksey

[10] RFR JDK-8186713: Document default rounding mode in NumberFormat

Hi, Please review the fix for JDK-8186713 Bug: https://bugs.openjdk.java.net/browse/JDK-8186713 Webrev: http://cr.openjdk.java.net/~nishjain/8186713/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8185777 Fix: Updated the specification of NumberFormat about the default rounding mode u

Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

Hi David, our mails crossed :) > PS3: We should replace these annoying exit(0) calls with code that returns >> "JNI_SILENT_EXIT", so the C++ code has a chance to finish. >> > > We should certainly look at getting rid of the exit() calls. Or at least consistently route them through the exit h