

Java finally getting closures, method handles and traits in JDK 8 - spullara
http://www.javarants.com/2011/01/22/using-closures-method-handles-and-extension-methods-in-java-8-jsr-335/

======
fingerprinter
Background: I started programming Java in 1996 or somewhere around there. I
was a huge advocate of Java over things like C/C++ for quite a long time and I
believe in early 2000 it was the best choice. I no longer believe Java is the
best choice for most projects as there are saner alternatives out there
including Scala, Clojure and Jruby (for the JVM) and other languages/VMs
altogether if you want out of the JVM.

Bottom line: Java seems dated.

Now, to my rant.

import java.util.*; interface Sortable<T, U extends Comparable<? super U>>
extends List<T> { void sortBy(Extractor<? super T, ? extends U> e) default
Impl.sortBy; static class Impl { public static<T, U extends Comparable<? super
U>> void sortBy(Sortable<T, U> sortable, final Extractor<? super T, ? extends
U> e) { Collections.sort(sortable, #{T a, T b ->
e.extract(a).compareTo(e.extract(b))}); } } }

I HATE this code. This is an example of when Java went downhill to me and
started to get really, really ugly. I always thought Java was verbose, but
with generics and others things it started to get ugly. That was enough for
me. I knew Python and Ruby and decided to go a different way. Found Erlang and
Clojure started to mature on the JVM. Bye bye Java.

~~~
kaffiene
I've been writing Java for a while now. I've never seen nor written code
anything like that. Heavy use of generics is usually hidden away in APIs and
don't usually occur in non-trivial ways in normal code.

~~~
Jach
It's not that much of a hyperbole...

    
    
        Map<String, Map<String, Map<String, Map<String, String>>> > meta_data = new LinkedHashMap<String, Map<String, Map<String, Map<String, String>>> >();
        ....
        for (Map.Entry<String, Map<String, Map<String, Map<String, String>>> > schema : meta_data.entrySet()) {
    

I really would rather just type:

    
    
        meta_data = {}
        ....
        for schema in meta_data.iteritems():

~~~
nevster
If you've got a structure like that, you've got bigger problems than the
verbosity of the declarations!

~~~
Jach
Oh come on, it's not that ridiculous to have a map only 4 levels deep. (Though
I'll admit the code there is a patch-job over a much worse design that will
all be refactored one day...) It's just ridiculous to express in Java.
JavaScript's pretty much built on the idea of nested objects/maps.

    
    
        new Ext.Panel({
            width: 400,
            height: 400,
            title: 'Pie Chart with Legend - Favorite Season',
            renderTo: 'container',
            items: {
                store: store,
                xtype: 'piechart',
                dataField: 'total',
                categoryField: 'season',
                //extra styles get applied to the chart defaults
                extraStyle:
                {
                    legend:
                    {
                        display: 'bottom',
                        padding: 5,
                        font:
                        {
                            family: 'Tahoma',
                            size: 13
                        }
                    }
                }
            }
        });

~~~
nevster
That's fine. My point is, it's extremely uncommon to come across this kind of
structure in Java-land. Typically, there'd be separate classes for these
objects - so you'd end up with a Panel class with fields width, height, title,
renderTo and items. Items would be another class with it's subsequent fields.
And so on with no maps in sight.

You're example Java declaration doesn't seem to actually capture the
Javascript code you've got there - ie each initial string does _not_ map to
another Map - in some cases it just maps to an integer or string.

By the way - I totally agree that the declarations of stuff in Java with
generics is way too verbose.

------
colanderman
Java has had closures for years. Otherwise how would an anonymous inner class
reference its parent's local variables?

I suspect the author is confusing closures (a language implementation
technique) with anonymous functions (a language feature which can be
implemented using closures).

~~~
dcminter
Do you mean method local variables? Because if so it doesn't - it copies them
and only allows you to reference them if they're declared final (const) for
exactly that reason.

~~~
colanderman
That's exactly what a closure is.

Keep in mind that the concept of a closure has been bred in the functional
programming community, where variables aren't mutable.

If you really need to reference a mutable variable in the enclosing scope, you
can do in Java exactly what you can do in languages like ML/Scheme -- let the
variable reference a mutable box (in Java, an object). The reference to the
box (or object) is copied, not the box itself.

In fact, in Java you can go one step further and just reference the entire
enclosing scope by storing the parent's "this" in a final variable.

~~~
DennisP
Scheme has mutable variables, and introduced lexical closures in the 70's. You
don't need any tricks with mutable boxes, you can just update an integer in
the outer scope and it works fine. Scheme doesn't have an object system built
in, but the closures make it easy to roll your own.

------
jburwell
Yet another half-baked implentation of concept. Why in the world closures are
limited to the SAM use case is beyond me. It's erasure all over again --
building a "general" purpose feature suited to one pratical use. It's no
wonder that Java has lost its position as the platform on which to innovate
and develop new projects. I wish Oracle would be willing to break backwards
compatibility in JDK8, and deliver an truly innovative and exciting product.
Guess I can wish for a visit from the Tooth Fairy too.

* I make my comments as a Java veteran, and fan of the platform.

~~~
Zak
The innovation on the Java platform is no longer in the Java language but in
other languages on the platform. Both JVM-specific languages like Clojure and
Scala as well as JVM implementations of existing languages like JRuby are
where people go for innovation these days.

~~~
spullara
I definitely agree that Clojure, Scala, Groovy, JRuby etc are pushing the
platform itself forward. InvokeDynamic is in JDK7 mostly for the benefit of
dynamic languages on the VM and only in JDK8 will Java language features be
dependent on it.

------
raganwald
My understanding is that the vast majority of Java development is done in
shops where conformance to coding and pattern "standards" is valued as a way
of allegedly making the code base easier to read and understand (I am not
agreeing with this, just stating what I believe they believe).

If my understanding is correct, which shop is going to allow people to start
using these new techniques, when they already have a code base full of
workarounds? Unless someone is going to sit down and refactor their humun-gi-
normous code base, they will in effect be creating a second dialect of Java in
their shop if they start using traits and closures instead of whatever they
were already doing with Java's existing feature set.

I just can't see this having any more than a token impact. Now Java users can
say, "Sure we have closures. We don't use them here, but they exist and if we
wanted to, we could use them. But we don't need them, so it's no big deal."

~~~
Sandman
Why wouldn't they use closures and other new stuff in Java? It's the same like
it was with generics - prior to 1.5 we used raw types with casting, but when
generics were introduced we started using them instead. When you encounter
some older code in your codebase that still uses raw types instead of
generics, you just rewrite that portion of code. No problem with that.

I mean, couldn't your point be made about any language that introduces new
features? When that happens, do developers decide to rewrite the entire
codebase? I don't think so.

~~~
TeHCrAzY
Do you really rewrite working and tested code just to use new or more
convenient features of the language? I don't see that being a good option, nor
one that most developers would take.

~~~
Sandman
If your code is covered with tests, why would you be afraid of rewriting it?

~~~
fizx
Hah!

------
mark_l_watson
Am I the only person who does not care very much about future features until
they are tested and released? Many thanks to the people working on new JSRs
but I'll wait.

