Re: RFR : 5036554 : unmarshal error on CORBA alias type in CORBA any
Thanks for review Stuart. I meant to give the public link. Here it is for records : http://cr.openjdk.java.net/~coffeys/webrev.5036554.jdk8/webrev/ http://cr.openjdk.java.net/%7Ecoffeys/webrev.5036554.jdk8/webrev/ regards, Sean. On 23/10/2013 06:00, Stuart Marks wrote: Seems like a sensible fix. (Note: your webrev appears to be on an internal server, not visible to the public, but nothing there is confidential to my eye.) It's unfortunate that the test involves creating another shell script test, but the alternative is probably a lot of work to develop a corba test library that knows how to run idlj and compile classes against the generated output. Oh well. s'marks On 10/22/13 12:44 PM, Seán Coffey wrote: This corba fix was fixed many moons ago in JDK5. Bad records meant it didn't get forward ported to JDK6 and later families. We need to fix that now. I'm looking to push this to jdk8-tl and backport to jdk7u-dev shortly afterwards. bug ID : https://bugs.openjdk.java.net/browse/JDK-5036554 webrev : http://t4.ie.oracle.com/home/sean/jdk8_tl.2/webrev.5036554.jdk8/webrev/ regards, Sean.
hg: jdk8/tl/jdk: 7105883: JDWP: agent crash if there exists a ThreadGroup with null name
Changeset: c077a2810782 Author:egahlin Date: 2013-10-23 10:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c077a2810782 7105883: JDWP: agent crash if there exists a ThreadGroup with null name Reviewed-by: sla, jbachorik ! src/share/back/ThreadGroupReferenceImpl.c + test/com/sun/jdi/NullThreadGroupNameTest.java
Re: DecimalFormat regression bug in Java 8?
Thank you for your answer. I understand completely. However, while I fully agree the Java 8 formatting is correct, is still causes regressions in the product I'm working on, and I shall have to code a workaround for Java 8. Oh well. Coding is what we get paid for. Best regards, /Lennart Börjeson
hg: jdk8/tl/jdk: 8025734: Use literal IP address where possible in SocketPermission generated by HttpURLPermission
Changeset: 1b0dfa631b6f Author:michaelm Date: 2013-10-23 11:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b0dfa631b6f 8025734: Use literal IP address where possible in SocketPermission generated by HttpURLPermission Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/URLPermission/nstest/LookupTest.java + test/java/net/URLPermission/nstest/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/java/net/URLPermission/nstest/SimpleNameService.java + test/java/net/URLPermission/nstest/SimpleNameServiceDescriptor.java + test/java/net/URLPermission/nstest/policy
hg: jdk8/tl/langtools: 8026508: Invokedynamic instructions don't get line number table entries
Changeset: b05db8c815e8 Author:jlahoda Date: 2013-10-23 07:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b05db8c815e8 8026508: Invokedynamic instructions don't get line number table entries Summary: Setting or correcting positions for many trees produced by LambdaToMethod. Reviewed-by: vromero, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/T8019486/WrongLNTForLambdaTest.java - test/tools/javac/T8019486/WrongLVTForLambdaTest.java
Re: RFR [8024521] (process) Async close issues with Process InputStream
Thank you Rob for offering the sponsor's help! Here's the exported patch: http://cr.openjdk.java.net/~igerasim/2commit/8024521-jdk8-Async-close-race.patch Alan, I reduced the default time gap to 20 seconds as you suggested. Sincerely yours, Ivan On 22.10.2013 23:14, Rob McKenna wrote: Happy to vounteer for sponsorship duties. Been following this from the sidelines. -Rob On 22/10/13 20:01, Alan Bateman wrote: On 18/10/2013 17:00, Ivan Gerasimov wrote: Thank you Martin for the references. I've implemented passing the limitation to the application in a similar manner. The timeout value is passed to the test through the CloseRaceTimeout system property. If the property wasn't set, the default value of 2 minutes is used. When the application creates its child process, this value is passed through the argument list. In any ways this test should be run by jtreg harness, since it uses 'testlibrary' for dealing with the child process. However, when run by hands, there's a way to specify for how long it should work. Ivan - do you have a sponsor for this one? It would be good to get this out of the way before ZBB. On the default timeout in the test then I'd prefer it to be something like 20s or 30s rather than 2 minutes. The reason is that we don't currently have any distinction between stress tests and other types of tests and so people tend to just run all the tests for an area (hence 2 minutes is a long time as we need the tests to execute as quickly as possible). -Alan.
Re: RFR [8024521] (process) Async close issues with Process InputStream
On 23/10/2013 12:41, Ivan Gerasimov wrote: Thank you Rob for offering the sponsor's help! Here's the exported patch: http://cr.openjdk.java.net/~igerasim/2commit/8024521-jdk8-Async-close-race.patch Alan, I reduced the default time gap to 20 seconds as you suggested. Thanks for dialing it down. If Martin comes up with a test that duplicates it more efficiently then we can replace the test. From Matthias's mail to jdk8-dev [1] then there is a proposal to allow test stablization fixes to be pushed after ZBB so that gives us a window in which to fix test issues without needing special approvals. -Alan. [1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-October/003443.html
hg: jdk8/tl/jdk: 7112404: 2 tests in java/lang/management/ManagementFactory fails with G1 because expect non-zero pools
Changeset: f4970c7abe93 Author:jbachorik Date: 2013-10-23 15:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4970c7abe93 7112404: 2 tests in java/lang/management/ManagementFactory fails with G1 because expect non-zero pools Reviewed-by: mchung, sjiang ! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java ! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java
8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
j.u.c.atomic.{Double,Long}.{Accumulator,Adder} extend a package-private
class Striped64 that does striping on 64-bit values. This super type is
Serializable by way of extending Number. Striped64 doesn't contribute
any serial fields but its name does leak into the serial stream because
there is a descriptor for the super type when it is also serializable.
Those that write conformance tests have noticed this.
In practical terms this is a bit of a non-issue but the reference to
Striped64 can be removed from the serial stream by changing these four
to use a serialization proxy. Doug has gone ahead and changed the
classes in jsr166 CVS and we need to bring these changes into jdk8/tl by
the ZBB date.
The webrev with the proposed changes is here:
http://cr.openjdk.java.net/~alanb/8026344/webrev/
A minor difference with what is currently in the CVS is that I've added
a link in the writeReplace javadoc to the proxy class. I've also added a
simple test as I didn't find any tests in the jdk repository that
exercise serialization of these classes.
-Alan.
hg: jdk8/tl/jdk: 8026789: Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection
Changeset: 8c20e9ef8709 Author:sla Date: 2013-10-23 15:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c20e9ef8709 8026789: Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection Reviewed-by: dcubed ! test/ProblemList.txt + test/java/lang/instrument/NMTHelper.java ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineBigClassApp.java ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/RetransformBigClassApp.java
hg: jdk8/tl/jdk: 8020758: HttpCookie constructor does not throw IAE when name contains a space
Changeset: f120672b91ef Author:chegar Date: 2013-10-23 14:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f120672b91ef 8020758: HttpCookie constructor does not throw IAE when name contains a space Reviewed-by: michaelm, msheppar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java
Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
On 10/23/2013 10:06 AM, Alan Bateman wrote:
In practical terms this is a bit of a non-issue
I suppose it is a good sign that people are mostly just
fixing non-issues as freeze dates approach :-)
The webrev with the proposed changes is here:
http://cr.openjdk.java.net/~alanb/8026344/webrev/
A minor difference with what is currently in the CVS is that I've added a
link in the writeReplace javadoc to the proxy class.
I adjusted accordingly. I'm not sure why just {@link ...} didn't suffice.
I've also added a simple test as I didn't find any tests in the jdk
repository that exercise serialization of these classes.
Thanks. We do have one in tck (junit) tests, but the more the merrier.
-Doug
Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
On Oct 23, 2013, at 4:06 PM, Alan Bateman alan.bate...@oracle.com wrote:
j.u.c.atomic.{Double,Long}.{Accumulator,Adder} extend a package-private class
Striped64 that does striping on 64-bit values. This super type is
Serializable by way of extending Number. Striped64 doesn't contribute any
serial fields but its name does leak into the serial stream because there is
a descriptor for the super type when it is also serializable. Those that
write conformance tests have noticed this.
In practical terms this is a bit of a non-issue but the reference to
Striped64 can be removed from the serial stream by changing these four to use
a serialization proxy. Doug has gone ahead and changed the classes in jsr166
CVS and we need to bring these changes into jdk8/tl by the ZBB date.
The webrev with the proposed changes is here:
http://cr.openjdk.java.net/~alanb/8026344/webrev/
A minor difference with what is currently in the CVS is that I've added a
link in the writeReplace javadoc to the proxy class. I've also added a simple
test as I didn't find any tests in the jdk repository that exercise
serialization of these classes.
Looks OK.
Testing wise if you really want to use lambda expressions then they need to be
explicitly marked as serializable otherwise it's gonna barf (as you probably
found out):
DoubleBinaryOperator plus = (DoubleBinaryOperator Serializable) (x,
y) - x + y;
Should you test accumulation/addition/reset after deserialization just to make
sure the value/identity are assigned correctly?
Paul.
Re: i18n dev RFR: 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing
Hi Masayoshi, At that time I was asked to have regression test to validate each translation changes. With our new translation process for TimeZoneNames and new planned regression tests from Aleksej for JDK-8025051 https://bugs.openjdk.java.net/browse/JDK-8025051, I believe we can remove those unnecessary tests in the future (probably together with JDK-8025051 https://bugs.openjdk.java.net/browse/JDK-8025051). For now, webrev [2] looks fine to take care of the short term regression failure. thanks, -michael On 13?10?22? 09:29 ??, Masayoshi Okutsu wrote: Hi Michael, 27 *@summary Test case for tzdata2005m support for 9 locales What's the purpose of this test? Do we really need to keep this one? Thanks, Masayoshi On 10/22/2013 8:13 PM, Aleksej Efimov wrote: Hi, Can I have a review for 8026772 [1] fix. The webrev link: [2] The timezone test is failed because of the changed TimeZone names introduced in 8025255 [3]. This timezone names were changed according to updated translation resource files introduced by 8025215 [4]. The fix changes the hard-coded time zone names for Australia/Currie to the values specified in 8025215. Thanks in Advance, Aleksej [1] http://bugs.sun.com/view_bug.do?bug_id=8026772 [2] http://cr.openjdk.java.net/~aefimov/8026772/webrev.00/ [3] http://bugs.sun.com/view_bug.do?bug_id=8025255 [4] http://bugs.sun.com/view_bug.do?bug_id=8025215
Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
Looks fine to me.
Should all SerializationProxy classes have the same serialVersionUID ( =
7249069246863182397L ) ?
-Chris.
On 23/10/2013 15:06, Alan Bateman wrote:
j.u.c.atomic.{Double,Long}.{Accumulator,Adder} extend a package-private
class Striped64 that does striping on 64-bit values. This super type is
Serializable by way of extending Number. Striped64 doesn't contribute
any serial fields but its name does leak into the serial stream because
there is a descriptor for the super type when it is also serializable.
Those that write conformance tests have noticed this.
In practical terms this is a bit of a non-issue but the reference to
Striped64 can be removed from the serial stream by changing these four
to use a serialization proxy. Doug has gone ahead and changed the
classes in jsr166 CVS and we need to bring these changes into jdk8/tl by
the ZBB date.
The webrev with the proposed changes is here:
http://cr.openjdk.java.net/~alanb/8026344/webrev/
A minor difference with what is currently in the CVS is that I've added
a link in the writeReplace javadoc to the proxy class. I've also added a
simple test as I didn't find any tests in the jdk repository that
exercise serialization of these classes.
-Alan.
Re: RFR: 8004912: Repeating annotations - getAnnotationsByType is not working as expected
On 10/22/2013 03:20 PM, Peter Levart wrote: I think the problem could be solved in two ways: - by explicitly scanning the inheritance chain for the 1st class that has the annotations of type T present directly or indirectly (by containment). - by canonicalizing the representation of the repeating annotations in the class file attributes. By this I mean that each repeating annotation is placed inside it's container at compile-time even if it is a single annotation of a particular type. This would mean that some features like specifying different @Targets or @Retentions for repeating annotation types and their containers would be prohibited and the specification would have to be changed. But I think this way the inheritance aspect of repeating annotations would be consistent even if not looking through containers (by using the old JDK7 API)... The canonicalization could be performed at runtime though, and I think there were such attempts already in the past. What happened to them? Regards, Peter Hi Peter, A new patch is available for review here: http://cr.openjdk.java.net/~alundblad/inherited-associated/ This includes a new test based on your code. The test passes after applying the patch. best regards, Andreas Lundblad
hg: jdk8/tl/jdk: 8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking
Changeset: 3cdf6ca3ef47 Author:kizune Date: 2013-10-23 18:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cdf6ca3ef47 8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking Reviewed-by: alanb, ksrini ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar.properties + test/tools/jar/normalize/TestNormal.java
Re: RFR : 5036554 : unmarshal error on CORBA alias type in CORBA any
Looks fine to me Sean. -Chris. On 23/10/2013 08:59, Seán Coffey wrote: Thanks for review Stuart. I meant to give the public link. Here it is for records : http://cr.openjdk.java.net/~coffeys/webrev.5036554.jdk8/webrev/ http://cr.openjdk.java.net/%7Ecoffeys/webrev.5036554.jdk8/webrev/ regards, Sean. On 23/10/2013 06:00, Stuart Marks wrote: Seems like a sensible fix. (Note: your webrev appears to be on an internal server, not visible to the public, but nothing there is confidential to my eye.) It's unfortunate that the test involves creating another shell script test, but the alternative is probably a lot of work to develop a corba test library that knows how to run idlj and compile classes against the generated output. Oh well. s'marks On 10/22/13 12:44 PM, Seán Coffey wrote: This corba fix was fixed many moons ago in JDK5. Bad records meant it didn't get forward ported to JDK6 and later families. We need to fix that now. I'm looking to push this to jdk8-tl and backport to jdk7u-dev shortly afterwards. bug ID : https://bugs.openjdk.java.net/browse/JDK-5036554 webrev : http://t4.ie.oracle.com/home/sean/jdk8_tl.2/webrev.5036554.jdk8/webrev/ regards, Sean.
hg: jdk8/tl/jdk: 5036554: unmarshal error on CORBA alias type in CORBA any
Changeset: 2af3f5a61322 Author:coffeys Date: 2013-10-23 16:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2af3f5a61322 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks + test/com/sun/corba/5036554/JavaBug.java + test/com/sun/corba/5036554/README + test/com/sun/corba/5036554/TestCorbaBug.sh + test/com/sun/corba/5036554/bug.idl
Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
On 23/10/2013 15:22, Doug Lea wrote:
On 10/23/2013 10:06 AM, Alan Bateman wrote:
A minor difference with what is currently in the CVS is that I've
added a
link in the writeReplace javadoc to the proxy class.
I adjusted accordingly. I'm not sure why just {@link ...} didn't suffice.
I think this is because the javadoc for package-private classes isn't
generated in the API docs build. The link to the class in the
serialized-form page is a big ugly but I don't see another choice at
this time.
Thanks. We do have one in tck (junit) tests, but the more the merrier.
Okay.
-Alan
Re: RFR 8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking
On 22/10/2013 23:56, Alexander Zuev wrote: Alan, i guess you're right, i have updated code to use the same method with fallback for creation .pack temporary file. New webrev can be found at http://cr.openjdk.java.net/~kizune/8020802/webrev.05 /Alex Thanks, this is better. A small suggestion (I think I mentioned in one of the early mails) is that you could use try-with-resources for the pack file, not critical, just a suggestion. Also a minor nit on line 217, missing space in if(. -Alan.
Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
On 23/10/2013 15:37, Paul Sandoz wrote: : Testing wise if you really want to use lambda expressions then they need to be explicitly marked as serializable otherwise it's gonna barf (as you probably found out): DoubleBinaryOperator plus = (DoubleBinaryOperator Serializable) (x, y) - x + y; Yes, that is what I was looking for (and meant to search the lambda serialization tests to see how to do this). Should you test accumulation/addition/reset after deserialization just to make sure the value/identity are assigned correctly? Good idea, I'll add that. -Alan.
hg: jdk8/tl/corba: 5036554: unmarshal error on CORBA alias type in CORBA any
Changeset: a90e9efa4264 Author:coffeys Date: 2013-10-23 16:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a90e9efa4264 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java
hg: jdk8/tl/nashorn: 3 new changesets
Changeset: 5df55690fd5b Author:sundar Date: 2013-10-23 17:30 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5df55690fd5b 8027128: jdk.nashorn.api.scripting.JSObject should be an interface Reviewed-by: hannesw, attila, jlaskey + src/jdk/nashorn/api/scripting/AbstractJSObject.java ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! test/script/basic/JDK-8024847.js ! test/script/basic/JDK-8024847.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: f31ee3a2847d Author:sundar Date: 2013-10-23 20:15 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f31ee3a2847d 8027150: ScriptObjectListAdapter won't work as expected Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/ListAdapter.java - src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java Changeset: 640c1854f742 Author:sundar Date: 2013-10-23 20:21 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/640c1854f742 Merge - src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java
Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
On 23/10/2013 15:32, roger riggs wrote: : The signature of the readObject methods usually has the return type Object even though in this case it should never be used. And a method comment would be nice saying why it always throws an exception. I checked Serializable and it defines readObject's return type as void. We could add a javadoc comment if needed but the @throws should be sufficient for testing. I might have been tempted to conserve on classes and code duplication to share a serialization proxy between the classes and maybe even shorten the name. But it is hard to argue with the simplicity and directness of this design. I don't have a strong opinion on this, it could be something really like short (if Doug is inclined). -Alan.
Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
On 10/23/2013 11:17 AM, Chris Hegarty wrote:
Looks fine to me.
Should all SerializationProxy classes have the same serialVersionUID ( =
7249069246863182397L ) ?
Not only that, it is the same as that for the main classes themselves.
It should simplify ability to check any errors in cases anyone ever
tries to change any of them without changing all of them.
-Doug
-Chris.
On 23/10/2013 15:06, Alan Bateman wrote:
j.u.c.atomic.{Double,Long}.{Accumulator,Adder} extend a package-private
class Striped64 that does striping on 64-bit values. This super type is
Serializable by way of extending Number. Striped64 doesn't contribute
any serial fields but its name does leak into the serial stream because
there is a descriptor for the super type when it is also serializable.
Those that write conformance tests have noticed this.
In practical terms this is a bit of a non-issue but the reference to
Striped64 can be removed from the serial stream by changing these four
to use a serialization proxy. Doug has gone ahead and changed the
classes in jsr166 CVS and we need to bring these changes into jdk8/tl by
the ZBB date.
The webrev with the proposed changes is here:
http://cr.openjdk.java.net/~alanb/8026344/webrev/
A minor difference with what is currently in the CVS is that I've added
a link in the writeReplace javadoc to the proxy class. I've also added a
simple test as I didn't find any tests in the jdk repository that
exercise serialization of these classes.
-Alan.
Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
On 10/23/2013 12:33 PM, Alan Bateman wrote: I might have been tempted to conserve on classes and code duplication to share a serialization proxy between the classes and maybe even shorten the name. But it is hard to argue with the simplicity and directness of this design. I don't have a strong opinion on this, it could be something really like short (if Doug is inclined). Well I was going to call it TheClassThatTheSerializationTestersNeedlesslyRequire, but SerializationProxy is bulky enough to remind me why I did it :-) -Alan.
hg: jdk8/tl/langtools: 8022720: Method refeerences - private method should be accessible (nested classes)
Changeset: 32ea6ccb7607 Author:rfield Date: 2013-10-23 10:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/32ea6ccb7607 8022720: Method refeerences - private method should be accessible (nested classes) Reviewed-by: jjg, ksrini ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/privateMethodReferences/MethodInvoker.java + test/tools/javac/lambda/privateMethodReferences/MethodSupplier.java + test/tools/javac/lambda/privateMethodReferences/ThirdClass.java
Re: RFR: 8026427: deprecate obsolete APIs from java.rmi
With the previous comments in mind, looks OK to me. Darryl On 10/21/2013 07:07 PM, Stuart Marks wrote: Hi all, Please review this small spec change to deprecate some obsolete RMI APIs, along with a bit of associated cleanup. There are no functional changes in this changeset. Bug: https://bugs.openjdk.java.net/browse/JDK-8026427 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8026427/webrev.0/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/8026427/specdiff.0/overview-summary.html Thanks, s'marks
Re: RFR (JAXP enableExtensionFunctions): 8004476 XSLT Extension Functions Don't Work in WebStart
Hi Joe, I believe all the private FeatureManager could be declared final since asfar as I can tell they are only set within the constructor. You could add 'final' to all declaration below: XSLTC.java: 53 private FeatureManager _featureManager; TransformerFactoryImpl.java: 232 private FeatureManager _featureManager; XPathExpressionImpl.java: 72 private FeatureManager featureManager; XPathFactoryImpl.java: 73 private FeatureManager _featureManager; XPathImpl.java: 74 FeatureManager featureManager; Otherwise looks good. -- daniel On 10/22/13 6:55 PM, huizhe wang wrote: Hi, This is a new implementation property that is consistent with recent additions as in JAXP 1.5 in that the scope and order are the same, refer to http://docs.oracle.com/javase/tutorial/jaxp/properties/scope.html. By default, feature enableExtensionFunctions is true. When FEATURE_SECURE_PROCESSING is set to true, the property is set to false allowing no extension functions. Setting FSP to false however will not change the value. The property enableExtensionFunctions is supported by the following API: TransformerFactory factory = TransformerFactory.newInstance(); factory.setFeature(name, value); XPathFactory factory = XPathFactory.newInstance(); factory.setFeature(name, value); Webrevs: http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/ Thanks, Joe
Re: 8026863: regression in anonymous Logger.setParent method
Hi Mandy, Thanks for the review. I have taken the opportunity to further clarify the behavior of the various setters when the logger is an anonymous logger. The fix itself hasn't changed. Here is the new revision: http://cr.openjdk.java.net/~dfuchs/webrev_8026863/webrev.01 best regards, -- daniel On 10/22/13 5:12 PM, Mandy Chung wrote: On 10/21/2013 2:11 PM, Daniel Fuchs wrote: Hi, Please find below a fix for 8026863: regression in anonymous Logger.setParent method This is a regression I introduced in JDK 8 with one of my recent logging fixes: 8023168: Cleanup LogManager class initialization and LogManager/LoggerContext relationship The issue is that whereas an anonymous Logger is specified to not do any security checks, it still did a check for setParent. My fix for 8023168 had the unfortunate side effect of removing that check for anonymous loggers - and here is a changeset that restores the previous behaviour. I also took the opportunity to clarify the spec in that respect. http://cr.openjdk.java.net/~dfuchs/webrev_8026863/webrev.00/ The fix looks good to me. Mandy
hg: jdk8/tl/jdk: 8027176: Remove redundant jdk/lambda/vm/DefaultMethodsTest.java
Changeset: 88acc99132e2 Author:rfield Date: 2013-10-23 11:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88acc99132e2 8027176: Remove redundant jdk/lambda/vm/DefaultMethodsTest.java Reviewed-by: ksrini - test/jdk/lambda/vm/DefaultMethodsTest.java
RFR: update to lambda metafactory spec
This webrev: http://cr.openjdk.java.net/~briangoetz/JDK-8019646/webrev/ contains minor changes to the lambda metafactory implementation, and a significant overhaul of its specification. There are only two behavioral changes, the rest of the changes are in exposition: - Metafactory no longer leaks ReflectiveOperationException - Alternate metafactory no longer infers serializability from presence of serializable supertype; requires FLAG_SERIALIZABLE. This makes alternate metafacory a pure generalization of the fast-path metafactory.
RFR : 8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs
Hi, this is a test stabilization fix for jdk8-tl. It turns out that the wsimport tool sets java.net.useSystemProxies to true. This can cause connection issues to localhost for some windows environments depending on proxy configuration. Best solution here is to disable the systemProxies since we don't need them. The test just needs access to localhost. bug : https://bugs.openjdk.java.net/browse/JDK-8026405 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8026405.jdk8/webrev/ regards, Sean.
Re: RFR : 8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs
Sean, I have seen this test failing consistently on some systems, the use of system proxies would explain that. Your change, to make the test independent of the system proxies, looks good to me. -Chris. On 10/23/2013 08:27 PM, Seán Coffey wrote: Hi, this is a test stabilization fix for jdk8-tl. It turns out that the wsimport tool sets java.net.useSystemProxies to true. This can cause connection issues to localhost for some windows environments depending on proxy configuration. Best solution here is to disable the systemProxies since we don't need them. The test just needs access to localhost. bug : https://bugs.openjdk.java.net/browse/JDK-8026405 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8026405.jdk8/webrev/ regards, Sean.
Re: RFR (JAXP enableExtensionFunctions): 8004476 XSLT Extension Functions Don't Work in WebStart
Hi Daniel, Thanks for the review and the detailed list. I've updated the webrev: http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/ Thanks, Joe On 10/23/2013 11:25 AM, Daniel Fuchs wrote: Hi Joe, I believe all the private FeatureManager could be declared final since asfar as I can tell they are only set within the constructor. You could add 'final' to all declaration below: XSLTC.java: 53 private FeatureManager _featureManager; TransformerFactoryImpl.java: 232 private FeatureManager _featureManager; XPathExpressionImpl.java: 72 private FeatureManager featureManager; XPathFactoryImpl.java: 73 private FeatureManager _featureManager; XPathImpl.java: 74 FeatureManager featureManager; Otherwise looks good. -- daniel On 10/22/13 6:55 PM, huizhe wang wrote: Hi, This is a new implementation property that is consistent with recent additions as in JAXP 1.5 in that the scope and order are the same, refer to http://docs.oracle.com/javase/tutorial/jaxp/properties/scope.html. By default, feature enableExtensionFunctions is true. When FEATURE_SECURE_PROCESSING is set to true, the property is set to false allowing no extension functions. Setting FSP to false however will not change the value. The property enableExtensionFunctions is supported by the following API: TransformerFactory factory = TransformerFactory.newInstance(); factory.setFeature(name, value); XPathFactory factory = XPathFactory.newInstance(); factory.setFeature(name, value); Webrevs: http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/ Thanks, Joe
hg: jdk8/tl/jdk: 8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs
Changeset: ee7f1c78bec7 Author:coffeys Date: 2013-10-23 20:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee7f1c78bec7 8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs Reviewed-by: chegar ! test/javax/xml/ws/clientjar/TestWsImport.java
Re: RFR (JAXP enableExtensionFunctions): 8004476 XSLT Extension Functions Don't Work in WebStart
On 10/23/13 9:42 PM, huizhe wang wrote: Hi Daniel, Thanks for the review and the detailed list. I've updated the webrev: http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/ Looks good! -- daniel Thanks, Joe On 10/23/2013 11:25 AM, Daniel Fuchs wrote: Hi Joe, I believe all the private FeatureManager could be declared final since asfar as I can tell they are only set within the constructor. You could add 'final' to all declaration below: XSLTC.java: 53 private FeatureManager _featureManager; TransformerFactoryImpl.java: 232 private FeatureManager _featureManager; XPathExpressionImpl.java: 72 private FeatureManager featureManager; XPathFactoryImpl.java: 73 private FeatureManager _featureManager; XPathImpl.java: 74 FeatureManager featureManager; Otherwise looks good. -- daniel On 10/22/13 6:55 PM, huizhe wang wrote: Hi, This is a new implementation property that is consistent with recent additions as in JAXP 1.5 in that the scope and order are the same, refer to http://docs.oracle.com/javase/tutorial/jaxp/properties/scope.html. By default, feature enableExtensionFunctions is true. When FEATURE_SECURE_PROCESSING is set to true, the property is set to false allowing no extension functions. Setting FSP to false however will not change the value. The property enableExtensionFunctions is supported by the following API: TransformerFactory factory = TransformerFactory.newInstance(); factory.setFeature(name, value); XPathFactory factory = XPathFactory.newInstance(); factory.setFeature(name, value); Webrevs: http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/ Thanks, Joe
hg: jdk8/tl/langtools: 8026770: javadoc creates invalid HTML in profile summary pages
Changeset: 8746caa5cf80 Author:bpatel Date: 2013-10-23 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8746caa5cf80 8026770: javadoc creates invalid HTML in profile summary pages Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java
Re: RFR (JAXP enableExtensionFunctions): 8004476 XSLT Extension Functions Don't Work in WebStart
looks OK joe On Oct 23, 2013, at 3:42 PM, huizhe wang wrote: Hi Daniel, Thanks for the review and the detailed list. I've updated the webrev: http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/ Thanks, Joe On 10/23/2013 11:25 AM, Daniel Fuchs wrote: Hi Joe, I believe all the private FeatureManager could be declared final since asfar as I can tell they are only set within the constructor. You could add 'final' to all declaration below: XSLTC.java: 53 private FeatureManager _featureManager; TransformerFactoryImpl.java: 232 private FeatureManager _featureManager; XPathExpressionImpl.java: 72 private FeatureManager featureManager; XPathFactoryImpl.java: 73 private FeatureManager _featureManager; XPathImpl.java: 74 FeatureManager featureManager; Otherwise looks good. -- daniel On 10/22/13 6:55 PM, huizhe wang wrote: Hi, This is a new implementation property that is consistent with recent additions as in JAXP 1.5 in that the scope and order are the same, refer to http://docs.oracle.com/javase/tutorial/jaxp/properties/scope.html. By default, feature enableExtensionFunctions is true. When FEATURE_SECURE_PROCESSING is set to true, the property is set to false allowing no extension functions. Setting FSP to false however will not change the value. The property enableExtensionFunctions is supported by the following API: TransformerFactory factory = TransformerFactory.newInstance(); factory.setFeature(name, value); XPathFactory factory = XPathFactory.newInstance(); factory.setFeature(name, value); Webrevs: http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/ Thanks, Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
hg: jdk8/tl/langtools: 2 new changesets
Changeset: abc3eaccba73 Author:jlahoda Date: 2013-10-23 23:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/abc3eaccba73 8027191: Fix for JDK-8026861 refers to an incorrect bug number Summary: Reverting changeset b05db8c815e8, so that it can be applied again with a correct bug number Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java - test/tools/javac/T8019486/WrongLNTForLambdaTest.java + test/tools/javac/T8019486/WrongLVTForLambdaTest.java Changeset: 864dafc5ab7a Author:jlahoda Date: 2013-10-23 07:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/864dafc5ab7a 8026861: Wrong LineNumberTable for variable declarations in lambdas Summary: Setting or correcting positions for many trees produced by LambdaToMethod. Reviewed-by: vromero, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/T8019486/WrongLNTForLambdaTest.java - test/tools/javac/T8019486/WrongLVTForLambdaTest.java
hg: jdk8/tl/jdk: 8024688: further split Map and ConcurrentMap defaults eliminating looping from Map defaults, Map.merge fixes and doc fixes.
Changeset: f4129fcfacdc Author:mduigou Date: 2013-10-23 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4129fcfacdc 8024688: further split Map and ConcurrentMap defaults eliminating looping from Map defaults, Map.merge fixes and doc fixes. Reviewed-by: psandoz, dholmes ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! test/java/util/Map/Defaults.java
Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
On 23 October 2013 17:33, Alan Bateman alan.bate...@oracle.com wrote: I might have been tempted to conserve on classes and code duplication to share a serialization proxy between the classes and maybe even shorten the name. But it is hard to argue with the simplicity and directness of this design. I don't have a strong opinion on this, it could be something really like short (if Doug is inclined). JSR-310 has a shared serialization proxy named Ser (one per package). It can save a lot of space if multiple types are sent. Stephen
Re: RFR: 8023862: deprecate HTTP proxying from RMI
On 10/21/2013 5:23 PM, Stuart Marks wrote:
Hi all,
Please review the following spec change (deprecation) and change of a
property default value.
Briefly, RMI has some machinery that will attempt to tunnel RMI
requests through HTTP under certain circumstances. This is a
maintenance burden and also causes customer confusion. The change here
deprecates the HTTP tunneling mechanism and changes a property to
disable HTTP tunneling by default.
...
Webrev:
http://cr.openjdk.java.net/~smarks/reviews/8023862/webrev.0/
This change looks fine. Just minor comments:
java/rmi/server/RMISocketFactory.java
47 * value to {@code false} will re-enable the HTTP tunneling mechanisms.
nit: In the context of a specification, would it be appropriate to say
enable instead of re-enable?
sun/rmi/transport/proxy/RMIMasterSocketFactory.java
line 120-123 which is existing code: is this catch block redundant?
I assume that separate bug will be filed to update the RMI documentations.
Mandy
hg: jdk8/tl/jdk: 8025868: Several lang/LMBD JCK tests fail with java.lang.BootstrapMethodError
Changeset: d9d3705a992f Author:rfield Date: 2013-10-23 15:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d9d3705a992f 8025868: Several lang/LMBD JCK tests fail with java.lang.BootstrapMethodError Summary: Wildcard marker interfaces can cause duplicate implemented interfaces in generated lambda class Reviewed-by: briangoetz ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/DupIntf.java
RFR 8025003: Base64 should be less strict with padding
Hi, The current spec and implementation of Base64 decoder [1] is standard/rfc based, in which it interprets/decodes the ending padding character(s) correctly if present. The ending padding character(s) is not requested (liberal), but if present, the spec and implementation requests they MUST be encoded correctly, any incorrect padding combination at the final unit (as listed below) is treated as incorrect encoded base64 data and results in exception. Patterns of possible incorrectly encoded padding final base64 unit are: = unnecessary padding character at the end of encoded stream xx= missing the last padding character xx=ymissing the last padding character, instead having a non-padding char The feedback we got so far suggests that incorrectly encoded padding unit might might be frequently observed in real world use scenario, especially in the MIME/email world, it might be desired to just accept these incorrectly encoded ending unit and decode the rest successfully without throwing an exception. It is also suggested it might be more appropriate to rename Base64.getEncoder(int lineLength, byte[] sept) to be Base64.getMimeEncoder(int, byte[]). The proposed changes here are to (1) rename the factory method for the customizable mime encoder to Base.getMimeEncoder(int, byte[]); (2) change the spec/implementation for the mime decoder to be lenient when handing the padding character in the final unit (mime decoder itself is lenient already. Its spec requests any non-base64 character during encoding. And our existing decoder is liberal when there is no padding present at all) Here is the webrev http://cr.openjdk.java.net/~sherman/8025003/webrev/ thanks! -Sherman Btw, updated mime decoder stilll throws exception for pattern like x=... or x, in which the last unit only has one valid byte/6-bit data. It's not sufficient to be decoded into a valid 8-bit/byte data.
JDK 8 RFR 4891331: BigInteger a.multiply(a) should use squaring code
Please review this patch at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-4891331 Webrev: http://cr.openjdk.java.net/~bpb/4891331/webrev/ This review request follows from this RFC thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022266.html More extensive micro-benchmark testing was performed using JMH [1] for the following cases: 1) multiply: current version of multiply() 2) multiplyNonSquare: proposed version of multiply() with parameter val such that (val != this val.equals(this)) == true 3) multiplyPowTwo: multiply by val == this with squaring performed via pow(2) 4) multiplySquare: proposed version of multiply() with parameter val such that val == this 5) powTwo: straightforward call of pow(2) 6) square: straightforward call of square() Test #1 represents current performance of multiplying two identical instances without squaring code. Test #2 represents performance after the patch when squaring code is *not* used, i.e., measures effect of val == this equality check. Test #4 represents performance after the patch when squaring code *is* used for the case of mag.length = 8. Tests #3, #5, and #6 are for informative purposes. The following bit lengths were tested: 32, 64, 96, 128, 160, 192, 224, 256, 288, 320, 384, 416, 448, 480, 512, 768, 1024, 1280, 1536. The following JMH parameters were used across all runs: # Forks: 5 # Warmup: 5 iterations, 1 s each # Measurement: 8 iterations, 3 s each # Benchmark mode: Throughput, ops/time Two sets of runs were performed on each of two platforms, one single-threaded and one with number of threads equal to the number of hardware cores, 4 in one case (Linux) and 8 in the other (Mac OS X). Linux system: 4 X Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz. Mac system: 8 X Intel(R) Xeon(R) CPU E5520 @ 2.27GHz Summaries of the aggregate tests results are available at [2], [3], [4], and [5] in terms of 99% confidence intervals in operations per millisecond. The results suggest that the effect of the equality test (val == this) is insignificant. Significant performance improvement was however observed for squaring of values with int array magnitude length = 8. The performance gain was up to 150-200% for the largest bit length tested (1536). Larger bit lengths were not tested as those would enter the current range of Karatsuba multiplication (= 1600 bits). While not pertinent to this review per se, it should be noted that the performance of pow(2) approaches that of square() as the bit length increases. It might be worth a subsequent investigation to determine whether there is a second threshold beyond which pow(2) overtakes square() altogether. Results for the same set of tests on a Windows 4 X Core-i7 860 2.8Ghz should be available tomorrow. More limited testing previously performed on Windows produced in relative terms results similar to the those obtained on Linux and Mac OS X. Lastly, I am not sure that the @implNote is necessary or even desirable here and if so whether a CCC request would be in order. Also note that if there were any doubt as to the exact threshold which ought to be used, then a slightly higher value than 8 could be used or the threshold test could be changed to a strict instead of =. Thanks, Brian [1] http://openjdk.java.net/projects/code-tools/jmh/ [2] http://cr.openjdk.java.net/~bpb/4891331/linux-threads-1.html [3] http://cr.openjdk.java.net/~bpb/4891331/linux-threads-4.html [4] http://cr.openjdk.java.net/~bpb/4891331/macosx-threads-1.html [5] http://cr.openjdk.java.net/~bpb/4891331/macosx-threads-8.html
hg: jdk8/tl/langtools: 8026936: Initialize LamdbaToMethod lazily and as required
Changeset: 31fe30e2deac Author:ksrini Date: 2013-10-23 15:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/31fe30e2deac 8026936: Initialize LamdbaToMethod lazily and as required Reviewed-by: jjg, rfield Contributed-by: jan.lah...@oracle.com ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
Re: RFR: 8023862: deprecate HTTP proxying from RMI
On 10/23/13 3:13 PM, Mandy Chung wrote:
On 10/21/2013 5:23 PM, Stuart Marks wrote:
Please review the following spec change (deprecation) and change of a property
default value.
Briefly, RMI has some machinery that will attempt to tunnel RMI requests
through HTTP under certain circumstances. This is a maintenance burden and
also causes customer confusion. The change here deprecates the HTTP tunneling
mechanism and changes a property to disable HTTP tunneling by default.
...
Webrev:
http://cr.openjdk.java.net/~smarks/reviews/8023862/webrev.0/
This change looks fine. Just minor comments:
Hi Mandy,
Thanks for taking a look at this.
java/rmi/server/RMISocketFactory.java
47 * value to {@code false} will re-enable the HTTP tunneling mechanisms.
nit: In the context of a specification, would it be appropriate to say enable
instead of re-enable?
Yes, good suggestion, saying just enable reads better here. Will fix.
sun/rmi/transport/proxy/RMIMasterSocketFactory.java
line 120-123 which is existing code: is this catch block redundant?
It's quite possibly redundant. It's hard to see how the code in the try block
could throw an exception, but if one is thrown, it needs to be caught in order
for the constructor to complete normally.
But setting the setFactories variable to false in the catch block is certainly
unnecessary, since setFactories is only set to true -- if it's set at all -- at
the very end of the try-block. I'll remove this and clarify the comment.
I assume that separate bug will be filed to update the RMI documentations.
Yes, I have a bunch of pending items to update the corresponding documentation,
which will be done separately from the code and javadoc updates here.
Mandy
Thanks!
s'marks
hg: jdk8/tl/langtools: 8006732: support correct bytecode storage of type annotations in multicatch
Changeset: d2fa3f7e964e Author:emc Date: 2013-10-23 23:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d2fa3f7e964e 8006732: support correct bytecode storage of type annotations in multicatch Summary: Fix issue with annotations being added before attribution, which causes multicatch not to work right and several tests to fail. Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java
hg: jdk8/tl/langtools: 8023682: Incorrect attributes emitted for anonymous class declaration
Changeset: 119747cd9f25 Author:emc Date: 2013-10-24 01:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/119747cd9f25 8023682: Incorrect attributes emitted for anonymous class declaration Summary: Cause javac to emit type annotations on new instruction as well as anonymous class supertype for annotated anonymous classes. Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/typeAnnotations/failures/TypeOnAnonClass.java + test/tools/javac/annotations/typeAnnotations/failures/TypeOnAnonClass.out ! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out ! test/tools/javac/annotations/typeAnnotations/newlocations/AnonymousClass.java
hg: jdk8/tl/jdk: 7122887: JDK ignores Gnome3 proxy settings
Changeset: c9562ac9b812 Author:dxu Date: 2013-10-23 22:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9562ac9b812 7122887: JDK ignores Gnome3 proxy settings Summary: Fix GConf and add to use GProxyResolver to handle network proxy resolution Reviewed-by: chegar ! src/solaris/native/sun/net/spi/DefaultProxySelector.c ! test/java/net/ProxySelector/SystemProxies.java
