Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

On 30.09.2015 18:08, Miroslav Kos wrote: On 30/09/15 16:20, Deva Sagar wrote: Hi Georgiy, I think both Miran and I are referring to the mention of SAAJMetaFactory in the bullet list about the public newInstance() method. The Javadoc of the SAAJMetaFactory class still describes it as an

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

Hello Martin, Stuart, Thank you for the notes, Yes, the initial utility is quite ugly, I just tried to prepare it as quickly as possible hoping that it covers the majority of "trivial" replace cases. Yes, it does not process multi-line inclusions. > s = s.replace( "", tag1); > s =

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> 在 2015年10月1日，下午7:36，Sean Mullan 写道： > > > > On 10/1/15 5:10 AM, Wang Weijun wrote: >> >>> 在 2015年10月1日，上午7:53，Steve Drach 写道： >>> >>> - JDK 8 jar signer does not work with a JDK 9 created keystore >>> - JDK 8 signed jar with JDK 8 created

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

+1 for manageable sized and per repo code-reviews. (unless someone has a tool that checks the patch to confirm that the only difference between the old and the new is the same small number of substitutions; another quick program perhaps...). On 10/1/2015 8:40 AM, Lance Andersen wrote: Hi

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/1/15 5:10 AM, Wang Weijun wrote: 在 2015年10月1日，上午7:53，Steve Drach 写道： - JDK 8 jar signer does not work with a JDK 9 created keystore - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore - JDK 8 signed jar

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

Hi Alexander, Personally, I would find it easier to review if the changes were sent out by category/module vs one large patch as it is easier to miss things. Also for technologies such as jaxws, these will need to go to the external workspace at the same time for the technology so these should

RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Please review a proposal for public Cleaner API: A Cleaner is proposed to provide an easy to use alternative to finalization. The service would provide easy registration and cancellation of cleanup functions for objects. Applications create a cleanup service for their own use and the service

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

Hello Lance, Yes, to be honest, I also fear to push at once a single changeset for jdk touching thousands of files. Moreover, I'm pretty sure that e.g. java.desktop part should go to a client repository instead of dev, changes for client and security libs should be approved by corresponding

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

Hi, there is a new version of specdiff: http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/index.html To remind, there were two problems to be addressed, both related to SAAJMetaFactory: http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/javax/xml/soap/SAAJMetaFactory.html 1) hidden

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Moh, On 10/1/2015 10:28 AM, Rezaei, Mohammad A. wrote: The proposed API makes good sense for what I would consider coarse grained cleanup. There is another significant use case for Weak/Soft references that is not covered here: weak/soft references used in cache like data structures, e.g.

RE: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

The proposed API makes good sense for what I would consider coarse grained cleanup. There is another significant use case for Weak/Soft references that is not covered here: weak/soft references used in cache like data structures, e.g. WeakHashMap. Wouldn't there be significant code reuse if

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

I think this is a great idea. In addition to the NetBeans precedent cited in the Issue, I'll note that Guava has FinalizableReferenceQueue. Like the NetBeans solution, that has proved tricky to make collectable in a context where its ClassLoader might become otherwise unreferenced. Having the

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

Hi Miran, My personal opinion is to prefer the more defensive approach instead of introducing a new abstract method, even though it would be more consistent with other factories to add the new abstract method. The spec doesn’t require _all_ factories to delegate to SAAJMetaFactory as I

Re: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific

On 01/10/2015 16:31, Zoltán Majó wrote: Hi, please review the patch for JDK-8137173. https://bugs.openjdk.java.net/browse/JDK-8137173 Problem: Mark Rheinhold filed this bug and suggested the following: "The doc comment for the @jdk.internal.HotSpotIntrinsicCandidate annotation says that

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Eamonn, Thanks for the comments and correction, the intention was to describe the behavior consistently. (I updated the webrev in place with the editorial changes). Thanks, Roger On 10/1/2015 11:11 AM, Eamonn McManus wrote: I think this is a great idea. In addition to the NetBeans

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 29/09/2015 21:46, Steve Drach wrote: Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238:

