date:20131108


On 08/11/2013 00:39, David Holmes wrote:


And linux? It has changed to vfork right?

So OSX has changed, linux has changed, but Solaris remains as-is. All 
platforms allow selecting the mechanism via the property 
jdk.lang.Process.launchMechanism


The only change is OSX where the default switches from fork to 
posix_spawn. No change to the default on Solaris or Linux.


-Alan.

hg: jdk8/tl/jdk: 8027752: sun/tools/jstatd/TestJstatdExternalRegistry.java: java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object

2013-11-08 Thread staffan . larsen

Changeset: 8a4405fb40ba
Author:ykantser
Date:  2013-11-07 16:55 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a4405fb40ba

8027752: sun/tools/jstatd/TestJstatdExternalRegistry.java: 
java.lang.SecurityException: attempt to add a Permission to a readonly 
Permissions object
Reviewed-by: sla, jbachorik

! test/sun/tools/jstatd/JstatdTest.java

Re: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script


On 08/11/2013 03:41, Patrick Zhang wrote:

Sorry, I have some problems to connect to cr.openjdk.java.net yesterday.
Now the webrev  and result are attached. Please help to review.
After checking the scripts in java.util, most of scripts have been 
finished in 8003890. So the webrev only change 2 rest files.


webrev:
http://cr.openjdk.java.net/~pzhang/8019502/webrev/

result:
http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr
http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr

cc'ing i18n-dev as that is where Calendar (and its tests) are maintained.

The change look okay to me but I wonder if perhaps you have the wrong 
bug number. JDK-8019502 is a confused bug but I think it was originally 
intended to be an audit of the tests that use Runtime.exec or 
ProcessBuilder to see if they should be changed to pass the options 
through. I just mention it as I suspect you might need to create a new 
bug for this and then split up JDK-8019502 into other tasks.


-Alan

RE: 8028027: serialver should emit declaration with the 'private' modifier

Hi Stuart,

Unfortunately, several Java SE interfaces have public SVUIDs, so the fix can 
cause confusion:

$ serialver java.security.PublicKey
java.security.PublicKey:private static final long serialVersionUID = 
7187392471159151072L;

$ javap java.security.PublicKey
Compiled from PublicKey.java
public interface java.security.PublicKey extends java.security.Key {
  public static final long serialVersionUID;
}

Thanks,
-Yuri

