Interesting that anonymous inner classes have not automatically been hoisted up to using this new JVM concept at the same time. Wouldn't that have simplified the programming model further, i.e. get rid of the requirement that arguments to methods be final?
On Tuesday, March 12, 2013 12:25:22 PM UTC+1, Reinier Zwitserloot wrote: > > The things Ricky said: > > * Essentially, the closures are stored in the class file as methods, and > referred to via a new JVM concept, vs. the 'old' way which makes a small > anonymous class, resulting in lots of $1 files in your classpath and issues > with permgen and the like, and slow execution. (The GC can often mostly > eliminate the stray object reference created by any anonymous inner class, > but there's also the need to hit the disk to fetch MyClass$85.class the > first time the closure is actually executed). > > * No semantic baggage of the 'this is an anonymous class' concept, so > 'this' is less weird and the like. > > And: > > * Much nicer syntax, this isn't something to just run right past, it's the > biggest reason (in my opinion) for why closures currently don't see much > use in java. The syntax is TOO unwieldy, meaning API developers try and > avoid as much as possible having to foist it on their users, meaning users > aren't too familiar with it, meaning it remains a 'pro' feature, meaning > even programmers who are well aware of what it does and how it works tend > to avoid it just to fit in. Languages are mostly syntax, really. They're > usually all turing complete. > > * API support. This 'let's not use that; it's too unwieldy' aspect is > prevalent in the JDK libraries themselves too. JDK8 also comes with many > API updates which go all in on closures. Basic things like map operations > on collections: Collection<Integer> parsed = someListOfStrings.map(x => > Integer.parseInt(x)); > > > > On Tuesday, March 12, 2013 12:37:47 AM UTC+1, clay wrote: >> >> Is there any substantial difference beyond the less bulky syntax? >> >> I purchased and skimmed Venkat's draft e-book on functional programming >> in Java 8: >> http://pragprog.com/book/vsjava8/functional-programming-in-java >> >> My first disappointment is that if you've seen his live presentations on >> functional programming -- which are extremely entertaining btw -- the book >> doesn't have newer or more in depth content. >> >> But the larger disappointment is that all of these functional practices >> are things I'm already used to in older versions of Java as long as you can >> use the bulkier anonymous inner class syntax and a third party functional >> collections library. >> >> For example, the book shows you how to do standard stuff like: >> >> public static void runLocked(Lock lock, Runnable block); >> >> runLocked(lock, () -> {/*...critical code ... */}); >> >> Java 5/6/7 code does this all the time like with the older bulkier syntax: >> >> runLocked(lock, new Runnable() { >> @Override public void run() { >> /* Critical code */ >> } >> }); >> >> -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/javaposse?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
