Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

On 19/07/2016 02:57, joe darcy wrote: Hi Brian, As as grammatical comment, I might start with "The {@code java.prefs} module defines ...", but otherwise, the change looks fine. Also I think it's API rather than "APIs". At some point then we need to do a pass over all the javadoc comments in

Re: RFR JDK-8155616: java/util/zip/TestLocalTime.java fails intermittently with storing mtime failed

Thanks for the fix, really a corner case. I think this looks reasonable. Just one minor thing, please update copyright header on the year when commit. BTW. I'm not official reviewer. Thanks, Amy On 7/19/16 2:23 PM, Xueming Shen wrote: Hi Amy, I finally got to the bottom of this failure. I

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

> On 19 Jul 2016, at 04:07, Martin Buchholz wrote: > > Recent discussion here: > > http://markmail.org/search/?q=core-libs-dev%20ConcurrentHashMap%20jdk.internal.misc.unsafe#query:core-libs-dev%20ConcurrentHashMap%20jdk.internal.misc.unsafe+page:1+mid:iviymmlotcuasv6t+state:results > > There a

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

Just a thought... Is it already too late (or too early?) to consider for jdk.internal.misc.Unsafe to expose a static instead of instance API ? Having instance API was a clever way to fold access checks to static initializer of consumer class, but with Jigsaw, this is not needed any more, rig

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

> On 18 Jul 2016, at 20:06, Steve Drach wrote: > >> >> I would be inclined to drop the note for Enumeration and add a @see tag >> referencing the Stream returned method. > > I actually had to use the versionedEntries method for jdeps. Because of that > and because I don’t see the harm with

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

Hi Peter, Yes, very true, you should log a bug on this, it can be done later during the development of 10 because it requires a coordinate JDK / VM change. Rémi - Mail original - > De: "Peter Levart" > À: "Paul Sandoz" > Cc: "Core-Libs-Dev" > Envoyé: Mardi 19 Juillet 2016 10:05:49 > O

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

> On 19 Jul 2016, at 10:13, Remi Forax wrote: > > Hi Peter, > Yes, very true, > you should log a bug on this, > it can be done later during the development of 10 because it requires a > coordinate JDK / VM change. > Yes, changing all instance methods to static methods is a larger change that

Re: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED

The fix looks good to me. Thanks, Alexandr. On 7/16/2016 2:55 AM, David Holmes wrote: Can I please get someone from AWT to approve this. Thanks, David On 14/07/2016 2:25 PM, David Holmes wrote: The bug report for this is confidential but quite simply all of the little tweaks and knobs we add

Re: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED

Thanks Alexandr! David On 19/07/2016 9:26 PM, Alexandr Scherbatiy wrote: The fix looks good to me. Thanks, Alexandr. On 7/16/2016 2:55 AM, David Holmes wrote: Can I please get someone from AWT to approve this. Thanks, David On 14/07/2016 2:25 PM, David Holmes wrote: The bug report for thi

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

I know I have to do the same for a few modules. Do you have a preference on the wording so it consistent to help reduce follow on changes: The {@code java.XXX} module defines and exports the XXX API Is that the preferred direction? > On Jul 19, 2016, at 3:12 AM, Alan Bateman wrote: > > On 1

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

ok. I would omit the 'of the Java SE platform' as being self referential and unnecessary. (and API should be singular) $.02, Roger On 7/18/2016 8:45 PM, Brian Burkhalter wrote: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8161402 Patch: [1] Thanks,

Re: RFR (JAXP): 8021787: javax.xml.datatype.XMLGregorianCalendar.getMonth() return is documented wrong

Hi Joe, thank you for your replay. As I'm new to javadoc writing feel free to add any comments. Please see updated webrev: http://cr.openjdk.java.net/~snikandrova/8021787/webrev.01/ Thank you, Svetlana On 18.07.2016 20:34, huizh

