hg: jdk8/tl/langtools: 8009138: javac, equals-hashCode warning tuning
Changeset: 3806171b52d8 Author:vromero Date: 2013-03-07 10:04 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3806171b52d8 8009138: javac, equals-hashCode warning tuning Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/6563143/EqualsHashCodeWarningTest.java + test/tools/javac/6563143/EqualsHashCodeWarningTest.out - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out
hg: jdk8/tl/langtools: 8009170: Regression: javac generates redundant bytecode in assignop involving arrays
Changeset: 823fb9229724 Author:vromero Date: 2013-03-07 10:12 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/823fb9229724 8009170: Regression: javac generates redundant bytecode in assignop involving arrays Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java + test/tools/javac/8009170/RedundantByteCodeInArrayTest.java
hg: jdk8/tl/jdk: 6370908: Add support for HTTP_CONNECT proxy in Socket class
Changeset: 48b7295f02f8 Author:chegar Date: 2013-03-07 10:07 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48b7295f02f8 6370908: Add support for HTTP_CONNECT proxy in Socket class Reviewed-by: chegar Contributed-by: Damjan Jovanovic , Chris Hegarty + src/share/classes/java/net/HttpConnectSocketImpl.java ! src/share/classes/java/net/Socket.java + test/java/net/Socket/HttpProxy.java
Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed
Hi folks, This is a slight alteration of the fix contributed by Stuart Douglas. This fix deals with a SocketException caused by getSoTimeout() on a closed connection. http://cr.openjdk.java.net/~robm/8009650/webrev.01/ -Rob
Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed
I am wondering why do you need two try-catch blocks here. - Kurchi On 3/7/13 8:18 AM, Rob McKenna wrote: Hi folks, This is a slight alteration of the fix contributed by Stuart Douglas. This fix deals with a SocketException caused by getSoTimeout() on a closed connection. http://cr.openjdk.java.net/~robm/8009650/webrev.01/ -Rob
Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed
The outer try/catch is meant to catch potential exceptions originating from the inner try/finally. (from setSoTimeout) -Rob On 07/03/13 16:51, Kurchi Subhra Hazra wrote: I am wondering why do you need two try-catch blocks here. - Kurchi On 3/7/13 8:18 AM, Rob McKenna wrote: Hi folks, This is a slight alteration of the fix contributed by Stuart Douglas. This fix deals with a SocketException caused by getSoTimeout() on a closed connection. http://cr.openjdk.java.net/~robm/8009650/webrev.01/ -Rob
Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed
I've fleshed out the bug report a little to make that clearer, sorry Kurchi! Also, I'll add a testcase to this review soon. -Rob On 07/03/13 16:51, Kurchi Subhra Hazra wrote: I am wondering why do you need two try-catch blocks here. - Kurchi On 3/7/13 8:18 AM, Rob McKenna wrote: Hi folks, This is a slight alteration of the fix contributed by Stuart Douglas. This fix deals with a SocketException caused by getSoTimeout() on a closed connection. http://cr.openjdk.java.net/~robm/8009650/webrev.01/ -Rob
Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed
Thanks Rob. Also, I am now looking at the previous changeset[1] where the regression was introduced, once available() figures out that a cached connection is no longer active, it should probably be removed from the cache. (setting ret to null doesn't remove it from the cache). If there were other reasons for not removing it from the cache that I am missing, that is fine - otherwise maybe we can file a separate bug for this. Thanks, Kurchi [1] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/diff/e6dc1d9bc70b/src/share/classes/sun/net/www/http/HttpClient.java On 3/7/2013 1:19 PM, Rob McKenna wrote: I've fleshed out the bug report a little to make that clearer, sorry Kurchi! Also, I'll add a testcase to this review soon. -Rob On 07/03/13 16:51, Kurchi Subhra Hazra wrote: I am wondering why do you need two try-catch blocks here. - Kurchi On 3/7/13 8:18 AM, Rob McKenna wrote: Hi folks, This is a slight alteration of the fix contributed by Stuart Douglas. This fix deals with a SocketException caused by getSoTimeout() on a closed connection. http://cr.openjdk.java.net/~robm/8009650/webrev.01/ -Rob -- -Kurchi
Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed
Rob,
Is it possible to avoid code duplication?
i.e. do something like this:
int r;
try {
...
} catch (SocketException e) {
// Comments goes here
r = -1
}
if (r == -1){
if (logger. ...
available = false;
}
return available;
-Dmitry
On 2013-03-07 20:18, Rob McKenna wrote:
> Hi folks,
>
> This is a slight alteration of the fix contributed by Stuart Douglas.
> This fix deals with a SocketException caused by getSoTimeout() on a
> closed connection.
>
> http://cr.openjdk.java.net/~robm/8009650/webrev.01/
>
> -Rob
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed
Hi Dmitry,
I'm not 100% sure what you mean by duplication, the exceptions and their
messages are distinct. I think it would be best to keep it that way.
-Rob
On 07/03/13 22:00, Dmitry Samersoff wrote:
Rob,
Is it possible to avoid code duplication?
i.e. do something like this:
int r;
try {
...
} catch (SocketException e) {
// Comments goes here
r = -1
}
if (r == -1){
if (logger. ...
available = false;
}
return available;
-Dmitry
On 2013-03-07 20:18, Rob McKenna wrote:
Hi folks,
This is a slight alteration of the fix contributed by Stuart Douglas.
This fix deals with a SocketException caused by getSoTimeout() on a
closed connection.
http://cr.openjdk.java.net/~robm/8009650/webrev.01/
-Rob
Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed
Rob,
Sorry for not being clean enough. We have repeated pattern:
if (logger.isLoggable(PlatformLogger.FINEST)) {
logger.finest("HttpClient.available(): " + msg
}
so it makes code better readable if we can put it to some common place.
-Dmitry
On 2013-03-08 02:31, Rob McKenna wrote:
> Hi Dmitry,
>
> I'm not 100% sure what you mean by duplication, the exceptions and their
> messages are distinct. I think it would be best to keep it that way.
>
> -Rob
>
> On 07/03/13 22:00, Dmitry Samersoff wrote:
>> Rob,
>>
>> Is it possible to avoid code duplication?
>>
>> i.e. do something like this:
>>
>> int r;
>>
>> try {
>>...
>> } catch (SocketException e) {
>> // Comments goes here
>> r = -1
>> }
>>
>> if (r == -1){
>>if (logger. ...
>>available = false;
>> }
>>
>>return available;
>>
>> -Dmitry
>>
>>
>> On 2013-03-07 20:18, Rob McKenna wrote:
>>> Hi folks,
>>>
>>> This is a slight alteration of the fix contributed by Stuart Douglas.
>>> This fix deals with a SocketException caused by getSoTimeout() on a
>>> closed connection.
>>>
>>> http://cr.openjdk.java.net/~robm/8009650/webrev.01/
>>>
>>> -Rob
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed
Ah, I see what you mean. Can do.
-Rob
On 07/03/13 23:13, Dmitry Samersoff wrote:
Rob,
Sorry for not being clean enough. We have repeated pattern:
if (logger.isLoggable(PlatformLogger.FINEST)) {
logger.finest("HttpClient.available(): " + msg
}
so it makes code better readable if we can put it to some common place.
-Dmitry
On 2013-03-08 02:31, Rob McKenna wrote:
Hi Dmitry,
I'm not 100% sure what you mean by duplication, the exceptions and their
messages are distinct. I think it would be best to keep it that way.
-Rob
On 07/03/13 22:00, Dmitry Samersoff wrote:
Rob,
Is it possible to avoid code duplication?
i.e. do something like this:
int r;
try {
...
} catch (SocketException e) {
// Comments goes here
r = -1
}
if (r == -1){
if (logger. ...
available = false;
}
return available;
-Dmitry
On 2013-03-07 20:18, Rob McKenna wrote:
Hi folks,
This is a slight alteration of the fix contributed by Stuart Douglas.
This fix deals with a SocketException caused by getSoTimeout() on a
closed connection.
http://cr.openjdk.java.net/~robm/8009650/webrev.01/
-Rob
