Re: RFR: 8176508 Update JAX-WS RI integration to latest version

> On Jun 1, 2017, at 10:29 PM, Roman Grigoriadi > wrote: > > >> On 1 Jun 2017, at 21:25, Mandy Chung > > wrote: >> >> >>> On May 31, 2017, at 5:06 AM, Roman Grigoriadi >> > wrote: >>> >>> Hi, >>> >>> New webrev can be found

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

> On 1 Jun 2017, at 21:25, Mandy Chung wrote: > > >> On May 31, 2017, at 5:06 AM, Roman Grigoriadi >> wrote: >> >> Hi, >> >> New webrev can be found here: >> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ >>

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

Igor On 2017/6/2 10:11, Igor Ignatyev wrote: Hi Felix, none of the jdk tests which fail w/ NCDFE: jdk/test/lib/process/StreamPumper depend on StreamPumper directly, they get this dependency transitively from jdk/test/lib/process/ProcessTools, That is why I think it is a bug too. so I don't

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

Hi Felix, none of the jdk tests which fail w/ NCDFE: jdk/test/lib/process/StreamPumper depend on StreamPumper directly, they get this dependency transitively from jdk/test/lib/process/ProcessTools, so I don't see how you will find this good definition of "explicit" even for the failures at hand

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

Hi Igor and Ioi, I partially agree with you. As initially stated in the proposal and bug(JDK-8181299 ), I don't think this patch is a fix but a quick workaround to make them runnable. "explicit" is reasonable for me. But "explicit" s

Re: asserts in jdk coding (outside hotspot)

Hi Thomas, On 1/06/2017 10:26 PM, Thomas Stüfe wrote: Hi David, On Thu, Jun 1, 2017 at 2:09 PM, David Holmes > wrote: Hi Thomas, On 1/06/2017 7:20 PM, Thomas Stüfe wrote: Hi all, so, we have the hotspot asserts with all the niceties o

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

> For example: doing this may be enough for now: > > * @build jdk.test.lib.process.* > > But what if in the future, jdk.test.lib.process is restructured to have a > private package jdk.test.lib.process.hidden? To work around > CODETOOLS-7901986, all the test cases that must be modified to t

Re: RFR 9+-: 8180582: The bind to rmiregistry is rejected by registryFilter even though registryFilter is set

Hi Roger, Ah, so your alternative to fixing up the regex is to avoid using regexes entirely! :-) Seriously, removing the regex is an improvement; it reduces a major source of fragility. The update looks fine. I did notice one typo: 82 * Data RMI Regiry bind test. No need for another

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

On 6/1/17 1:17 PM, Igor Ignatyev wrote: On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: Igor, On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: Hi Felix, I have suggested the exact opposite change[1-3] to fix the same problem. I’m sorry, but this is all just too confusing. After your chang

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

On 6/1/17 1:17 PM, Igor Ignatyev wrote: On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: Igor, On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: Hi Felix, I have suggested the exact opposite change[1-3] to fix the same problem. I’m sorry, but this is all just too confusing. After your chang

Re: RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9

> On 1 Jun 2017, at 14:55, Mandy Chung wrote: > > >> On Jun 1, 2017, at 8:56 AM, Paul Sandoz wrote: >> >> Hi, >> >> To make it easier on 166 and Graal code to support both 9 and 10 we should >> back port the renaming of the internal Unsafe.compareAndSwap to >> Unsafe.compareAndSet: >> >>

Re: RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9

> On Jun 1, 2017, at 8:56 AM, Paul Sandoz wrote: > > Hi, > > To make it easier on 166 and Graal code to support both 9 and 10 we should > back port the renaming of the internal Unsafe.compareAndSwap to > Unsafe.compareAndSet: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsaf

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

> On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: > > Igor, > >> On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: >> >> Hi Felix, >> >> I have suggested the exact opposite change[1-3] to fix the same problem. > > I’m sorry, but this is all just too confusing. After your change, who, or > wha

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

