Re: Review request:Updated JDK-8004728 Implement core reflection API for parameter reflection

On 12/20/2012 01:04 AM, Zhong Yu wrote: On Wed, Dec 19, 2012 at 5:47 PM, Peter Levart wrote: 279 public Parameter[] getParameters() { 280 // TODO: This may eventually need to be guarded by security 281 // mechanisms similar to those in Field, Method, etc. 282

Re: Review request:Updated JDK-8004728 Implement core reflection API for parameter reflection

On 12/20/2012 06:33 AM, Eric McCorkle wrote: On 12/19/12 18:47, Peter Levart wrote: >Hi Eric, > >in Executable.java: > > 292 private Parameter[] privateGetParameters() { > 293 if (null != parameters) > 294 return parameters.get(); > > >If/when SoftReference is cleared,

Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

+res = readFully (fdin, &magic, sizeof(magic)); +if (res != 4 || magic != magicNumber()) { s/4/sizeof(magic)/ --- +extern int errno; Delete. --- +#define ALLOC(X,Y) { \ +void *mptr; \ +mptr = malloc (Y); \ +if (mptr == 0) { \ +error (fdout, ERR_MALLOC); \ +} \

Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

Thanks for this. I agree with the strategy. I'm hoping build folks and macosx folks also take a look at this hairy change. +LINKFLAG = +ifeq ($(ARCH_DATA_MODEL), 64) +LINKFLAG = -m64 +endif It looks wrong to be specifying toolchain-specific flags here. Also, -m64 is logically a compiler flag,

Re: RFR : CR8004015 : Add parent interfaces and default methods to basic functional interfaces

On Dec 16 2012, at 20:18 , David Holmes wrote: > On 15/12/2012 4:58 AM, Mike Duigou wrote: >> >> On Dec 13 2012, at 22:28 , David Holmes wrote: >> I have added @throws NPE for a number of the default methods. We won't be including @throws NPE in all cases where null is disallowed bec

Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

Hi folks, Thanks for the feedback so far. I've uploaded a new webrev to: http://cr.openjdk.java.net/~robm/5049299/webrev.02/ I've made the following headline changes: - Initial effort to get this stuff into the new build-infra. Hoping

RFR: 8005290: remove -showversion from RMI test library subprocess mechanism

Hi all, Please review the fix [1] for bug 8005290 [2]. [1] http://cr.openjdk.java.net/~smarks/reviews/8005290/webrev.0/ [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005290 I just filed this bug, so it hasn't made it to the public website yet. The salient text from the bug report is

Re: java.nio.*Buffer read/write atomicity

I'm with David on this one - since BB specifically says that it's not threadsafe I don't see why there would be any expectation of atomicity. Same goes for IntBuffer or LongBuffer. Vitaly Sent from my phone On Dec 19, 2012 6:23 PM, "Zhong Yu" wrote: > Users are unlikely to expect multi-byte ato

Re: Review request:Updated JDK-8004728 Implement core reflection API for parameter reflection

On Wed, Dec 19, 2012 at 5:47 PM, Peter Levart wrote: > 279 public Parameter[] getParameters() { > 280 // TODO: This may eventually need to be guarded by security > 281 // mechanisms similar to those in Field, Method, etc. > 282 Parameter[] raw = privateGetParameters

Re: Review request:Updated JDK-8004728 Implement core reflection API for parameter reflection

Hi Eric, in Executable.java: 292 private Parameter[] privateGetParameters() { 293 if (null != parameters) 294 return parameters.get(); If/when SoftReference is cleared,privateGetParameters will be returning null forever. Also Executable objects are already SoftRefe

Re: java.nio.*Buffer read/write atomicity

Users are unlikely to expect multi-byte atomicity on a ByteBuffer. However they are more likely to expect int-width atomicity on an IntBuffer view of a ByteBuffer; such atomicity is unfortunately not guaranteed either. Zhong Yu On Wed, Dec 19, 2012 at 11:48 AM, Aleksey Shipilev wrote: > Hi guys

Review request:Updated JDK-8004728 Implement core reflection API for parameter reflection

Hello, Please review the implementation of the core reflection API for method parameter reflection. This changeset introduces a new class, Parameter, which represents information about method parameters. It introduces a new method into Executable which returns an array of the parameters for the

Re: java.nio.*Buffer read/write atomicity

Aleksey, If multiple threads have to synchronize access to the buffer then the reads/writes do not need to be atomic. Atomicity is only needed when data races are allowed. David On 20/12/2012 3:48 AM, Aleksey Shipilev wrote: Hi guys, I wanted to cross-check what's the expected behavior of

hg: jdk8/tl/jdk: 8005097: Tie isSynthetic javadoc to the JLS

Changeset: 1f9c19741285 Author:darcy Date: 2012-12-19 11:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f9c19741285 8005097: Tie isSynthetic javadoc to the JLS Reviewed-by: mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor

Re: JDK 8 review request for 8005097 Tie isSynthetic javadoc to the JLS

Thank you for adding these links. They look fine. Mike On Dec 19 2012, at 11:19 , Joe Darcy wrote: > Hello, > > It has come to my attention recently that the various isSynthetic methods in > core reflection cite the Java Language Specification, but do not reference a > particular section. To

JDK 8 review request for 8005097 Tie isSynthetic javadoc to the JLS

Hello, It has come to my attention recently that the various isSynthetic methods in core reflection cite the Java Language Specification, but do not reference a particular section. To remedy this, I've prepared a small patch to add "@jls" tags which cite the section in question: http://

Re: java.nio.*Buffer read/write atomicity

On 19/12/2012 18:56, Aleksey Shipilev wrote: On 12/19/2012 10:45 PM, Alan Bateman wrote: On memory model rules then there is is an outstanding bug to update the buffer spec with at least minimal properties. Doug might remember the discussion with Dave Dice about this a few years ago. I've always

Re: java.nio.*Buffer read/write atomicity

On 12/19/2012 10:45 PM, Alan Bateman wrote: > On memory model rules then there is is an outstanding bug to update the > buffer spec with at least minimal properties. Doug might remember the > discussion with Dave Dice about this a few years ago. I've always meant > to do it but it never got to the

Re: RFR: javax.xml.transform: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

On 12/19/2012 6:34 AM, Daniel Fuchs wrote: Hi, Please find below an updated webrev for the javax.xml.transform package, taking into account Mandy's & Joe's comments - namely: 1. Fixed call to creationMethod.invoke. 2. Got rid of the 4 args FactoryFinder.newInstance method. 3. Got rid of the

Re: java.nio.*Buffer read/write atomicity

On 19/12/2012 17:48, Aleksey Shipilev wrote: Hi guys, I wanted to cross-check what's the expected behavior of Buffers with respect to atomicity? Don't confuse the atomic operations (a la j.u.c.atomic.*) and the read/write atomicity. Here's the concrete example, should the assert always be true?

Re: RFR: javax.xml.transform: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

On 12/19/2012 6:34 AM, Daniel Fuchs wrote: Thanks for the update and it looks much better. FactoryFinder L214-215: this will swallow the new TransformerFactoryConfigurationError thrown at L210. Maybe you can

Re: Review Request : Java exe doesn't process args ending Back slash

Hello Jayashree, a. you are referencing a bug which has already been fixed, is there a new one for this ? b. with regards to the fix, I don't quite understand the issue, could you please provide a use case ? c. your regression test does not seem to be accurate it behaves the same wi

java.nio.*Buffer read/write atomicity

Hi guys, I wanted to cross-check what's the expected behavior of Buffers with respect to atomicity? Don't confuse the atomic operations (a la j.u.c.atomic.*) and the read/write atomicity. Here's the concrete example, should the assert always be true? ByteBuffer buf = ByteBuffer.allocate(100);

Review Request : Java exe doesn't process args ending Back slash

Hi All, Java.exe doesn't seems to process arguments ending with back slashes well , in windows only . I have added test scenario and changeset in the below webrev . http://cr.openjdk.java.net/~jviswana/7188114/webrev.01/ This seems to be introduced after the bug fix for 7188114 has be made i

Re: Review request: 8003562: Provide a command-line tool to find static dependencies

On 18/12/2012 23:12, Mandy Chung wrote: : We can enhance the tool after the initial push. I'd like to get it in jdk8 soon so that developers can try it out and give feedback. Thanks for the update, I think it looks very good. I agree we should get this in so that people can try it out and send

hg: jdk8/tl/langtools: 8005098: Provide isSynthesized() information on Attribute.Compound

Changeset: f72c9c5aeaef Author:jfranck Date: 2012-12-16 11:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f72c9c5aeaef 8005098: Provide isSynthesized() information on Attribute.Compound Reviewed-by: jjg ! make/build.properties ! src/share/classes/com/sun/tools/javac

Re: RFR: javax.xml.transform: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

Hi, Please find below an updated webrev for the javax.xml.transform package, taking into account Mandy's & Joe's comments - namely: 1. Fixed call to creationMethod.invoke. 2. Got rid of the 4 args FactoryFinder.newInstance method. 3. Got rid of the useBSClsLoader which was always passed as 'fa

RFR 7175464 problems

I ran some of our j.u.c tck tests on lambda builds. Our tests included some for TreeMap because it was updated via jsr166 when NavigableMaps were introduced. I noticed a failure due to: 7175464 : entrySetView field is never updated in NavigableSubMap http://cr.openjdk.java.net/~mduigou/7175464/0/

Re: JDK 8 code review request for 8005042 Add Method.isDefault to core reflection

Hi Joe, Also, now studying the logic of Class.privateGetPublicMethods(), I don't quite get the reasoning behind current implementation regardless of default interface methods. The javadoc for Class.getMethods() is not very precise about what happens with multiple public methods with same sign

hg: jdk8/tl/langtools: 8004833: Integrate doclint support into javac

Changeset: 67b01d295cd2 Author:jjg Date: 2012-12-19 11:29 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/67b01d295cd2 8004833: Integrate doclint support into javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/s

Re: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

On 12/19/12 12:10 AM, Joe Wang wrote: It's different. If 'foo.bar' is specified but not found, it indicates a configuration error. If the factory falls back to an impl by the default factory id, it would serve to hide the error. Yes - I fully agree with that. Note that newInstance/newFactory w

Re: JDK 8 code review request for 8005042 Add Method.isDefault to core reflection

Hi Joe, I think that besides this bug, also the Class.privateGetPublicMethods() will need to be revised. Currently it suppresses any methods from direct interfaces that either: - have a non-abstract method with same signature in a superclass - have an abstract or non-abstract method with same

Re: JDK 8 code review request for 8005042 Add Method.isDefault to core reflection

On 12/19/2012 10:01 AM, Peter Levart wrote: On 12/19/2012 01:35 AM, David Holmes wrote: On 19/12/2012 10:24 AM, Joe Darcy wrote: On 12/18/2012 04:20 PM, David Holmes wrote: On 19/12/2012 10:16 AM, Joe Darcy wrote: On 12/18/2012 04:12 PM, David Holmes wrote: On 19/12/2012 8:40 AM, Louis Wasse

Re: JDK 8 code review request for 8005042 Add Method.isDefault to core reflection

On 12/19/2012 01:35 AM, David Holmes wrote: On 19/12/2012 10:24 AM, Joe Darcy wrote: On 12/18/2012 04:20 PM, David Holmes wrote: On 19/12/2012 10:16 AM, Joe Darcy wrote: On 12/18/2012 04:12 PM, David Holmes wrote: On 19/12/2012 8:40 AM, Louis Wasserman wrote: It's not 100% obvious to me whet

Re: RFR: [jdk7u-dev] - 8003898: X11 toolkit can be chosen as the default toolkit

On 17/12/2012 18:46, Rob McKenna wrote: Hi folks, This review contains: 8003898: X11 toolkit can be chosen as the default toolkit 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem Unfortunately th

Re: RFR: [jdk7u-dev] - 8003898: X11 toolkit can be chosen as the default toolkit

Looks good for me. On 17.12.2012 22:46, Rob McKenna wrote: Hi folks, This review contains: 8003898: X11 toolkit can be chosen as the default toolkit 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsyste