Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

I was thinking about the same. But a CCC request is needed for such a change in public API. It can be done separately if any other API changes are necessary. Thanks, Serguei On 8/23/12 6:27 PM, David Holmes wrote: Hi Mandy, While I understand what you are doing and that it "works" it is far

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

Hi Dan, On 24/08/2012 7:46 AM, Dan Xu wrote: Please review the fix of CR 7193406 at http://cr.openjdk.java.net/~dxu/7193406/webrev/. It cleans up warnings in the following java files. src/share/classes/java/io/FilePermission.java I'm surprised that you need this: 426 @SuppressWarnings(

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

On 8/23/12 5:12 PM, Andrew Hughes wrote: Dan Xu wrote: Please review the fix of CR 7193406 at http://cr.openjdk.java.net/~dxu/7193406/webrev/. And it enables fatal warning flag in the following make file. make/java/jar/Makefile Please don't do this, at least not unconditionally. Right,

Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

Hi Mandy, While I understand what you are doing and that it "works" it is far from obvious upon code inspection that where you replace null with Foo.class.getClassLoader(), that the result would always be null. Another way to simplify this would be to add a new overload of Class.forName():

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

- Original Message - > > > - Original Message - > > Please review the fix of CR 7193406 at > > http://cr.openjdk.java.net/~dxu/7193406/webrev/. > > > > snip... > > > And it enables fatal warning flag in the following make file. > > > > make/java/jar/Makefile > > > > Pl

Re: rmi network traffic

Hi fuyou001, if you're using RMI in a J2SE project and it is OK, but it isn't when you use the web project, then I suggest you look at the Jetty/Resin implementation as it may be the culprit. Specifically, I'd look at the ClassLoader in use. See this URL (http://java.sun.com/javase/6/doc

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

- Original Message - > Please review the fix of CR 7193406 at > http://cr.openjdk.java.net/~dxu/7193406/webrev/. > snip... > And it enables fatal warning flag in the following make file. > > make/java/jar/Makefile > Please don't do this, at least not unconditionally. At the ver

Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

On 8/23/2012 2:26 PM, Dmitry Samersoff wrote: Mandy, 1. You replace null with getClassLoader() calls in couple of places. getClassLoader requires special permissions - RuntimePermission("getClassLoader") so probably you need to use doPrivileget() there. No, the caller's class load

Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

Looks good. Thanks, Serguei On 8/23/12 12:33 PM, Mandy Chung wrote: On 8/23/2012 11:58 AM, Alan Bateman wrote: On 23/08/2012 18:43, Mandy Chung wrote: This change is to bring the jdk modularization changes from jigsaw repo [1] to jdk8. This allows the jdk modularization changes to be expos

Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

Please review the fix of CR 7193406 at http://cr.openjdk.java.net/~dxu/7193406/webrev/. It cleans up warnings in the following java files. src/share/classes/java/io/FilePermission.java src/share/classes/java/util/ArrayDeque.java src/share/classes/java/util/Arrays.java src/share/clas

Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

Mandy, 1. You replace null with getClassLoader() calls in couple of places. getClassLoader requires special permissions - RuntimePermission("getClassLoader") so probably you need to use doPrivileget() there. Did you test your changes with SecurityManager/No permissions for the tes

Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

On 23/08/2012 20:33, Mandy Chung wrote: : Done. This is a good cleanup I considered to do too but missed in the previous webrev. http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ Thanks for the review. Mandy That looks much better, so looks good to me. -Alan

Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

On 8/23/2012 12:48 PM, serguei.spit...@oracle.com wrote: Mandy, It looks good. Thanks. Just a question below. || *src/share/classes/java/lang/management/ManagementFactory.java* 596 String intfName = mxbeanInterface.getName(); 599 " is not an instance of " + m

Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

Mandy, It looks good. Just a question below. || *src/share/classes/java/lang/management/ManagementFactory.java* 596 String intfName = mxbeanInterface.getName(); 599 " is not an instance of " + mxbeanInterface); Did you want this?: 596 String intfName

Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

On 8/23/2012 11:58 AM, Alan Bateman wrote: On 23/08/2012 18:43, Mandy Chung wrote: This change is to bring the jdk modularization changes from jigsaw repo [1] to jdk8. This allows the jdk modularization changes to be exposed for testing as early as possible and minimize the amount of changes c

Re: Review Request: 7193339 Prepare system classes be defined by a non-null module loader

On 23/08/2012 18:43, Mandy Chung wrote: This change is to bring the jdk modularization changes from jigsaw repo [1] to jdk8. This allows the jdk modularization changes to be exposed for testing as early as possible and minimize the amount of changes carried in the jigsaw repo that helps sync up

Review Request: 7193339 Prepare system classes be defined by a non-null module loader

This change is to bring the jdk modularization changes from jigsaw repo [1] to jdk8. This allows the jdk modularization changes to be exposed for testing as early as possible and minimize the amount of changes carried in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. Webrev at: http

Re: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String

Hopefully some day we would have fixed: Bug 6373386 - Method chaining for instance methods that return void That would prevent us from such bloated sub classes. Hopefully such "workarounds" would not force later incompatibilities -U

hg: jdk8/tl/jdk: 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx]

Changeset: de5a85353f4d Author:alanb Date: 2012-08-23 13:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de5a85353f4d 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] Reviewed-by: alanb Contributed-by: Jason T Gree

Re: Improve registering signal handlers in java.lang.Terminator.setup()

On 23/08/2012 6:37 PM, Frank Ding wrote: Hi David, Sorry that Jonathan has already committed the code with bug id 7193463. Could you please dup the 2 bugs? Alan has already taken care of it. David Best regards, Frank On 8/23/2012 4:27 PM, David Holmes wrote: On 23/08/2012 6:05 PM, Frank Di

Re: Improve registering signal handlers in java.lang.Terminator.setup()

Hi David, Sorry that Jonathan has already committed the code with bug id 7193463. Could you please dup the 2 bugs? Best regards, Frank On 8/23/2012 4:27 PM, David Holmes wrote: On 23/08/2012 6:05 PM, Frank Ding wrote: Thanks all. I created sun bug 7193463 to track the code change. We al

hg: jdk8/tl/jdk: 7193463: Improve registering signal handlers in java.lang.Terminator.setup()

Changeset: e7b53fe85540 Author:dingxmin Date: 2012-08-23 16:28 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7b53fe85540 7193463: Improve registering signal handlers in java.lang.Terminator.setup() Reviewed-by: dholmes, alanb ! src/solaris/classes/java/lang/Terminator.java

Re: Improve registering signal handlers in java.lang.Terminator.setup()

On 23/08/2012 6:05 PM, Frank Ding wrote: Thanks all. I created sun bug 7193463 to track the code change. We already have 7189865 for this. David Best regards, Frank On 8/22/2012 10:13 AM, David Holmes wrote: On 22/08/2012 12:11 PM, Frank Ding wrote: Hi Alan and David, So is it OK to commi

Re: Improve registering signal handlers in java.lang.Terminator.setup()

Thanks all. I created sun bug 7193463 to track the code change. Best regards, Frank On 8/22/2012 10:13 AM, David Holmes wrote: On 22/08/2012 12:11 PM, Frank Ding wrote: Hi Alan and David, So is it OK to commit the patch in Terminator class? I think Neil will continue proposing the change in c