Re: RFR: 8023524: Mechanism to dump generated lambda classes / log lambda code generation
On 09/19/2013 01:00 AM, Henry Jen wrote: Class names can contain '\' and other characters which are problematic on Windows. Thanks for reviewing, I suspect you are pointing out a potential issue to look at, not that the problem exists in current implementation. According to JLS 3.8, the classname(an identifier) can only have letters, digits, plus '_' and '$'. You need to look at the JVM specification, there are only very few characters it excludes. The restrictions come from javac, not the JVM. For example, on Linux, java '\' will load a \.class file and run it (yes, I tried). -- Florian Weimer / Red Hat Product Security Team
Re: RFR: 8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
On 18/09/2013 20:45, Xueming Shen wrote: OK, how about this one? I'm even using lambda:-) http://cr.openjdk.java.net/~sherman/8023113/webrev/ -Sherman Looks okay except that Files.list returns a stream that needs to be closed to avoid leaking resources. As a side note, as cleanup is attempting to delete a file tree then you could eliminate the recursion by using Files.walkFileTree with the directories removed in the postVisitDirectory method. It might be tempting to use the new walk method but it returns each directory before its entries and so isn't appropriate for recursive ops where you need to do touch the directory after its entries. I'm not suggesting spending any more time on this test of course, you've done more than enough. -Alan.
Review request for 8011697: ScriptEngine js randomly means either rhino or nashorn, but should instead select one
Hi, the HashSet used for the script engine factories caused the random behaviour. Bug: https://bugs.openjdk.java.net/browse/JDK-8011697 Webrev: http://cr.openjdk.java.net/~arieber/8011697/webrev.01/ Please review and sponsor required... thanks Andreas On 19.09.2013 08:55, Andreas Rieber wrote: Hi Sundar, On 19.09.2013 08:34, A. Sundararajan wrote: Hi, Few comments on this: 1) This is a JDK repo (where javax.script lives) change and so core-libs-dev review is needed will do that (when i have 3). 2) Not sure if it affects any word on spec. - need to go through spec + javadoc comments closely I checked the javadoc, there is nothing mentioned about the internal implementation of the script engine factories. So this should be fine. 3) You need a test that demonstrates that order is preserved I will try to setup a test with your sample script engine attached to the issue. Hope this helps, -Sundar thanks Andreas On Thursday 19 September 2013 11:43 AM, Andreas Rieber wrote: Hi, the HashSet used for the script engine factories caused the random behaviour. Bug: https://bugs.openjdk.java.net/browse/JDK-8011697 Webrev: http://cr.openjdk.java.net/~arieber/8011697/webrev.00/ Please review and sponsor required... thanks Andreas
Re: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX
Hi Phil,
thank you for looking at the changes. Please find my answers inline:
On Thu, Sep 19, 2013 at 12:22 AM, Phil Race philip.r...@oracle.com wrote:
Volker,
I've skimmed the client related changes - mostly based on the descriptions.
I'll look in more detail as soon as I can after JavaOne. We also have some
engineers out on vacation who might want to look at these too.
A couple of things that stood out :
On AIX, fontconfig is not a standard package supported by IBM.
I am surprised AIX does not support fontconfig.
That is something IBM should reconsider as its hard to imagine
a modern Unix based system working without it ..
I totally agree, but this is an OpenJDK port not a AIX renovation:)
That said, IBM offers fontconfig packages from a special AIX Toolbox for
Linux Applications OpenSource site. But these OpenSource packages are not
supported and users have to install them manually (i.e. they are not part
of the standard installation images and you can not rely on them beeing
installed).
Very basic start for AIX - feel free to complete ..
169 */
170 static char *fullAixFontPath[] = {
...
I'd really like to see it completed but these days
that's largely a fall back for no fontconfig.
Again, this can get quite complicated and AIX-version dependent. I think
the provided list is a good starting point.
/* AIX does not provide the 'dladdr' function. But fortunately, we've
42 * already implemented it in the HotSpot, because we need it there as
43 * well (see hotspot/src/os/aix/vm/porting_**aix.{hpp,cpp}).
Whilst this is in ifdef AIX this reliance on an exported hotspot
function sounds hacky. What actual requirement is there that the
AIX class libraries be so tightly-coupled with that VM?
There is no contract there.
You're right, there is no contract. It's just pragmatic solution and I
think it should always work because the libjvm will always be loaded at the
point in AWT where it is used. Another solution would be to re-implement
the functionality in the class library and I don't like code duplication
either.
-phil.
On 9/16/2013 12:30 PM, Volker Simonis wrote:
Resending this to more lists as requested by Alan Bateman with the kind
request to anybody to review the parts for which he feels responsible:)
For those not up to date, this change is part of the ongoing PowerPC/AIX
Porting Project:
http://openjdk.java.net/**projects/ppc-aix-porthttp://openjdk.java.net/projects/ppc-aix-port
https://wiki.openjdk.java.net/**display/PPCAIXPorthttps://wiki.openjdk.java.net/display/PPCAIXPort
http://openjdk.java.net/jeps/**175 http://openjdk.java.net/jeps/175
Please send reviews to all currently included recipients.
Thank you and best regards,
Volker
-- Forwarded message --
From: *Volker Simonis*
Date: Monday, September 16, 2013
Subject: RFR(L): 8024854: Basic changes and files to build the class
library on AIX
To:
ppc-aix-port-dev@openjdk.**java.netppc-aix-port-...@openjdk.java.netmailto:
ppc-aix-port-dev@**openjdk.java.net ppc-aix-port-...@openjdk.java.net
ppc-aix-port-dev@openjdk.**java.net
ppc-aix-port-...@openjdk.java.netmailto:
ppc-aix-port-dev@**openjdk.java.net ppc-aix-port-...@openjdk.java.net,
Java Core Libs
core-libs-...@openjdk.java.**netcore-libs-dev@openjdk.java.netmailto:
core-libs-dev@openjdk.**java.net core-libs-dev@openjdk.java.net
Hi,
could you please review the following webrev which contains the basic
changes and files needed in the 'jdk' repository in order to build the
OpenJDK on AIX:
http://cr.openjdk.java.net/~**simonis/webrevs/8024854http://cr.openjdk.java.net/~simonis/webrevs/8024854
http://cr.openjdk.java.net/%**7Esimonis/webrevs/8024854http://cr.openjdk.java.net/%7Esimonis/webrevs/8024854
This change together with 8024265: Enable new build on AIX (jdk part)
http://cr.openjdk.java.net/%**7Esimonis/webrevs/8024265_jdk/http://cr.openjdk.java.net/%7Esimonis/webrevs/8024265_jdk/
** allows it to configure and completely build the staging repository
on AIX 5.3 and 7.1 with the following command:
configure --with-boot-jdk=jdk-image --with-jvm-variants=core
--with-jvm-interpreter=cpp --with-cups-include=/opt/**freeware/include
--x-includes=/opt/freeware/**include
Below you can find the changes and additions I've done, sorted by file.
Most of them are just additions which are only active during the AIX build
anyway or simple changes where AIX has been added to conditions which
already check for Linux and/or Solaris. The files with the biggest changes
which you're probably want to look on more thoroughly are
'src/solaris/native/java/net/**NetworkInterface.c' and
'src/solaris/native/sun/nio/**ch/Net.c' altough they shouldn't change
anything on the current OpenJDK platforms as well.
Notice that there are still some files and some functionality missing
from the current change (notably NIO) but it still yields a running JDK
which can execute HelloWorld on the
Re: Replacement of sun.reflect.Reflection#getCallerClass
On 09/18/2013 05:21 PM, David M. Lloyd wrote:
On 09/03/2013 12:16 PM, Peter Levart wrote:
[...]
*AND* that Reflection.getCallerClass() can only be called from within
methods annotated with @CallerSensitive.
Now for that part, the public API equivalent
(StackTraceFrame.getCallerClass() or whatever it is called) need not
be restricted to methods annotated with any annotation, but that
means that this public API should not be used to implement security
decisions since MethodHandles API allows caller to be spoofed unless
looking-up a method annotated with @CallerSensitive...
Peter, can you please elaborate on this a bit? I could find nothing
in the MethodHandles API or its associated classes that would seem to
give the ability to call another method with a spoofed caller. Yes
you can set up a Lookup for another class but I don't see how that
would affect the ability of (say) a security manager to make access
decisions based on the call stack/class context?
Hi David,
The thing with method handles is that they perform all security checks
not at invoke-time (like reflection), but at lookup-time. If you have a
hold on a MethodHandle object, you can always invoke it. All security
checks must have been performed at lookup-time. This includes security
checks that are based on what the caller of the method is. In case of
method handles, the caller is the class associated with the Lookup
object - the lookup class.
Try this example:
// --- the following be loaded by the bootstrap class loader
package sys;
import sun.reflect.CallerSensitive;
import sun.reflect.Reflection;
import java.lang.invoke.MethodHandles;
public class CSUtil
{
public static final MethodHandles.Lookup lookup =
MethodHandles.lookup();
@CallerSensitive
public static void printCallerClassLoader(String prefix) {
Class? cc = Reflection.getCallerClass();
System.err.println(prefix + :\n
+ cc + \n loaded by
+ cc.getClassLoader() + \n);
}
public static class Nested {}
}
// ---the following be loaded by application class loader
package usr;
import sys.CSUtil;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
public class CSTest
{
public static final MethodHandles.Lookup lookup =
MethodHandles.lookup();
public static void main(String[] args) throws Throwable
{
MethodHandle mh1 = CSTest.lookup.findStatic(
CSUtil.class,
printCallerClassLoader,
MethodType.methodType(void.class, String.class)
);
mh1.invokeExact(mh1);
MethodHandle mh2 = CSUtil.lookup.findStatic(
CSUtil.class,
printCallerClassLoader,
MethodType.methodType(void.class, String.class)
);
mh2.invokeExact(mh2);
MethodHandle mh3 =
CSUtil.lookup.in(CSUtil.Nested.class).findStatic(
CSUtil.class,
printCallerClassLoader,
MethodType.methodType(void.class, String.class)
);
mh3.invokeExact(mh3);
MethodHandle mh4 = CSUtil.lookup.in(CSTest.class).findStatic(
CSUtil.class,
printCallerClassLoader,
MethodType.methodType(void.class, String.class)
);
mh4.invokeExact(mh4);
}
}
...which prints:
mh1:
class java.lang.invoke.MethodHandleImpl$BindCaller$T/523429237
loaded by sun.misc.Launcher$AppClassLoader@15db9742
mh2:
class java.lang.invoke.MethodHandleImpl$BindCaller$T/1450495309
loaded by null
mh3:
class java.lang.invoke.MethodHandleImpl$BindCaller$T/2001049719
loaded by null
Exception in thread main java.lang.IllegalAccessException: Attempt to
lookup caller-sensitive method using restricted lookup object
at
java.lang.invoke.MethodHandles$Lookup.findBoundCallerClass(MethodHandles.java:1123)
at
java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:619)
at usr.CSTest.main(CSTest.java:39)
You can see that the caller class it not actually the class doing
lookup, but some anonymous class which is loaded by the same class
loader as the lookup class and maybe it shares some other properties
with it (it seems that this is sufficient for security checks). The mh3
is interesting in that the caller is different from that of mh2. The
Lookup.in(Class) method returns a Lookup object with different lookup
class and so the caller class is different too. Although the
printCallerClassLoader is a public method in a public class, the mh4 can
not be looked-up, because this could be used to spoof the caller class
loader for any such public method. Imagine:
// this throws IllegalAccessException. If it didn't...
MethodHandle mh = MethodHandles.lookup()
.in(String.class)
.findVirtual(
Field.class,
get,
MethodType.methodType(Object.class,
Re: java.lang.reflect.Parameter comments
Sorry for the late reply,
On 8/25/2013 7:03 AM, Kasper Nielsen wrote:
Hi,
just 2 short questions/commons on java.lang.reflect.Parameter
1)
I was wondering if there is any reason for java.lang.reflect.Parameter not
to expose the index field?
Not sure what you mean by the index field, but if you mean the
name_index item in the MethodParameters attribute, then it is possible to
know whether it's zero by calling Parameter#isNamePresent.
I'm talking about the index field as in
java.lang.reflect.Parameter.index, the field that indicates which parameter
you are if you call parameter.getDeclaringExecutable().getParameters().
I have a couple of places where I have to include the index when passing a
parameter around. Instead of just being able to call parameter.getIndex().
A simple getter should do
public int getIndex() {
return index;
}
Yes and no. First, the historic use of getGenericXXX in java.lang.reflect
is wrong (it should be getParameterizedXXX) but it can't be changed now.
The Language Model API in javax.lang.model.** is much better with
terminology. Second, when we add methods to existing java.lang.reflect
types, we hold our noses and use Generic for consistency, e.g., the new
AnnotatedArrayType interface for type annotations has a method
getAnnotatedGenericComponentTy**pe that is consistent with the
getGenericComponentType method in GenericArrayType. Third, when we add new
types to java.lang.reflect, we use the correct terminology, hence Parameter#
**getParameterizedType.
Thanks for explanation.
- Kasper
hg: jdk8/tl/langtools: 8017248: Compiler Diacritics Issue
Changeset: 36e342dd57e2 Author:kizune Date: 2013-09-19 17:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36e342dd57e2 8017248: Compiler Diacritics Issue Reviewed-by: naoto ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java
hg: jdk8/tl/jdk: 8017248: Compiler Diacritics Issue
Changeset: 22e9f0067b5a Author:kizune Date: 2013-09-19 17:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22e9f0067b5a 8017248: Compiler Diacritics Issue Reviewed-by: naoto ! src/share/classes/sun/launcher/LauncherHelper.java + test/tools/launcher/8017248/ClassAÌ.java + test/tools/launcher/8017248/test.sh
Re: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX
Hi,
w.r.t the one issue below : is the awt load library code the only place you
need/are doing this ? If someone else (hotspot, core-libs) already
assented to this
then I guess I could too but I'd like to hear for sure that hotspot and
core-libs
teams both agree to this approach and whether there is an alternative.
-phil.
On 9/19/13 4:29 AM, Volker Simonis wrote:
Hi Phil,
thank you for looking at the changes. Please find my answers inline:
/* AIX does not provide the 'dladdr' function. But fortunately, we've
42 * already implemented it in the HotSpot, because we need it
there as
43 * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}).
Whilst this is in ifdef AIX this reliance on an exported hotspot
function sounds hacky. What actual requirement is there that the
AIX class libraries be so tightly-coupled with that VM?
There is no contract there.
You're right, there is no contract. It's just pragmatic solution and I
think it should always work because the libjvm will always be loaded
at the point in AWT where it is used. Another solution would be to
re-implement the functionality in the class library and I don't like
code duplication either.
-phil.
Re: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method
Thanks Joel,
I will push this now.
Regards, Peter
On 09/18/2013 11:28 AM, Joel Borggrén-Franck wrote:
Looks good Peter,
cheers
/Joel
On 2013-09-15, Peter Levart wrote:
Hi,
I rebased the changes and added @bug tag to test. Here's new webrev:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.04/
Joel, I believe you've got the R mojo now...
Regards, Peter
On 09/09/2013 06:57 PM, Peter Levart wrote:
Hi Joel,
Thanks for reviewing.
On 09/09/2013 04:25 PM, Joel Borggrén-Franck wrote:
Hi Peter,
Thanks for this, please add a @bug 8011940 tag to your test. IMO you don't
need a re-review for that. Otherwise looks good.
I'll do that. I just didn't know whether tagging with bug-ID is
meant for all tests that arise from fixing a particular bug or
just those that test the presence/fixture of the bug. The 8011940
bug is about scalability and the test is not testing scalability
(it has been demonstrated by a micro-benchmark, but that is not
included in the test). The test is just covering the logic that
has been re-factored and has not had any tests before.
Regards, Peter
We still need a Reviewer, Chris, you reviewed a previous version, can you look
at this one too?
cheers
/Joel
On 27 aug 2013, at 15:00, Peter Levartpeter.lev...@gmail.com wrote:
Hi Joel and others,
Here's a 3rd revision of this proposed patch:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.03/
I used LinkedHashMap for annotations in this one. It means that now even
.getAnnotations() are reported in declaration order: 1st inherited (includes
overridden) then declared (that are not overriding). For example, using @Inherited
annotations A1, A2, A3:
@A1(C)
@A2(C)
class C {}
@A1(D)
@A3(D)
class D extends C {}
D.class.getAnnotations() now returns: { @A1(D), @A2(C), @A3(D) } ...
The LHM constructor uses the following expression to estimate the initial
capacity of the LHM:
3326 annotations = new LinkedHashMap((Math.max(
3327 declaredAnnotations.size(),
3328 Math.min(12, declaredAnnotations.size() +
superAnnotations.size())
3329 ) * 4 + 2) / 3
3330 );
I think this strikes some balance between effectivity and accuracy of
estimation. I could pre-scan the superclass annotations and calculate the exact
final size of the annotations Map before constructing it though. Tell me if
this is worth the effort.
I also created a test that tests 3 things:
- class annotation inheritance
- order of class annotations reported by .getAnnotations() and
.getDeclaredAnnotations() methods (although not specified, the order is now
stable and resembles declaration order)
- behaviour of class annotation caching when class is redefined
Regards, Peter
On 08/13/2013 09:52 AM, Joel Borggrén-Franck wrote:
Hi,
Comments inline,
On 12 aug 2013, at 14:40, Peter Levartpeter.lev...@gmail.com wrote:
On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote:
- annotation (@interface) declarations can themselves be redefined (for
example, defaults changed). Such redefinitions don't affect already initialized
annotations. Default values are cached in AnnotationType which is not
invalidated as a result of class redefinition. Maybe it should be. And even if
AnnotationType was invalidated as a result of class redefinition, the defaults
are looked-up when particular annotations are initialized and then combined
with parsed values in a single values map inside each annotation instance
(proxy), so invalidating AnnotationType would have no effect on those
annotations.
3326 if (annotations == null) { // lazy construction
3327 annotations = new HashMap();
3328 }
I think this should be a LinkedHashMap, so that iteration is predictable
(I know it isn't in the current code). Also the size of the map is known
so you can use a constructor with an explicit initial capacity.
Right, AnnotationParser does return LinkedHashMap, so at least
decalredAnnotations are in parse-order. I will change the code to use
LinkedHashMap for inherited/combined case too.
Thanks.
The number of annotations that end-up in inherited/combined Map is not known in
advance. I could make a separate pre-scan for superclass annotations that are
@Inheritable and don't have the same key as any of declared annotations and
then sum this count with declared annotations count, but I don't think this
will be very effective. I could allocate a large-enough Map to always fit (the
count of superclass annotations + the count of declared annotations), but that
could sometimes lead to much over-allocated Maps. I could take the
min(DEFAULT_CAPACITY, superclass annotations count + declared annotations
count) as the initial capacity for the Map. What do you think which of those 3
alternatives is the best?
My bad. I was thinking of the case where every inherited
hg: jdk8/tl/langtools: 8024609: sjavac assertion fails during call to BuildState.collectArtifacts
Changeset: 0cfd5baa7154 Author:ohrstrom Date: 2013-09-19 08:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0cfd5baa7154 8024609: sjavac assertion fails during call to BuildState.collectArtifacts Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/BuildState.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java
hg: jdk8/tl/jdk: 8011940: java.lang.Class.getAnnotations() always enters synchronized method
Changeset: 7557062d2dd2 Author:plevart Date: 2013-09-19 16:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7557062d2dd2 8011940: java.lang.Class.getAnnotations() always enters synchronized method Reviewed-by: jfranck, chegar, psandoz, shade ! src/share/classes/java/lang/Class.java + test/java/lang/annotation/AnnotationsInheritanceOrderRedefinitionTest.java
RFR 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales
Hi, please review my fix for 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales The idea of the fix is to replace test case with the complex file name in it by the test that generates and compiles such file at the run time. The webrev can be found at: http://cr.openjdk.java.net/~kizune/8025076/webrev.04/ With best regards, /Alex
hg: jdk8/tl/jdk: 8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
Changeset: 278873b2b3f8 Author:sherman Date: 2013-09-19 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/278873b2b3f8 8023113: tools/jar/ChangeDir.java fails if /tmp/a exists Summary: updated the test case Reviewed-by: alanb ! test/tools/jar/ChangeDir.java
Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
Recommended changes made:
http://cr.openjdk.java.net/~drchase/8022701/webrev.04/
Test with jtreg (for pass and for induced failure) on MacOS,
not sure what additional other testing is desired since it is entirely in the
libraries.
I included code to handle the case of a broken field-referencing methodhandle,
but did not test it because there's no syntax for these in Java, nor is their
creation
well-documented.
David
On 2013-09-13, at 12:02 AM, John Rose john.r.r...@oracle.com wrote:
On Sep 12, 2013, at 5:44 PM, David Chase david.r.ch...@oracle.com wrote:
Do these sibling bugs have numbers?
Yes, 8022701. I just updated the bug to explain their common genesis.
And I take it you would like to see
1) a test enhanced with ASM to do all 3 variants of this
Yes, please. The case of no such field does not have a direct cause from
lambda expressions AFAIK, but it can occur with raw CONSTANT_MethodHandles.
(It would be reasonable for javac to emit CONSTANT_MH's for fields in some
very limited circumstances, but I'll bet it doesn't.)
2) DO attach the underlying cause
Yes. Read the javadoc for ExceptionInInitializerError for an example of why
users want the underlying cause for linkage errors.
(Golly, I wonder what happens if resolution of a CONSTANT_MethodHandle tries
to touch a class with a booby-trapped clinit. I hope it's the case that
the ExceptionInInitializerError just passes straight up the stack. But if it
were to get wrapped in a ROE of some sort, it would probably bubble up as an
IAE. Could be a charming exploration. Actually, no, I don't want to go in
there. Getting all possible linkage errors correct is fine, but we have more
important things to do.)
— John
David
On 2013-09-12, at 5:35 PM, John Rose john.r.r...@oracle.com wrote:
It looks good. I have three requests.
Regarding this comment:
+ * See MethodSupplier.java to see how to produce these bytes.
+ * They encode that class, except that method m is private, not public.
The recipe is incomplete, since it does not say which bits to tweak to make
m private. Please add that step to the comments more explicitly, or if
possible to the code (so bogusMethodSupplier is a clean copy of the od
output). I suppose you could ask sed to change the byte for you. That
will make this test a better example for future tests, and make it easier
to maintain if javac output changes. The high road to use would be asm,
although for a single byte tweak od works OK.
Also, this bug has two twins. The same thing will happen with
NoSuchMethodE* and NoSuchFieldE*. Can you please make fixes for those guys
also?
FTR, see MemberName.makeAccessException() for logic which maps the other
way, from *Error to *Exception. I don't see a direct way to avoid the
double mapping (Error=Exception=Error) when it occurs.
For the initCause bit we should do this:
} catch (IllegalAccessException ex) {
Error err = new IllegalAccessError(ex.getMessage());
err.initCause(ex.getCause()); // reuse underlying cause of ex
throw err;
} ... and for NSME and NSFE...
That way users can avoid the duplicate exception but can see any underlying
causes that the JVM may include.
Thanks for untangling this!
— John
On Sep 12, 2013, at 12:17 PM, David Chase david.r.ch...@oracle.com wrote:
The test is adapted from the test in the bug report.
The headline on the bug report is wrong -- because it uses reflection in
the test to do the invocation,
the thrown exception is wrapped with InvocationTargetException, which is
completely correct.
HOWEVER, the exception inside the wrapper is the wrong one.
The new test checks the exception in both the reflective-invocation and
plain-invocation cases,
and also checks both a method handle call (which threw the wrong
exception) and a plain
call (which threw, and throws, the right exception).
The test also uses a tweaked classloader to substitute the borked
bytecodes necessary to get
the error, so it is not only shell-free, it can also be run outside jtreg.
On 2013-09-12, at 2:34 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
On Sep 12, 2013, at 11:28 AM, David Chase david.r.ch...@oracle.com
wrote:
New webrev, commented line removed:
http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
I think the change is good given that the tests work now. Is your test
derived from the test in the bug report?
And it would be good if John could also have a quick look (just be to be
sure).
-- Chris
On 2013-09-12, at 1:53 PM, David Chase david.r.ch...@oracle.com wrote:
I believe it produced extraneous output -- it was not clear to me that
it was either necessary or useful to fully describe all the converted
exceptions that lead to the defined exception being thrown. The
commented line should have just been removed (I think).
On
Re: RFR: 8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
On 9/19/2013 1:52 AM, Alan Bateman wrote: On 18/09/2013 20:45, Xueming Shen wrote: OK, how about this one? I'm even using lambda:-) http://cr.openjdk.java.net/~sherman/8023113/webrev/ -Sherman Looks okay except that Files.list returns a stream that needs to be closed to avoid leaking resources. updated accordingly. http://cr.openjdk.java.net/~sherman/8023113/webrev agreed we had enough fun already here. -Sherman As a side note, as cleanup is attempting to delete a file tree then you could eliminate the recursion by using Files.walkFileTree with the directories removed in the postVisitDirectory method. It might be tempting to use the new walk method but it returns each directory before its entries and so isn't appropriate for recursive ops where you need to do touch the directory after its entries. I'm not suggesting spending any more time on this test of course, you've done more than enough. -Alan.
Re: RFR (S) 8001109: arity mismatch on a call to spreader method handle should elicit IllegalArgumentException
Looks good. Best regards, Vladimir Ivanov On 9/13/13 5:02 AM, John Rose wrote: Please review this change for a change to the JSR 292 implementation: http://cr.openjdk.java.net/~jrose/8001109/webrev.00/ The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs. In the RI, the exception-raising code is simplified to throw just IAE. Thanks, — John
Re: Replacement of sun.reflect.Reflection#getCallerClass
On 09/19/2013 07:03 AM, Peter Levart wrote:
On 09/18/2013 05:21 PM, David M. Lloyd wrote:
On 09/03/2013 12:16 PM, Peter Levart wrote:
[...]
*AND* that Reflection.getCallerClass() can only be called from within
methods annotated with @CallerSensitive.
Now for that part, the public API equivalent
(StackTraceFrame.getCallerClass() or whatever it is called) need not
be restricted to methods annotated with any annotation, but that
means that this public API should not be used to implement security
decisions since MethodHandles API allows caller to be spoofed unless
looking-up a method annotated with @CallerSensitive...
Peter, can you please elaborate on this a bit? I could find nothing
in the MethodHandles API or its associated classes that would seem to
give the ability to call another method with a spoofed caller. Yes
you can set up a Lookup for another class but I don't see how that
would affect the ability of (say) a security manager to make access
decisions based on the call stack/class context?
Hi David,
The thing with method handles is that they perform all security checks
not at invoke-time (like reflection), but at lookup-time. If you have a
hold on a MethodHandle object, you can always invoke it. All security
checks must have been performed at lookup-time. This includes security
checks that are based on what the caller of the method is. In case of
method handles, the caller is the class associated with the Lookup
object - the lookup class.
Try this example:
// --- the following be loaded by the bootstrap class loader
package sys;
import sun.reflect.CallerSensitive;
import sun.reflect.Reflection;
import java.lang.invoke.MethodHandles;
public class CSUtil
{
public static final MethodHandles.Lookup lookup =
MethodHandles.lookup();
@CallerSensitive
public static void printCallerClassLoader(String prefix) {
Class? cc = Reflection.getCallerClass();
System.err.println(prefix + :\n
+ cc + \n loaded by
+ cc.getClassLoader() + \n);
}
public static class Nested {}
}
// ---the following be loaded by application class loader
package usr;
import sys.CSUtil;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
public class CSTest
{
public static final MethodHandles.Lookup lookup =
MethodHandles.lookup();
public static void main(String[] args) throws Throwable
{
MethodHandle mh1 = CSTest.lookup.findStatic(
CSUtil.class,
printCallerClassLoader,
MethodType.methodType(void.class, String.class)
);
mh1.invokeExact(mh1);
MethodHandle mh2 = CSUtil.lookup.findStatic(
CSUtil.class,
printCallerClassLoader,
MethodType.methodType(void.class, String.class)
);
mh2.invokeExact(mh2);
MethodHandle mh3 =
CSUtil.lookup.in(CSUtil.Nested.class).findStatic(
CSUtil.class,
printCallerClassLoader,
MethodType.methodType(void.class, String.class)
);
mh3.invokeExact(mh3);
MethodHandle mh4 = CSUtil.lookup.in(CSTest.class).findStatic(
CSUtil.class,
printCallerClassLoader,
MethodType.methodType(void.class, String.class)
);
mh4.invokeExact(mh4);
}
}
...which prints:
mh1:
class java.lang.invoke.MethodHandleImpl$BindCaller$T/523429237
loaded by sun.misc.Launcher$AppClassLoader@15db9742
mh2:
class java.lang.invoke.MethodHandleImpl$BindCaller$T/1450495309
loaded by null
mh3:
class java.lang.invoke.MethodHandleImpl$BindCaller$T/2001049719
loaded by null
Exception in thread main java.lang.IllegalAccessException: Attempt to
lookup caller-sensitive method using restricted lookup object
at
java.lang.invoke.MethodHandles$Lookup.findBoundCallerClass(MethodHandles.java:1123)
at
java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:619)
at usr.CSTest.main(CSTest.java:39)
You can see that the caller class it not actually the class doing
lookup, but some anonymous class which is loaded by the same class
loader as the lookup class and maybe it shares some other properties
with it (it seems that this is sufficient for security checks). The mh3
is interesting in that the caller is different from that of mh2. The
Lookup.in(Class) method returns a Lookup object with different lookup
class and so the caller class is different too. Although the
printCallerClassLoader is a public method in a public class, the mh4 can
not be looked-up, because this could be used to spoof the caller class
loader for any such public method. Imagine:
// this throws IllegalAccessException. If it didn't...
MethodHandle mh = MethodHandles.lookup()
.in(String.class)
.findVirtual(
Field.class,
hg: jdk8/tl/langtools: 8024437: Inferring the exception thrown: sometimes fails to compile
Changeset: 2375ce96e80d Author:vromero Date: 2013-09-19 20:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2375ce96e80d 8024437: Inferring the exception thrown: sometimes fails to compile Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java
Re: Java 8 RFR 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent
On Sep 17, 2013, at 6:03 PM, Remi Forax wrote: On 09/18/2013 02:08 AM, Brian Burkhalter wrote: The proposed patch has been updated at the same location: http://cr.openjdk.java.net/~bpb/8024331/. Thanks, Brian looks good. Rémi Thanks, Rémi JDK 8 Reviewers: This patch still needs Official Approval unless of course there are objections. Thanks, Brian On Sep 17, 2013, at 4:27 PM, Brian Burkhalter wrote: I'll make the various updates and repost.
Re: RFR (S) 8001108: an attempt to use init as a method name should elicit NoSuchMethodException
On Sep 18, 2013, at 5:05 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
src/share/classes/java/lang/invoke/MethodHandles.java:
+ * methods as if they were normal methods, but the JVM verifier rejects
them.
I think you should say JVM byte code verifier here.
Done. s/byte code/bytecode/.
+ * em(Note: JVM internal methods named {@code init} not visible
to this API,
+ * even though the {@code invokespecial} instruction can refer to
them
+ * in special circumstances. Use {@link #findConstructor
findConstructor}
Not exactly sure but should this read are not visible?
Yes.
MemberName resolveOrFail(byte refKind, Class? refc, String name,
MethodType type) throws NoSuchMethodException, IllegalAccessException {
+type.getClass(); // NPE
checkSymbolicClass(refc); // do this before attempting to resolve
-name.getClass(); type.getClass(); // NPE
+checkMethodName(refKind, name);
Could you add a comment here saying that checkMethodName does an implicit
null pointer check on name? Maybe a comment for checkMethodName too.
Done.
What was the problem with the null pointer exceptions? Is it okay that we
might throw another exception before null checking name?
Foo. The reordering of those null checks seems to be a needless change that
crept in. I'm going to keep them the way they are.
See updated webrev:
http://cr.openjdk.java.net/~jrose/8001108/webrev.01/
— John
On Sep 12, 2013, at 6:47 PM, John Rose john.r.r...@oracle.com wrote:
Please review this change for a change to the JSR 292 implementation:
http://cr.openjdk.java.net/~jrose/8001108/webrev.00
Summary: add an explicit check for leading , upgrade the unit tests
The change is mostly to javadoc and unit tests, documenting and testing some
corner cases of JSR 292 APIs.
In the RI, there is an explicit error check.
Thanks,
— John
P.S. Since this is a change which oriented toward JSR 292 functionality, the
review request is to mlvm-dev and core-libs-dev.
Changes which are oriented toward performance will go to mlvm-dev and
hotspot-compiler-dev.
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales
Hi Alex, Should the test case also check the encoding of the platform? Does it work under the environment where the encoding is, say US-ASCII? Naoto On 9/19/13 9:43 AM, Alexander Zuev wrote: Hi, please review my fix for 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales The idea of the fix is to replace test case with the complex file name in it by the test that generates and compiles such file at the run time. The webrev can be found at: http://cr.openjdk.java.net/~kizune/8025076/webrev.04/ With best regards, /Alex
Re: RFR (S) 8024599: JSR 292 direct method handles need to respect initialization rules for static members
On Sep 12, 2013, at 7:24 PM, John Rose john.r.r...@oracle.com wrote: Please review this change for a change to the JSR 292 implementation: http://cr.openjdk.java.net/~jrose/8024599/webrev.00/ Summary: Align MH semantic with bytecode behavior of constructor and static member accesses, regarding clinit invocation. The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs. I have a reviewer (Alex Buckley) for the documentation changes, but I would also like a quick code review for the unit test. Also, there is a code insertion (predicated on a false symbolic constant) which serves to document the buggy JDK 7 behavior. I'm not particularly attached to it, so I'm open to either a yea or nay on keeping it. Leaning nay at the moment. — John
Re: RFR 8024707: TRANSFORMEREXCEPTION : ITEM() RETURNS NULL WITH NODE LIST OF LENGTH =1 IN JAXP
Hi Aleksej, Looks like the getLength() method has the same problem. Joe On 9/17/2013 5:01 AM, Aleksej Efimov wrote: Hi Everyone, There is a bug [1] in JAXP about transformation of one-item sized node list: When the length of nodelist which is passed to a XSLT extension function is 1, the node gotten from the node list becomes null. New test illustrates this issue [2]. Full webrev with proposed fix can be found here: [3]. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024707 [2] http://cr.openjdk.java.net/~aefimov/8024707/raw_files/new/jdk/test/javax/xml/jaxp/parsers/8024707/XSLT.java [3] http://cr.openjdk.java.net/~aefimov/8024707/ Best regards, Aleksej
Re: Replacement of sun.reflect.Reflection#getCallerClass
On 09/19/2013 09:55 PM, David M. Lloyd wrote: Imagine: // this throws IllegalAccessException. If it didn't... MethodHandle mh = MethodHandles.lookup() .in(String.class) .findVirtual( Field.class, get, MethodType.methodType(Object.class, Object.class) ); Field valueField = String.class.getDeclaredField(value); String abc = abc; // ... then the following would invoke: valueField.get(abc) and pretend that // it was invoked from the String class, which would succeed... char[] abcArray = (char[])(Object) mh.invokeExact(valueField, (Object) abc); // ...and you could observe the following: abcArray[0] = 'A'; assert abc.charAt(0) == 'A'; This must have changed since JDK 7 because I don't see any of this behavior with the classic getCallerClass(int) method. In other words using in does not appear to affect the frames reported by getCallerClass(int) (or SecurityManager.getClassContext() or Thread.getStackTrace()) at all. It only affects frames seen in caller sensitive methods. In other methods, the JDK7 reported caller is the one invoking the MH, I think, but that's not important, since other methods are not caller sensitive. In JDK8 you can't even get the caller unless you are in the @CS annotated method. It looks like this new behavior is a result of @CallerSensitive and changes associated with it (in particular those weird pseudo-class names are not reported in 7); I'd say the fatal flaw exposed here is in those changes, not in the original method behavior. It seems like we've gone way off course if this is the case. I think the behavior is equivalent. In JDK7 all caller-sensitive methods are maintained as a hard-coded list/switch inside MHs implementation. They are marked with @CS annotation in JDK8 instead, which is easier to maintain. Especially consider that SecurityManager.getClassContext() is a supported, non-deprecated API designed for the express purpose of access checking, which (as far as I can test) works similarly to getCallerClass(int). If method handles could spoof callers in this way then we've blown yet another massive hole in Java security. They can't spoof callers. As you can see in above example, such spoofing look-ups of @CS methods are prevented. -- - DML Regards, Peter
Re: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales
Hi Naoto, I've checked that it works in C locale - since I'm setting LC_CTYPE to UTF-8 before calling both javac and java everything works as expected. With best regards, /Alex 20.09.2013, в 1:34, Naoto Sato naoto.s...@oracle.com написал(а): Hi Alex, Should the test case also check the encoding of the platform? Does it work under the environment where the encoding is, say US-ASCII? Naoto On 9/19/13 9:43 AM, Alexander Zuev wrote: Hi, please review my fix for 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales The idea of the fix is to replace test case with the complex file name in it by the test that generates and compiles such file at the run time. The webrev can be found at: http://cr.openjdk.java.net/~kizune/8025076/webrev.04/ With best regards, /Alex
Re: JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions
The webrev has been updated with Joe's comments addressed. On 09/19/13 00:11, David Holmes wrote: On 19/09/2013 9:59 AM, Eric McCorkle wrote: This still needs to be reviewed. You seem to have ignored Joe's comments regarding the change to Modifier being incorrect. David On 09/16/13 14:50, Eric McCorkle wrote: I pulled the class files into byte array constants, as a temporary measure until a viable method for testing bad class files is developed. The webrev has been refreshed. The class files will be taken out before I push. http://cr.openjdk.java.net/~emc/8020981/ On 09/13/13 20:48, Joe Darcy wrote: To avoid storing binaries in Hg, you could try something like: * uuencode / ascii armor the class file * convert to byte array in the test * load classes from byte array -Joe On 09/13/2013 11:54 AM, Eric McCorkle wrote: I did it by hand with emacs. I would really rather tackle the bad class files for testing issue once and for all, the Right Way (tm). But with ZBB looming, now is not the time to do it. Hence, I have created this task https://bugs.openjdk.java.net/browse/JDK-8024674 I also just created this one: https://bugs.openjdk.java.net/browse/JDK-8024812 On 09/13/13 13:54, Peter Levart wrote: Hi Eric, How did you create those class files? By hand using a HEX editor? Did you create a program that patched the original class file? If the later is the case, you could pack that patching logic inside a custom ClassLoader... To hacky? Dependent on future changes of javac? At least the bad name patching could be performed trivially and reliably, I think: search and replace with same-length string. Regards, Peter On 09/13/2013 07:35 PM, Eric McCorkle wrote: Ugh. Byte arrays of class file data is really a horrible solution. I have already filed a task for test development post ZBB to develop a solution for generating bad class files. I'd prefer to file a follow-up to this to add the bad class file tests when that's done. On 09/13/13 10:55, Joel Borggrén-Franck wrote: I think the right thing to do is to include the original compiling source in a comment, together with a comment on how you modify them, and then the result as a byte array. IIRC I have seen test of that kind before somewhere in our repo. cheers /Joel On Sep 13, 2013, at 4:49 PM, Eric McCorkle eric.mccor...@oracle.com wrote: There is no simple means of generating bad class files for testing. This is a huge deficiency in our testing abilities. If these class files shouldn't go in, then I'm left with no choice but to check in no test for this patch. However, anyone can run the test I've provided with the class files and see that it works. On 09/13/13 09:55, Joel Borggrén-Franck wrote: Hi Eric, IIRC we don't check in classfiles into the repo. I'm not sure how we handle testing of broken class-files in jdk, but ASM might be an option, or storing the class file as an embedded byte array in the test. cheers /Joel On Sep 13, 2013, at 3:40 PM, Eric McCorkle eric.mccor...@oracle.com wrote: A new webrev is posted (and crucible updated), which actually validates parameter names correctly. Apologies for the last one. On 09/12/13 16:02, Eric McCorkle wrote: Hello, Please review this patch, which implements correct behavior for the Parameter Reflection API in the case of malformed class files. The bug report is here: https://bugs.openjdk.java.net/browse/JDK-8020981 The webrev is here: http://cr.openjdk.java.net/~emc/8020981/ This review is also on crucible. The ID is CR-JDK8TL-182. Thanks, Eric eric_mccorkle.vcf
RFR: 6233323,,ZipEntry.isDirectory() may return false incorrectly
Hi, Please help review the change for #6233323. http://cr.openjdk.java.net/~sherman/6233323/webrev Background info: ZipFile.getEntry() is implemented the way that it first tries to find the entry with the exactly matched name. If failed, it then tries to see if the specified name ends with a slash '/', if not, it then tries to find the entry with the '/' appended, with the expectation that there might be a directory entry, whose name ends with '/'. The problem here is that the returned entry actually sets its name with the original passed in name in this situation, so if the passed in name does not end with the '/' and the search result is the one with '/' (directory), the returned entry then fails the ZipEntry.isDirectory() test, which is purely implemented on the assumption/specification that A directory entry is defined to be one whose name ends with a '/'. The change here is to return the entry with the name of the real name of the entry in the zip file, with the '/' slash appended. I also added some words to clarify this behavior (given the nature of the change, I probably need a CCC approval). Interestingly, an entry whose name ends with a slash is a directory entry appears to be a convention, instead of something being explicitly specified in either pkware or info-zip's specification. zip/uzip and our jar definitely work with the assumption that a slash / ended entry is a directory, however it easily to read/write an entry with slash ended name as a normal file entry via ZipInputStream/OutputStream (both unzip and jar treat such an entry as a directory entry, they create a directory instead of extracting it as a file, when being extracted). One of the reasons that I did not explicitly say directory entry in the wording added to the getEntry() method. Thanks! -Sherman
Re: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales
Thanks for checking. Looks good to me. Naoto On 9/19/13 3:12 PM, Alexander Zuev wrote: Hi Naoto, I've checked that it works in C locale - since I'm setting LC_CTYPE to UTF-8 before calling both javac and java everything works as expected. With best regards, /Alex 20.09.2013, в 1:34, Naoto Sato naoto.s...@oracle.com написал(а): Hi Alex, Should the test case also check the encoding of the platform? Does it work under the environment where the encoding is, say US-ASCII? Naoto On 9/19/13 9:43 AM, Alexander Zuev wrote: Hi, please review my fix for 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales The idea of the fix is to replace test case with the complex file name in it by the test that generates and compiles such file at the run time. The webrev can be found at: http://cr.openjdk.java.net/~kizune/8025076/webrev.04/ With best regards, /Alex
Re: RFR 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales
Hi Alex, The class can be compiled into the current directory (scratch), this will eliminate: a. the deletion of the files and allow jtreg to clean out the scratch directory b. uses of TEST_CLASSES_DIR.getAbsolutePath(). Thanks Kumar Hi, please review my fix for 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales The idea of the fix is to replace test case with the complex file name in it by the test that generates and compiles such file at the run time. The webrev can be found at: http://cr.openjdk.java.net/~kizune/8025076/webrev.04/ With best regards, /Alex
hg: jdk8/tl/jdk: 8025002: .codePoints().sorted().iterator().hasNext() causes NegativeArraySizeException
Changeset: f36714707c38 Author:psandoz Date: 2013-09-18 10:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f36714707c38 8025002: .codePoints().sorted().iterator().hasNext() causes NegativeArraySizeException Reviewed-by: henryjen, alanb ! src/share/classes/java/lang/CharSequence.java ! test/java/lang/CharSequence/DefaultTest.java
hg: jdk8/tl/langtools: 8025110: TreeCopier does not correctly copy LabeledStatementTree
Changeset: 9a75bdb249a2 Author:jjg Date: 2013-09-19 19:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9a75bdb249a2 8025110: TreeCopier does not correctly copy LabeledStatementTree Reviewed-by: jjg Contributed-by: Werner Dietl wdi...@gmail.com ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
hg: jdk8/tl/nashorn: 4 new changesets
Changeset: f954d3f4d192 Author:sundar Date: 2013-09-19 13:34 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f954d3f4d192 8025048: true as case label results in ClassCastException Reviewed-by: lagergren ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8025048-2.js + test/script/basic/JDK-8025048.js Changeset: 740b1133f1b6 Author:hannesw Date: 2013-09-19 15:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/740b1133f1b6 8023154: compileAllTests fails with: 2 tests failed to compile Reviewed-by: sundar, jlaskey ! make/build-benchmark.xml ! make/build.xml ! make/project.properties Changeset: 821b0b610861 Author:sundar Date: 2013-09-19 21:20 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/821b0b610861 8025080: Object literal getter, setter function with number format property name results in ClassFormatError Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8025080.js + test/script/basic/JDK-8025080.js.EXPECTED ! test/script/basic/parser/objectLitExpr.js.EXPECTED Changeset: 18d64bc4937d Author:sundar Date: 2013-09-19 23:48 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/18d64bc4937d 8025090: 'while' statement with 'test' using var before being declared in body results in VerifyError Reviewed-by: jlaskey ! src/jdk/nashorn/internal/ir/WhileNode.java + test/script/basic/JDK-8025090.js
hg: jdk8/tl/jdk: 8024405: Spliterators.spliterator should support CONCURRENT characteristic
Changeset: 0ef7ddef9de0 Author:psandoz Date: 2013-09-19 20:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ef7ddef9de0 8024405: Spliterators.spliterator should support CONCURRENT characteristic Reviewed-by: martin ! src/share/classes/java/util/Spliterator.java ! src/share/classes/java/util/Spliterators.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
