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

On 24.08.2017 23:43, Paul Sandoz wrote: On 23 Aug 2017, at 23:49, stanislav lukyanov wrote: I still think that instead of debugging this spec and making sure that it behaves similarly to `asType` it would be better to keep delegating to the implied `asType` and allow it not to throw IAE for

Any known issues posting to core-libs-dev?

Hi, are there any known issues with posting to core-libs-dev at the moment? I've got a couple of colleagues who are newly registered subscribers who have posted but their messages have not got through even after waiting several days...? Thanks Andrew Unless stated otherwise above: IBM United Ki

Re: Any known issues posting to core-libs-dev?

Hi Andrew, I'm not yet aware of any ongoing problems posting to lists at this time. Could you please send an e-mail to ops@openjdk detailing the issue, along with the e-mail headers? Thanks! cheers, dalibor topic On 25.08.2017 11:10, Andrew Leonard wrote: Hi, are there any known issues with

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

+1 > On Aug 24, 2017, at 9:26 PM, huizhe wang wrote: > > 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: JDK8: Unloading native JNI library

Hi David, On 25. aug. 2017 04:18, David Holmes wrote: Hi Vemund, What OS do you see this on? Are you able to test different OS? Excellent question. Earlier in my struggles to get this working I had tested on both an RHEL7 and Ubuntu 16.04 and seen the same problems, so I did further testing

Proposal: ModuleReferenceImpl.c to use ReleaseStringUTFChars not jvmtiDeallocate

Hello, I would like to propose the change below to src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c native code so that the getName function use ReleaseStringUTFChars() to release the memory obtained using GetStringUTFChars() instead of the current jvmtiDeallocate() meth

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

> On 25 Aug 2017, at 00:47, stanislav lukyanov > wrote: > > > On 24.08.2017 23:43, Paul Sandoz wrote: >>> On 23 Aug 2017, at 23:49, stanislav lukyanov >>> wrote: >>> I still think that instead of debugging this spec and making sure that it >>> behaves similarly to `asType` >>> it would be b

Re: Proposal: ModuleReferenceImpl.c to use ReleaseStringUTFChars not jvmtiDeallocate

On 25/08/2017 15:59, Steve Groeger wrote: Hello, I would like to propose the change below to src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c native code so that the getName function use ReleaseStringUTFChars() to release the memory obtained using GetStringUTFChars() instea

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

Hi Charlie, Not sure how much you know already so just in case… See here: http://openjdk.java.net/guide/producingChangeset.html I am guessing you have an ssh key to access http://cr.openjdk.java.net/~headius/

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

On 25/08/2017 17:19, Paul Sandoz wrote: Then you will need a sponsor (to perhaps upload the webrev if necessary and) to commit the patch after review, i suggest someone knowledgable in the area should sponsor. Naoto, hint hint :-) or Sherman, I see he already has the mapping tables for ISO-

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

Yep, I believe Sherman is more knowledgeable on this than me :-) Naoto On 8/25/17 9:30 AM, Alan Bateman wrote: On 25/08/2017 17:19, Paul Sandoz wrote: Then you will need a sponsor (to perhaps upload the webrev if necessary and) to commit the patch after review, i suggest someone knowledga

RFR [10] 8186217 : Remove erroneous @hidden JavaDoc tag from java.util.Properties.replace(Object, Object, Object)

Hi, Please review this simple doc fix for: https://bugs.openjdk.java.net/browse/JDK-8186217 When working on JDK-8029891, solutions were sought to avoid cluttering up the Properties JavaDoc with new overridden methods. The @hidden tag was considered, then later rejected. Here[1] is the email

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

Thanks Lance! Joe On 8/25/2017 3:49 AM, Lance Andersen wrote: +1 On Aug 24, 2017, at 9:26 PM, huizhe wang > wrote: Hi, Removing an implementation detail from the javadoc of SAXSource, please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8186675 webre

Re: RFR [10] 8186217 : Remove erroneous @hidden JavaDoc tag from java.util.Properties.replace(Object, Object, Object)

