Claes Redestad | 13 Aug 16:02 2014
Picon

RFR(S): 8055032: Improve numerical parsing in java.net and sun.net

Hi,

can I have a review for this patch to take advantage of offset-based 
parseInt methods added in
8041972 for java.net/sun.net classes?

bug: https://bugs.openjdk.java.net/browse/JDK-8055032
webrev: http://cr.openjdk.java.net/~redestad/8055032/webrev.0

This causes fewer temporary String objects to be allocated and shows a 
direct throughput improvement
in micros (1.2x in java.net.URLDecoder#decode and 
sun.net.www.ParseUtil#decode, for example)

/Claes

Mark Sheppard | 7 Aug 20:15 2014
Picon

RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently

Hi,
   please oblige and review the following fix
http://cr.openjdk.java.net/~msheppar/8054118/webrev/

to address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8054118

The Windows test environment has a Teredo interface.
This oscillates between being configured with IPv6 and not been configured.
The configured state is transient. When configured its IPv6 is retrieved as
first local ipv6 address. As such, it can happen that during the test the
interface is disabled, and the test will fail with the report Socket 
receive timeout.

This fix removes the Teredo interface from the testing scenario, so that 
a more stable interface
will be used.

regards
Mark

Wang Weijun | 1 Aug 07:39 2014
Picon

nameservers in solaris/.../ResolverConfigurationImpl not static

There are 2 sun.net.dns.ResolverConfigurationImpl implementations. The cached searchlist and
nameservers in the solaris version are instance fields and those in windows are static. The cache
mechanism in both is guarded by static fields changed and lastRefresh. Therefore it seems the solaris
searchlist/nameservers should also be static.

--Max

Amanda Jiang | 29 Jul 00:25 2014
Picon

RFR 8047031: Need new tests to check socket permission

Hi All,

Could you please review 1 new test to be added for SocketPermission.
New test is added to check socket permissions, for instance -
- java.net.SocketPermission with "connect", "resolve", "accept", "listen"
with Socket, DatagramSocket, MulticastSocket etc.

JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8047031
WebRev: http://cr.openjdk.java.net/~rhalade/8047031/webrev.00/

Thanks,
Amanda

Rob McKenna | 24 Jul 22:54 2014
Picon

RFR: 8031435: Ftp download does not work properly for ftp user without password

Hi folks,

Very simple fix to allow FtpURLConnection connect without a password in 
the url. (i.e. ftp://user <at> server/ as opposed to the current 
ftp://user: <at> server)

http://cr.openjdk.java.net/~robm/8031435/webrev.01/

     -Rob

Andreas Rieber | 17 Jul 20:03 2014
Picon

JDK-6797318: Undeclared IAE thrown from HttpURLConnection.connect for some URLs

Hi,

i would like to contribute a patch for this old issue. The suggested
fix in the issue looks right but instead of the IOE it would simply
connect to localhost. The same wrong behaviour can be reproduced
with ProxySelector.setDefault(null).

I also checked other protocols and http, https and ftp are affected.
The hostname is not checked currently and the used
InetAddress.getAllByName(host) just returns the "loopbackAdress" if
hostname is empty.

Running the test under security manager got me a
StringIndexOutOfBoundsException from the URLPermission/HostPortrange,
where the hostname is not checked for empty string.

With the test i try to cover all cases. Simple connect, with no
ProxySelector, wrong redirect URL and all with security manager.

Bug:
https://bugs.openjdk.java.net/browse/JDK-6797318

Bug also fixed with no additional change (test included):
https://bugs.openjdk.java.net/browse/JDK-6563286

Webrev:
http://cr.openjdk.java.net/~arieber/6797318/webrev.00/

I did run jtreg */net */security on Ubuntu 14, Solaris 11 and Windows 8.1.
Sponsor required as usually.
(Continue reading)

Mark Sheppard | 17 Jul 13:01 2014
Picon

RFR: JDK-8050922 - add additional diagnostic to java/net/MulticastSocket/TestInterfaces.java

Hi,
    please oblige and review the following diagnostic output addition to
the test java/net/MulticastSocket/TestInterfaces.java

http://cr.openjdk.java.net/~msheppar/8050922/webrev/

for the task

https://bugs.openjdk.java.net/browse/JDK-8050922

which will assist in diagnosing an intermittent failing test
https://bugs.openjdk.java.net/browse/JDK-8041677

the addition displays the interface details, of the failing scenario,  
to std err

regards
Mark

Mark Sheppard | 16 Jul 19:00 2014
Picon

RFR: JDK-8040810 - Uninitialised memory in jdk/src/windows/native/java/net: net_util_md.c, TwoStacksPlainSocketImpl.c, TwoStacksPlainDatagramSocketImpl.c, DualStackPlainSocketImpl.c, DualStackPlainDatagramSocketImpl.c

Hi
     please oblige and review the following changes

http://cr.openjdk.java.net/~msheppar/8040810/webrev/

which address the issue raised in

https://bugs.openjdk.java.net/browse/JDK-8040810

resulting from static code analysis.

these changes explicitly initialize local function variables, which are 
in the main
out parameters to other function calls and hence are set within the 
called function.
It can be reasonably argued that the initialization is unnecessary, but 
current coding
guidance is to perform the initialization

regards
Mark

Peter Levart | 11 Jul 17:11 2014
Picon

URL constructor/equals/hashCode/sameFile/openConnection synchronization issues

Hi,

java.net.URL is supposed to behave as an immutable object, so URL 
instances can be shared among threads and among parts of code without 
fear that they will be modified. URL class has an unusual way to achieve 
this (or at least it tries to). Partly because of the design which uses:

- URL constructor(s) that take a 'spec' String to be parsed into URL object
- parsing is delegated to various URLStreamHandler(s) which are chosen 
in the URL constructor (depending on the protocol used in URL string to 
be parsed)

An unitialized URL instance (this) is passed from constructor to the 
chosen URLStreamHandler which has the responsibility to parse the string 
and set back the fields that hold various parts of URL object being 
constructed. Consequently, these fields can not be declared as final, as 
definite assignment analysis doesn't cross method borders. It is 
therefore illegal to unsafely publish URL instances (via data races) to 
non-constructing threads because they can appear not fully initialized. 
Nevertheless URL, with the help of various URLStreamHandler 
implementations, tries hard to make URL appear stable at least where it 
is required to be stable. For example: URL.hashCode() is (almost) stable 
even if URL instance is unsafely published. This is achieved by making 
hashCode() synchronized and cache the result. At least one way of 
constructing URLs - constructors that take 'spec' String to be parsed - 
is also making sure that hashCode is computed from fully initialized 
fields, as parsing is delegated to URLStreamHandler which uses 
package-private URL.set() method to set back the parsed fields and the 
set() method is also synchronized. But making URL appear stable even 
though it is published unsafely doesn't seem to be the primary concern 
(Continue reading)

Peter Firmstone | 10 Jul 02:50 2014
Picon

java.net.URI and RFC 3986 compliance

Are there parties on this list interested in updating java.net.URI to 
RFC3986?

Is there anyone here who has previously attempted this?  If so what 
issues did you find with regard to backward compatibility?

Regards,

Peter.

Peter Levart | 9 Jul 14:12 2014
Picon

Re: RFR JDK-8049228: Improve multithreaded scalability of InetAddress cache

On 07/09/2014 01:54 PM, Claes Redestad wrote:
> I see you're still expanding scope from private to package:
>
> -    private static InetAddress[] getAddressesFromNameService(String 
> host, InetAddress reqAddr)
> +    static InetAddress[] getAddressesFromNameService(String host, 
> InetAddress reqAddr)
>
> /Claes

Thanks for being alert, Claes. I think I own an explanation. After you 
have notified me about this the 1st time, I remembered why I dropped the 
"private" from method declaration in the first place. The method is now 
called from within NameServiceAddresses inner class. I wanted to 
suppress javac from generating synthetic access methods. Since java.net 
is a sealed package, there's no security issue, am I right?

Regards, Peter

>
> On 07/09/2014 01:52 PM, Peter Levart wrote:
>> Hi Michael,
>>
>> Thanks for testing. I have prepared another webrev:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.03/ 
>>
>>
>> It only cleans up two comments suggested by Bernd (removed 
>> superfluous phrase "with 0" from statements about comparing time 
(Continue reading)


Gmane