A small question

[Daniel Latrémolière]

When reading these threads, I have a small question.

It seems the key driver for lambda is parallelism (which is a very small 
part of their code for many programmers, hopefully for avoiding brain 
damaging) and avoiding explosion of number of interfaces (probably the 
interfaces of extra166y.Ops.*).

Given I see a probable consensus in mailing list for implementing lambda 
as java.dyn.MethodHandle, I would like to know how not replacing all 
these interfaces of extra166y.Ops.* by a MethodHandle in code using 
these interfaces? (and not defining any lambda in Java language).


--- Some motivations/explanations of my question:

With this replacement type of lambda will be clearly erased, but you can 
introduce some annotations for helping error detection (like JSR 305): 
@Signature(returnType=@Type($ReturnType.class), 
arguments={@Type(ArgType1.class), ...}) [1]. When, and only when, 
experience will be here and usage of lambda sufficiently frequent, it 
will be time for changing Java language.

Currently Java has many other typing features, more frequently used, not 
supported by VM, javac and language, like @NotNull (JSR 303) / @Nonnull 
(JSR 305).

I don't think the shortening of source code is a good reason, given it 
will be much more generic and useful for all programmers to have 
something like type aliasing, which will save much more characters in 
all source code (particularly in code using generics, even if diamond 
operator has already given some improvements).

If selection of MethodHandle by name, is really a problem, this will 
need method/field literals (currently without many talks on this list). 
Adding of method/field literals can be useful, even if I think more 
large input would be useful (possibly useful in some validation 
annotations, JPQL made by annotations, etc.). This feature seems to have 
been rejected for Project Coin.

Not allowing lambda will reduce tendency to have many nested levels of 
context (class -> method -> lambda) with loops (for, while) or 
conditional paths (if-then-else) adding their own changing contexts. 
Simplicity is always needed for avoiding bugs (programmer need to 
understand code, immediately and perfectly!).

I prefer having a slightly more verbose solution in current Java and 
adding some partial but really generic solutions to having a half-baked 
solution made only for a specific library hampering all Java 
programmers. I prefer some form of progressive enhancements to big 
breaking changes.

We don't know lifetime of this library in Java platform. Personally, I'm 
not really considering possible uses of this library: if I need highly 
parallel computing framework, I would probably use Java to dynamically 
generate optimized OpenCL code. For me, Java is a language for complex 
logic programming (CPU) with random-access memory and big caches, not 
for small-tasks parallel programming (DSP/GPU) with streaming-access 
memory. These use-models of memory are intrinsics of the performances of 
these two silicon chips and I don't think personally they will 
disappear/merge, even by migrating on the same SoC (cf. embedded). When 
you manipulate methods for generating OpenCL code, having names 
(identifiers) and signature is very useful, then the java.lang.reflect 
model is probably correct; performance is not really needed, because you 
don't execute these methods: you create OpenCL code and send it to DSP 
for parallel execution.


My two cents,
Daniel Latrémolière.


[1]: Strictly speaking, this solution need some convolutions to allow 
native types, given annotations does not support Integer.TYPE as valid 
class literal.

public @interface Signature {
     Type returnType() default @Type; // void by default
     Type[] argumentTypes()  default {};
}

public @interface Type {
     Class<?> value() default Void.class;
     Native nativeType() default Native.CLASS;
}

public enum Native {
     BYTE, SHORT, INT, LONG, FLOAT, DOUBLE, CHAR, CLASS;
}

Example with "Integer Integer.valueOf(int)":
@Signature(returnType=@Type(Integer.class), 
argumentTypes={@Type(nativeType=Native.INT)}) MethodHandle valueOf;