RFR 9: JEP 290: Filter Incoming Serialization Data

Please review the design, implementation, and tests of JEP 290: Filter Incoming Serialization Data[1] It allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. The JEP[1] has more detail on the background and scope. The core mecha

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

It seems to me it would be less work overall if there were only one single issue to subsume adding the verbiage for all modules. There is only one single line of verbiage for each such issue and having so many reviews go around is a lot of noise. Then also if a CCC were required there would be o

RFR: 8161379: Force inline methods calling Reflection.getCallerClass

Hi, most @CallerSensitive methodscall Reflection.getCallerClass(), which turn out to have problematic performance characteristics when it fails to inline. Making @CallerSensitive imply @ForceInline actually works rather well across benchmarks, but didn't meet with approval from hotspot-compiler

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

On 19/07/2016 16:06, Brian Burkhalter wrote: It seems to me it would be less work overall if there were only one single issue to subsume adding the verbiage for all modules. There is only one single line of verbiage for each such issue and having so many reviews go around is a lot of noise. T

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

> On Jul 19, 2016, at 8:19 AM, Alan Bateman wrote: > > On 19/07/2016 16:06, Brian Burkhalter wrote: > >> It seems to me it would be less work overall if there were only one single >> issue to subsume adding the verbiage for all modules. There is only one >> single line of verbiage for each su

Re: RFR JDK-8155616: java/util/zip/TestLocalTime.java fails intermittently with storing mtime failed

Thanks Amy! webrev has been updated accordingly for the copyright header. Sherman On 7/19/16 12:24 AM, Amy Lu wrote: Thanks for the fix, really a corner case. I think this looks reasonable. Just one minor thing, please update copyright header on the year when commit. BTW. I'm not official

Question on MVJAR usage

I have some questions. I believe core-lib is the right place. If not please let me know. 1) Given a Java 9 runtime, is there any perceptible difference between a non-multiversion jar, and a versioned jar which has placed all its classes under /META-INF/versions/9 ? Pretend each jar has the same id

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

On Jul 19, 2016, at 8:20 AM, Alexandre (Shura) Iline wrote: >> On Jul 19, 2016, at 8:19 AM, Alan Bateman wrote: >> >> I agree, I think we should close the bulk of these issues and replace with >> one issue. >> >> Shura - are you okay if we close all the issues that you created and replace >

Re: RFR JDK-8155616: java/util/zip/TestLocalTime.java fails intermittently with storing mtime failed

Hi Sherman, Looks good to normalize to the system timezone, even if it was changed. +1, Roger On 7/19/2016 11:24 AM, Xueming Shen wrote: Thanks Amy! webrev has been updated accordingly for the copyright header. Sherman On 7/19/16 12:24 AM, Amy Lu wrote: Thanks for the fix, really a corner

[8u-dev] RFR (JAXP) 8028363: XmlGregorianCalendarImpl.getTimeZone() bug when offset is less than 10 minutes

Hello, please review this fix for 8u-dev. For jdk9 problem has been addressed in JEP 255 (Xerces update). Please note that changeset contains of 2 parts: XMLGregorianCalendarImpl fix in jaxp ws: http://cr.openjdk.java.net/~snikandrova/8028363/

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

It doesn’t add that much value. I’ll take it out. > On Jul 19, 2016, at 1:12 AM, Paul Sandoz wrote: > > >> On 18 Jul 2016, at 20:06, Steve Drach wrote: >> >>> >>> I would be inclined to drop the note for Enumeration and add a @see tag >>> referencing the Stream returned method. >> >> I ac

Re: Question on MVJAR usage

Hi Paul, > I have some questions. I believe core-lib is the right place. If not please > let me know. This is the right place. First, the name was changed to Multi-Release JAR, so it’s MRJAR (or Mr. Jar) instead of MVJAR. > > 1) Given a Java 9 runtime, is there any perceptible difference betw

Re: Question on MVJAR usage

