caution: bleeding-edge ahead!

[Michael Barker]

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> 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
>
>
>
>
> 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>
> 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
>
>
>
>
>
>
>
>
> 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
>