[9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific

Hi, please review the patch for JDK-8137173. https://bugs.openjdk.java.net/browse/JDK-8137173 Problem: Mark Rheinhold filed this bug and suggested the following: "The doc comment for the @jdk.internal.HotSpotIntrinsicCandidate annotation says that it is "specific to the Oracle Java HotSpot

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>>> - JDK 8 jar signer does not work with a JDK 9 created keystore >>> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK >>> 9 signed jar with JDK 9 keystore >>> - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK >>> 9 signed jar with the same JDK

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Please review the following webrev that adds support for multi-release jars as specified in JEP-238. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734

Re: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific

2015/10/1 8:41 -0700, alan.bate...@oracle.com: > On 01/10/2015 16:31, Zoltán Majó wrote: >> please review the patch for JDK-8137173. >> >> https://bugs.openjdk.java.net/browse/JDK-8137173 >> >> ... >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ >> > This looks okay. Is it

Re: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific

P.S.: On 10/01/2015 05:31 PM, Zoltán Majó wrote: Problem: Mark Rheinhold filed this bug and suggested the following: I ment Mark Reinhold (w/o the 'h'). Sorry for the mistake. Best regards, Zoltan "The doc comment for the @jdk.internal.HotSpotIntrinsicCandidate annotation says that it

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

Nice try Martin, but I'm not going to get sucked into a round of perl code golf with you. :-) I wasn't sure why the absolute path stuff was in there; I just carried it over from Alexander's code. I'll let Alexander fix this along with your point about handling multiple files, if he wants to.

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 01/10/2015 18:07, Steve Drach wrote: Yes, the JEP issue has several subtasks. This one, 8132734, is just for java.util.jar.JarFile. There will be a separate webrev for jar tool and another one for enhancements to ZipFileSystem. And then there are several more pieces to the puzzle such

Re: JEP 269: Convenience Factory Methods for Collections

On 9/29/15 11:32 PM, Stephen Colebourne wrote: In my view, the proposal is pretty good. I too use Guava's immutable classes as types, because of the extra value obtained. But that does not mean these methods should not be in the JDK. (Not every project uses Guava). Hi Stephen, Thanks for

Re: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs

Hi s'marks, You probably don't need to absolutify paths. And you can easily handle multiple args. (just for fun!) Checks for javadoc comment; handles popular html entities; handles multiple lines; handles both tt and code: #!/bin/bash find "$@" -name '*.java' | \ xargs -r perl -p0777i -e \

RFR (JAXP) 8138721 : ElementTraversal: javadoc warning; also, hasFeature shall return true

Hi, Thanks Lance and Daniel for pointing out the javadoc warning! Here's the fix. Also, added ElementTraversal to the DOMImplementation supported feature list. JBS: https://bugs.openjdk.java.net/browse/JDK-8138721 http://cr.openjdk.java.net/~joehw/jdk9/8138721/webrev/ Thanks, Joe

Optional used as method argument?

I hear people saying Optional is usually used as return values. Can I use it as an argument, like this? void consume(Optional value) This way, I don't need to add spec like "@param value can be null if there is no such value". Thanks Max

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> 在 2015年10月2日，上午12:15，Steve Drach 写道： > > I think I’m getting distracted here, not focusing on getting tests created. > Is it okay to move on? Please move on. If you think anything is strange, just send me all related files. One last request about the SSLException,

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> I think I’m getting distracted here, not focusing on getting tests created. >> Is it okay to move on? > > Please move on. If you think anything is strange, just send me all related > files. > > One last request about the SSLException, can you still generate the full > debug output for jar

Re: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific

Hi Alan, Hi Mark, On 10/01/2015 05:54 PM, mark.reinh...@oracle.com wrote: 2015/10/1 8:41 -0700, alan.bate...@oracle.com: On 01/10/2015 16:31, Zoltán Majó wrote: please review the patch for JDK-8137173. https://bugs.openjdk.java.net/browse/JDK-8137173 ... Webrev:

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

On 30/09/15 17:31, Miroslav Kos wrote: On 30/09/15 16:50, Georgiy Rakov wrote: 2. This is not related to ServiceLoader feature, but anyway - SAAJMetaFactory.java: 30 * SAAJ API./_*All *_//_*of the {@code newInstance} methods defined on factories*_/ in 31 * SAAJ 1.3 defer to

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> 在 2015年10月1日，上午7:53，Steve Drach 写道： > > - JDK 8 jar signer does not work with a JDK 9 created keystore > - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 > signed jar with JDK 9 keystore > - JDK 8 signed jar with JDK 8 created keystore is