A small question

[Reinier Zwitserloot]

So, we avoid an explosion of actual types in jsr166's Ops class by....
writing the same types in an awkward new format based on annotations.

I think your long argument can be boiled down to something much, much
simpler: Is reducing jsr166's Ops class by itself reason enough to add
closures to java?

I'm guessing that Mark Reinhold thinking for years since the closure wars of
'07 about the very topic means this question has been decided already.
Whether jsr166 is the only reason or whether it was merely a catalyst,
closures are going to happen.

I would make a passionate argument in favour of dropping function types
altogether (nicely sidestepping all that pain, such as arrays of closures,
and negative feeling about the .() operation) in favour of a solid inference
algorithm and relying only on SAMs, but it seems that this, too, has already
been decided.

--Reinier Zwitserloot



2010/2/16 Daniel Latrémolière <daniel.latremoliere at gmail.com>

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