hg: jdk8/tl/jdk: 8019646: Clarify javadoc contract of LambdaMetafactory
Changeset: 5fa2fd782993 Author:briangoetz Date: 2013-10-24 13:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fa2fd782993 8019646: Clarify javadoc contract of LambdaMetafactory Reviewed-by: briangoetz, rfield Contributed-by: dan.sm...@oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java
hg: jdk8/tl/langtools: 8024930: Re-enable disabled bridging tests
Changeset: 62a67e0875ff Author:briangoetz Date: 2013-10-30 14:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/62a67e0875ff 8024930: Re-enable disabled bridging tests Reviewed-by: psandoz, rfield ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java
hg: jdk8/tl/jdk: 8027318: Lambda Metafactory: generate serialization-hostile read/writeObject methods for non-serializable lambdas
Changeset: ddb0b681654a Author:briangoetz Date: 2013-10-29 12:31 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddb0b681654a 8027318: Lambda Metafactory: generate serialization-hostile read/writeObject methods for non-serializable lambdas Reviewed-by: rfield, psandoz ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java
hg: jdk8/tl/jdk: 8024633: Lambda linkage performance - initialize generated class earlier
Changeset: 9732816c9d17 Author:briangoetz Date: 2013-10-29 12:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9732816c9d17 8024633: Lambda linkage performance - initialize generated class earlier Reviewed-by: briangoetz, rfield Contributed-by: sergey.kukse...@oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
hg: jdk8/tl/jdk: 8024637: Lambda linkage performance - use reflection instead of ASM to manipulate parameter types; ...
Changeset: 82ee370c3d7e Author:briangoetz Date: 2013-10-31 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82ee370c3d7e 8024637: Lambda linkage performance - use reflection instead of ASM to manipulate parameter types 8023984: Lambda linkage performance - use a method ref to a static factory instead of a ctor ref Reviewed-by: briangoetz, rfield Contributed-by: sergey.kukse...@oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
Re: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...
Ineexof(char) sounds like as fast and simpler?
Sent from my iPhone
On Nov 5, 2013, at 8:55 AM, Peter Levart wrote:
> On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote:
>> Changeset: 51b002381b35
>> Author:rfield
>> Date: 2013-11-04 10:12 -0800
>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51b002381b35
>>
>> 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class
>> 8027681: Lambda serialization fails once reflection proxy generation kicks in
>> Reviewed-by: ksrini, briangoetz, jfranck
>> Contributed-by: joel.fra...@oracle.com, brian.go...@oracle.com,
>> robert.fi...@oracle.com
>>
>> ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java
>> ! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java
>> ! src/share/classes/sun/reflect/misc/ReflectUtil.java
>> + test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java
>> !
>> test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java
>> + test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java
>>
> Hi Robert,
>
> I also propose a much faster variant of:
>
> + /**
> + * Checks if {@code Class cls} is a VM-anonymous class
> + * as defined by {@link sun.misc.Unsafe#defineAnonymousClass}
> + * (not to be confused with a Java Language anonymous inner class).
> + */
> + public static boolean isVMAnonymousClass(Class cls) {
> + return cls.getSimpleName().contains("/");
> + }
>
>
> The following:
>
> public static boolean isVMAnonymousClassFAST(Class cls) {
> String name = cls.getName();
> for (int i = name.length() - 1; i >= 0; i--) {
> char c = name.charAt(i);
> if (c == '.') return false;
> if (c == '/') return true;
> }
> return false; // root package
> }
>
> It's about 12..25x faster for typical class names and doesn't produce any
> garbage.
>
>
> Regards, Peter
>
Re: The future of Serialization
I've noticed there's not much interest in improving Serialization on these lists. This makes me wonder if java Serialization has lost relevance in recent years with the rise of protocol buffers apache thrift and other means of data transfer over byte streams. I sense your frustration, but I think you may be reaching the wrong conclusion. The lack of response is probably not evidence that there's no interest in fixing serialization; its that fixing serialization, with all the constraints that "fix" entails, is just really really hard, and its much easier to complain about it (and even say "let's just get rid of it") than to fix it. Should Serializable eventually be deprecated? Should Serialization be disabled by default? Should a new mechanism be developed? If a new mechanism is developed, what about circular object relationships? As I delved into my own explorations of serialization, I started to realize why such a horrible approach was the one that was ultimately chosen; while serialization is horrible and awful and leaky and insecure and complex and brittle, it does address problems like cyclic data structures and independent evolution of subclass and superclass better than the "clean" models. My conclusion is, at best, a new mechanism would have to live side-by-side with the old one, since it could only handle 95% of the cases. It might handle those 95% much better -- more cleanly, securely, and allowing easier schema evolution -- but the hard cases are still there. Still, reducing the use of the horrible old mechanism may still be a worthy goal, even if it can't be killed outright.
hg: jdk7/tl/jdk: 7012540: java.util.Objects.nonNull() incorrectly named
Changeset: 25462d7eee24 Author:briangoetz Date: 2011-02-02 13:13 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25462d7eee24 7012540: java.util.Objects.nonNull() incorrectly named Reviewed-by: darcy, weijun ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/nio/file/DirectoryIteratorException.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Objects.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! test/java/util/Objects/BasicObjectsTest.java
Re: hg: jdk8/tl/jdk: 8001642: Add Optional, OptionalDouble, OptionalInt, OptionalLong
> Has the optional classes been verified to serialize/deserialize correctly? > They are not serializable. > Finally, are these utilities critical to some other part JDK 8 that they were > pushed out now as opposed to JDK 9? > > They are part of the libraries being added by JSR-335 / Project Lambda. There is extensive discussion on Optional on lambda-dev and the JSR 335 EG lists.
