caution: bleeding-edge ahead!

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Sun Jan 18 21:41:46 UTC 2015


On 18/01/15 11:17, Ali Ebrahimi wrote:
> This works for me with latest code.
Thanks - I will take a look anyway to see what's going on.

Maurizio
>
> On Sun, Jan 18, 2015 at 1:15 PM, Michael Barker <mikeb01 at gmail.com 
> <mailto:mikeb01 at gmail.com>> wrote:
>
>     Hi,
>
>     The following compiles, but crashes at runtime.
>
>     public class C<any T> {
>         public void foo() {
>             __WhereVal(T) {
>                 ;
>             }
>             __WhereRef(T) {
>                 ;
>             }
>         }
>
>         public static void main(String[] args) {
>             C<int> c = new C<int>();
>             c.foo();
>         }
>     }
>
>     [barkerm at localhost SpecialisedMap]$ $JAVA_HOME/bin/javac -d bin
>     src/github/mikeb01/C.java && $JAVA_HOME/bin/java -cp bin
>     github.mikeb01.C
>     Specializing github.mikeb01.C${0=I}; searching for
>     github/mikeb01/C.class (not found)
>     Specializing github.mikeb01.C${0=I}; searching for
>     github/mikeb01/C.class (found)
>     Exception in thread "main"
>     java.lang.ArrayIndexOutOfBoundsException: 256
>     at
>     jdk.internal.org.objectweb.asm.ClassReader.readUTF8(ClassReader.java:2445)
>     at valhalla.specializer.WhereAttribute.read(WhereAttribute.java:62)
>     at
>     jdk.internal.org.objectweb.asm.ClassReader.readAttribute(ClassReader.java:2312)
>     at
>     jdk.internal.org.objectweb.asm.ClassReader.readMethod(ClassReader.java:965)
>     at
>     jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:729)
>     at valhalla.specializer.Specializer.specialize(Specializer.java:77)
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:409)
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:386)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:385)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:426)
>     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:317)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:359)
>     at github.mikeb01.C.main(C.java:14)
>
>     Mike.
>
>     On 14 January 2015 at 03:38, Timo Kinnunen
>     <timo.kinnunen at gmail.com <mailto:timo.kinnunen at gmail.com>> wrote:
>
>
>         I think it could be used to address that as well. You can’t
>         add layers to an existing class without rewriting its source
>         code, right? So under that allowance, you could rewrite
>         java.util.List by splitting it into two, like this:
>
>
>         public interface List<T> extends PackagePrivateBaseList<T> {
>
>
>           T remove(int index);
>
>           boolean remove(Object o);
>
>
>         }
>
>
>
>         Then provide another interface for value types:
>
>
>
>
>         interface PackagePrivateAnyList<any T> __aliasOf List<any T>
>         extends PackagePrivateBaseList<any T> {
>
>
>           T removeByIndex(int index);
>
>           boolean removeByValue(T o);
>
>
>         }
>
>
>
>         And finally provide implementations for references and values,
>         respectively:
>
>
>         public class ArrayList<T> implements List<T> { /* … */ }
>
>
>         class PackagePrivateArrayAnyList<any T> __aliasOf
>         ArrayList<any T> implements List<any T> { /* … */ }
>
>
>
>
>         This is probably not binary-compatible as-is, but maybe that
>         could be addressed as well.
>
>
>
>
>         --
>         Have a nice day,
>         Timo.
>
>         Sent from Windows Mail
>
>
>
>
>
>         From: Maurizio Cimadamore
>         Sent: ‎Tuesday‎, ‎January‎ ‎13‎, ‎2015 ‎13‎:‎07
>         To: Ali Ebrahimi, Timo Kinnunen
>         Cc: Brian Goetz, valhalla-dev at openjdk.java.net
>         <mailto:valhalla-dev at openjdk.java.net>
>
>
>
>
>         Timo, Ali,
>         type aliasing won't address all issues associated with
>         layering - i.e. the fact that we'd like, for instance, to be
>         able to say that a method remove(Object) only exists on
>         reference-parameterized collections.
>
>         That said, something like type aliasing might be useful when
>         doing wholesale specialization (i.e. custom specialized
>         implementation for i.e. ArrayList<boolean>).
>
>         Maurizio
>
>
>         On 13/01/15 09:31, Ali Ebrahimi wrote:
>
>
>
>
>         I don't see this how solves the problems layering tries to
>         solve. Just now we can alias IntStream as Stream<int> in User
>         code maybe in import statements.
>
>
>         import j.u.IntStream as Stream<int>;
>
>         Stream<int> intStream; // compiles as IntStream intStream;
>
>
>
>
>         On Tue, Jan 13, 2015 at 10:16 AM, Timo Kinnunen
>         <timo.kinnunen at gmail.com <mailto:timo.kinnunen at gmail.com>> wrote:
>
>
>
>
>         How about a new keyword “__aliasOf”, which would be used in a
>         class declaration like this:
>
>
>
>
>         public class IntArrayList __aliasOf ArrayList<int> implements
>         List<int> {
>
>         // int layer is implemented here
>
>         }
>
>
>
>
>
>
>         The effect of __aliasOf would be that user code could call
>
>
>
>
>         new ArrayList<int>()
>
>
>
>
>         but this would actually execute like a call to
>
>
>
>
>         new IntArrayList()
>
>
>
>
>         and user code would then be compiled against the methods and
>         fields from IntArrayList.
>
>
>
>
>
>
>
>         (And the name of the keyword is subject to change, of course.)
>
>
>
>
>
>         --
>         Have a nice day,
>         Timo.
>
>         Sent from Windows Mail
>
>
>
>
>
>         From: Maurizio Cimadamore
>         Sent: ‎Tuesday‎, ‎January‎ ‎13‎, ‎2015 ‎1‎:‎21
>         To: Ali Ebrahimi, Brian Goetz
>         Cc: valhalla-dev at openjdk.java.net
>         <mailto:valhalla-dev at openjdk.java.net>
>
>
>
>
>
>
>
>
>         On 12/01/15 23:32, Ali Ebrahimi wrote:
>         > Why we can not adapt C++'s #if, #elif, #else, and #endif
>         Directives
>         > for java with java-like syntax. You can see that in hotspot
>         code the
>         > similar problems (OS depends-code) perfectly to be solved by
>         Directives.
>         >
>         > So we can have support for multiple any type vars and nested
>         layers,
>         > and compiler can do flow analysis for nested layers (where
>         clauses or
>         > what ever you want).
>         Hi Ali,
>         I agree that, to some extent, the end goal of layers is to
>         effectively
>         enable some form of 'optional' membership/overriding which
>         could also be
>         thought of in terms of classic C++-style macros around method
>         declarations/blocks etc. In fact, I think that, apart from partial
>         abstractness, what's implemented right now is more or less
>         functionally
>         equivalent to layers (modulo bugs, of course). That said, I
>         think we are
>         in the search of something that would sit better with the Java
>         programming model; granted, #ifdefs and friends will take you
>         there, but
>         I think it will also be overly powerful - and prone to be
>         abused (and
>         perhaps, as some of you have noted in this mailing list,
>         layers has that
>         problem); what if there was a nice little construct that, with
>         minimal
>         footprint could take you all the way there - meaning that you
>         could
>         retrofit the libraries you care about, w/o really adding a new
>         powerful
>         hammer to the language? I think that 'something' is the sort
>         of magic we
>         are after here.
>
>         Maurizio
>
>
>
>
>         --
>
>
>
>
>         Best Regards,
>
>         Ali Ebrahimi
>
>
>
>
>
> -- 
>
> Best Regards,
> Ali Ebrahimi



More information about the valhalla-dev mailing list