hg: jdk8/tl/langtools: 8024398: javac, compiler crashes with try with empty body
Changeset: 2de3750d65a5 Author:vromero Date: 2013-09-08 11:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2de3750d65a5 8024398: javac, compiler crashes with try with empty body Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T8024398/NPETryTest.java
Re: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
Kumar - the makefile changes look good to me. Tim On 09/ 7/13 03:50 AM, Staffan Larsen wrote: This is a welcome change. I've looked at the serviceability test and the changes look good except: test/demo/jvmti/DemoRun.java test/sun/tools/jhat/HatRun.java - Looks like there are still some -d64 remnants that I wasn't expecting. Thanks, /Staffan On 6 sep 2013, at 22:17, Kumar Srinivasan kumar.x.sriniva...@oracle.com wrote: On 9/6/2013 12:21 PM, Alan Bateman wrote: On 06/09/2013 17:47, Kumar Srinivasan wrote: Hello, Please review the changes to remove Solaris 32-bit binaries from JDK8 distros, at this time the dual mode support in the launcher is being disabled. Message regarding this: http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html The jdk changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ The top forest changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ I haven't studied the changes yet but I see you've updated test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh. I don't think you need the changes at L42-48, instead you can just hg rm the 32-bit libraries that are in test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib. Will do, I was wondering about those libraries. You might want to bring the changes to serviceability-dev because of the change to the JDI launching connector and the JDI tests. cc'ed. Thanks Kumar -Alan.
Re: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
Hi Kumar, A few minor comments ... src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java Seems to me this is all dead now: 199 /* 200 * A wrinkle in the environment: 201 * 64-bit executables are stored under $JAVA_HOME/bin/os_arch 202 * 32-bit executables are stored under $JAVA_HOME/bin 203 */ 204 String os_arch = System.getProperty(os.arch); os_arch is no longer used and the comment no longer applicable. --- src/solaris/bin/java_md_solinux.c This seems to force DUAL_MODE off regardless of what the user may set it to: #ifdef __solaris__ ! # ifdef DUAL_MODE ! #undef DUAL_MODE ! # endif why doesn't it just not define DUAL_MODE? --- test/demo/jvmti/DemoRun.java test/sun/tools/jhat/HatRun.java It isn't clear to me why you need to retain the d64 variable at all. --- test/tools/launcher/ExecutionEnvironment.java typo: appopriate Thanks, David On 7/09/2013 2:47 AM, Kumar Srinivasan wrote: Hello, Please review the changes to remove Solaris 32-bit binaries from JDK8 distros, at this time the dual mode support in the launcher is being disabled. Message regarding this: http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html The jdk changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ The top forest changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ Thanks Kumar
Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8
On 9/4/2013 6:02 PM, David M. Lloyd wrote: This seems reasonable on the surface but falls over once you capture the caller for more than one purpose. For example, say a logging framework captures the caller for the purpose of supplementing log information. But you call this logging framework from another framework which uses caller information for another purpose, for example locating resources. The intent here might be to show information from the second framework in the log, however with one universal @CallerSensitive annotation you cannot distinguish which capture you want to grab - the second framework, or the caller who called the second framework. However by traversing the stack to a fixed depth, you can do so very definitively (as long as you always know that your internal code does *not* directly call the sensitive method - an easy thing to design for in most frameworks). It would need to detect if the intermediate frames don't call any sensitive method. @sun.reflect.CallerSensitive is primarily defined for the security issue and specifically for JEP 176. As you said, the current form of @CS doesn't satisfy other purposes. In fact you can usually traverse the stack to a fixed depth for this kind of thing, with one key exception that comes up in log frameworks. When you have one log API which forwards to another, you want to capture the first caller of any log API. Pursuant to this, most log frameworks have log method variants which accept the fully-qualified class name of that first logger. The moral equivalent to this scenario would likely be to provide an API variant which accepts a Class or ClassLoader (depending on the usage) and a variant which does not and uses a fixed-depth reach into the stack instead. This IMO blows a hole in the whole idea of a single *public* @CS annotation, and in fact in public framework code, a depth indicator seems to be adequate and more or less problem-free for any purpose I've run across. I'm not sure if we can be very certainabout the depth in a runtime environment (non-debugging) unless it requires all VM implementation to support a reliable way to return a frame at a given depth. The stack trace is not guaranteed to contain all stack frames. E.g. in the spec of Throwable.getStackTrace(): Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this throwable is permitted to return a zero-length array from this method. Mandy
Re: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
On 7/09/2013 1:28 AM, Alan Bateman wrote: On 06/09/2013 15:18, David Chase wrote: webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ Question #2, what's the best way to write a jtreg test suite that requires incompatible class files, that could not result from a single javac compilation? Can you coerce ASM into creating it? Alternatively it is something that you can create off-line and include in a class as a byte array (to load via your own URLClassLoader)? Multiple @compile tags in the main test? David - Question #3, the message(s) attached to the exception are not the same in all cases: a. IllegalAccessError's been caught java.lang.IllegalAccessError: member is private: MethodSupplier.m()void/invokeVirtual, from MethodInvoker b. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker c. IllegalAccessError's been caught java.lang.IllegalAccessError: d. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker The difference between a. and c. above (and these are the two that change under this fix, the code the execution definitely intersects at the fix) is: a = Class.forName(MethodInvoker).getMethod(invoke).invoke(null); c = MethodInvoker.invoke(); yet one has the message copied from the underlying IllegalAccessException (not IAError) and the other does not. Do you mean you want the messages to be consistent? (I don't think I quite get the question). -Alan
Re: Please review two corrections for java.time
Hi Roger, On 7/09/2013 3:58 AM, roger riggs wrote: Please review for two corrections: - The java/time/tck/java/time/TCKLocalTime test failed on a slow machine; the test should be more lenient. The test is not appropriate for a conformance test and is moved to java/time/test/java/time/TestLocalTime. As per the bug report the issue is not slow machines per-se but the use of Xcomp when running the test. I don't think the jck should ever be run with Xcomp. It will be interesting to see if the change from 100ms to 500ms cures the problem on all machines. Thanks, David - The javadoc for the JapaneseEra.MEIJI era should indicate the start date is 1868-01-01 to be consistent with java.util.Calendar. Note that java.time does not permit dates before Meiji 6 to be created since the calendar is not clearly defined until then. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/ Thanks, Roger
hg: jdk8/tl/jdk: 8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded linux-ppc*
Changeset: 6bfabb71ae1e Author:weijun Date: 2013-09-09 11:08 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bfabb71ae1e 8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded linux-ppc* Reviewed-by: xuelei ! test/sun/security/krb5/runNameEquals.sh
Re: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
Hi David, Staffan, Alan, I have addressed all the issues pointed and some more I found while jprt testing. The updated webrev for jdk is here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/ and the delta webrev since the last review webrev is here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html Thanks Kumar Hi Kumar, A few minor comments ... src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java Seems to me this is all dead now: 199 /* 200 * A wrinkle in the environment: 201 * 64-bit executables are stored under $JAVA_HOME/bin/os_arch 202 * 32-bit executables are stored under $JAVA_HOME/bin 203 */ 204 String os_arch = System.getProperty(os.arch); os_arch is no longer used and the comment no longer applicable. --- src/solaris/bin/java_md_solinux.c This seems to force DUAL_MODE off regardless of what the user may set it to: #ifdef __solaris__ ! # ifdef DUAL_MODE ! #undef DUAL_MODE ! # endif why doesn't it just not define DUAL_MODE? --- test/demo/jvmti/DemoRun.java test/sun/tools/jhat/HatRun.java It isn't clear to me why you need to retain the d64 variable at all. --- test/tools/launcher/ExecutionEnvironment.java typo: appopriate Thanks, David On 7/09/2013 2:47 AM, Kumar Srinivasan wrote: Hello, Please review the changes to remove Solaris 32-bit binaries from JDK8 distros, at this time the dual mode support in the launcher is being disabled. Message regarding this: http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html The jdk changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ The top forest changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ Thanks Kumar
Re: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
Hi Kumar, This is still dead code in src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java String os_arch = System.getProperty(os.arch); Also: test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so I know this already exist but I thought binaries were disallowed in the open repo? Davud On 9/09/2013 1:09 PM, Kumar Srinivasan wrote: Hi David, Staffan, Alan, I have addressed all the issues pointed and some more I found while jprt testing. The updated webrev for jdk is here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/ and the delta webrev since the last review webrev is here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html Thanks Kumar Hi Kumar, A few minor comments ... src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java Seems to me this is all dead now: 199 /* 200 * A wrinkle in the environment: 201 * 64-bit executables are stored under $JAVA_HOME/bin/os_arch 202 * 32-bit executables are stored under $JAVA_HOME/bin 203 */ 204 String os_arch = System.getProperty(os.arch); os_arch is no longer used and the comment no longer applicable. --- src/solaris/bin/java_md_solinux.c This seems to force DUAL_MODE off regardless of what the user may set it to: #ifdef __solaris__ ! # ifdef DUAL_MODE ! #undef DUAL_MODE ! # endif why doesn't it just not define DUAL_MODE? --- test/demo/jvmti/DemoRun.java test/sun/tools/jhat/HatRun.java It isn't clear to me why you need to retain the d64 variable at all. --- test/tools/launcher/ExecutionEnvironment.java typo: appopriate Thanks, David On 7/09/2013 2:47 AM, Kumar Srinivasan wrote: Hello, Please review the changes to remove Solaris 32-bit binaries from JDK8 distros, at this time the dual mode support in the launcher is being disabled. Message regarding this: http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html The jdk changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/ The top forest changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/ Thanks Kumar
