Re: RFR(s): 8171958: Several tests from java/time/test/java/time/format requiring jdk.localedata for execution

Hi Sergei, I could see you modified tests only in /test/java/time/*test*/java/time/format/ directory. Won't the tests from test/java/time/*tck*/java/time/format/ directory fail with same issue? Thanks and Regards, Nadeesh On 12/26/2016 8:27 PM, Sergei Kovalev wrote: Hello Team, Please

Re: jdk.internal.reflect.ReflectionFactory and SecurityManager

On 2016-12-27 02:02, David Holmes wrote: Hi Claes, On 27/12/2016 9:48 AM, Claes Redestad wrote: Hi, while perhaps an enhancement in isolation, I'll argue this to be a blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that At this stage I would categorise it as one possible

Re: jdk.internal.reflect.ReflectionFactory and SecurityManager

Hi Claes, On 27/12/2016 9:48 AM, Claes Redestad wrote: Hi, while perhaps an enhancement in isolation, I'll argue this to be a blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that At this stage I would categorise it as one possible way to work around the issue that JDK-8062389

Re: jdk.internal.reflect.ReflectionFactory and SecurityManager

Hi, while perhaps an enhancement in isolation, I'll argue this to be a blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that has been long in the making - thus I don't agree that the time for this has passed, and neither do I think this needs a critical approval request if it's

Re: jdk.internal.reflect.ReflectionFactory and SecurityManager

Hi Peter, I know this is response to the problems with your other recent change, but this is an enhancement in my opinion, not a bug fix, and the time for enhancements is passed - though there is still a process to request them. I do not like to see last minutes changes like this where not

Re: jdk.internal.reflect.ReflectionFactory and SecurityManager

On 2016-12-26 21:39, Peter Levart wrote: Hi Claes, On 12/26/2016 09:11 PM, Claes Redestad wrote: Hi, with strong encapsulation in place this seems perfectly fine to me. The only downside is that we will lose the extra reminder that the ReflectionFactory must not escape to untrusted code,

Re: jdk.internal.reflect.ReflectionFactory and SecurityManager

Hi Claes, On 12/26/2016 09:11 PM, Claes Redestad wrote: Hi, with strong encapsulation in place this seems perfectly fine to me. The only downside is that we will lose the extra reminder that the ReflectionFactory must not escape to untrusted code, but I think we can all help ensure that

Re: jdk.internal.reflect.ReflectionFactory and SecurityManager

Hi, with strong encapsulation in place this seems perfectly fine to me. The only downside is that we will lose the extra reminder that the ReflectionFactory must not escape to untrusted code, but I think we can all help ensure that doesn't happen, right? :-) Thanks! /Claes On 2016-12-26

jdk.internal.reflect.ReflectionFactory and SecurityManager

Hi, There are 2 ReflectionFactory classes in JDK 9. The old one is sun.reflect.ReflectionFactory which ended in jdk.unsupported module and to which access is restricted with SecurityManager. There is also new jdk.internal.reflect.ReflectionFactory which is used internally by JDK, is exported

Re: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k'

Hi Roger, Could you please push it for 9ea? If so, please find the attached changeset files. Regards Abhijit On 12/21/2016 7:53 PM, Roger Riggs wrote: Hi Abhijit, Looks fine to push with this additional change to make the descriptions of 'F' match. Thanks, Roger On 12/21/16 7:16 AM,

Re: RFR 8171988: backout of 8062389, 8029459, 8061950

Hi, I see there remaining failures are not trivial to fix in a hurry. So I think it's better to just backout this change and than prepare new fix... I'm pushing this backout now. Regards, Peter On 12/26/2016 06:55 PM, Claes Redestad wrote: Hi, many of the tier 1 failures listed seems to

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi, sorry for the delay! I updated Lucene's build system to use the JFrog snapshort artifacts and build succeeds with JDK 9 b148+: That's the one that was choosen by Apache Ant's Ivy downloader: groovy-all-2.4.8-20161220.101835-40.jar So we are waiting for a release! Uwe - Uwe Schindler

Re: RFR 8171988: backout of 8062389, 8029459, 8061950

Hi, many of the tier 1 failures listed seems to fail due to a cyclic bootstrap dependency on the new PublicMethods -> Policy.isSet() -> ... -> PublicMethods that appears in all tests which install a security manager. It turns out the dependency is only there (Policy.isSet) to ensure the VM has

Re: RFR 8171988: backout of 8062389, 8029459, 8061950

Hi, Just returned from a trip... So. No, there's no problem pushing this. But I can also just fix the real problem. If you give me a couple of minutes, I think I can diagnose what's going on... Regards, Peter On 12/26/2016 06:30 PM, Chris Hegarty wrote: On 26 Dec 2016, at 16:26, joe

Re: RFR 8171988: backout of 8062389, 8029459, 8061950

> On 26 Dec 2016, at 16:26, joe darcy wrote: > > Hello, > > Assuming we'll want to revisit this work at some point, there are some > advantages to anti-delta-ing the code changes now, but just problem listing > the tests in terms of making a less confusing history. My

