Re: caution: bleeding-edge ahead!

Timo Kinnunen timo.kinnunen at
Tue Jan 13 14:38:53 UTC 2015

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,

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

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


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

Sent from Windows Mail

From: Maurizio Cimadamore
Sent: ‎Tuesday‎, ‎January‎ ‎13‎, ‎2015 ‎1‎:‎21
To: Ali Ebrahimi, Brian Goetz
Cc: valhalla-dev at

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.



Best Regards,

Ali Ebrahimi

More information about the valhalla-dev mailing list