> On May 31, 2017, at 5:06 AM, Roman Grigoriadi > wrote: > > Hi, > > New webrev can be found here: > http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ > jaxp/src/java.xml/share/classes/module-info.java I’

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

> On Jun 1, 2017, at 2:18 PM, Roman Grigoriadi > wrote: > >> >> On 1 Jun 2017, at 20:08, Lance Andersen > > wrote: >> >> Hi Aleks, >> >> Its all good. I don’t suppose there is a webrev of the diffs from 01 to 02 >> (or an easy way to see what changed)? >

Re: RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9

Thank you, Paul, for backporting it. On 6/1/17 8:56 AM, Paul Sandoz wrote: Hi, To make it easier on 166 and Graal code to support both 9 and 10 we should back port the renaming of the internal Unsafe.compareAndSwap to Unsafe.compareAndSet: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

> On 1 Jun 2017, at 20:08, Lance Andersen wrote: > > Hi Aleks, > > Its all good. I don’t suppose there is a webrev of the diffs from 01 to 02 > (or an easy way to see what changed)? Unfortunately no list of changed files, just a description of changes in my last message. In addition to tho

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

Hi Aleks, Its all good. I don’t suppose there is a webrev of the diffs from 01 to 02 (or an easy way to see what changed)? Best Lance > On Jun 1, 2017, at 2:06 PM, Aleks Efimov wrote: > > I'm sorry Lance! I'm uploading new version of the webrev right now to the > same location :-) It should

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

I'm sorry Lance! I'm uploading new version of the webrev right now to the same location :-) It should be on-line soon =) Best, Aleksei On 06/01/2017 06:34 PM, Lance Andersen wrote: Hi Roman, The webrev seems to have gotten moved as I was reviewing it and now it is gone :-) On May 31, 2017,

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

Hi Roman, The webrev seems to have gotten moved as I was reviewing it and now it is gone :-) > On May 31, 2017, at 8:06 AM, Roman Grigoriadi > wrote: > > Hi, > > New webrev can be found here: > http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ >

RFR 8181292 Backport Rename internal Unsafe.compare methods from 10 to 9

Hi, To make it easier on 166 and Graal code to support both 9 and 10 we should back port the renaming of the internal Unsafe.compareAndSwap to Unsafe.compareAndSet: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8181292-unsafe-cas-rename-jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/J

Re: RFR: JDK-8176784 - Amend HREF to technote/guides in CORBA API docs to unilinks for guides

+1 On 6/1/2017 11:53 AM, Chris Hegarty wrote: On 31 May 2017, at 17:43, Mark Sheppard wrote: Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8176784-IV/webrev.02/ Looks good to me Mark. -Chris.

Re: RFR: JDK-8176784 - Amend HREF to technote/guides in CORBA API docs to unilinks for guides

> On 31 May 2017, at 17:43, Mark Sheppard wrote: > > Hi, > please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8176784-IV/webrev.02/ Looks good to me Mark. -Chris.

Re: asserts in jdk coding (outside hotspot)

Hi Roger, On Thu, Jun 1, 2017 at 3:06 PM, Roger Riggs wrote: > Hi, > > Is there a clean way for hotspot to export the assert mechanism so it can > be called from > the C based native JDK libraries? > > Thanks, Roger > > It would be no problem to export a C stub which calls the error handler. And

Re: asserts in jdk coding (outside hotspot)

Hi, Is there a clean way for hotspot to export the assert mechanism so it can be called from the C based native JDK libraries? Thanks, Roger On 6/1/2017 8:26 AM, Thomas Stüfe wrote: Hi David, On Thu, Jun 1, 2017 at 2:09 PM, David Holmes wrote: Hi Thomas, On 1/06/2017 7:20 PM, Thomas St

Re: JDK 10 RFR 8181417: Code cleanups in com.sun.jdi

Hi Christoph, l Copyright years need adjusting in a large number of files. Otherwise looks ok. ..Thomas On Thu, Jun 1, 2017 at 11:39 AM, Langer, Christoph wrote: > Hi, > > during integration work of the jdi library for one of our projects I > spotted some places where a few cleanups could be d

