Re: RFR(s): 8044626 & 8165649 RMI spec changes for modularization

> On Jan 31, 2017, at 4:22 PM, Stuart Marks wrote: > > diff -r 0e0e0fbc5bf3 -r b84c67d49349 > src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java > --- > a/src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java > Fri Jan 13

Re: RFR: 8173607: JMX RMI connector should be in its own module

> On Jan 31, 2017, at 10:26 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a patch for: > > 8173607: JMX RMI connector should be in its own module > https://bugs.openjdk.java.net/browse/JDK-8173607 > > webrev: >

Re: RFR: 8171524: jar --help doesn't provide information that stdout and stdin can be used as output and input for tool

Looks good. On Feb 1, 2017, at 7:40 AM, Henry Jen wrote: Hi, Please review a trivial fix[1] for JDK-8171524. The fix added a short paragraph about @argfile. Clarify stdin or stdout is used if ―file is omitted. It also correct that -h, not -? is for the short option for

Re: RFR: jsr166 jdk9 integration wave 14

On Tue, Jan 31, 2017 at 4:30 PM, Paul Sandoz wrote: > > On 31 Jan 2017, at 16:16, Martin Buchholz wrote: > > > > On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz > wrote: > >> >>> ConcurrentSkipListSet >>> — >>> >>> 76 * Bulk

Re: RFR: jsr166 jdk9 integration wave 14

> On 31 Jan 2017, at 16:16, Martin Buchholz wrote: > > > > On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz > wrote: >> >> ConcurrentSkipListSet >> — >> >> 76 * Bulk operations that add, remove, or examine

RFR(s): 8044626 & 8165649 RMI spec changes for modularization

Hi all, Please review these small spec changes that adjust RMI specifications for the modular environment in Java 9. RMI does some reflection to handle stubs and to activate objects. The changes specify what kind of accessibility (package exports/opens, and class/method/constructor

Re: RFR: jsr166 jdk9 integration wave 14

On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz wrote: > >> ConcurrentSkipListSet >> — >> >> 76 * Bulk operations that add, remove, or examine multiple elements, >> 77 * such as {@link #addAll}, {@link #removeIf} or {@link #forEach}, >> 78 * are not guaranteed to be

Re: RFR: jsr166 jdk9 integration wave 14

> On 31 Jan 2017, at 14:55, Martin Buchholz wrote: > > > > On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz > wrote: > > 1057 static final VarHandle ITEM; > 1058 static final VarHandle NEXT; > > Suggest a

RFR: 8171524: jar --help doesn't provide information that stdout and stdin can be used as output and input for tool

Hi, Please review a trivial fix[1] for JDK-8171524. The fix added a short paragraph about @argfile. Clarify stdin or stdout is used if —file is omitted. It also correct that -h, not -? is for the short option for —help. Cheers, Henry [1]

Re: RFR: 8172309: classpath wildcards code does not support --class-path

Can we have tests in sets of threes, checking -cp, -classpath, --class-path (and perhaps also CLASSPATH environment) --- a/test/tools/launcher/ClassPathWildCard.sh +++ b/test/tools/launcher/ClassPathWildCard.sh @@ -125,7 +125,7 @@ CheckFail TestA rm -f TestB${OUTEXT} - $JAVA${variant}

Re: RFR: 8172309: classpath wildcards code does not support --class-path

I would try to avoid having the wildcard code know about the various ways of specifying classpath. We now have 3 different classpath flags - can they be canonicalized into one form before wildcard handling? On Wed, Jan 25, 2017 at 1:23 PM, Henry Jen wrote: > Hi, > >

Re: RFR: jsr166 jdk9 integration wave 14

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz wrote: > > 1057 static final VarHandle ITEM; > 1058 static final VarHandle NEXT; > > Suggest a comment as to why they are package private, due to access via a > nested class. (Same in LinkedTransferQueue). > > package

Re: RFR: jsr166 jdk9 integration wave 14

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz wrote: > > — > > 131 static void spinAwait(Supplier waitingForGodot) { > 132 for (int spins = 0;;) { > 133 if (waitingForGodot.get()) > 134 return; > > > :-) "Let's wait till we know

Re: RFR: jsr166 jdk9 integration wave 14

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz wrote: > > ConcurrentLinkedDeque > — > > 1427 if ((e = p.item) != null) > 1428 ((a != null) ? a : (a = new Object[n]))[i++] = e; > > This is awfully hard to read. Is it really worth it to

Re: RFR: 8172309: classpath wildcards code does not support --class-path

OK -- Jon On 01/27/2017 01:12 PM, Henry Jen wrote: How about following patch instead for langtools repo? diff -r ef142ac9824e test/tools/javac/Paths/wcMineField.sh --- a/test/tools/javac/Paths/wcMineField.sh Thu Jan 26 16:53:56 2017 -0800 +++ b/test/tools/javac/Paths/wcMineField.sh

Re: RFR: jsr166 jdk9 integration wave 14

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz wrote: > ForkJoinPool > — > > These changes will require a feature extension request and CCC. > > Why does the default worker thread construction require the permission > “getClassLoader” but the innocuous worker thread

Re: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work with multi-version jar

Hi Andrey, The test looks reasonable. Assuming Alan has blessed the location and we have run these on all platforms via JPRT, you should be good to go. Best Lance > On Jan 31, 2017, at 8:05 AM, Andrey Nazarov > wrote: > > Hi, > > Anyone please review and

Re: RFR: jsr166 jdk9 integration wave 14

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz wrote: > > — > > 690 Callable task = new > CheckedCallable() { > > 756 Callable task = new > CheckedCallable() { > > > Diamond on the RHS. > Diamond compiles with jdk9 but fails with jdk8,

Re: [9] RFR: 8173423: Wrong display name for supplemental Japanese era

+1 On Jan 31, 2017, at 5:27 AM, Naoto Sato wrote: Hello, Please review the fix to the following bug: https://bugs.openjdk.java.net/browse/JDK-8173423 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8173423/webrev.00/ There is a functionality in

Re: RFR: jsr166 jdk9 integration wave 14

ForkJoinPool — These changes will require a feature extension request and CCC. Why does the default worker thread construction require the permission “getClassLoader” but the innocuous worker thread construction does not? Both result in a call to getSystemLoader. Unless there is some

Re: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect (updated)

Thanks Brent, looks good! Coleen On 1/31/17 1:19 PM, Brent Christian wrote: On 1/30/17 5:52 PM, Coleen Phillimore wrote: in http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html 287 int mode = 0; 288 if

RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi Joe, evenutally I have updated my webrev for this issue: http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/ I've implemented your suggestion to add a property "jdk.xml.generatePrefix" which is true by default. I also added a testcase which tests the correct behavior with

Re: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect (updated)

> On Jan 27, 2017, at 8:26 AM, Mandy Chung wrote: > > >> On Jan 26, 2017, at 5:07 PM, Brent Christian >> wrote: >> >> Hi, >> >> Please review my updated approach for fixing 8156073 ("2-slot >> LiveStackFrame locals (long and double) are

RFR: 8173607: JMX RMI connector should be in its own module

Hi, Please find below a patch for: 8173607: JMX RMI connector should be in its own module https://bugs.openjdk.java.net/browse/JDK-8173607 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 This patch makes it possible to remove the requires transitive java.rmi from the

Re: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect (updated)

On 1/30/17 5:52 PM, Coleen Phillimore wrote: in http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html 287 int mode = 0; 288 if (_jvf->is_interpreted_frame()) { mode |= MODE_INTERPRETED; } 289 if (_jvf->is_compiled_frame()){ mode

Re: RFR: jsr166 jdk9 integration wave 14

Thanks! Well spotted! On Tue, Jan 31, 2017 at 9:08 AM, Stefan Zobel wrote: > Hi Martin, > > minor thing in CopyOnWriteArrayListTest.java, line 57 > > > 55 public static Test suite() { > 56 class Implementation implements CollectionImplementation { > 57

Re: RFR: jsr166 jdk9 integration wave 14

Hi Martin, minor thing in CopyOnWriteArrayListTest.java, line 57 55 public static Test suite() { 56 class Implementation implements CollectionImplementation { 57 public Class klazz() { return ArrayList.class; } Shouldn't this be CopyOnWriteArrayList.class? Regards, Stefan

RFR: jsr166 jdk9 integration wave 14

Another too-big too-scary wave for this phase of jdk9, but I still think it should go in. Or we can put into jdk10 first, then down-integrate into jdk9 (when??). http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ --- concurrent-collections has spliterator bug fixes

Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

Approved, please make sure you have run all the jprt -testset pit tests. Kumar On 1/30/2017 5:05 AM, Alan Bateman wrote: On 30/01/2017 12:11, Ramanand Patil wrote: Thank you Alan. I have eliminated the inner catch block for LinkageError. Here is the updated webrev:

Re: RFR: 8029019: (ann) Optimize annotation handling in core reflection

Hi Peter, On 01/25/2017 08:01 PM, Peter Levart wrote: Hi Claes, On 01/24/2017 03:34 PM, Claes Redestad wrote: Hi Peter, thanks for the thorough examination of this issue. Thanks for looking into this change... After going through the patch I do like what I see, but I have a few

Re: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work with multi-version jar

Hi, Anyone please review and approve —Andrey > On 26 Jan 2017, at 21:29, Andrey Nazarov wrote: > > Hi > Move tests to new place. Please review. > http://cr.openjdk.java.net/~anazarov/8075617/webrev.01/webrev/ >

Updated Webrev: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring

Hi, I made a small update to the webrev (in place). I externalized class TransformerTestTemplate now to be able to use it in other tests besides TransformerTest.java. Best regards Christoph From: Langer, Christoph Sent: Montag, 30. Januar 2017 15:28 To: core-libs-dev@openjdk.java.net Subject: