Re: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently

On 16/11/2012 06:34, Kurchi Subhra Hazra wrote: Updated webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev.01/ - Kurchi Looks fine (I didn't mean you to have to re-generate a second webrev). -Alan.

Re: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently

Looks good, Kurchi. Mandy On 11/15/2012 10:16 PM, Kurchi Subhra Hazra wrote: Hi, The tests in jdk/test/util/prefs are not good candidates to run concurrently, since on platforms such as Windows and Mac OS X, they currently read/write from the same location on the persistent storage. This

Re: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently

Updated webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev.01/ - Kurchi On 11/15/12 10:28 PM, Alan Bateman wrote: On 16/11/2012 06:16, Kurchi Subhra Hazra wrote: Hi, The tests in jdk/test/util/prefs are not good candidates to run concurrently, since on platforms such as Windows an

Re: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently

On 16/11/2012 06:16, Kurchi Subhra Hazra wrote: Hi, The tests in jdk/test/util/prefs are not good candidates to run concurrently, since on platforms such as Windows and Mac OS X, they currently read/write from the same location on the persistent storage. This fix simply informs jtreg[1] t

Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently

Hi, The tests in jdk/test/util/prefs are not good candidates to run concurrently, since on platforms such as Windows and Mac OS X, they currently read/write from the same location on the persistent storage. This fix simply informs jtreg[1] to not run these tests concurrently when using the co

Re: Review Request: 8001533: Java launcher must launch JavaFX applications

>>> L496-517 somewhat duplicates the logic added for FX in the >>> getMainClassFromJar method. Have you considered some refactoring >>> work you could do to simplify the fix since I think once you get >>> the classname of the entry point (either from a JAR or command-line >>> and with a

hg: jdk8/tl/jdk: 7199750: Loading sequence of service provider is changed

Changeset: 64a42798ea5e Author:naoto Date: 2012-11-15 20:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64a42798ea5e 7199750: Loading sequence of service provider is changed Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! t

Re: RFR: 8003471 - Add Add instrumentation facilities for Throwables

+2 Intrusive instrumentation just can't be the way to go. In addition though you need to be very careful about the impact on the initialization sequence of classes here. I suspect your instrumentation may be activated early during VM initialization where your instrumentation framework will not

Re: code review request: Test case for JDK-7198904 TreeMap.clone issue

Looks like a good test to me as well. The one possible addition is to check that m1 hasn't been modified after the mutation of m2. Mike On Nov 14 2012, at 05:38 , David Buck wrote: > Hi! > > This is a review request to add only the test case for the following > OracleJDK issue: > > [ 7198904

Re: Review Request: 8001533: Java launcher must launch JavaFX applications

On 11/15/2012 5:01 PM, David DeHaven wrote: L428-430: is this fallback needed? Would it be better if LauncherHelper.getApplicationClass() always returns a non-null class if the mainClass has been loaded successfully. Looks like this is the case in your implementation. Good poi

Re: Review Request: 8001533: Java launcher must launch JavaFX applications

On 11/15/2012 5:54 PM, Steve Sides wrote: FXLauncherTest.java - very good test that covers many test cases. Do you plan to add the classpath case (i.e. not from a jar file)? I hadn't, but if it's worthwhile then we could certainly add a test to do so. Thoughts on this Steve? I added it t

hg: jdk8/tl/jdk: 8003263: redundant cast build failure after 8003120

Changeset: 51c695958712 Author:weijun Date: 2012-11-16 10:34 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51c695958712 8003263: redundant cast build failure after 8003120 Reviewed-by: alanb ! src/share/classes/com/sun/naming/internal/ResourceManager.java

Re: Review Request: 8001533: Java launcher must launch JavaFX applications

FXLauncherTest.java - very good test that covers many test cases. Do you plan to add the classpath case (i.e. not from a jar file)? I hadn't, but if it's worthwhile then we could certainly add a test to do so. Thoughts on this Steve? I added it to the test plan to be implemented after in

Re: Review Request: 8001533: Java launcher must launch JavaFX applications

> java.c: L427 it would be helpful to add a comment to explain >the case where appClass is different than mainClass. >Probably the comment above L425 should be updated to >reflect the support for JavaFX Done. >L428-430: is this fallback needed? Would it be better >if Launch

Re: Review Request: 8001533: Java launcher must launch JavaFX applications

Hi David, On 11/14/12 9:43 AM, David DeHaven wrote: Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001533 Webrev: http://cr.openjdk.java.net/~ddehaven/8001533/webrev.0/ java.c: L427 it would be helpful to add a comment to explain the case where appClass is different than mainCla

Re: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String

Hi, This change is 6 months old now. I wonder if Oracle received any complaints from the users since then. I mean complaints that are based on real observations of performance degradation in real code - not only speculation. Regards, Peter 2012/11/15 Zhong Yu > Since this change is to achieve

hg: jdk8/tl/langtools: 8003257: refactor javadoc tool option handling

Changeset: 467f4f754368 Author:jjg Date: 2012-11-15 14:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/467f4f754368 8003257: refactor javadoc tool option handling Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/too

Re: RFR: 8003471 - Add Add instrumentation facilities for Throwables

On 11/15/2012 4:28 AM, Alan Bateman wrote: On 15/11/2012 12:19, Nils Loodin wrote: Webrev: http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 Nils - you can explain why the byte code instrumentation can't be used here?

hg: jdk8/tl/langtools: 8000800: javadoc uses static non-final fields

Changeset: bfec2a1cc869 Author:jjg Date: 2012-11-15 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bfec2a1cc869 8000800: javadoc uses static non-final fields Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWrite

Re: What happened to System/Process.getPid() ?

I've just done some bug cleanup here. I've altered the synopsis of 4244896 to: Provide Process.waitFor(timeout), Process.destroyForcibly() and Process.isAlive() and I've created: 8003488: (process) Provide Process.getPid() 8003490: (process) Provide System.getPid() For some reason Process b

Re: RFR: 8003380 - Compiler warnings in logging test code

Well -- yes and no. The problem is the way Loggers are handled -- as weak refs. They can get easily gc'd. Now in this code it doesn't really make much difference, but I'm trying to be consistent. That said, the right thing, now that I look at it again, would be to make the declarations of l

Re: RFR: 8003380 - Compiler warnings in logging test code

Jim, I'm not convinced that the use of "unused" is strictly necessary, but I'm not an Eclipse user. It looks like there is an easy way around this. For example, in new/test/java/util/logging/LoggingDeadlock3.java, rather than add @SuppressWarnings("unused"), will the follow keep the compiler

Re: RFR: 8003322: Add instrumentation points for tracing of I/O calls

I now have some micro-benchmark numbers on windows and linux (the solaris runs are not complete yet). While doing these runs we initially saw a regression on the file reading benchmarks. Investigation showed that the compiler was not able to inline the IoTrace.xxBegin() and IoTrace.xxEnd() metho

Re: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx]

On 15/11/2012 15:08, Alexey Utkin wrote: : Questions: 1] That have I do with tests marked as "Easy to fix, but it cuts off test coverage"? 2] Should I remove/move the manual tests and tests that essentially depends from AWT or Swing? It seems that the switch "-Djava.awt.headless=true" is use