Re: asserts in jdk coding (outside hotspot)

Hi David, On Thu, Jun 1, 2017 at 2:09 PM, David Holmes wrote: > Hi Thomas, > > On 1/06/2017 7:20 PM, Thomas Stüfe wrote: > >> Hi all, >> >> so, we have the hotspot asserts with all the niceties of our error >> reporting. But these asserts are only accessible from within hotspot >> coding. >> >>

Re: asserts in jdk coding (outside hotspot)

Hi Thomas, On 1/06/2017 7:20 PM, Thomas Stüfe wrote: Hi all, so, we have the hotspot asserts with all the niceties of our error reporting. But these asserts are only accessible from within hotspot coding. In the JDK, in a number of places, I see that we use the standard posix assert()( http://

Re: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java

On 01/06/2017 11:22, Amy Lu wrote: java/nio/file/Files/walkFileTree/find.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181394 webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.00/ (I'll add @build jdk.test.lib.process.* if

JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java

java/nio/file/Files/walkFileTree/find.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181394 webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.00/ (I'll add @build jdk.test.lib.process.* if this is the "best" workaround of CO

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

Hi Chris, updated webrev: http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ -Felix On 2017/6/1 17:11, Chris Hegarty wrote: On 1 Jun 2017, at 04:27, Felix Yang wrote: Hi Chris and Daniel, new webrev with a few of explicit builds than wildcard. http://cr.openjdk.java.net/~xiaofeya

JDK 10 RFR 8181417: Code cleanups in com.sun.jdi

Hi, during integration work of the jdi library for one of our projects I spotted some places where a few cleanups could be done. I'd like to contribute this. It is mostly about import statements and formatting/empty lines. I think at this stage of JDK10 it's a good time for such kind of work.

asserts in jdk coding (outside hotspot)

Hi all, so, we have the hotspot asserts with all the niceties of our error reporting. But these asserts are only accessible from within hotspot coding. In the JDK, in a number of places, I see that we use the standard posix assert()( http://pubs.opengroup.org/onlinepubs/009695399/functions/assert

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

> On 1 Jun 2017, at 04:27, Felix Yang wrote: > > Hi Chris and Daniel, > >new webrev with a few of explicit builds than wildcard. > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ This seems very odd to me: http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/test/sun/security

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

Hi Felix, This looks much better to me. Thanks! -- daniel On 01/06/2017 04:27, Felix Yang wrote: Hi Chris and Daniel, new webrev with a few of explicit builds than wildcard. http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ Thanks, Felix On 2017/5/31 18:20, Chris Hegarty wrote:

RFR 8181080/10, Refactor several sun/net shell tests to plain java tests

Hi there, please review the patch convert several sun/net shell tests to plain java tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8181080 Webrev: http://cr.openjdk.java.net/~xiaofeya/8181080/webrev.00/ Thanks, Felix

(10) RFR of JDK-8180927: refactor ./java/io/Serializable/class/run.sh to java test

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8180927 webrev: http://cr.openjdk.java.net/~mli/8180927/webrev.00/ Thank you -Hamlin

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

Igor, > On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: > > Hi Felix, > > I have suggested the exact opposite change[1-3] to fix the same problem. I’m sorry, but this is all just too confusing. After your change, who, or what, is responsible for building/compiling the test library dependencies?

RFR 8181414/10, Refactor misc test/sun/net/www/protocol/jar shell tests to plain java tests

Hi there, please review the patch to convert several shell tests to plain java tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8181414 Webrev: http://cr.openjdk.java.net/~xiaofeya/8181414/webrev.00/ Thanks, Felix

RFR 8181413/10, Refactor test/sun/net/www/protocol/jar/jarbug/run.sh to plain java tests

Hi there, please review the patch to covert a shell test to a plain java test, and simplify a few of unnecessary test logic. Bug: https://bugs.openjdk.java.net/browse/JDK-8181413 Webrev: http://cr.openjdk.java.net/~xiaofeya/8181413/webrev.00/ Thanks, Felix