Re: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks

Hi Igor, Thanks for the review! -- dima On 26.12.2016 18:42, Igor Ignatyev wrote: Hi Dima, the fix looks good to me, Cheers, — Igor On Dec 23, 2016, at 7:13 PM, Dmitry Fazunenenko wrote: Hi, new version:

Re: RFR 8171988: backout of 8062389, 8029459, 8061950

Hello, Assuming we'll want to revisit this work at some point, there are some advantages to anti-delta-ing the code changes now, but just problem listing the tests in terms of making a less confusing history. Thanks, -Joe On 12/26/2016 1:58 AM, Chris Hegarty wrote: On 26 Dec 2016, at

Re: RFR 8171988: backout of 8062389, 8029459, 8061950

Hi Peter, Chris and Jeff. First of: thx u for your expeditious work! ... (I know... quite a Christmas activity ... :) ). Guys, please assure to run the roll back thru JPRT so we get back to normal as clean as possible. Cheers, GGG On 12/26/16 11:05 AM, Jeff Dinkins wrote: Thanks

Re: RFR 8171988: backout of 8062389, 8029459, 8061950

Thanks Peter! Can you give us an ETA of when you think you’ll be able to put back? thanks, -jeff > On Dec 26, 2016, at 3:35 AM, Peter Levart wrote: > > Hi Jeff, > > I've been told that the latest change I pushed causes some tests to fail, so > I prepared a backout

Re: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks

On 26.12.2016 18:45, Andrey Nazarov wrote: On 26 Dec 2016, at 18:36, Dmitry Fazunenenko wrote: Hi Andrey, On 26.12.2016 17:53, Andrey Nazarov wrote: Hi, 2 minor comments. bug id has not been added “@bug 8171441” I believe the purpose of the @bug tag is to

Re: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks

> On 26 Dec 2016, at 18:36, Dmitry Fazunenenko > wrote: > > Hi Andrey, > > On 26.12.2016 17:53, Andrey Nazarov wrote: >> Hi, >> >> 2 minor comments. >> bug id has not been added “@bug 8171441” > I believe the purpose of the @bug tag is to list the issues the

Re: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks

Hi Dima, the fix looks good to me, Cheers, — Igor > On Dec 23, 2016, at 7:13 PM, Dmitry Fazunenenko > wrote: > > Hi, > > new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ > > This comment now looks like: > > 152 /* > 153 * Checks if

Re: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks

Thank you, Stanislav. -- Dima On 26.12.2016 17:40, Stanislav Smirnov wrote: Hi, thanks, looks good Best regards, Stanislav Smirnov On 23 Dec 2016, at 19:13, Dmitry Fazunenenko > wrote: Hi, new version:

Re: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks

Hi Andrey, On 26.12.2016 17:53, Andrey Nazarov wrote: Hi, 2 minor comments. bug id has not been added “@bug 8171441” I believe the purpose of the @bug tag is to list the issues the test verifies or the test is regression test for. And it's not need to mention all the problem with the test

RFR(s): 8171958: Several tests from java/time/test/java/time/format requiring jdk.localedata for execution

Hello Team, Please review below fix for tests. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958 Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/ Issue: some tests fails in case of module limitation by '--limit-module java.base' command line option. Root cause: The

Re: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks

Hi, 2 minor comments. bug id has not been added “@bug 8171441” javadoc should start with /** not 152 /* —Andrey > On 26 Dec 2016, at 17:40, Stanislav Smirnov > wrote: > > Hi, > > thanks, looks good > > Best regards, > Stanislav Smirnov > > > > > >> On

Re: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks

Hi, thanks, looks good Best regards, Stanislav Smirnov > On 23 Dec 2016, at 19:13, Dmitry Fazunenenko > wrote: > > Hi, > > new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ > > >

Re: Need info regarding Java Source Code

Hi Prakhar, Java is the name of the spec but if you look for the source of the OpenJDK, everything is here http://hg.openjdk.java.net/ How to download the source http://openjdk.java.net/install/index.html Remi On December 26, 2016 1:23:53 PM GMT+01:00, Prakhar Makhija

Need info regarding Java Source Code

Hi, Can anyone please tell me from where I can find and download/clone : 1) The source code of Java, of various releases. 2) The Java code of all JDK and it's various libraries. Looking forward to hear from you.

Re: RFR 8171988: backout of 8062389, 8029459, 8061950

> On 26 Dec 2016, at 09:35, Peter Levart wrote: > > Hi Jeff, > > I've been told that the latest change I pushed causes some tests to fail, so > I prepared a backout patch for 8062389, 8029459, 8061950: > >

RFR 8171988: backout of 8062389, 8029459, 8061950

Hi Jeff, I've been told that the latest change I pushed causes some tests to fail, so I prepared a backout patch for 8062389, 8029459, 8061950: http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ From the stacktrace of the bug report, it seems an early

RFR of JDK-8030175: java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due to timeout

Would you please review the below patches? bug: https://bugs.openjdk.java.net/browse/JDK-8030175 webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/ webrev (version B): http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ There are 2 versions