Perhaps you don't see a peep in this channel is because any discussion will instantly devolve into a scala fanboy fest? This post turned into one halfway throughout clay's 1st post!
I'm guessing there's not much happening because: * Testing lambda features is still a ways out, but the IDEs are just now coming online. I believe IntelliJ has beta support. Netbeans definitely does, and you can now chuck a plugin into Eclipse Kepler and have fun with it. Still, it is _very_ early. More to the point, perhaps, those who really want to play around with this stuff have been able to do so for a long time, and for them nothing is changing. * The exciting bits about lambda are split between "What is it? Let's talk about how to bring closures to the java platform!" and "How does it make my day-to-day programming java different / easier?". We're in the limbo in between. We can't use it yet in 'real' code (certainly not until JDK8 is released officially, and then still slowly as libraries need to come online, you first need to convince the dev team, you have to test your stuff on JRE8, yadayada), but the feature-set and design is completely frozen and has been for a long time now. Essentially, there isn't much to talk about. Did you see the insane traffic about it on this mailing list and elsewhere around the time the syntax discussions were going on? The rank-and-file that haven't looked at it yet (A) don't hang out here, and (B) still haven't looked yet. They will in a few more months. But they'll mostly just adopt it, anybody that really was itching to discuss it would have done so a long time ago. * We haven't had a podcast to start the discussion in quite a while. As far as your downsides: * Java's lambda approach is unique. It is more concise than scala's (due to not needing to mention the types of the variables), and the type system does not involve monstrosities such as Function22<A, B, C, ... all the way through W>. As far as I know, no language, certainly no popular/mainstream one, has gone with the novel concept of requiring the closure to have context such that its nominal type can always be strictly determined. All other languages either have functional types and will optionally auto-box into a nominal type if the context dictates that this is necessary (scala), or, don't have any nominal typing in the first place, and treat a function just as 'a function', without caring about types in the first place (javascript, python, ruby, etc). This alone already shows that calling java 'way behind' is misleading. Java is an apple, and scala is a pear. * Scala is not 'basically java 8 + syntax cleanup + pattern matching'. For starters, scala has operator overloading and 'implicit', and more pragmatically speaking, if you look at generic random java code, it looks completely, utterly different from generic random scala code. The communities are totally different. The mindset? Totally different. The preferred models and API approaches? totally different. * If we're going to bash adoption rates, scala still isn't even close to upgrading so that its closures can interop better with java's, mostly because scala doesn't want to end up in a situation where the class files it produces can't run on JRE6, last time I talked with Odersky & team. That's fair, but it goes to show that the compatibility dance is something that takes a while everywhere. * Busying terms like 'philistines' and 'pathetic', while we're probably all guilty of doing that from time to time, mostly just makes you sound like Ranty McRantersons. If the aim is to engender some discussion, I'm guessing that isn't the best of ways to get it going into a fruitful direction. On Thursday, 13 February 2014 21:46:16 UTC+1, clay wrote: > > I'm disappointed there is not a peep about JDK 8 in this forum. > > IMO, the main features are: > > - Cleaner lambda expression syntax than the anonymous inner class route > from Java 1.1 > - Functional collections in the standard JDK as opposed to relying on > somewhat obscure add-on libraries like FunctionalJava or Clojure. > - Standard Optional type which actually includes map and flatMap unlike > the philistines from Guava. OptionalInt doesn't include these for some odd > reason. > - Lots of VM improvements. No permgen! Some of my microbenchmarks saw 10% > speedups on old code, which is completely unexpected. > - New date/time library. Successor to Joda as a standard library. If you > have to deal with calendar date/times and can afford JDK8+ runtime > requirement, this is a super elegant library. > > Downsides: > > - Still way, way behind Scala. Scala is basically Java 8 + a ton of syntax > clean up and fixing legacy problems inherited from its C origins + pattern > matching system + for comprehensions designed for flatMap-able types > (Monads) + better designed library. Typesafe's ecosystem is also really > attractive with SBT,Akka,Slick,Play. Most of those support Java, but Scala > is clearly preferred. > - My employer will likely not approve any JDK 8 work for three years or > so. If there is a shred of a possibility we will have to ship code to > someone who expects JDK7 compatibility, we can't upgrade. > - Major features are mostly catch up with everyone else. There are more > exciting new developments elsewhere. > - Android has pinned much of the Java programming community to legacy JDK > 6. Even new Android 4.4 has this pathetic support for the trivial syntax > additions, but doesn't support the major JDK7 features like InvokeDynamic > byte code and the NIO.2 library. > > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