Re: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx]

Alexey -- where's the webrev? This message just appeared in core-libs-dev, but I don't see the previous message(s) it appears to be a follow-up to. Thanks, Jim On 11/15/2012 10:08 AM, Alexey Utkin wrote: Let's move forward step by step and be very accurate. There are ~35 CoreLib tests with

Re: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx]

Let's move forward step by step and be very accurate. There are ~35 CoreLib tests with AWT/Swing. Here they are with short annotation (sub-question: is [closed/com/sun/jmx] a part of CoreLib? It is not in your list.): *closed/com/sun/jmx/snmp/B7159066.java : * test for AppContext - Useless in a

Re: What happened to System/Process.getPid() ?

I got a start on this back in September ( http://cr.openjdk.java.net/~jgish/pidstuff/ ), but as Alan indicated, it's not as easy as all this. I haven't gotten back to it, but it is on our radar. Thanks, Jim On 11/15/2012 07:26 AM, Martin Bu

Re: RFR: 8003471 - Add Add instrumentation facilities for Throwables

On Nov 15, 2012, at 1:28 PM, Alan Bateman wrote: > On 15/11/2012 12:19, Nils Loodin wrote: Webrev: http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 >>> Nils - you can explain why the byte code instrumentat

hg: jdk8/tl/jdk: 6244047: impossible to specify directories to logging FileHandler unless they exist

Changeset: ac22a52a732c Author:jgish Date: 2012-11-15 13:46 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac22a52a732c 6244047: impossible to specify directories to logging FileHandler unless they exist Reviewed-by: alanb ! src/share/classes/java/util/logging/FileHandler.j

Re: Code review request: 8003263: redundant cast build failure after 8003120

Ping again. If there is no more suggestion, I'll push my fix in the first webrev. Here I'm more concerned about the build failure than the behavior of the input streams. Thanks Max On 11/12/2012 06:22 PM, Weijun Wang wrote: In fact, it looks like the resources object here is of type InputS

Re: RFR: 8003471 - Add Add instrumentation facilities for Throwables

On 15/11/2012 12:19, Nils Loodin wrote: Webrev: http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 Nils - you can explain why the byte code instrumentation can't be used here? No real reason it couldn't, I just hadn't

Re: What happened to System/Process.getPid() ?

I was half-planning on implementing getPid back in 2008 but ran out of time. My intent was to have the pid simply be a String, even though on common platforms an int would suffice, leaving enough room for unusual implementations to get what they want. Essentially, return in String form what humans

Re: RFR: 8003471 - Add Add instrumentation facilities for Throwables

Webrev: http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 Nils - you can explain why the byte code instrumentation can't be used here? No real reason it couldn't, I just hadn't implemented it that way for simplicity's s

Re: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist

On 14/11/2012 21:54, Jim Gish wrote: On 11/14/2012 04:38 PM, Alan Bateman wrote: On 14/11/2012 20:56, Jim Gish wrote: Check out the latest, please -- http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/

Re: RFR: 8003471 - Add Add instrumentation facilities for Throwables

On 15/11/2012 10:52, Nils Loodin wrote: Hello all! Please review this change that would add facilities to help instrumentation of Throwables, to get a rough count of how many Exceptions and Errors an application has thrown during its lifetime. This can help developers and people working in c

Re: Request for Review : 7175464 : entrySetView field is never updated in NavigableSubMap

On Nov 15, 2012, at 11:58 AM, Alan Bateman wrote: > On 15/11/2012 05:28, Mike Duigou wrote: >> This bug appears to have been present as far back as Java 6 when >> NavigableSet was introduced. I could only check 6u33 but it seems unlikely >> to have been broken during the course of Java 6 maint

Re: RFR: 8003380 - Compiler warnings in logging test code

On 14/11/2012 22:44, Chris Hegarty wrote: - @SuppressWarnings("unused") Eclipse??? Do we have precedent for adding these suppressions?? I don't see it in the -Xlint options that javac supports so it might be specific to ECJ. I recall this topic came up during one of the warnings clean-up

Re: Request for Review : 7175464 : entrySetView field is never updated in NavigableSubMap

On 15/11/2012 05:28, Mike Duigou wrote: This bug appears to have been present as far back as Java 6 when NavigableSet was introduced. I could only check 6u33 but it seems unlikely to have been broken during the course of Java 6 maintenance releases. As these are views which pass through mutati

RFR: 8003471 - Add Add instrumentation facilities for Throwables

Hello all! Please review this change that would add facilities to help instrumentation of Throwables, to get a rough count of how many Exceptions and Errors an application has thrown during its lifetime. This can help developers and people working in customer-related support roles to do a hi

Re: RFR: 8003322: Add instrumentation points for tracing of I/O calls

Hi Rémi, Thanks for your suggestions, they made the code much simpler - and more correct! /Staffan On 15 nov 2012, at 09:04, Remi Forax wrote: > Hi Staffan, > in IOTraceAgent, > ASM provides a method named Type.getOpcode(baseOpcode) that allows you > to emit load/store or return depending on t

Re: What happened to System/Process.getPid() ?

On 15/11/2012 01:11, Rob McKenna wrote: Hi Thomas, Don't ask me why, but for some reason this mail just landed in my client now. (this happens a lot on this mailing list for some reason) getPid() is still on the todo list at the moment. Once I clear my plate a little I'll follow up on it.

Re: RFR: 8003322: Add instrumentation points for tracing of I/O calls

Hi Staffan, in IOTraceAgent, ASM provides a method named Type.getOpcode(baseOpcode) that allows you to emit load/store or return depending on the type (type specialized opcode like ILOAD, ALOAD, etc are in the same order). // by example for load mv.visitVarInsn(type.getOpcode(ILOAD), slot); // a