Some time ago, I got an invitation from Heinz Kabutz (the man behind the Java Specialists newsletter, to which you should subscribe right away if you haven't already), to join the JCrete conference.
My wife took a dim view of this. “You mean, there is no program? You'll just stand around and drink beer and chat?” I tried to explain to her that it's no different for me when I go to Java One, where I learn more from the hallway conversations than from the sessions. The solution was to take the entire family along.
It turned out to be great. To see what JCrete is all about, read the blogs by Geertjan Wielenga and Fabian Lange who explain the “unconference” approach very nicely. Here you can see it in action. The clusters of folks in the water at the beach of Falarnassa are conference attendees, who, being geeks, mostly talk tech. I learned a bunch about sun.misc.Unsafe while swimming.
I co-lead a discussion on what one would like to see in java.util.stream in the future. Compared for example with the Scala API, streams are missing quite a few useful operations. For example, there is no zip (it was removed). There is no convenient way of turning iterators or iterables into streams (also removed).
There are good reasons for these omissions. Zipping is best done with pairs, and pairs are best done with value types. A stream method on iterables might work better when we have specialization of generics. It makes sense to wait until these features are ready, perhaps in Java 10. (Nothing much is going to happen with streams in JDK 9. I only found one new stream-related method: Optional.stream turns an Optional into a stream of length 0 or 1.)
What can you do in the meantime? We found a number of libraries that provide stream-like abstractions with richer APIs: LazySeq, ProtonPack, jOOλ, JavaSlang.
Personally, I like to use streams for the “what, not how” API, not so much for parallel streams. Sure, parallel streams are impressive, but they are also quite specialized. They work well when you want to keep all cores busy, with data from an in-memory data structure that is efficiently splittable, and stream operations that are computationally intensive. I don't have many situations like that in practice, which explains why my teaching examples always seem to involve factoring BigInt.
Some of the attendees reported from their consulting jobs where they saw eager stream users add .parallel() everywhere. Clearly, that's a terrible idea. If the data come from a file or database, it won't be split efficiently with the fork-join framework. If the stream operations block, the fork-join pool can starve. And in an app server, does one really want to go full bore on all cores? (It is possible to constrain the pool, but not obvious.)
Other than telling people to be careful about parallel streams, what did I learn? I'll have to figure out how to build Project Valhalla so that I can learn all about value types and generic specialization. I won't have to learn about sun.misc.Unsafe. DukeScript looks cool, and I'll have to check it out.
Most importantly, I learned about JCrete. The unconference format is great, the location is unbeatable, and the attendees have been amazing. Check out some videos from Steven Chin's blog here.