+1 Naoto On 8/25/17 10:03 AM, Brent Christian wrote: Hi, Please review this simple doc fix for: https://bugs.openjdk.java.net/browse/JDK-8186217 When working on JDK-8029891, solutions were sought to avoid cluttering up the Properties JavaDoc with new overridden methods. The @hidden tag was

Re: RFR [10] 8186217 : Remove erroneous @hidden JavaDoc tag from java.util.Properties.replace(Object, Object, Object)

+2 On Aug 25, 2017, at 10:28 AM, Naoto Sato wrote: > +1 > > Naoto > > On 8/25/17 10:03 AM, Brent Christian wrote: >> Hi, >> Please review this simple doc fix for: >> https://bugs.openjdk.java.net/browse/JDK-8186217

Re: RFR [10] 8186217 : Remove erroneous @hidden JavaDoc tag from java.util.Properties.replace(Object, Object, Object)

Thanks! -B On 08/25/2017 10:29 AM, Brian Burkhalter wrote: +2 On Aug 25, 2017, at 10:28 AM, Naoto Sato mailto:naoto.s...@oracle.com>> wrote: +1 Naoto On 8/25/17 10:03 AM, Brent Christian wrote: Hi, Please review this simple doc fix for: https://bugs.openjdk.java.net/browse/JDK-8186217

[10] RFR 8171049: Era.getDisplayName doesn't work with non-IsoChronology

Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8171049 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8171049/webrev.00/ The fix is to implement Era.getDisplayName() in each Era enum. Naoto

Re: [10] RFR 8171049: Era.getDisplayName doesn't work with non-IsoChronology

The formatter should be a static constant in both cases - no need to create each time. I would have expected this to be done without using DateTimeFormatter however, just directly calling an internal API. Stephen On 25 August 2017 at 18:43, Naoto Sato wrote: > Hi, > > Please review the fix

Re: [10] RFR 8171049: Era.getDisplayName doesn't work with non-IsoChronology

Hi, Something like: DateTimeFormatterBuilder.DateTimeTextProvider .getInstance()     .getText(ChronoField.ERA, value, style, locale); Take a look at what TextPrinterParser.format does: line 3291. Roger On 8/25/2017 1:49 PM, Stephen Colebourne wrote: The formatter should be a stat

Re: [10] RFR 8171049: Era.getDisplayName doesn't work with non-IsoChronology

Hi Stephen, thanks for the review. On 8/25/17 10:49 AM, Stephen Colebourne wrote: The formatter should be a static constant in both cases - no need to create each time. Yes, that can be done. I would have expected this to be done without using DateTimeFormatter however, just directly calli

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

Stuart, you have my blessing to commit what you have, even though both your reviewers are still nitpicking that wait loop. The thing that bothers me in while ( and ) { long timeout = ... ; // recompute timeout values is that you can't check for until you've done the "recom

Re: [10] RFR 8171049: Era.getDisplayName doesn't work with non-IsoChronology

On 8/25/17 11:04 AM, Naoto Sato wrote: Hi Stephen, thanks for the review. On 8/25/17 10:49 AM, Stephen Colebourne wrote: The formatter should be  a static constant in both cases - no need to create each time. Yes, that can be done. I further looked at this, but it seems the Builder and Form

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

Thanks everyone, I'll work with Sherman to get a patch together. On Fri, Aug 25, 2017 at 1:19 PM Naoto Sato wrote: > Yep, I believe Sherman is more knowledgeable on this than me :-) > > Naoto > > On 8/25/17 9:30 AM, Alan Bateman wrote: > > > > > > On 25/08/2017 17:19, Paul Sandoz wrote: > >> > >

Re: RFR 8186539 [testlibrary] : TestSocketFactory should allow triggers before match/replace

On 8/21/17 2:08 PM, Roger Riggs wrote: Please review a rmi testlibrary enhancement to allow a trigger byte sequence before the match and replace. It improves the ease with which stream contents can be identified when streams contain IP addresses and sequence numbers that change from run to ru

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

On 8/25/17 11:34 AM, Martin Buchholz wrote: Stuart, you have my blessing to commit what you have, even though both your reviewers are still nitpicking that wait loop. OK, thanks, I was thinking the same thing. :-) s'marks