RFR(XS) 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac
These tests started failing recently on some mac machines. They appear to hang and timeout. FAILED: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh FAILED: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh Webrev: http://cr.openjdk.java.net/~chegar/8006669/webrev.00/webrev/ Debugging the test shows that the HttpsURLConnection being made by the test is not being proxied, even though the test explicitly sets the system properties, https.proxyHost and https.proxyPort. The properties are being set correctly, but the system has configured values for non proxy hosts: foobar:/tmp/chris networksetup -getproxybypassdomains Ethernet *.local 169.254/16 *.xx.yy.com So, the connection to foobar.xx.yy.com is made directly, as will all connections to the xx.yy.com domain. This causes the test to hang: The test setups a simple proxy, and has a non daemon thread blocked in ServerSocket accept. It expects the client part of the test to connect to it. And in this case it never does. The specific machines, foobar, network proxybypassdomains could be changed to remove *.xx.yy.com, and this would resolve the problem, but a more robust solution would be to up date the test so that it uses the URL.openConnection(Proxy) API, specifying the actual proxy, rather than URL.openConnection() and allowing the system default proxy selector to choose. -Chris.
hg: jdk8/tl/langtools: 8006673: TargetType52 fails because of bad golden file
Changeset: be443002e970 Author:mcimadamore Date: 2013-01-22 16:23 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be443002e970 8006673: TargetType52 fails because of bad golden file Summary: Fix golden file in negative test Reviewed-by: jjg ! test/tools/javac/lambda/TargetType52.out
Code Review Request: 7017962: Obsolete link is used in URL class level spec
The current javadoc for URL.java points to a non-existent link [1] to explain different types of URLs used by different protocols. The same document can currently be found at [2]. Bug: http://bugs.sun.com/view_bug.do?bug_id=7017962 Webrev: http://cr.openjdk.java.net/~khazra/7017962/webrev.00/ Although I have used [2] as a substitute in the webrev above, here are some other alternatives that I could find: 1. http://www.w3.org/TR/WD-html40-970917/htmlweb.html#h-5.1 2. http://www.utoronto.ca/web/HTMLdocs/NewHTML/url.html 3. Simply remove reference to the document in the javadoc. Any suggestions are welcome. Thanks, Kurchi [1] http://www.socs.uts.edu.au/MosaicDocs-old/url-primer.html [2] http://www.mathematik.uni-halle.de/doc/NCSA/Mosaic-Docs/url-primer.html
hg: jdk8/tl/jdk: 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running
Changeset: c18f28312c49 Author:smarks Date: 2013-01-22 18:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c18f28312c49 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running Reviewed-by: mchung ! test/java/rmi/activation/ActivationSystem/unregisterGroup/ActivateMe.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy
Re: Code review request 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource()
Hi Chris and Kurchi, Thank you both for your comments. I have reformatted the patch accordingly @ http://cr.openjdk.java.net/~dingxmin/7183373/webrev.03/ Please take a look again :-) Best regards, Frank On 1/22/2013 4:42 AM, Chris Hegarty wrote: On 01/21/2013 08:36 PM, Kurchi Subhra Hazra wrote: The change looks consistent with what we had already (findResource() will now silently consume an UnknownServiceException instead of a NullPointerException for MailToURLConnection). Also, I noticed that the test does not fail on Mac OS X even without the fix - it does fail on Windows though. This is really just a Windows specific issue, where not closing the stream will prevent the file from being deleted. It is ok to have a general test that runs on all platforms, but well done for noticing! The test will probably need some minor reformatting(some lines are greater than the standard 80 characters). Agreed, it would be nicer to reformat some lines where applicable. Also, can you put the copyright header at the top of the file, and move the imports below it. And update the year to 2013, or year range ( if applicable ). -Chris. Thanks, Kurchi On 1/21/13 12:20 AM, Frank Ding wrote: Hi Chris, Thanks for your review. I did jtreg test on net module (java/net and sun/net) and no regression issue was found. Could anybody else review the patch as well? Best regards, Frank On 1/18/2013 10:55 PM, Chris Hegarty wrote: I haven't been able to spend as much time on this as I would like, jdk8 M6 code freeze is approaching fast. Since this area is fraught with danger the safest change would be what is in the .2 version of the webrev [1]. I think I would be ok with this. -Chris. [1] http://cr.openjdk.java.net/~shirishk/7183373/webrev.2/ On 18/01/2013 06:54, Frank Ding wrote: Hi Michael, Could you please take a look at my comment below? Best regards, Frank On 1/6/2013 4:23 PM, Frank Ding wrote: Hi Michael, After reading carefully discussion thread, let me elaborate my investigation and conclusion. The 2nd version of Shirish's patch tries to address your concern that Would it be possible to fix this within the context of whatever loader is currently being invoked?. The new solution sticks to using Loader rather than JarLoader. The call cl.close() in the jtreg test case, according to its spec (URLClassLoader.close) should close any files that were opened by it in case of jar. Its implementation code shows it closes any opened resources through api such as getResourceAsStream invoked by client code but doesn't take care of any resources opened by findResource(String) or findResources(String). This implies that findResource should return any resource found but should not leave it in open state. The key issue for a Loader.findResource() when searching within a jar file does not follow this rule because the code combination InputStream is = url.openStream(); is.close(); (in URLClassPath.Loader.findResource()) leaves the jar file in open state. As Shirish pointed out, if useCaches is set to true, the problem is gone. It can be easily verified from code JarURLInputStream.close() defined in JarURLConnection.java. My conclusion is that Shirish's first patch is reasonable (except the constructor change which I have not fully understood yet) because choosing a JarLoader avoids unclosed resources after calling URLClassLoader.getResource() and 2nd patch also makes sense as explained above. The ramifications of these 2 patches need deliberate considerations but we still have to fix the issue after weighing their risks. Could you please shed your light on it? Best regards, Frank On 8/25/2012 12:02 AM, Shirish Kuncolienkar wrote: On 8/24/2012 5:39 PM, Michael McMahon wrote: On 23/08/12 18:50, Shirish Kuncolienkar wrote: Could I get the change reviewed please This behavior is seen on Windows. Logic in URLClassPath.getLoader() does not take care of an URL which looks like jar:file:/C:/test/xyz.jar!/. The logic ends up choosing a FileLoader instead of a JarLoader. JarLoader has provision for closing file handles, so choosing a JarLoader will solve the problem. Secondly the constructor of JarLoader blindly adds a prefix and suffix to the provided URL to make it look like a jar URL. Changed the code here to conditionally append/prepend The change set can be found at http://cr.openjdk.java.net/~shirishk/7183373/webrev.0/ -Shirish Shirish, I have a slight concern that this would modify the Loader class to be used in some circumstances completely independent of the requirements of URLClassLoader.close(). This is very sensitive code. Would it be possible to fix this within the context of whatever loader is currently being invoked? - Michael Michael, Thanks for the review comments. The second version of the fix is uploaded at http://cr.openjdk.java.net/~shirishk/7183373/webrev.2/ Could you please take a look at this one ? Description of the fix:
hg: jdk8/tl/langtools: 2 new changesets
Changeset: f5b70712e0d5 Author:jjg Date: 2013-01-22 19:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f5b70712e0d5 8006728: temporarily workaround jtreg problems for doclint tests in othervm Reviewed-by: jjh + test/tools/doclint/html/AAA.java + test/tools/doclint/tidy/AAA.java + test/tools/doclint/tool/AAA.java Changeset: 385828dd5604 Author:jjg Date: 2013-01-22 19:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/385828dd5604 Merge
hg: jdk8/tl/jdk: 8003680: JSR 310 Date/Time API
Changeset: 919afffa70b0 Author:sherman Date: 2013-01-22 20:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/919afffa70b0 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebou...@joda.org, roger.ri...@oracle.com, richard.warbur...@gmail.com, mist...@gmail.com ! make/docs/CORE_PKGS.gmk ! make/java/Makefile + make/java/time/Makefile ! make/jprt.properties ! make/sun/Makefile + make/sun/tzdb/Makefile ! make/tools/Makefile + make/tools/src/build/tools/tzdb/ChronoField.java + make/tools/src/build/tools/tzdb/DateTimeException.java + make/tools/src/build/tools/tzdb/LocalDate.java + make/tools/src/build/tools/tzdb/LocalDateTime.java + make/tools/src/build/tools/tzdb/LocalTime.java + make/tools/src/build/tools/tzdb/TimeDefinition.java + make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java + make/tools/src/build/tools/tzdb/Utils.java + make/tools/src/build/tools/tzdb/ZoneOffset.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java + make/tools/src/build/tools/tzdb/ZoneRules.java + make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java + make/tools/tzdb/Makefile ! makefiles/CreateJars.gmk + makefiles/GendataTZDB.gmk ! makefiles/GenerateData.gmk ! makefiles/Tools.gmk + src/share/classes/java/time/Clock.java + src/share/classes/java/time/DateTimeException.java + src/share/classes/java/time/DayOfWeek.java + src/share/classes/java/time/Duration.java + src/share/classes/java/time/Instant.java + src/share/classes/java/time/LocalDate.java + src/share/classes/java/time/LocalDateTime.java + src/share/classes/java/time/LocalTime.java + src/share/classes/java/time/Month.java + src/share/classes/java/time/Period.java + src/share/classes/java/time/PeriodParser.java + src/share/classes/java/time/Ser.java + src/share/classes/java/time/ZoneId.java + src/share/classes/java/time/ZoneOffset.java + src/share/classes/java/time/ZoneRegion.java + src/share/classes/java/time/ZonedDateTime.java + src/share/classes/java/time/calendar/ChronoDateImpl.java + src/share/classes/java/time/calendar/HijrahChrono.java + src/share/classes/java/time/calendar/HijrahDate.java + src/share/classes/java/time/calendar/HijrahDeviationReader.java + src/share/classes/java/time/calendar/HijrahEra.java + src/share/classes/java/time/calendar/JapaneseChrono.java + src/share/classes/java/time/calendar/JapaneseDate.java + src/share/classes/java/time/calendar/JapaneseEra.java + src/share/classes/java/time/calendar/MinguoChrono.java + src/share/classes/java/time/calendar/MinguoDate.java + src/share/classes/java/time/calendar/MinguoEra.java + src/share/classes/java/time/calendar/Ser.java + src/share/classes/java/time/calendar/ThaiBuddhistChrono.java + src/share/classes/java/time/calendar/ThaiBuddhistDate.java + src/share/classes/java/time/calendar/ThaiBuddhistEra.java + src/share/classes/java/time/calendar/package-info.java + src/share/classes/java/time/format/DateTimeBuilder.java + src/share/classes/java/time/format/DateTimeFormatStyleProvider.java + src/share/classes/java/time/format/DateTimeFormatSymbols.java + src/share/classes/java/time/format/DateTimeFormatter.java + src/share/classes/java/time/format/DateTimeFormatterBuilder.java + src/share/classes/java/time/format/DateTimeFormatters.java + src/share/classes/java/time/format/DateTimeParseContext.java + src/share/classes/java/time/format/DateTimeParseException.java + src/share/classes/java/time/format/DateTimePrintContext.java + src/share/classes/java/time/format/DateTimePrintException.java + src/share/classes/java/time/format/DateTimeTextProvider.java + src/share/classes/java/time/format/FormatStyle.java + src/share/classes/java/time/format/SignStyle.java + src/share/classes/java/time/format/TextStyle.java + src/share/classes/java/time/format/package-info.java + src/share/classes/java/time/overview.html + src/share/classes/java/time/package-info.java + src/share/classes/java/time/temporal/Adjusters.java + src/share/classes/java/time/temporal/Chrono.java + src/share/classes/java/time/temporal/ChronoField.java + src/share/classes/java/time/temporal/ChronoLocalDate.java + src/share/classes/java/time/temporal/ChronoLocalDateTime.java + src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java + src/share/classes/java/time/temporal/ChronoUnit.java + src/share/classes/java/time/temporal/ChronoZonedDateTime.java + src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java + src/share/classes/java/time/temporal/Era.java + src/share/classes/java/time/temporal/ISOChrono.java + src/share/classes/java/time/temporal/ISOEra.java + src/share/classes/java/time/temporal/ISOFields.java + src/share/classes/java/time/temporal/JulianFields.java + src/share/classes/java/time/temporal/MonthDay.java + src/share/classes/java/time/temporal/OffsetDate.java + src/share/classes/java/time/temporal/OffsetDateTime.java +
hg: jdk8/tl: 8003680: JSR 310 Date/Time API
Changeset: 8209c91b751d Author:sherman Date: 2013-01-22 21:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8209c91b751d 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebou...@joda.org, roger.ri...@oracle.com, richard.warbur...@gmail.com, mist...@gmail.com ! common/makefiles/javadoc/CORE_PKGS.gmk ! make/jprt.properties ! test/Makefile
