hg: jdk8/tl/langtools: 8019397: javap does not show SourceDebugExtension properly
Changeset: 27a2e8c78bd0 Author:vromero Date: 2013-07-02 10:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/27a2e8c78bd0 8019397: javap does not show SourceDebugExtension properly Reviewed-by: jjg Contributed-by: dmytro_she...@hotmail.com ! src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java
hg: jdk8/tl/jdk: 8017174: NPE when using Logger.getAnonymousLogger or LogManager.getLogManager().getLogger
Changeset: 020f023f87d1 Author:dfuchs Date: 2013-07-02 11:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/020f023f87d1 8017174: NPE when using Logger.getAnonymousLogger or LogManager.getLogManager().getLogger Summary: This patch makes sure that LoggerContext instances created for applets have a root and global logger. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java ! test/java/util/logging/LogManagerInstanceTest.java + test/java/util/logging/TestAppletLoggerContext.java
hg: jdk8/tl/jdk: 8017463: [TEST_BUG] 2 tests from tools/pack200/ remain about 1 GB of data in work directory after execution
Changeset: b1fffbbdf58c Author:ksrini Date: 2013-07-02 05:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1fffbbdf58c 8017463: [TEST_BUG] 2 tests from tools/pack200/ remain about 1 GB of data in work directory after execution Reviewed-by: mchung ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/BandIntegrity.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Pack200Props.java ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/RepackTest.java ! test/tools/pack200/T7007157.java ! test/tools/pack200/TestExceptions.java ! test/tools/pack200/TimeStamp.java ! test/tools/pack200/UnpackerMemoryTest.java ! test/tools/pack200/Utils.java ! test/tools/pack200/typeannos/TestTypeAnnotations.java
6560175: HttpURLConnection should support arbitrary methods
Hi, i am looking for a sponsor. In the issue comment it says: sounds feasible for jdk7 - but well, it didn't make it... Bug: http://bugs.sun.com/view_bug.do?bug_id=6560175 I checked the code and would like to update the comment and javadoc of the current setRequestMethod() - no code change there. Then i would add a new method setExtensionMethod() with a sandbox, add a setExtensionMethod to NetPermissions (also in the policy tool) plus a new jtreg test. Looks like a small change. One minor thing is the new HttpURLPermission class where '*' is used as wild-card. This is a valid extension-method. Not that i know one implemented such a method but it means a URL permission could not be set for a '*' method. Request methods are case sensitive, but converted to uppercase in HttpURLPermission. This means a URL permission could not be set for a 'lowercase' method. Other option would be to allow only the following known extension methods: WebDAV (RFC 2518, RFC 3253, RFC 4437 experimental) BASELINE-CONTROL, CHECKIN, CHECKOUT, CONNECT, COPY, LABEL, LOCK, MERGE, MKCOL, MKWORKSPACE, MKACTIVITY, MOVE, PATCH, PROPFIND, PROPPATCH, REPORT, UNLOCK, UNCHECKOUT, UPDATE, VERSION-CONTROL, MKREDIRECTREF, UPDATEREDIRECTREF Still a small change and up to you. Thanks Andreas
hg: jdk8/tl/langtools: 8019460: tests in changeset do not have @bug tag
Changeset: 565341d436e2 Author:ksrini Date: 2013-07-01 16:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/565341d436e2 8019460: tests in changeset do not have @bug tag Reviewed-by: darcy ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
hg: jdk8/tl/jdk: 7184195: java.util.logging.Logger.getGlobal().info() doesn't log without configuration
Changeset: 70bff2d12af0 Author:dfuchs Date: 2013-07-02 19:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70bff2d12af0 7184195: java.util.logging.Logger.getGlobal().info() doesn't log without configuration Summary: Due to subtle synchronization issues between LogManager Logger class initialization the global logger doesn't have its 'manager' field initialized until the LogManager is initialized. This fix will ensure that the global logger has its 'manager' field set when getGlobal() is called. Reviewed-by: mchung, plevart ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/getGlobal/TestGetGlobal.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java + test/java/util/logging/Logger/getGlobal/logging.properties + test/java/util/logging/Logger/getGlobal/policy + test/java/util/logging/Logger/getGlobal/testgetglobal/BadLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/DummyLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/HandlerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl1.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl2.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl3.java
hg: jdk8/tl/langtools: 6326693: variable x might already have been assigned, when assignment is in catch block
Changeset: 3b4f92a3797f Author:vromero Date: 2013-07-02 22:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3b4f92a3797f 6326693: variable x might already have been assigned, when assignment is in catch block Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.out
hg: jdk8/tl/jdk: 8007035: deprecate public void SecurityManager.checkMemberAccess(Class? clazz, int which)
Changeset: cf7202b32a34 Author:mchung Date: 2013-07-02 15:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf7202b32a34 8007035: deprecate public void SecurityManager.checkMemberAccess(Class? clazz, int which) Reviewed-by: jrose, alanb, dfuchs ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Member.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java + test/java/lang/invoke/TestPrivateMember.java
Re: RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
Michael wrote:
I'd agree with this. If the exception is being swallowed now, how
will we know when the test fails?
The peer thread saves off any Exceptions into {server,client}Exception
volatile variable, which is then examined by the main thread at the end,
and the stacktrace would be sent to System.out in the case of both the
client/server throwing an exception. Stuart pointed where exceptions
were truly being swallowed when the threads are being created, and I've
updated the webrev to address that.
Also, I don't see where the change is invoking the newer framework? Am I
looking
at the right webrev?
Sorry, I used the word framework when I should have used template.
JSSE has a test template that I wrote back in the unbundled 1.0.3 days
(2004) because we needed to do client/server-side testing, and we were
always spending too much time getting the details worked out. So I made
a general template that most of the tests now use. Most of the time
only the top half of the test needs modification, but there are
occasions where the initialization needs tweaking.
It could be made into a framework/library. I've filed:
JDK-8019776: Make the JSSE Test Templates into a library
There was no initCause/Suppressed back in those days, but those are good
additions to add now. We got the same debug info by printing the stack
trace of any secondary exceptions.
Stuart wrote:
The open URL to view this bug is:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017333
Whoops, my apologies.
It looks like startServer() and startClient() now both try to catch any
exceptions and store them in variables for later processing. But they
still are declared to throw Exception, and the code that calls them from
the constructor throws away any exception that's caught there. Hm, it's
hard to know what exception might be caught at that point, but since we
don't really know what's going on, we probably shouldn't rule anything out.
Good point, I'll capture that and add it as either the root cause, the
init cause, or a suppressed exception (depending on what others there
are to report), both here and in SSLSocketTemplate and friends.
Most places catch Exception. One possibility to consider is whether an
Error of some type might be thrown, which isn't caught by catch
(Exception) clauses.
I believe we talked about that in earlier versions of the template. If
there's an Error, that's a more serious problem and nothing should be
trusted coming out. I would think the jtreg framework will output Errors.
In the place where you potentially have two exceptions to report, you
might consider using the suppressed exception mechanism. This is bending
the semantics a bit, but if the client is subordinate to the server (or
vice versa) and both throw exceptions, only one can be propagated, so it
could seem somewhat proper to consider one exception to have suppressed
the other.
Sounds good. I think I'd go with the initCause for peerException, and
add a suppressed exception if there is an additional exception (unlikely).
New webrev under:
http://cr.openjdk.java.net/~wetmore/8019341/webrev.01/
Brad
