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