Thank you Steve. I have only one follow-up then. If the platform version is *always* a major version, does that imply that minor versions will not add API? The big benefit of MRJAR :-) is that I can provide separate code for different targeted runtimes. If 9.1 wouldn't add new API, then I am good.

RFR: 8161588: MemberName::resolveOrNull cause and hide NoSuchMethodErrors

Hi, please review this bug fix to ensure MemberName::resolveOrNull doesn't throw exceptions when speculatively looking up members that aren't there. HS: http://cr.openjdk.java.net/~redestad/8161588/hs.01 JDK: http://cr.openjdk.java.net/~redestad/8161588/jdk.01 This avoids throwing NoSuchMethodE

Re: Question on MVJAR usage

> Thank you Steve. I have only one follow-up then. If the platform version is > *always* a major version, does that imply that minor versions will not add > API? No. Minor releases can add new JDK specific apis. We’ve chosen to support only major release for now, a known restriction. > The b

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

Brian and I exchanged email off-line. I will take ownership of this and grab the existing bugs Wed. Best Lance > On Jul 19, 2016, at 11:31 AM, Brian Burkhalter > wrote: > > On Jul 19, 2016, at 8:20 AM, Alexandre (Shura) Iline > wrote: > >>> On Jul 19, 2016, at 8:19 AM, Alan Bateman wrote:

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

I was originally assuming that different engineers would be responsible for providing descriptions for different modules … if to merge all that into one bug, a single person will either have to come up with everything himself/herself or go around and ask for all the description in the e-mail. S

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

OK, now I am confused :-) Earlier in the thread, it was raised that it would be more efficient to have 1 bug and 1 owner. Your reply seemed to agree to that, but now it looks like you are rethinking this? The module descriptions seemed to all be something similar to The {@code java.X

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

> On Jul 19, 2016, at 2:59 PM, Lance Andersen wrote: > > OK, now I am confused :-) > > Earlier in the thread, it was raised that it would be more efficient to have > 1 bug and 1 owner. Your reply seemed to agree to that, but now it looks like > you are rethinking this? > > The module descri

RFR 9 : 8161718 : Copyright/License updates to corba, jdk

Hi, Please review some spacing and punctuation changes that should be made to the copyright and license text in the corba and jdk repositories. No code changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8161718 Webrev: http://cr.openjdk.java.net/~bchristi/8161718/webrev.00/index.html

Re: RFR 9 : 8161718 : Copyright/License updates to corba, jdk

Hi Brent, Looks OK to me. Brian On Jul 19, 2016, at 4:26 PM, Brent Christian wrote: > Hi, > > Please review some spacing and punctuation changes that should be made to the > copyright and license text in the corba and jdk repositories. No code > changes. > > Bug: https://bugs.openjdk.ja

Re: RFR 9 : 8161718 : Copyright/License updates to corba, jdk

+1 Naoto On 7/19/16 4:45 PM, Brian Burkhalter wrote: Hi Brent, Looks OK to me. Brian On Jul 19, 2016, at 4:26 PM, Brent Christian wrote: Hi, Please review some spacing and punctuation changes that should be made to the copyright and license text in the corba and jdk repositories. No co

Re: RFR 9 : 8161718 : Copyright/License updates to corba, jdk

Thank you, Brian and Naoto! -Brent On 7/19/16 4:46 PM, Naoto Sato wrote: +1 Naoto On 7/19/16 4:45 PM, Brian Burkhalter wrote: Hi Brent, Looks OK to me. Brian On Jul 19, 2016, at 4:26 PM, Brent Christian wrote: Hi, Please review some spacing and punctuation changes that should be made

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

The ObjectInputFilter interface has only one method. Are we expecting more methods to be added later and maybe some people will only be interested in a new method? If yes, I suggest we provide a default implementation of the current method to return ALLOWED. --Max > On Jul 19, 2016, at 10:02 P