-Original Message-
From: core-libs-dev-boun...@openjdk.java.net 
[mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Stuart Marks
Sent: Friday, November 8, 2013 7:03 AM
To: core-libs-dev
Subject: RFR: 8028027: serialver should emit declaration with the 'private' 
modifier

Hi all,

Please review this quick one-liner to change the serialver tool so that it 
emits a serialVersionUID declaration with the 'private' modifier, which 
comports with the recommendation in the java.io.Serializable page.

Bug:

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

Patch appended below.

Thanks,

s'marks


--


# HG changeset patch
# User smarks
# Date 1383868023 28800
# Node ID 1e1088bfea50d7d3cc7cfdce2b0085b7adc6a180
# Parent  f18b60bd22a1be988d329960c46d504f4b75000f
8028027: serialver should emit declaration with the 'private' modifier
Reviewed-by: XXX

diff -r f18b60bd22a1 -r 1e1088bfea50
src/share/classes/sun/tools/serialver/SerialVer.java
--- a/src/share/classes/sun/tools/serialver/SerialVer.java  Thu Nov 07 
15:45:21 
2013 -0800
+++ b/src/share/classes/sun/tools/serialver/SerialVer.java  Thu Nov 07 
15:47:03 
2013 -0800
@@ -211,7 +211,7 @@
  Class? cl = Class.forName(classname, false, loader);
  ObjectStreamClass desc = ObjectStreamClass.lookup(cl);
  if (desc != null) {
-return static final long serialVersionUID =  +
+return private static final long serialVersionUID =  +
  desc.getSerialVersionUID() + L;;
  } else {
  return null;

Re: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script

2013-11-08 Thread Patrick Zhang


Hi Alan,

I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to hold it.

Regards
Patrick

On 11/8/13 5:24 PM, Alan Bateman wrote:

On 08/11/2013 03:41, Patrick Zhang wrote:

Sorry, I have some problems to connect to cr.openjdk.java.net yesterday.
Now the webrev  and result are attached. Please help to review.
After checking the scripts in java.util, most of scripts have been 
finished in 8003890. So the webrev only change 2 rest files.


webrev:
http://cr.openjdk.java.net/~pzhang/8019502/webrev/

result:
http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr
http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr

cc'ing i18n-dev as that is where Calendar (and its tests) are maintained.

The change look okay to me but I wonder if perhaps you have the wrong 
bug number. JDK-8019502 is a confused bug but I think it was 
originally intended to be an audit of the tests that use Runtime.exec 
or ProcessBuilder to see if they should be changed to pass the options 
through. I just mention it as I suspect you might need to create a new 
bug for this and then split up JDK-8019502 into other tasks.


-Alan

Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

2013-11-08 Thread Tristan Yan


/Thank you, Stuart
There is one review point I want to ask you opinion. Which is the reason 
that I moved from test/java/rmi/reliability/benchmark/bench/rmi to 
test/java/rmi/reliability/benchmark is Main.java need access class 
TestLibrary for supporting random port. TestLibrary is a unpackage 
class, I couldn't find a way to let a class which has Package to access 
the class without package. Do you have suggestion on that?

Thank you so much.
Tristan

On 11/06/2013 09:50 AM, Stuart Marks wrote:
/

/
/ /
On 11/1/13 9:18 AM, Tristan Yan wrote:
/

/Hi Everyone
http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/
/ /
Description:
1. Convert shell script test to Java program test.
2. Using random server port by reusing Darryl Mocek's work to replace 
fixed

server port.
3. Using java Process class to start client process.
4. Also convert other shell script test runSerialBench.sh to java 
program test also

/

/
Hi Tristan,
/ /
Several comments on this webrev.
/ /
/ /
** The original arrangement within the 
test/java/rmi/reliability/benchmark directory had the main benchmark 
files (scripts) at the top, some benchmark framework files in the 
bench subdirectory, and the actual RMI and serialization benchmarks 
in bench/rmi and bench/serial subdirectories.

/ /
The webrev moves all the RMI benchmarks to the top benchmark directory 
but leaves the serial benchmarks in bench/serial. The RMI benchmarks 
are now all cluttering the top directory, but the main serial 
benchmark test is now buried in the bench/serial directory. The nice 
organization that was there before is now spoiled. Is this 
rearrangement necessary in order to convert the scripts to Java? I 
would prefer the original arrangement be left in place.

/ /
/ /
** The RMI benchmark Main.java file has a @run tag of the form,
/ /
@run main/othervm/policy=policy.all/timeout=1800 -server Main -c 
config

/ /
There is a subtle but serious problem here: the -server option is 
passed to the JVM and not as an argument to the main() method. The 
main() method gets neither a -server nor a -client argument, so its 
default run mode as defined by the benchmark itself is SAMEVM. This 
runs the client and server in the same JVM, which is different from 
the shell script, which ran separate client and server JVMs.

/ /
/ /
** The logic to process the -server argument still expects to take a 
port, even though the port is assigned automatically. So the obvious 
fix to the above,

/ /
@run main/othervm/policy=policy.all/timeout=1800 Main -server -c 
config

/ /
doesn't work, since a port is missing. The logic to increment the 
argument index to collect the port argument should be removed. Also, 
the -server line should be restored to the usage message, but without 
the port argument.

/ /
/ /
** After this is done, the client's command line is constructed 
improperly. The command line ends up looking something like this:

/ /
java client -cp classpath Main client localhost:58583 -c config
/ /
The word client appears twice, but what's really required is 
-client to appear as an argument after Main.

/ /
/ /
** The client is run using ProcessBuilder, which by default sends 
stdout and stderr to pipes to be read by the parent. But the parent 
never reads them, thus any messages from the client are never seen. 
The client is the one that emits the benchmark report, so its output 
needs to be seen. It might be sufficient to have the client inherit 
the parent's stdout and stderr. This might intermix the client's and 
server's output, but it's better than nothing.

/ /
/ /
** The config file is checked with the following code:
/ /
try {
confFile = args[i];
confstr = new FileInputStream(System.getProperty(test.src)
+ System.getProperty(file.separator) + confFile);
} catch (IOException e) {
die(Error: unable to open \ + args[i] + \);
}
/ /
This is potentially misleading, as the message doesn't print the 
actual filename that was attempted to be opened.

/ /
This is important, as the test.src property doesn't exist in the 
client JVM.

/ /
Note that the original shell script passed full pathnames for the 
config file to both the client and the server. The new @run tag merely 
says -c config which redefines the config filename to be relative to 
the test.src directory. You could pass -Dtest.src=... to the client, 
but it seems like there should be something better than can be done.

/ /
/ /
** The client needs to have its security policy set up. This is 
missing from the construction of the client's command line.

/ /
/ /
** ProcessBuilder takes a ListString for its command; there is no 
need to turn the list into an array.

/ /
/ /
** In the benchmark main methods, code of the form,
/ /
while (true) {
runBenchmarks();
if (exitRequested) {
System.exit();
}
}
/ /
was replaced with
/ /
while (!exitRequested) {
runBenchmarks();
}
/ /
This is a subtle

Re: i18n dev RFR: 8027370: (tz) Support tzdata2013h

2013-11-08 Thread Aleksej Efimov


 Hi,
Can I ask reviewers to look at this fix? As was mentioned, the testing 
issues described in request were resolved.


Thanks in advance,
Aleksej

On 11/06/2013 11:11 PM, Aleksej Efimov wrote:

Hi,
We have a fix for JDK-8027848 and it was approved in parallel thread. 
With '-XX:-UseMathExactIntrinsics' tests run flag and applied fix for 
JDK-8027848 all tests from the following test sets are passing: 
test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone test/java/time test/java/util/Formatter.
I suppose, that we're good to go with this change, unless there are  
some comments or issues.


-Aleksej

On 11/05/2013 10:07 PM, Aleksej Efimov wrote:

Alan,
Thank you for advise.
I have executed the same test sets with -XX:-UseMathExactIntrinsics 
and, as was expected, there is only one failure: 
sun/util/calendar/zi/TestZoneInfo310.java.


-Aleksej

On 11/05/2013 09:50 PM, Alan Bateman wrote:

On 05/11/2013 16:38, Aleksej Efimov wrote:

Hi,

Can I have a review for tzdata2013h integration [1]. The webrev 
link can be located here [2].


The following test sets were executed on build with fix:
test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone test/java/time test/java/util/Formatter


And here is the list of failures:
FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1%
FAILED: java/time/tck/java/time/TCKInstant.java %1%
FAILED: java/time/tck/java/time/TCKLocalDate.java %1%
FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1%
FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1%
FAILED: java/time/tck/java/time/TCKOffsetTime.java %1%
FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1%
FAILED: 
java/time/test/java/time/format/TestZoneTextPrinterParser.java %1%

FAILED: java/util/Calendar/JavatimeTest.java %1%

FAILED: sun/util/calendar/zi/TestZoneInfo310.java


The group %1% tests failures relates to the JDK-8027622 bug and are 
expected (actually, it was already resolved in hotspot repo).
In another thread, Amy Lu is updating the ProblemList.txt to exclude 
these tests until the hotspot fix gets to jdk8/tl. For your testing 
then you could run with -XX:-UseMathExactIntrinsics and check that 
the all tests related to time and time zones are passing.


-Alan.

Re: RFR: 8028027: serialver should emit declaration with the 'private' modifier

2013-11-08 Thread Chris Hegarty


Looks good to me. It should have been this way from day one.

-Chris.

On 08/11/2013 03:02, Stuart Marks wrote:

Hi all,

Please review this quick one-liner to change the serialver tool so that
it emits a serialVersionUID declaration with the 'private' modifier,
which comports with the recommendation in the java.io.Serializable page.

Bug:

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

Patch appended below.

Thanks,

s'marks


--


# HG changeset patch
# User smarks
# Date 1383868023 28800
# Node ID 1e1088bfea50d7d3cc7cfdce2b0085b7adc6a180
# Parent f18b60bd22a1be988d329960c46d504f4b75000f
8028027: serialver should emit declaration with the 'private' modifier
Reviewed-by: XXX

diff -r f18b60bd22a1 -r 1e1088bfea50
src/share/classes/sun/tools/serialver/SerialVer.java
--- a/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov 07
15:45:21 2013 -0800
+++ b/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov 07
15:47:03 2013 -0800
@@ -211,7 +211,7 @@
Class? cl = Class.forName(classname, false, loader);
ObjectStreamClass desc = ObjectStreamClass.lookup(cl);
if (desc != null) {
- return  static final long serialVersionUID =  +
+ return  private static final long serialVersionUID =  +
desc.getSerialVersionUID() + L;;
} else {
return null;

Re: 8028027: serialver should emit declaration with the 'private' modifier


On 08/11/2013 09:45, Yuri Gaevsky wrote:

Hi Stuart,

Unfortunately, several Java SE interfaces have public SVUIDs, so the fix can 
cause confusion:
I think Stuart's suggestion is good for the case where the class doesn't 
have the serialVersionUID already, you just paste it into the source 
code to keep the value as it was generated previously.


I think your concern is where the serialVersionUID is declared but 
hasn't following the recommendation. In that case then the emitted 
source line won't match the existing source declaration. Does that 
matter? I guess serialver should use reflection to get the modifiers and 
print a helpful suggestion.


-Alan.

RE: 8028027: serialver should emit declaration with the 'private' modifier

 Unfortunately, several Java SE interfaces have public SVUIDs, so the fix can 
 cause confusion:
 I think Stuart's suggestion is good for the case where the class doesn't have 
 the serialVersionUID already, you just paste it into the source code to keep 
 the value as it was generated previously.

Fully agree.

 I think your concern is where the serialVersionUID is declared but hasn't 
 following the recommendation. In that case then the emitted source line won't 
 match the existing source declaration. Does that matter? I guess serialver 
 should use reflection to get the modifiers and print a helpful suggestion.

Well, it would be more consistent to check for existence of protected or public 
serialVersionUID with Reflection API and change the serialver output 
accordingly.

Thanks,
-Yuri

Re: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script

2013-11-08 Thread David Holmes


On 8/11/2013 8:13 PM, Patrick Zhang wrote:

Hi Alan,

I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to hold it.


My understanding is that 8019502 was originally covering this issue for 
a broad range of tests across different areas. They were then split out 
into different CRs for different groups of tests. The remaining tests in 
the original bug were then handed to Patrick.


David


Regards
Patrick

On 11/8/13 5:24 PM, Alan Bateman wrote:

On 08/11/2013 03:41, Patrick Zhang wrote:

Sorry, I have some problems to connect to cr.openjdk.java.net yesterday.
Now the webrev  and result are attached. Please help to review.
After checking the scripts in java.util, most of scripts have been
finished in 8003890. So the webrev only change 2 rest files.

webrev:
http://cr.openjdk.java.net/~pzhang/8019502/webrev/

result:
http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr
http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr

cc'ing i18n-dev as that is where Calendar (and its tests) are maintained.

The change look okay to me but I wonder if perhaps you have the wrong
bug number. JDK-8019502 is a confused bug but I think it was
originally intended to be an audit of the tests that use Runtime.exec
or ProcessBuilder to see if they should be changed to pass the options
through. I just mention it as I suspect you might need to create a new
bug for this and then split up JDK-8019502 into other tasks.

-Alan

Re: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev)

2013-11-08 Thread Rob McKenna

vfork was the default in Linux before 5049299. You can see the variable
START_CHILD_USE_VFORK being set in:
http://cr.openjdk.java.net/~robm/5049299/webrev.06/src/solaris/native/java/lang/UNIXProcess_md.c.cdiff.html

-Rob

On 08/11/13 00:39, David Holmes wrote:

On 7/11/2013 11:53 PM, Rob McKenna wrote:

Ah, thanks for catching that David, I've updated the webrev in place.

I believe the reasoning is that we want to minimise any potential impact
to customers running in production. The general feeling seems to be that
Mac is a development platform and is less likely to cause us problems in
that regard. (not that I would anticipate any on Solaris, but I
understand the desire to be conservative)

And linux? It has changed to vfork right?

So OSX has changed, linux has changed, but Solaris remains as-is. All
platforms allow selecting the mechanism via the property
jdk.lang.Process.launchMechanism

Thanks,
David

-Rob

On 07/11/13 01:51, David Holmes wrote:

On 6/11/2013 10:00 PM, Rob McKenna wrote:

Hi David,

The only difference in 5049299 is the change in the default property
value in Solaris. Apologies for not making that clear.

Given this was primarily aimed at Solaris in the first place it seems
strange to me to not make the change on Solaris. If this is considered
risky fr an update release then I would think that applies to all
platforms equally. ??

If Solaris is not in fact changing then the comment in
src/solaris/native/java/lang/UNIXProcess_md.c needs to be altered:

* Based on the above analysis, we are currently using vfork() on
! * Linux and spawn() on other Unix systems, but the code to use
clone()

! * and fork() remains.

David
-

-Rob

On 06/11/13 01:09, David Holmes wrote:

Hi Rob,

How different is this to the JDK 8 version?

Thanks,
David

On 6/11/2013 7:24 AM, Rob McKenna wrote:

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

-Rob

On 05/11/13 21:23, Rob McKenna wrote:

Hi folks,

I'd like to backport this change to JDK7. Note: this fix uses
posix_spawn by default on Mac OSX only. On Solaris fork will remain
the default behaviour.

I've just noticed that there is a problem with the testcase on
Solaris
in that it will test fork twice. (and won't test posix_spawn) I'll
figure out a way around this, but in the mean time I'd like to get
the
ball rolling on this review anyway.

-Rob

RFR: JDK-8028055: (reflect) invoking Method/Constructor in anonymous classes breaks with -Dsun.reflect.noInflation=true

2013-11-08 Thread Joel Borggren-Franck

Hi

Please review fix for: https://bugs.openjdk.java.net/browse/JDK-8028055
(reflect) invoking Method/Constructor in anonymous classes breaks with
-Dsun.reflect.noInflation=true

As Peter observed here [1] the current fix is incomplete as it does not
work when -Dsun.reflect.noInflation=true is set.

Also included is a modification of ReflectUtil.isVMAnonymousClass(cls)
to not allocate new Strings, guided by performance numbers from Peter
[2].

webrev here: http://cr.openjdk.java.net/~jfranck/8028055/webrev.00/

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022872.html
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022955.html

cheers
/Joel

Re: RFR: 8026330: java.util.Base64 urlEncoder should omit padding


On 06/11/2013 18:44, Xueming Shen wrote:

Hi,

The latest spec and implementation of java.util.Base64.getXXXEncoder()
is to add appropriate padding character(s) at the end of the output
encoded data stream, to follow the note explicitly specified in the
RFC

   Implementations MUST include appropriate pad characters at the end
   of encoded data unless the specification referring to this document
   explicitly states otherwise.

However the RFE also mentions that

   In some circumstances, the use of padding (=) in base-encoded data
   is not required or used...

Feedback so far also suggests that Base64.encoder without padding might
be desired in some real world use scenario.

So here is the webrev to add a new method to the Encoder class to return
a non-padding version.

http://cr.openjdk.java.net/~sherman/8026330/webrev
The API looks okay although some developers might not initially 
recognize that an Encoder is immutable. In particularly, this statement 
might not be clear:


  This instance of encoder is unaffected by this invocation.

What you would think about including an example in the javadoc so that 
it's clear how to get an Encoder that doesn't emit padding?


Otherwise this looks good except that I wonder about needing to eagerly 
create all 6 Encoders.


So are you trying to get this into 8 or are you thinking of holding this 
to 9?


-Alan.

RE: 8028027: serialver should emit declaration with the 'private' modifier

 Well, it would be more consistent to check for existence of protected or 
 public serialVersionUID with Reflection API and change the serialver output 
 accordingly.

Please see suggested fix and its output below.

Thanks,
-Yuri

$ serialver java.security.PublicKey
java.security.PublicKey:public static final long serialVersionUID = 
7187392471159151072L;

$ serialver java.lang.Exception
java.lang.Exception: static final long serialVersionUID = 
-3387516993124229948L;

$ serialver java.lang.AssertionError
java.lang.AssertionError:private static final long serialVersionUID = 
-5013299493970297370L;

$ serialver javax.xml.ws.soap.SOAPFaultException
javax.xml.ws.soap.SOAPFaultException:private static final long 
serialVersionUID = -104968645459360720L;


$ hg diff
diff --git a/src/share/classes/sun/tools/serialver/SerialVer.java 
b/src/share/classes/sun/tools/serialver/SerialVer.java
--- a/src/share/classes/sun/tools/serialver/SerialVer.java
+++ b/src/share/classes/sun/tools/serialver/SerialVer.java
@@ -38,6 +38,7 @@
 import java.net.MalformedURLException;
 import java.util.StringTokenizer;
 import sun.net.www.ParseUtil;
+import java.lang.reflect.Modifier;
 
 public class SerialVer extends Applet {
 GridBagLayout gb;
@@ -211,7 +212,17 @@
 Class? cl = Class.forName(classname, false, loader);
 ObjectStreamClass desc = ObjectStreamClass.lookup(cl);
 if (desc != null) {
-return static final long serialVersionUID =  +
+   String ams = ;
+   try {
+   final int mod =
+   cl.getDeclaredField(serialVersionUID).getModifiers();
+   ams = Modifier.isPublic(mod) ? public
+   : Modifier.isProtected(mod) ? protected
+   : Modifier.isPrivate(mod) ? private : ;
+   } catch (NoSuchFieldException nsfe) {
+   ams = private;
+   }
+return  + ams +  static final long serialVersionUID =  +
 desc.getSerialVersionUID() + L;;
 } else {
 return null;

Re: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

2013-11-08 Thread Chris Hegarty


Alan,

 An alternative might be to just throw the IOException with
 InterruptedException as the cause.

Perfect. Updated in the new webrev.

Dan,

You are completely correct. I was only catering for the case where
  java.nio.file.FileSystemException: your_file: The process cannot
   access the file because it is being used by another process.

Where the delete succeeds then we need to wait until the underlying 
platform delete completes, i.e. the file no longer exists.


Updated webrev ( with only the diff from the previous ) :
  http://cr.openjdk.java.net/~chegar/fileUtils.02/webrev/

Thanks,
-Chris.


On 08/11/2013 02:26, Dan Xu wrote:


On 11/07/2013 11:04 AM, Alan Bateman wrote:

On 07/11/2013 14:59, Chris Hegarty wrote:

Given both Michael and Alan's comments. I've update the webrev:
http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/

1) more descriptive method names
2) deleteXXX methods return if interrupted, leaving the
interrupt status set
3) Use Files.copy with REPLACE_EXISTING
4) Use SimpleFileVisitor, rather than FileVisitor


This looks better although interrupting the sleep means that the
deleteXXX will quietly terminate with the interrupt status set (which
could be awkward to diagnose if used with tests that are also using
Thread.interrupt). An alternative might be to just throw the
IOException with InterruptedException as the cause.

-Alan.



Hi Chris,

In the method, deleteFileWithRetry0(), it assumes that if any other
process is accessing the same file, the delete operation,
Files.delete(), will throw out IOException on Windows. But I don't see
this assumption is always true when I investigated this issue on
intermittent test failures.

When Files.delete() method is called, it finally calls DeleteFile or
RemoveDirectory functions based on whether the target is a file or
directory. And these Windows APIs only mark the target for deletion on
close and return immediately without waiting the operation to be
completed. If another process is accessing the file in the meantime, the
delete operation does not occur and the target file stays at
delete-pending status until that open handle is closed. It basically
implies that DeleteFile and RemoveDirectory is like an async operation.
Therefore, we cannot assume that the file/directory is deleted after
Files.delete() returns or File.delete() returns true.

When checking those intermittently test failures, I find the test
normally succeeds on the Files.delete() call. But due to the
interference of Anti-virus or other Windows daemon services, the target
file changes to delete-pending status. And the immediately following
operation fails due the target file still exists, but our tests assume
the target file is already gone. Because the delete-pending status of a
file usually last for a very short time which depends on the
interference source, such failures normally happens when we recursively
delete a folder or delete-and-create a file with the same file name at a
high frequency.

It is basically a Windows API design or implementation issue. I have
logged an enhancement, JDK-8024496, to solve it from Java library layer.
Currently, I have two strategies in mind. One is to make the delete
operation blocking, which means to make sure the file/directory is
deleted before the return. The other is to make sure the delete-pending
file does not lead to a failure of subsequent file operations. But they
both has pros and cons.

Thank!

-Dan

RFR (XS): 8027823: catchException combinator fails with 9 argument target

2013-11-08 Thread Vladimir Ivanov


http://cr.openjdk.java.net/~vlivanov/8027823/webrev.00/

MethodHandleImpl.makeGuardWithCatch has special invokers 
(GuardWithCatch.invoke_L*) for methods with arity up to 8.
When method arity is larger, generic invoker (GuardWithCatch.invoke_V) 
is used.


Generic invoker expects GuardWithCatch.target  GuardWithCatch.catcher 
method handles to have (Object... av)Object type, but they can reference 
arbitrary methods, so type conversion is needed.


makeSpreadArguments takes care of parameters' type conversion, but 
return type is left as is. That's the reason why GuardWithCatch.invoke_V 
fails to invoke both target or catcher.


The fix is to add return type conversion on both paths.

Testing: failing test, test/java/lang/invoke/

Thanks!

Best regards,
Vladimir Ivanov

JBS: https://bugs.openjdk.java.net/browse/JDK-8027823

hg: jdk8/tl/jdk: 8027351: (ref) Private finalize method invoked in preference to protected superclass method

2013-11-08 Thread mandy . chung

Changeset: 41d7ce111bd8
Author:mchung
Date:  2013-11-08 07:53 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41d7ce111bd8

8027351: (ref) Private finalize method invoked in preference to protected 
superclass method
Reviewed-by: alanb, dholmes, mr, plevart, psandoz

! makefiles/lib/CoreLibraries.gmk
! makefiles/mapfiles/libjava/mapfile-vers
! makefiles/mapfiles/libjava/reorder-sparc
! makefiles/mapfiles/libjava/reorder-sparcv9
! makefiles/mapfiles/libjava/reorder-x86
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/ref/Finalizer.java
! src/share/classes/sun/misc/JavaLangAccess.java
! src/share/classes/sun/misc/VM.java
+ test/java/lang/ref/FinalizeOverride.java

hg: jdk8/tl/jdk: 8022963: java/net/NetworkInterface/Equals.java fails equality for Windows Teredo Interface

2013-11-08 Thread chris . hegarty

Changeset: 3112729d6b74
Author:tyan
Date:  2013-11-08 15:12 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3112729d6b74

8022963: java/net/NetworkInterface/Equals.java fails equality for Windows 
Teredo Interface
Reviewed-by: chegar

! test/java/net/MulticastSocket/TestInterfaces.java
! test/java/net/NetworkInterface/Equals.java

hg: jdk8/tl/jdk: 8019834: InetAddress.getByName hangs for bad IPv6 literals

2013-11-08 Thread chris . hegarty

Changeset: 771c77b49bb6
Author:chegar
Date:  2013-11-08 15:15 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/771c77b49bb6

8019834: InetAddress.getByName hangs for bad IPv6 literals
Reviewed-by: alanb

! src/share/classes/java/net/InetAddress.java
! test/java/net/ipv6tests/BadIPv6Addresses.java

Re: i18n dev RFR: 8027370: (tz) Support tzdata2013h

2013-11-08 Thread Xueming Shen


looks fine. I would assume you've also run the corresponding tests at 
test/closed repo.

-Sherman

On 11/5/2013 8:38 AM, Aleksej Efimov wrote:

Hi,

Can I have a review for tzdata2013h integration [1]. The webrev link can be 
located here [2].

The following test sets were executed on build with fix:
test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone 
test/sun/util/calendar test/java/util/TimeZone test/java/time 
test/java/util/Formatter

And here is the list of failures:
FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1%
FAILED: java/time/tck/java/time/TCKInstant.java %1%
FAILED: java/time/tck/java/time/TCKLocalDate.java %1%
FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1%
FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1%
FAILED: java/time/tck/java/time/TCKOffsetTime.java %1%
FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1%
FAILED: java/time/test/java/time/format/TestZoneTextPrinterParser.java %1%
FAILED: java/util/Calendar/JavatimeTest.java %1%

FAILED: sun/util/calendar/zi/TestZoneInfo310.java


The group %1% tests failures relates to the JDK-8027622 bug and are expected 
(actually, it was already resolved in hotspot repo).
The 'TestZoneInfo310' test failure is an actual error in current ZoneInfoFile 
class implementation in JDK. I have filled a bug for this one [3] and will send 
a separate review with fix later today.

[1] https://bugs.openjdk.java.net/browse/JDK-8027370
[2] http://cr.openjdk.java.net/~aefimov/8027370/webrev.00/
[3] https://bugs.openjdk.java.net/browse/JDK-8027848

hg: jdk8/tl/jdk: 8028069: (ref) Finalizer.c not deleted in the changeset for JDK-8027351

2013-11-08 Thread mandy . chung

Changeset: 1c9ba18198d5
Author:mchung
Date:  2013-11-08 09:43 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c9ba18198d5

8028069: (ref) Finalizer.c not deleted in the changeset for JDK-8027351
Reviewed-by: alanb

- src/share/native/java/lang/ref/Finalizer.c

Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port

2013-11-08 Thread Stuart Marks


Hi Tristan,

Yes, it's kind of a problem that the RMI TestLibrary is in the unnamed package. 
Classes in a named package cannot import classes from the unnamed package. We've 
run into problems with this before. Eventually, we should move TestLibrary a 
named package.


I think it's possible to work around this without too much difficulty. Note that 
classes in the unnamed package can import classes from named packages. So, 
perhaps you can put the RmiBench main class in the unnamed package so it has 
access to TestLibrary. Then have the benchmarks themselves in the bench.rmi 
package. The config file already references the benchmarks by fully qualified 
class name (e.g., bench.rmi.NullCalls) so with a bit of tinkering you ought to 
be able to get this to work.


s'marks

On 11/8/13 3:00 AM, Tristan Yan wrote:

/Thank you, Stuart
There is one review point I want to ask you opinion. Which is the reason that 
I moved from test/java/rmi/reliability/benchmark/bench/rmi to 
test/java/rmi/reliability/benchmark is Main.java need access class TestLibrary 
for supporting random port. TestLibrary is a unpackage class, I couldn't find 
a way to let a class which has Package to access the class without package. Do 
you have suggestion on that?

Thank you so much.
Tristan

On 11/06/2013 09:50 AM, Stuart Marks wrote:
/

/
/ /
On 11/1/13 9:18 AM, Tristan Yan wrote:
/

/Hi Everyone
http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/
/ /
Description:
1. Convert shell script test to Java program test.
2. Using random server port by reusing Darryl Mocek's work to replace fixed
server port.
3. Using java Process class to start client process.
4. Also convert other shell script test runSerialBench.sh to java program 
test also

/

/
Hi Tristan,
/ /
Several comments on this webrev.
/ /
/ /
** The original arrangement within the test/java/rmi/reliability/benchmark 
directory had the main benchmark files (scripts) at the top, some benchmark 
framework files in the bench subdirectory, and the actual RMI and 
serialization benchmarks in bench/rmi and bench/serial subdirectories.

/ /
The webrev moves all the RMI benchmarks to the top benchmark directory but 
leaves the serial benchmarks in bench/serial. The RMI benchmarks are now all 
cluttering the top directory, but the main serial benchmark test is now 
buried in the bench/serial directory. The nice organization that was there 
before is now spoiled. Is this rearrangement necessary in order to convert 
the scripts to Java? I would prefer the original arrangement be left in place.

/ /
/ /
** The RMI benchmark Main.java file has a @run tag of the form,
/ /
@run main/othervm/policy=policy.all/timeout=1800 -server  Main -c config
/ /
There is a subtle but serious problem here: the -server option is passed to 
the JVM and not as an argument to the main() method. The main() method 
gets neither a -server nor a -client argument, so its default run mode as 
defined by the benchmark itself is SAMEVM. This runs the client and server in 
the same JVM, which is different from the shell script, which ran separate 
client and server JVMs.

/ /
/ /
** The logic to process the -server argument still expects to take a port, 
even though the port is assigned automatically. So the obvious fix to the above,

/ /
@run main/othervm/policy=policy.all/timeout=1800 Main -server -c config
/ /
doesn't work, since a port is missing. The logic to increment the argument 
index to collect the port argument should be removed. Also, the -server line 
should be restored to the usage message, but without the port argument.

/ /
/ /
** After this is done, the client's command line is constructed improperly. 
The command line ends up looking something like this:

/ /
java client -cp classpath Main client localhost:58583 -c config
/ /
The word client appears twice, but what's really required is -client to 
appear as an argument after Main.

/ /
/ /
** The client is run using ProcessBuilder, which by default sends stdout and 
stderr to pipes to be read by the parent. But the parent never reads them, 
thus any messages from the client are never seen. The client is the one that 
emits the benchmark report, so its output needs to be seen. It might be 
sufficient to have the client inherit the parent's stdout and stderr. This 
might intermix the client's and server's output, but it's better than nothing.

/ /
/ /
** The config file is checked with the following code:
/ /
try {
confFile = args[i];
confstr = new FileInputStream(System.getProperty(test.src)
+ System.getProperty(file.separator) + confFile);
} catch (IOException e) {
die(Error: unable to open \ + args[i] + \);
}
/ /
This is potentially misleading, as the message doesn't print the actual 
filename that was attempted to be opened.

/ /
This is important, as the test.src property doesn't exist in the client JVM.
/ /
Note that the original shell script passed full pathnames for the config

Re: 8028027: serialver should emit declaration with the 'private' modifier

2013-11-08 Thread Stuart Marks


On 11/8/13 7:20 AM, Yuri Gaevsky wrote:

Well, it would be more consistent to check for existence of protected or public 
serialVersionUID with Reflection API and change the serialver output 
accordingly.


Please see suggested fix and its output below.


This change isn't consistent with the intent of the 'serialver' utility. Its 
intent is to produce a declaration that's suitable for copying into an evolving 
class. [1] (Clearly, this means the source code of a class.) The spec [2] 
strongly advises that serialVersionUID be private. As such, serialver should 
follow the strong advice given in the spec.


If there happens to be a declaration in the class that, probably mistakenly, 
goes against this advice, serialver shouldn't emit a line that perpetuates this 
mistake.


One can use javap -v to determine the presence of serialVersionUID field, 
including its modifiers, if that's what's desired.


s'marks

[1] http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/serialver.html

[2] http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html






Thanks,
-Yuri

$ serialver java.security.PublicKey
java.security.PublicKey:public static final long serialVersionUID = 
7187392471159151072L;

$ serialver java.lang.Exception
java.lang.Exception: static final long serialVersionUID = 
-3387516993124229948L;

$ serialver java.lang.AssertionError
java.lang.AssertionError:private static final long serialVersionUID = 
-5013299493970297370L;

$ serialver javax.xml.ws.soap.SOAPFaultException
javax.xml.ws.soap.SOAPFaultException:private static final long 
serialVersionUID = -104968645459360720L;


$ hg diff
diff --git a/src/share/classes/sun/tools/serialver/SerialVer.java 
b/src/share/classes/sun/tools/serialver/SerialVer.java
--- a/src/share/classes/sun/tools/serialver/SerialVer.java
+++ b/src/share/classes/sun/tools/serialver/SerialVer.java
@@ -38,6 +38,7 @@
  import java.net.MalformedURLException;
  import java.util.StringTokenizer;
  import sun.net.www.ParseUtil;
+import java.lang.reflect.Modifier;

  public class SerialVer extends Applet {
  GridBagLayout gb;
@@ -211,7 +212,17 @@
  Class? cl = Class.forName(classname, false, loader);
  ObjectStreamClass desc = ObjectStreamClass.lookup(cl);
  if (desc != null) {
-return static final long serialVersionUID =  +
+   String ams = ;
+   try {
+   final int mod =
+   cl.getDeclaredField(serialVersionUID).getModifiers();
+   ams = Modifier.isPublic(mod) ? public
+   : Modifier.isProtected(mod) ? protected
+   : Modifier.isPrivate(mod) ? private : ;
+   } catch (NoSuchFieldException nsfe) {
+   ams = private;
+   }
+return  + ams +  static final long serialVersionUID =  +
  desc.getSerialVersionUID() + L;;
  } else {
  return null;

JDK RFR to clean-up lint warnings in reflection implementation

2013-11-08 Thread Joe Darcy


Hello,

Please review the simple patch below which addresses a handful of raw 
types lint warning in the core reflection implementation code.


(If memory serves, this code dates back from a time during the 
development of JDK 5 when wildcards could not be used with arrays; 
before the release shipped, that combination was allowed.)


Thanks,

-Joe

diff -r 46982ca895b4 
src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
--- 
a/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
Fri Nov 08 18:54:29 2013 +
+++ 
b/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
Fri Nov 08 11:37:54 2013 -0800

@@ -52,7 +52,7 @@
 }

 private void validateConstructorArguments() {
-TypeVariable/*?*/[] formals = rawType.getTypeParameters();
+TypeVariable?[] formals = rawType.getTypeParameters();
 // check correct arity of actual type args
 if (formals.length != actualTypeArguments.length){
 throw new MalformedParameterizedTypeException();
diff -r 46982ca895b4 
src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
--- 
a/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java 
Fri Nov 08 18:54:29 2013 +
+++ 
b/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java 
Fri Nov 08 11:37:54 2013 -0800

@@ -42,7 +42,7 @@
 public abstract class GenericDeclRepositoryS extends Signature
 extends AbstractRepositoryS {

-private TypeVariable[] typeParams; // caches the formal type parameters
+private TypeVariable?[] typeParams; // caches the formal type 
parameters


 protected GenericDeclRepository(String rawSig, GenericsFactory f) {
 super(rawSig, f);
@@ -64,7 +64,7 @@
  * Return the formal type parameters of this generic declaration.
  * @return the formal type parameters of this generic declaration
  */
-public TypeVariable/*?*/[] getTypeParameters(){
+public TypeVariable?[] getTypeParameters(){
 if (typeParams == null) { // lazily initialize type parameters
 // first, extract type parameter subtree(s) from AST
 FormalTypeParameter[] ftps = 
getTree().getFormalTypeParameters();

Re: JDK RFR to clean-up lint warnings in reflection implementation

2013-11-08 Thread Lance Andersen - Oracle

looks fine Joe
On Nov 8, 2013, at 2:40 PM, Joe Darcy wrote:

 Hello,
 
 Please review the simple patch below which addresses a handful of raw types 
 lint warning in the core reflection implementation code.
 
 (If memory serves, this code dates back from a time during the development of 
 JDK 5 when wildcards could not be used with arrays; before the release 
 shipped, that combination was allowed.)
 
 Thanks,
 
 -Joe
 
 diff -r 46982ca895b4 
 src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
 --- 
 a/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
  Fri Nov 08 18:54:29 2013 +
 +++ 
 b/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
  Fri Nov 08 11:37:54 2013 -0800
 @@ -52,7 +52,7 @@
 }
 
 private void validateConstructorArguments() {
 -TypeVariable/*?*/[] formals = rawType.getTypeParameters();
 +TypeVariable?[] formals = rawType.getTypeParameters();
 // check correct arity of actual type args
 if (formals.length != actualTypeArguments.length){
 throw new MalformedParameterizedTypeException();
 diff -r 46982ca895b4 
 src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
 --- 
 a/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
  Fri Nov 08 18:54:29 2013 +
 +++ 
 b/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
  Fri Nov 08 11:37:54 2013 -0800
 @@ -42,7 +42,7 @@
 public abstract class GenericDeclRepositoryS extends Signature
 extends AbstractRepositoryS {
 
 -private TypeVariable[] typeParams; // caches the formal type parameters
 +private TypeVariable?[] typeParams; // caches the formal type 
 parameters
 
 protected GenericDeclRepository(String rawSig, GenericsFactory f) {
 super(rawSig, f);
 @@ -64,7 +64,7 @@
  * Return the formal type parameters of this generic declaration.
  * @return the formal type parameters of this generic declaration
  */
 -public TypeVariable/*?*/[] getTypeParameters(){
 +public TypeVariable?[] getTypeParameters(){
 if (typeParams == null) { // lazily initialize type parameters
 // first, extract type parameter subtree(s) from AST
 FormalTypeParameter[] ftps = getTree().getFormalTypeParameters();
 


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/jdk: 8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on slow/single core machine

2013-11-08 Thread chris . hegarty

Changeset: 46982ca895b4
Author:tyan
Date:  2013-11-08 18:54 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46982ca895b4

8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on 
slow/single core machine
Reviewed-by: chegar

! test/com/sun/net/httpserver/bugs/B6433018.java

Re: JDK RFR to clean-up lint warnings in reflection implementation


On 08/11/2013 19:40, Joe Darcy wrote:

Hello,

Please review the simple patch below which addresses a handful of raw 
types lint warning in the core reflection implementation code.


(If memory serves, this code dates back from a time during the 
development of JDK 5 when wildcards could not be used with arrays; 
before the release shipped, that combination was allowed.)
This looks okay to me (and I think we have the same thing in a few other 
areas).


-Alan

hg: jdk8/tl/jdk: 8025985: com.sun.management.OSMBeanFactory should not be public

2013-11-08 Thread mandy . chung

Changeset: 40ca9e4866de
Author:mchung
Date:  2013-11-08 12:13 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40ca9e4866de

8025985: com.sun.management.OSMBeanFactory should not be public
Reviewed-by: alanb, erikj, ihse, jbachorik

! makefiles/lib/ServiceabilityLibraries.gmk
! makefiles/mapfiles/libmanagement/mapfile-vers
+ src/share/classes/sun/management/BaseOperatingSystemImpl.java
! src/share/classes/sun/management/ManagementFactoryHelper.java
- src/share/classes/sun/management/OperatingSystemImpl.java
- src/solaris/classes/com/sun/management/OSMBeanFactory.java
- src/solaris/classes/com/sun/management/UnixOperatingSystem.java
+ src/solaris/classes/sun/management/OperatingSystemImpl.java
- src/solaris/native/com/sun/management/LinuxOperatingSystem.c
- src/solaris/native/com/sun/management/MacosxOperatingSystem.c
- src/solaris/native/com/sun/management/SolarisOperatingSystem.c
- src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
+ src/solaris/native/sun/management/LinuxOperatingSystem.c
+ src/solaris/native/sun/management/MacosxOperatingSystem.c
+ src/solaris/native/sun/management/OperatingSystemImpl.c
+ src/solaris/native/sun/management/SolarisOperatingSystem.c
- src/windows/classes/com/sun/management/OSMBeanFactory.java
- src/windows/classes/com/sun/management/OperatingSystem.java
+ src/windows/classes/sun/management/OperatingSystemImpl.java
- src/windows/native/com/sun/management/OperatingSystem_md.c
+ src/windows/native/sun/management/OperatingSystemImpl.c

hg: jdk8/tl/jdk: 8028076: Correct raw type lint warnings in core reflection implementation classes

2013-11-08 Thread joe . darcy

Changeset: 11376ad23e21
Author:darcy
Date:  2013-11-08 12:19 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11376ad23e21

8028076: Correct raw type lint warnings in core reflection implementation 
classes
Reviewed-by: lancea, alanb

! 
src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java

Re: JDK RFR to clean-up lint warnings in reflection implementation

2013-11-08 Thread Joe Darcy


On 11/08/2013 12:06 PM, Alan Bateman wrote:

On 08/11/2013 19:40, Joe Darcy wrote:

Hello,

Please review the simple patch below which addresses a handful of raw 
types lint warning in the core reflection implementation code.


(If memory serves, this code dates back from a time during the 
development of JDK 5 when wildcards could not be used with arrays; 
before the release shipped, that combination was allowed.)
This looks okay to me (and I think we have the same thing in a few 
other areas).





Hi Alan,

Yes; over 1/3 of the remaining lint warnings in core-libs are for the 
use of raw types. There are many uses of Class or Class[] instead of 
Class? or Class?[].


-Joe

Re: JDK RFR to clean-up lint warnings in reflection implementation

2013-11-08 Thread Joel Borggrén-Franck

Looks good Joe.

cheers
/Joel

On 8 nov 2013, at 20:40, Joe Darcy joe.da...@oracle.com wrote:

 Hello,
 
 Please review the simple patch below which addresses a handful of raw types 
 lint warning in the core reflection implementation code.
 
 (If memory serves, this code dates back from a time during the development of 
 JDK 5 when wildcards could not be used with arrays; before the release 
 shipped, that combination was allowed.)
 
 Thanks,
 
 -Joe
 
 diff -r 46982ca895b4 
 src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
 --- 
 a/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
  Fri Nov 08 18:54:29 2013 +
 +++ 
 b/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
  Fri Nov 08 11:37:54 2013 -0800
 @@ -52,7 +52,7 @@
 }
 
 private void validateConstructorArguments() {
 -TypeVariable/*?*/[] formals = rawType.getTypeParameters();
 +TypeVariable?[] formals = rawType.getTypeParameters();
 // check correct arity of actual type args
 if (formals.length != actualTypeArguments.length){
 throw new MalformedParameterizedTypeException();
 diff -r 46982ca895b4 
 src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
 --- 
 a/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
  Fri Nov 08 18:54:29 2013 +
 +++ 
 b/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java
  Fri Nov 08 11:37:54 2013 -0800
 @@ -42,7 +42,7 @@
 public abstract class GenericDeclRepositoryS extends Signature
 extends AbstractRepositoryS {
 
 -private TypeVariable[] typeParams; // caches the formal type parameters
 +private TypeVariable?[] typeParams; // caches the formal type 
 parameters
 
 protected GenericDeclRepository(String rawSig, GenericsFactory f) {
 super(rawSig, f);
 @@ -64,7 +64,7 @@
  * Return the formal type parameters of this generic declaration.
  * @return the formal type parameters of this generic declaration
  */
 -public TypeVariable/*?*/[] getTypeParameters(){
 +public TypeVariable?[] getTypeParameters(){
 if (typeParams == null) { // lazily initialize type parameters
 // first, extract type parameter subtree(s) from AST
 FormalTypeParameter[] ftps = getTree().getFormalTypeParameters();

RE: 8028027: serialver should emit declaration with the 'private' modifier

Stuart,

Sorry, but such inconsistency between serialver/javap is a bug (IMHO, of 
course).

 If there happens to be a declaration in the class that, probably mistakenly, 
 goes against this advice, serialver shouldn't emit a line that perpetuates 
 this mistake.

I would argue that for any real-life API it's almost impossible to fix such 
explicitly-defined bad  (i.e. public/protected) SVUID in any compatible way,  
so emitting 'private'  will not help there, unfortunately. 

-Yuri

-Original Message-
From: Stuart Marks [mailto:stuart.ma...@oracle.com] 
Sent: Friday, November 8, 2013 10:48 PM
To: Yuri Gaevsky
Cc: Alan Bateman; core-libs-dev
Subject: Re: 8028027: serialver should emit declaration with the 'private' 
modifier

On 11/8/13 7:20 AM, Yuri Gaevsky wrote:
 Well, it would be more consistent to check for existence of protected or 
 public serialVersionUID with Reflection API and change the serialver output 
 accordingly.

 Please see suggested fix and its output below.

This change isn't consistent with the intent of the 'serialver' utility. Its 
intent is to produce a declaration that's suitable for copying into an 
evolving class. [1] (Clearly, this means the source code of a class.) The spec 
[2] strongly advises that serialVersionUID be private. As such, serialver 
should follow the strong advice given in the spec.

If there happens to be a declaration in the class that, probably mistakenly, 
goes against this advice, serialver shouldn't emit a line that perpetuates this 
mistake.

One can use javap -v to determine the presence of serialVersionUID field, 
including its modifiers, if that's what's desired.

s'marks

[1] http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/serialver.html

[2] http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html



 Thanks,
 -Yuri

 $ serialver java.security.PublicKey
 java.security.PublicKey:public static final long serialVersionUID = 
 7187392471159151072L;

 $ serialver java.lang.Exception
 java.lang.Exception: static final long serialVersionUID = 
 -3387516993124229948L;

 $ serialver java.lang.AssertionError
 java.lang.AssertionError:private static final long serialVersionUID = 
 -5013299493970297370L;

 $ serialver javax.xml.ws.soap.SOAPFaultException
 javax.xml.ws.soap.SOAPFaultException:private static final long 
 serialVersionUID = -104968645459360720L;


 $ hg diff
 diff --git a/src/share/classes/sun/tools/serialver/SerialVer.java 
 b/src/share/classes/sun/tools/serialver/SerialVer.java
 --- a/src/share/classes/sun/tools/serialver/SerialVer.java
 +++ b/src/share/classes/sun/tools/serialver/SerialVer.java
 @@ -38,6 +38,7 @@
   import java.net.MalformedURLException;
   import java.util.StringTokenizer;
   import sun.net.www.ParseUtil;
 +import java.lang.reflect.Modifier;

   public class SerialVer extends Applet {
   GridBagLayout gb;
 @@ -211,7 +212,17 @@
   Class? cl = Class.forName(classname, false, loader);
   ObjectStreamClass desc = ObjectStreamClass.lookup(cl);
   if (desc != null) {
 -return static final long serialVersionUID =  +
 +   String ams = ;
 +   try {
 +   final int mod =
 +   
 cl.getDeclaredField(serialVersionUID).getModifiers();
 +   ams = Modifier.isPublic(mod) ? public
 +   : Modifier.isProtected(mod) ? protected
 +   : Modifier.isPrivate(mod) ? private : ;
 +   } catch (NoSuchFieldException nsfe) {
 +   ams = private;
 +   }
 +return  + ams +  static final long serialVersionUID =  +
   desc.getSerialVersionUID() + L;;
   } else {
   return null;

RFR: 8028041 Serialized Form description of j.l.String is not consistent with the implementation

2013-11-08 Thread roger riggs


Hi,

Please review this correction to the documentation of the serialized 
form of String.
There is no change to the specification or behavior of the serialization 
of strings.


It seemed safer to refer to the serialization specification and remove the
incorrect details instead of trying to correct the incorrect details by 
adding more detail.


Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-string-serial-8028041/

Thanks, Roger

[1 ] JDK-8028041 https://bugs.openjdk.java.net/browse/JDK-8028041 
Serialized Form description of j.l.String is not consistent with the 
implementation

hg: jdk8/tl/jdk: 8028074: InetAddress.getByName fails with UHE invalid IPv6 address if host name starts with a-f

2013-11-08 Thread alan . bateman

Changeset: 50df04934e86
Author:alanb
Date:  2013-11-08 21:07 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50df04934e86

8028074: InetAddress.getByName fails with UHE invalid IPv6 address if host 
name starts with a-f
Reviewed-by: chegar

! src/share/classes/java/net/InetAddress.java

Re: RFR: 8028041 Serialized Form description of j.l.String is not consistent with the implementation


On 08/11/2013 20:56, roger riggs wrote:

Hi,

Please review this correction to the documentation of the serialized 
form of String.
There is no change to the specification or behavior of the 
serialization of strings.


It seemed safer to refer to the serialization specification and remove 
the
incorrect details instead of trying to correct the incorrect details 
by adding more detail.


Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-string-serial-8028041/
It make sense to reference the spec rather than duplicate how long 
strings are handled. So looks good to me (assuming the link works as 
expected when the docs are generated).


-Alan.

Re: RFR: 8028041 Serialized Form description of j.l.String is not consistent with the implementation

2013-11-08 Thread Stuart Marks


On 11/8/13 1:34 PM, Alan Bateman wrote:

On 08/11/2013 20:56, roger riggs wrote:

Please review this correction to the documentation of the serialized form of
String.
There is no change to the specification or behavior of the serialization of
strings.

It seemed safer to refer to the serialization specification and remove the
incorrect details instead of trying to correct the incorrect details by adding
more detail.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-string-serial-8028041/

It make sense to reference the spec rather than duplicate how long strings are
handled. So looks good to me (assuming the link works as expected when the docs
are generated).


Hi Roger,

Yes, I agree with the approach of referencing the spec as well.

On the link format, I'd recommend using {@docRoot} instead of a long chain of 
double dots. (Yes, this is used inconsistent in the javadoc. It's yet another 
thing to be cleaned up.)


s'marks

Re: RFR: 8026330: java.util.Base64 urlEncoder should omit padding

2013-11-08 Thread Xueming Shen


On 11/08/2013 06:00 AM, Alan Bateman wrote:

On 06/11/2013 18:44, Xueming Shen wrote:

Hi,

The latest spec and implementation of java.util.Base64.getXXXEncoder()
is to add appropriate padding character(s) at the end of the output
encoded data stream, to follow the note explicitly specified in the
RFC

   Implementations MUST include appropriate pad characters at the end
   of encoded data unless the specification referring to this document
   explicitly states otherwise.

However the RFE also mentions that

   In some circumstances, the use of padding (=) in base-encoded data
   is not required or used...

Feedback so far also suggests that Base64.encoder without padding might
be desired in some real world use scenario.

So here is the webrev to add a new method to the Encoder class to return
a non-padding version.

http://cr.openjdk.java.net/~sherman/8026330/webrev

The API looks okay although some developers might not initially recognize that 
an Encoder is immutable. In particularly, this statement might not be clear:

  This instance of encoder is unaffected by this invocation.

What you would think about including an example in the javadoc so that it's 
clear how to get an Encoder that doesn't emit padding?


I have updated that statement to be more verbose and obvious

 *
 * p The encoding scheme of this encoder instance is unaffected by
 * this invocation. The returned encoder instance should be used for
 * non-padding encoding operation.
 *

Hope it is now clear enough. Personally I feel it might be clearer than an 
example
like
Base64.Encoder nonPaddingEncoder = Base64.getEncoder().withoutPadding();



Otherwise this looks good except that I wonder about needing to eagerly create 
all 6 Encoders.



Given the non-padding encoder is supposed to not be used frequently as
the standard one, and the encoder is really a simple/not-expensive object,
I removed the singleton approach for the non-padding encoders. We can add
any time later, if requested/ pointed out to be necessary.

http://cr.openjdk.java.net/~sherman/8026330/webrev/


So are you trying to get this into 8 or are you thinking of holding this to 9?



I hope it can get in, as it is requested couple weeks ago. But if it has to be
cut off and leave for 9, then be it:-)

thanks!
-Sherman

Re: RFR 8025003: Base64 should be less strict with padding

2013-11-08 Thread Bill Shannon

Have you had a chance to think about this?  Can the MIME decoder be made
more lenient, or can I get an option to control this?

Bill Shannon wrote on 10/25/13 15:24:
 Xueming Shen wrote on 10/25/13 15:19:
 On 10/25/13 2:19 PM, Bill Shannon wrote:
 If I understand this correctly, this proposes to remove the lenient
 option we've been discussing and just make it always lenient.  Is that
 correct?

 Yes. Only for the mime type though.
 
 That's fine.
 
 Unfortunately, from what you say below, it's still not lenient enough.
 I'd really like a version that never, ever, for any reason, throws an
 exception.  Yes, that means when you only get a final 6 bits of data
 you have to make an assumption about what was intended, probably padding
 it with zeros to 8 bits.

 This is something I'm hesitated to do. I can be lenient for the padding end
 because the
 padding character itself is not the real data, whether or not it's present,
 it's missing or
 it's incorrect/incomplete, it does not impact the integrity of the data. But 
 to
 feed the last
 6 bits with zero, is really kinda of guessing, NOT decoding.
 
 I understand.  And if the people who write spamming software knew how to
 read a spec, we wouldn't have this problem!  :-)
 
 Still, there's a lot of bad data out there on the internet, and people
 want the software to do the best job it can to interpret the data.  It's
 better to guess at the missing 2 bits of data than to lose the last 6 bits
 of data.

Re: RFR: 8028041 Serialized Form description of j.l.String is not consistent with the implementation

2013-11-08 Thread roger riggs


Hi Stuart,

I agree that {@docroot} is preferred.
The serialization spec is in a parallel directory to the API spec.
The platform/ docs are above the api docs, so at least 1 ../ is needed.
I tried it with {@docroot}/../... but the normal docs build defaulted 
docroot to /

and the link did not work.

Roger

On 11/8/2013 4:41 PM, Stuart Marks wrote:

On 11/8/13 1:34 PM, Alan Bateman wrote:

On 08/11/2013 20:56, roger riggs wrote:
Please review this correction to the documentation of the serialized 
form of

String.
There is no change to the specification or behavior of the 
serialization of

strings.

It seemed safer to refer to the serialization specification and 
remove the
incorrect details instead of trying to correct the incorrect details 
by adding

more detail.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-string-serial-8028041/
It make sense to reference the spec rather than duplicate how long 
strings are
handled. So looks good to me (assuming the link works as expected 
when the docs

are generated).


Hi Roger,

Yes, I agree with the approach of referencing the spec as well.

On the link format, I'd recommend using {@docRoot} instead of a long 
chain of double dots. (Yes, this is used inconsistent in the javadoc. 
It's yet another thing to be cleaned up.)


s'marks

Re: RFR (XS): 8027823: catchException combinator fails with 9 argument target

2013-11-08 Thread John Rose

Reviewed.  Thanks for the fix.  The test case will also be a useful quick test 
for unboxed catchEx paths.  — John

On Nov 8, 2013, at 7:25 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:

 http://cr.openjdk.java.net/~vlivanov/8027823/webrev.00/
 
 MethodHandleImpl.makeGuardWithCatch has special invokers 
 (GuardWithCatch.invoke_L*) for methods with arity up to 8.
 When method arity is larger, generic invoker (GuardWithCatch.invoke_V) 
 is used.
 
 Generic invoker expects GuardWithCatch.target  GuardWithCatch.catcher 
 method handles to have (Object... av)Object type, but they can reference 
 arbitrary methods, so type conversion is needed.
 
 makeSpreadArguments takes care of parameters' type conversion, but 
 return type is left as is. That's the reason why GuardWithCatch.invoke_V 
 fails to invoke both target or catcher.
 
 The fix is to add return type conversion on both paths.
 
 Testing: failing test, test/java/lang/invoke/
 
 Thanks!
 
 Best regards,
 Vladimir Ivanov
 
 JBS: https://bugs.openjdk.java.net/browse/JDK-8027823
 ___
 mlvm-dev mailing list
 mlvm-...@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

hg: jdk8/tl/jdk: 8028041: Serialized Form description of j.l.String is not consistent with the implementation

2013-11-08 Thread roger . riggs

Changeset: df2f7f288353
Author:rriggs
Date:  2013-11-08 17:50 -0500
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df2f7f288353

8028041: Serialized Form description of j.l.String is not consistent with the 
implementation
Summary: Replaced incorrect description with reference to the serialization 
specification
Reviewed-by: alanb, smarks

! src/share/classes/java/lang/String.java

Re: RFR (XS): 8027823: catchException combinator fails with 9 argument target

2013-11-08 Thread Vladimir Ivanov


Thank you, John.

Since I'm not a Committer in JDK8, I need a sponsor to push this fix. 
Any volunteers? :-) Will provide the changeset at first demand.


Best regards,
Vladimir Ivanov

On 11/9/13 3:26 AM, John Rose wrote:

Reviewed.  Thanks for the fix.  The test case will also be a useful quick test 
for unboxed catchEx paths.  — John

On Nov 8, 2013, at 7:25 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:


http://cr.openjdk.java.net/~vlivanov/8027823/webrev.00/

MethodHandleImpl.makeGuardWithCatch has special invokers
(GuardWithCatch.invoke_L*) for methods with arity up to 8.
When method arity is larger, generic invoker (GuardWithCatch.invoke_V)
is used.

Generic invoker expects GuardWithCatch.target  GuardWithCatch.catcher
method handles to have (Object... av)Object type, but they can reference
arbitrary methods, so type conversion is needed.

makeSpreadArguments takes care of parameters' type conversion, but
return type is left as is. That's the reason why GuardWithCatch.invoke_V
fails to invoke both target or catcher.

The fix is to add return type conversion on both paths.

Testing: failing test, test/java/lang/invoke/

Thanks!

Best regards,
Vladimir Ivanov

JBS: https://bugs.openjdk.java.net/browse/JDK-8027823
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: RFR (XS): 8027823: catchException combinator fails with 9 argument target

2013-11-08 Thread John Rose

I'll push it for you.  — John

On Nov 8, 2013, at 4:08 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:

 Thank you, John.
 
 Since I'm not a Committer in JDK8, I need a sponsor to push this fix. Any 
 volunteers? :-) Will provide the changeset at first demand.
 
 Best regards,
 Vladimir Ivanov
 
 On 11/9/13 3:26 AM, John Rose wrote:
 Reviewed.  Thanks for the fix.  The test case will also be a useful quick 
 test for unboxed catchEx paths.  — John
 
 On Nov 8, 2013, at 7:25 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
 wrote:
 
 http://cr.openjdk.java.net/~vlivanov/8027823/webrev.00/
 
 MethodHandleImpl.makeGuardWithCatch has special invokers
 (GuardWithCatch.invoke_L*) for methods with arity up to 8.
 When method arity is larger, generic invoker (GuardWithCatch.invoke_V)
 is used.
 
 Generic invoker expects GuardWithCatch.target  GuardWithCatch.catcher
 method handles to have (Object... av)Object type, but they can reference
 arbitrary methods, so type conversion is needed.
 
 makeSpreadArguments takes care of parameters' type conversion, but
 return type is left as is. That's the reason why GuardWithCatch.invoke_V
 fails to invoke both target or catcher.
 
 The fix is to add return type conversion on both paths.
 
 Testing: failing test, test/java/lang/invoke/
 
 Thanks!
 
 Best regards,
 Vladimir Ivanov
 
 JBS: https://bugs.openjdk.java.net/browse/JDK-8027823
 ___
 mlvm-dev mailing list
 mlvm-...@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

hg: jdk8/tl/langtools: 4 new changesets

Changeset: fea486d30d41
Author:cl
Date:  2013-10-31 12:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fea486d30d41

Added tag jdk8-b114 for changeset 850d2602ae98

! .hgtags

Changeset: 6b4d6205366c
Author:lana
Date:  2013-10-31 16:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b4d6205366c

Merge

- test/tools/javac/ExtDirs/ext1/pkg1.jar
- test/tools/javac/ExtDirs/ext2/pkg2.jar
- test/tools/javac/ExtDirs/ext3/pkg1.jar
- test/tools/javac/ExtDirs/ext3/pkg2.jar
- test/tools/javac/T8019486/WrongLVTForLambdaTest.java

Changeset: 3c040b04af05
Author:cl
Date:  2013-11-07 08:16 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3c040b04af05

Added tag jdk8-b115 for changeset 6b4d6205366c

! .hgtags

Changeset: 21294feaf311
Author:lana
Date:  2013-11-08 17:39 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/21294feaf311

Merge

hg: jdk8/tl/corba: 4 new changesets

Changeset: d425685e0b74
Author:cl
Date:  2013-10-31 12:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/d425685e0b74

Added tag jdk8-b114 for changeset 0bbccf77c23e

! .hgtags

Changeset: 8d07115924b7
Author:lana
Date:  2013-10-31 16:30 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/8d07115924b7

Merge


Changeset: 5fdc44652089
Author:cl
Date:  2013-11-07 08:16 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/5fdc44652089

Added tag jdk8-b115 for changeset 8d07115924b7

! .hgtags

Changeset: 4796555c4dc8
Author:lana
Date:  2013-11-08 17:16 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/4796555c4dc8

Merge

hg: jdk8/tl/jaxp: 3 new changesets

Changeset: d3b6da1b3e25
Author:cl
Date:  2013-10-31 12:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d3b6da1b3e25

Added tag jdk8-b114 for changeset 1b1e12117fe2

! .hgtags

Changeset: f610fd46463e
Author:lana
Date:  2013-10-31 16:31 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f610fd46463e

Merge


Changeset: e757eb9aee3d
Author:cl
Date:  2013-11-07 08:16 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e757eb9aee3d

Added tag jdk8-b115 for changeset f610fd46463e

! .hgtags

hg: jdk8/tl/jaxws: 2 new changesets

Changeset: e126d8eca69b
Author:cl
Date:  2013-10-31 12:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e126d8eca69b

Added tag jdk8-b114 for changeset 9ad289610fc6

! .hgtags

Changeset: 587560c222a2
Author:cl
Date:  2013-11-07 08:16 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/587560c222a2

Added tag jdk8-b115 for changeset e126d8eca69b

! .hgtags

hg: jdk8/tl: 3 new changesets

Changeset: b65d48f6938a
Author:cl
Date:  2013-10-31 12:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/b65d48f6938a

Added tag jdk8-b114 for changeset 4f2011496393

! .hgtags

Changeset: 763ada2a1d8c
Author:lana
Date:  2013-10-31 16:24 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/763ada2a1d8c

Merge


Changeset: 40e892e2a4f2
Author:cl
Date:  2013-11-07 08:16 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/40e892e2a4f2

Added tag jdk8-b115 for changeset 763ada2a1d8c

! .hgtags

hg: jdk8/tl/nashorn: 4 new changesets

Changeset: f109bb255b80
Author:cl
Date:  2013-10-31 12:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f109bb255b80

Added tag jdk8-b114 for changeset 79f7b79bf97b

! .hgtags

Changeset: f0d3ac2474ee
Author:lana
Date:  2013-10-31 16:47 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f0d3ac2474ee

Merge

- src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java

Changeset: 0fb1a427fbf6
Author:cl
Date:  2013-11-07 08:16 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0fb1a427fbf6

Added tag jdk8-b115 for changeset f0d3ac2474ee

! .hgtags

Changeset: d091499d67fc
Author:lana
Date:  2013-11-08 17:39 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d091499d67fc

Merge

hg: jdk8/tl/hotspot: 37 new changesets