caution: bleeding-edge ahead!

[Ali Ebrahimi]

This works for me with latest code.

On Sun, Jan 18, 2015 at 1:15 PM, Michael Barker <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>
> 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
>>
>
>


-- 

Best Regards,
Ali Ebrahimi