Well grounded Java developer (WGJD)

The first three hour session I attended on day two of Devoxx was called Well Grounded Java Developer. The decision to go there was based on some stuff which I read about one of the speakers – Martijn Werburg. Both with the other guy – Ben Evans, they are mostly known as active JUG leaders from London. BTW they are going to publish soon a book with the same name. So I expected something really interesting and fairly unconventional.

What makes a Java developers well grounded? First of all they have to understand some eternal things: the basics of the JVM, think of development as social activities (forget about the Hollywood model of successful guys, who code in their bedroom), spend significant amount of time and energy on software craftsmanship and architecture. Then – the three moving aspects, which are true now, but may change in future: WGJD should know Java 7, polyglot and functional programming as well as good concurrency practices. For the remainder of the talk the speakers turned our attentions exactly on these three moving aspects.

The goal of Java 7 after Plan B was to introduce much more concise and readable code. An example of that is the small language changes implemented as part of project Coin: diamond operator, strings in switch to name a few. The speakers went quickly through the various new platform enhancements. They also emphasized on the new APIs. They advised us to go and look at the all new ‘plural’ classes like Objects and Files. These provide plenty of helpful static methods that ease lots of the things that we usually do. Something like good old Collections class that gives us factory methods as well as basic functionality for searching and sorting. The speakers also pointed that the method handles introduced for implementing the invokedynamic byte code can be used for a lot more things (for example Oracle will maybe use it for realizing the default implementation of interface methods in Java 8).

Another now popular “feature” of the well grounded Java developer is that they should be polyglot programmers. Right now Java the language is not a natural fit for defining DSLs (domain specific languages). That’s why we all should learn a language that is better for that (like Groovy or Scala for example). Good remark was that Java is a more conservative language as opposed to the newly created ones. To introduce a change in it takes much more effort in terms of evaluating its impact on the currently existing features – Java has to stay compatible. I read a very good article on this topic by Brian Goetz.

The biggest difference between [partly] functional languages and Java is the ability to pass code as arguments. The speakers warned the audience to think twice before calling this feature a closure in front of functional programmers. What we are going to have in Java 8 is actually lambda functions, which among the rest cannot modify the state of the enclosing variables, while closures can. Finally Ben and Martijn urged everyone to go on and test the preliminary Java 8 versions, because a product is as good as the number of people using its beta.

The third important ability possessed by a WGJD is utilization of the hardware by avoiding the old synchronized keyword style. The speakers, as well as everyone with more experience, tend to dislike the old fashioned way to do multi-threaded code – using the synchronized keyword and calling wait() and notify() on a monitor object. Yes, you can do concurrency this way, but you have to be very, very careful and pay attention to the smallest detail. As of Java 5 we have the java.util.concurrent classes, which do a lot of tedious things for us: reentrant locks replace synchronized blocks, conditions replace wait and notify and countdown latch is great for testing multi-threaded code (I didn’t get how). You can use also HandoffQueue to hand off work between two threads, which is much better than the old approach with JMS. The fork/join framework introduced in Java 7 raises the abstraction a couple of steps further when talking about concurrency – it takes care of all the locking and other java.util.concurrent stuff, letting developers concentrate even further in the business logic.

This was quite an inspiring talk. Even though Ben and Martijn talked whole three hours, I didn’t feel weary even for a moment. Another thing that I noticed is that these guys had profound knowledge on a lot of aspects on the Java language and platform, languages running on the JVM and frameworks in the ecosystem. I’m not sure how they achieved this, but it’s awesome. With these two, together with other two guys, whose work I closely follow (Stephen Colebourne and Sandro Mancuso) the London Java community seems to have great potential and should be an example for the rest of the world JUGs (yes, sure, don’t forget Paris JUG either).

Java FX

I went to this talk, because I was afraid that the Groovy ecosystem session would be quite advanced for me. Well, I made a mistake. Neither the Groovy talk was too advanced nor was this one quite as interesting as I expected. I already saw a presentation by Michael Heinrich on Java FX 2 at the last Java2Days conference in Sofia and this three-hour talk showed the same things in a little bit more details.

So, what is JavaFX 2? It has 100% Java API as opposed to the previous releases where you coded in JavaFX Script. The main reason for this change – a Java developer is reluctant to learn a completely new language. Besides that, integration of a JVM based language (as JavaFX script is) with another one (like Groovy and Scala) is not as smooth as one would expect – Java integrates better. Of course the UI markup can be specified in FXML – you can get from its name that it is XML based. It follows the Java API in terms of elements and attributes, so knowing the former is good enough when you are reading the latter.

In the middle of the talk the speakers cheered up (and awoke ) the audience by playing the Java life video inside the JavaFX media player. You can have also web content inside JavaFX [desktop] application. A usecase for that feature is if you want to reuse existing OAuth login page, web forms or if you want to embed a map from Google’s site.

In the area of UI controls (this is the first thing to be open sourced) we can finally report the existence of Table component! The checkbox has three states (the GUI that my colleagues in my department develop is not alone in supporting this great feature ). We don’t have to go to JFreeChart for various charts any more – JavaFX has them, even with animation on top.

Last but not least, Java FX scenes should be embeddable inside Swing and even SWT. I don’t know, maybe I will learn HTML 5 first and only then will try JavaFX. But for sure you need either to experiment a lot or to be a GUI magician in order to get right all the gradients and other 2D graphics goodies that JavaFX provides.

Type safe Hibernate and JPA with Scala

This was the most intriguing talk of the day, at least for me. I am not a Scala developer, but I know some of its advantages for defining DSLs. I didn’t know about its implicits, which help you extending existing APIs without being “intrusive” as the speaker stated it. The implementation of the library presented during the talk was inspired by Martin Odersky’s post Pimp my Library.

I don’t remember many details, but the open source library created by the Caelum team “extends” the existing Hibernate and JPA APIs via implicit conversion to enable type safe building of queries. Right now the option is either to use HQL or JPQL strings, which are not checked at compile time for correctness. The other way is to use the tedious Criteria API. The pimped query API introduces Scala language features like named parameters, type reification, operator overloading to build and execute queries. The only decent documentation which I found about the library was its github home page. You may check it to translate the above theory in more practical concepts.

The reaction to the talk was quite controversial. Most of the twitter comments concentrated more on the content: they praised the idea to apply the Scala language features to achieve such a common task as building and executing ORM framework queries. However, there were quite a few foolish comments about speaker’s performance. Yes, he was very uneasy on the Devoxx stage. And yes, the presentation did not go as smoothly as it would go if it was presented by an experienced conference speaker. But yes, I still do support Lucas (this is speaker’s name). Devoxx is a conference for developers by developers. So for me the content is much more important than the way it is presented! And I learned much more from this talk than I lost from the uneasy behavior of the presenter.

Groovy actors

I will not surprise anyone if I state that concurrent programming is one of the prevailing new things these days (check what the Well Grounded Java Developers say). So it is +1 for every [JVM] language if besides web framework, build tool and test library it has an actor proposal.

According to Vaclav Pech, actors are asynchronous guys with a mailbox. The mailbox is read in their onMessage method. They have a reply method if they want to return something to their senders. In order to send an actor something, you use a send method for asynchronous approach or sendAndWait for a synchronous one. Everything is bootstrapped by a start method. You should take care only about these aspects. All the heavy lifting and low level synchronization and messaging is done for you by the library. Basically this is how Groovy’s GPAR (and also Scala’s AKKA) framework is working.

Besides all the Groovy’s parallel machinery, GPARs can utilize other JVM languages constructs. You can transform existing POJOs (or POGOs) to Groovy actors by just annotating them as @ActiveObject and their potential actor methods as @ActiveMethod (with the option to declare them as synchronous or non-blocking).

The library is not as mature as AKKA, though. For example it doesn’t support distributed actors (across several machines). I didn’t take too much notes about that as well, but you can still check the official site.

The fireside chat

Day two of Devoxx finished with the fireside chat. This is not a standard session. It actually features several very smart guys sitting around a table (like in a bar), drinking wine and discussing themes that they decide on the fly. No prepared questions by the moderator (well, at least), no scenario, no presentations. The initial idea was to have a more distributed lineup of participants with James Gosling and an Adobe representative in the list. For one reason or other James didn’t show up for second consecutive Devoxx and Adobe rejected as well. So we had one Googler (Tim Bray) and three Oracles (Henrik Stahl, Mark Reinhold and Cameron Purdy). So it was not the liveliest talk, but anyway, we got some “interesting insights”:

• XML is awful for describing non-documents – JSON like formats are much better for defining configuration
• We heard one of Devoxx 2011 jokes: “The difference between Ant and Maven is that Ant’s creator apologized”
• People like to predict the future but are rarely successful in it
• Big success stories happen not because, but in spite of the push from company’s CEO
• HTML5 is just an envelope for standard JavaScript
• Generics could have been done better

You can see that the discussed topics were diverse enough. The good thing was that already in the beginning Tim avoided the flame coming from the Oracle guys about the ‘Linux based platform that claims to use Java’, so the talk did not turn into a corporative dispute. Hopefully next time we’ll have participation dispersed among the leading companies better than Oracle:Google 3:1.

Your nosoftskills bloggers spent great times at the last Devoxx edition. And they decided to share some of the experience with you (for the rest – you’ve got to feel it!). Most of you may have already started reading, but we decided to put up this page for those who want to have the complete picture at a glance.

Here are the reports from the different days:

University Day 1
University Day 2
Conference Day 1
Conference Day 2
Conference Day 3

And here are the more in-depth reports from our latest nosoftskills author Stoyan:

Crash Course into Scala
The Groovy Ecosystem
What’s in store for Scala
Java Past, Present and Future

Good luck, cheers and thanks!

Discussion panel

Each Java conference starts with keynote and most of them end with a discussion panel. There some of the most respectful people of the industry come on stage and answer the questions from the community. Devoxx is not an exception – on Friday morning we had Oracle’s Brian Goetz and Mark Reinhold, Google’s Josh Bloch, JBoss’s Emmanuel Bernard (actually he was representing the open source movement), JUGs’ representative Ben Evans and Brian Prince from Microsoft (:-)). The talk was moderated by JavaPosse’s Joe Nuxxol and Carl Quinn. Joe was posing the questions that everybody had the opportunity to ask in a Google Moderator group. All the speakers had foil hats, which they put in case when they could not answer certain questions for “political” reasons. Fortunately the hats were used just a few times.

I again will try not to paraphrase each question and the answers. I will give just some statements that were interesting to me:

• The definite winners of the Oracle – Google lawsuit (and all the other lawsuits on patents) will be the lawyers. The losers will be the developers
• If Java and its successors want to be successful, then they should avoid creating incompatible dialects like there are in C++
• Oracle’s corporate culture is better for Java than Sun’s. According to Ben, Oracle did not place any barriers in front of the community
• Open sourcing doesn’t mean just dumping code on the internet. A lot of big companies that have done it that way, have miserably failed
• The Java language did not become much more complex than it was in 1.02. Just the level of abstraction rose. It was the same in the very beginning: the first versions hid memory management from the developers

Of course there were some flames on the scene as well. Josh Bloch: “What is JavaFX?” Mark Reinhold: “What does Android have to do with Java?”  We heard also Joe ask Emmanuel a question in English, but with French accent. Which reminds me that the French people were target of a lot of jokes during this conference, most of which friendly. They will surely strike back on DevoxxFrance next April.

Evolution of Java

This was the second talk by Josh Bloch on Devoxx and it was a sequel to his first one about the first version of Java. I will not go into too many details here as my nosoftskills co-blogger already did it (thanks, Stoyan ).

So Josh evaluated all the 17 language changes made after the inception of Java in 1995. The criterion for that was whether they kept the feel of Java, defined by James Gosling: Java should be a blue collar language. One that takes all the good stuff from the existing languages and in the same time stays simple enough to be understood by the average programmer.

The most bashed features were serialization and generics. The first one was criticized because it does a lot of things behind the scenes: introduces hidden constructor, by default leeks private fields (unless not explicitly declared transient), it breaks the hashes of the serialized objects, so structures like hash tables, where these objects reside, are also broken, etc. Generics were basically fine before wildcards were added in the last moment. With this last minute act they introduced big complexity (the FAQs are 297 pages long) and harmed the feel of Java. The erasure of the generic type during compilation (done for backward compatibility with raw types) is just the opposite to what is done with arrays – they pertain their type in runtime. This impedance mismatch hides a lot of puzzlers inside and Josh has some of them in his book.

On the other side we have features like enums, foreach and annotations, which help a lot in simplifying the language, the runtime and in bringing type safety. Josh confessed that he has not tried intensively the new stuff in Java 7. However he said that Joe Darcy and his team have done a great job in their definition and implementation. And all the new features in the latest release got good ratings. Let’s hope that next year we’ll not have to watch yet another Java 7 puzzlers talk on Devoxx.

The Ceylon programming language

The last talk that I attended on this year’s Devoxx was about the Ceylon (pronounced Se-lon) programming language. Like Kotlin it was one of the JVM languages that emerged this year. Unlike Kotlin it did not have a compiler and IDE support. Well, not any more. Emmanuel and Stephane announce the brand new project site, where you can download the Eclipse plugin and find out how you can get the compiler.

The goals of the language are: easy to learn, less verbose than Java, very type safe (i.e. statically typed), hierarchical structures (like XML, UI, etc.) should be better expressed, etc. I have also heard that its target would be people writing business application. As the language author is Gavin King (the creator of WebBeans, a.k.a. Seam), I would not be surprised if we see contexts and dependency injection (CDI) as part of the language. Some of the most prominent features of Ceylon are:

• Everything is by default final. If you need to mutate your variables, you have to express that explicitly. If you need to override a method you have to declare that explicitly both in the parent as well as in the child class
• Method overloading is not possible. However, methods can have default values for their parameters, so you can omit them when calling the method. This looks like currying
• Interfaces can define default implementations for their methods, just what we expect in Java 8
• There are no primitive types
• There are optional types (String? s). When you have such a type, the compiler explicitly checks whether you have a check for null before invoking a method
• There is operator overloading for a limited set of operators. You cannot redefine new operators as it is in other languages. The way to overload (or override actually) an operator is by overriding the respective method. For example for == and != you need to override equals

There are a lot of cool features that can be looked up in the documentation. What I didn’t get is whether it supports Java in the way that Groovy or Scala does – can you write Java code inside Ceylon classes. I didn’t get also how you define the main method of a module. But anyway, this is not so important. More important is the following observation: we have several new languages (I mean serious ones) coming out each year. Every one of them claims that it solves most of the problems of Java and that it does it in a better way than the other ones on the JVM. Every new language usually also adds something unique (e.g. Ceylon has a different type system). OK, that’s fine, it’s great that lots of people in the community are creative and I do believe in Gavin King’s creativity. However, I still cannot find what’s in for me in most of the emerging JVM languages. And the Ceylon guys have still much work to do (which they realize even better) to bring me on their side (not that I am particularly important to them ).

The good part is that they are doing the things in the right way. Just to mention some other observations:

• It’s not necessary that the language is backward compatible (it’s not decided yet though)
• The Ceylon team values the community (which I guess is the JBoss culture) – everything is on Github, there are mailing lists, even the project page can be edited by people from outside
• They tend to avoid lots of Java fallacies (e.g. threads and parallelization are part of the libraries not of the language)

Good luck guys, I’ll be watching your progress!

In the last day of Devoxx, one of the most anticipated sessions was Joshua Bloch‘s The Evolution of Java: Past, Present, and Future. As Joshua put it, the intention of his talk was to critique every single language feature which appeared in the language since its first version. In many ways, this talk was a continuation of Joshua’s talk Java: The Good, the Bad, and the Ugly Parts from the first conference day, already covered in one of Ivan’s previous posts. The session went through all features introduced in Java from 1.1 to 7, explained their intention, showed their “good, bad, and ugly” parts, and finally presented a rating on a scale between “Success” (happy Duke) and “Failure” (Duke shooting himself in the leg).

In the beginning of the talk, the speaker revisited one James Gosling talk from 1996 and a subsequent article The Feel of Java which was published few months later. According to Gosling, Java is practical, not theoretical; it does not introduce new ideas but prefers tried-and-tested things; it feels hyped, playful, flexible, deterministic, and non-threatening. All these characteristics were the main reasons for Java’s worldwide success. There were also naysayers – for example, Bjarne Stroustroup predicted back then that Java will inevitably become more complex and develop implementation specifics. So the ratings of the language features were based on Joshua’s judgment of the extent to which each of them managed to preserve the original “feel of Java”. Features rated as success are simple, useful, and widely adopted, while those rated as failure are either too complex, obscure, or have serious design flaws which lead to “puzzlers”.

Java 1.1

• Nested Classes. Provide better encapsulation and rudimentary closures. The fact that they are non-static by default is often wasteful and can be deadly; mixing inheritance and non-static nesting is evil. So they are not good enough for closures, should have been static by default, and are still not supported by the VM. Conclusion: not a bad feature, but could have been really good. Neutral
• Serialization. Besides library, this is also a language feature, since it impacts the design of arrays. One major weakness is that it doesn’t get along with instance control, e.g. singletons. It sort of works, but has a lot of flaws: introduces a hidden constructor; has security holes; leaks private fields; performs abysmally; introduced bugs (Hashtable); designing readObject methods is really hard; final fields don’t mix; requires casting; the serialVersionUID is needless clutter. Conclusion: arguably the worst feature ever added. Failure

Java 1.2

• strictfp modifier. Addresses an idiosyncrasy in Intel’s x87 math coprocessor. Conclusion: minor wart that could have been avoided. Failure

Java 1.4

• Assertions. Back in 2001, Joshua encouraged developers to “accept assertions into their lives”. There were and still are good reasons for this, but sadly his advice was mostly ignored – maybe he didn’t preach enough, or maybe developers felt uncomfortable with the uncertainty whether assertions should be switched on or off in production. As a result, most programmers get little benefit from this feature. Conclusion: a net win, but barely. Neutral

Java 5

• Generics. Enforces specification at runtime, achieving “stronger typing with less typing” as Joshua put it back then. However, adding wildcards at the last minute was a disaster, and generics finally turned out so complex that even the best programmers don’t understand the intricacies. Conclusion: generics are essential, but the design was wrong, “we blew our complexity budget with this feature”. Failure
• Annotations. General purpose metadata facility. Although it wasn’t perfect, it was well integrated and enabled many successful projects. Conclusion: success – modestly useful for many, critical for some. Success
• Enums. Combines the power of the typesafe enum pattern with the ease of use of regular enums. Conclusion: rip roaring success. Success
• Enhanced for loop (for-each). Lets you iterate over collections. Conclusion: most successful language change to date. Success
• Autoboxing / Unboxing. As Joshua put it, “dragons lurk in these waters” due to many design flaws. This feature achieved reduced verbosity, but the distinction between primitives and objects still exists, and more puzzlers were introduced. Conclusion: instead, generics should have been made to work for primitives. Failure
• Varargs. Variable number of parameters in method declarations, mainly for printf and reflection. It turned out to be very useful, but not very often. Conclusion: a flawed success, made worse by generic shortcomings. Neutral
• Static Import. Conclusion: very modest success. Neutral

Java 7

• Strings in Switch. Useful, but may encourage overuse of String. Conclusion: modest success. Success
• Binary Literals, Underscores in Numeric Literals. You can express the US national debt as “14_516_500_000_000L”. Conclusion: modest success. Success
• Multi-catch. Conclusion: no known downside, moderately big win. Success
• More Precise Rethrow. Conclusion: modest win. Success
• Type Inference for Generic Instance Creation ( operator). Reduces the verbosity of generics. It is complex under the surface, but this complexity is not exposed to developers. Conclusion: big win. Success
• Try-with-resources. Introduces linguistic support for the “dispose” pattern. Eliminates lots of verbiage, without significantly complicating the language. Conclusion: big win. Success
• Safe Varargs. Conclusion: modest success. Success

Where are the puzzlers in Java 7? Maybe there aren’t going to be puzzlers – but don’t bet on it.

Future

Regarding Java 8 and beyond, Joshua advised the language designers “not to give Stroustroup the last laugh”. More is not always better, so before adding a feature a genuine need should be demonstrated.

Conclusion

This talk was informative and entertaining, and offered a very interesting perspective to the history of Java. I liked the speaker’s attitude, really objective and honest even when evaluating features for the design of which he has responsible himself. In Java and other JVM-based languages, are today’s hypes tomorrow’s puzzlers? Or have the language designers really learned from their past mistakes?

I believe Bjarne Stroustroup’s prediction has largely already become true. “The feel of Java” was attractive and compelling, so Java became a great success. However, during its further evolution the language designers had to add many additional features to maintain its viability. For some developers even this was not enough, so they switched to new JVM languages such as Groovy and Scala which favor conciseness, consistency, and expressive power over simplicity. “Polyglot programming” instead of “The feel of Java” is today’s norm – let’s see for how long.

The second conference day started with a great keynote by Google’s Tim Bray. As he is an Android advocate, you can imagine that most of the talk was about mobile. Not strictly about Google’s effort in the area, but more about trends and concepts from all the key players.

The amount of Android devices activated each day is overwhelming and growing. The same applies for the number of applications uploaded on the Android market. So if you want to be discovered in that forest, it’s not enough your application to be good, it ought to be great. In order to reach that, you have to pay special attention to the quality of design. Developers tend to be not so good in this area, so you should have professional designer in your team. Or become such.

Next, Tim went on to give a quick overview of what is there in the forth version of the Android operating system (Ice-cream sandwich – ICS). There is a new face detection API with numerous possible use cases (unlocking your phone is the first which I heard about). The calendar API is now defined and is a little bit different than the non-official interfaces that developers used to call so far. You can now also send NDEF messages between devices that support Near Field Communication (NFC) – you can send over the wire links to music, web pages and all of that sort.

The speaker maybe disappointed some of the attendees as he stated that he has fallen out of love with Java and likes much more JRuby. However, when you develop mobile apps, it’s quite hard to do it in test-driven style because of the zillions of mocks that you need to create. And with dynamically typed language if you are not writing tests, then you are lost. So, Tim’s advice was to write statically typed code.

There were some ideas that were brought in during the talk:

• There are not enough women in IT. But I wonder is it because they are not given chance? Isn’t it more because most of them are not particularly interested in IT?
• You don’t have to pay for getting small chunks of information. Rather you have to pay for getting services around the information
• The target market for mobile devices is the third world. There you will not get lots of money from individual sales of high end devices, but the amount of people who may buy your stuff is great

I would cite a tweet that I saw in the break after the session: Tim had a very humble talk. Non-offensive and pragmatic, not flaming and blaming at all.

UI Design

So, I followed Tim’s advice and went to Hall number 3 to see Joe Nuxoll’s talk on UI design. Well, another reason is that he is from the JavaPosse and I’m an old fan of their podcast. It tended to be the start of a JavaPosse@Devoxx day, so keep reading.

Actually Joe didn’t just talk about user interfaces. Fonts, colors and component layout are really important, but not as important as the user experience (UX). To achieve appealing UX, engineers and designers should co-operate and train each other.

My opinion on one of the problems when creating software products is nearly the same as what Joe said. The communication between the various parties involved in the process is not good.  Some people don’t listen to feedback, either because they are not able to listen or because they are too proud to do it. On the other side other people don’t provide feedback, either because they simply don’t say anything, or because the only things they say is “This sucks!”. We (and this includes me!) should learn to be much more open when it comes to considering other people’s opinion.

For the rest of the talk (before the Q&A session) Joe gave valuable advices to the attendees:

• Data structure should not define UI design. It is not necessary for the user to see what the DB tables or your entities are
• The opposite is also valid: UI should not define data structure
• First identify the requirements for your application and only then choose the technology for implementing it
• Before prototyping anything, start with the use cases that need to be covered
• Identify the different categories of users of your application. Think about the various paths in your application based on those and tailor them accordingly
• Think in flows, not in features. You don’t need Login screen, but rather Login process with all the different paths and screens, which are part of it
• Prototype often and abandon prototypes often. Build prototypes quickly and toss them with no regrets
• Make the next step in the flow obvious and at the same time reduce the amount of things that the user should perceive when looking at your screens
• Be consistent when designing your screens: next button should always be at one and the same place
• Don’t load/reload whole pages. In the Web 2.0 era updating just part of them is possible and looks great

The final golden egg from Joe was: don’t hurry up to ship your product. Before that make sure you provide your customers great user experience.

World wide wait

The next talk reminded us of last year’s Devoxx. Back then Matt Raible had a comparison of web frameworks, where he showed a big matrix of various criteria and finally a ranking, where Grails won. The guys from the Belgian Java user group (Stein, Guy and Ward), whose last names I most probably can’t pronounce correctly, gave a talk on comparing five of those (GWT, Spring MVC, JSF, Wicket and Vaadin), but this time based on scalability and performance.

I will start backwards and announce that GWT was the big winner with JSF at the back. The results seem to be heavily dependent on the type of the framework. In the client side web frameworks the server is pushing up just data and the client (i.e. the browser) decides how to build the DOM tree. This is done basically by JavaScript code sending AJAX requests to the server. A clear representative of this type of frameworks is GWT. The server side frameworks are just the opposite – the server has component representations and knows exactly how to build the DOM tree, while the client just visualized HTML. Here we have Wicket, JSF and Vaadin (the server side GWT). SpringMVC is somewhere in the middle. The approach which the presenters chose was to have JSP views that use jQuery to communicate with the server.

These guys have done impressive work. This was a true benchmark taking into account all the little details that you might think of. They reserved three EC2 images (or maybe it was four at the end) – one for the data store, one for the app server and third for the load balancer. Then they measured the time from sending the request up to receiving the response.  The rendering time in the browser is completely different story, but it seems that the overall time follows the same pattern as the request-response delay.

There is also another aspect of the measuring. GWT might be the fastest, but in terms of ease of development it doesn’t seem to be the best. Its lines of code were the most of all solutions. Another aspect – if the database doesn’t scale, then it becomes the bottleneck and all the web frameworks perform equally well (or bad?). So the final question that the presenters asked was: is it really the presentation layer that is usually the bottleneck?

Scala, Play!, Scalate, Jade, HTML5 and many others in action

This was one of the best sessions that I attended so far. It was by the same Matt Raible that I already mentioned and who caused some havoc in the java community with his last year’s talk. What he particularly liked about coming to Devoxx was the Belgian beer. That is why he wanted to come this year again. In the summer he decided that he wants to learn Scala and there’s no better way for a web developer to learn a new language than by using a web framework. That is why Matt downloaded Play! It targets not only Java developers, but web developers as a whole. And it is not exactly Scala as I initially thought, but Scala can be added to it. The other good thing about Play! was that with it you can test your application in the browser – you can save it even in your favorite text editor, then it just takes one refresh and you’ll see even things like compiler errors.

What he initially tried to do was a stopwatch web application. Besides Scala and Play! he used CoffeeScript, which helps you to write Java-like code that compiles to JavaScript. Web developers tend to like it more than GWT, as they don’t like too much the Java language. Then for HTML generation he used a template language called jade in conjunction with the Scalate template engine. The latter nicely integrates into Play – just sync the dependencies, create Scalate template engine class and integrate it inside your application controller. In the meantime Matt had some problems, which were solved in no time after his post in the Play! Google groups. Finally he uploaded his application to the cloud at Heroku,

Matt then decided to try some other frameworks and libraries like HTML5 Boilerplate, HTML 5 Geolocation API (to present a map that shows the starting and ending point of a route), Google Maps JavaScript API, JS2Coffee, LESS, twitter’s Bootstrap, Anorm ORM solution. The ultimate problem was that the application could not work on the phone while sent to background (when the phone is locked for example). He needed something native for his iPhone that can run his application, that’s why he turned to PhoneGap – a framework where you can write native iOS applications in HTML, CSS and JavaScript. And he finally made it! Everything was working. You can watch the whole process in Matt’s making short movie.

Pretty impressive talk and playing the video at end on the big screen was perfect conclusion of it. You see, these days there are open source libraries and frameworks that can help you be more productive. They can also make learning a new language great fun. There is also vibrant community in the JVM world. Matt, who used the products of this community, is in one way or another part of it, as he wrote a long series of blog posts after each of the important steps in his quest. He also showed an incremental way of learning a technology – first create something small, then add new features to the already existing application and with each new step learn new things.

Don’t get me wrong, I’m not saying here that we should always use maximum number of frameworks and libraries, especially in corporate environment. Using many technologies often leads to hard to understand and maintain code. However, I agree with Matt that there’s no better way for learning something new than by writing a project. And we all want to learn more, don’t we?

It’s JavaPosse time!

The last two sessions that I attended in the second conference day were by JavaPosse members (I skipped the last but one slot – I needed to catch up with my blog).

First it was the JavaPosse live. I’m a regular listener to the podcast since maybe its hundredth episode and I was on their live during last year’s conference. Before this session I had the feeling that they have started to repeat themselves. On their last JavaZone and JavaOne shows they did one and the same thing: count how many people from the audience are from the different parts of the world, what kinds of JVM languages are they using, which is their preferable IDE, etc. So I was afraid that we are going to see yet another remake of this story.

Luckily I was not right. This was by far the most interesting JavaPosse live that I have ever seen (or heard)! They made up a story: suppose that one of them for some reason is not able anymore to talk on the podcast. So they needed to pick amongst the attendees a JavaPosse deputy. After the most objective draw I have ever seen (;-)), the posse chose five contestants form among all the attendees in the hall – Chet Haase, Mark Reinhold, Brian Goetz, James Ward and Stephan Jansen. They had to participate in 9 rounds to compete for the spot.

The first four rounds were about each of the posse’s abilities connected with the podcast – Carl can find any information about a topic that they are not sure about, Thor is always coding when they discuss a topic which he is not permitted or interested to talk about, Joe is the king of making up funny translations of know or not well known abbreviations and Dick knows exactly what is the sound only by looking at its wave form. The next rounds included pronouncing hard to say names (John Smith and Romain Guy being the hardest), knowing what a particular JavaPosse term means (Lerooooooooy Jenkiiiiiiiins!), etc. Finally they absolutely objectively chose Stephan as the fifth JavaPosse member, closely followed by Chet. In his inaugural speech the winner promised to keep on organizing this great conference. And I hope that I’ll be able to meet Dick, Joe, Carl and Thor in person in a European JavaPosse roundup, which we all anticipate!

The final talk of the day was by Dick Wall and was a more philosophical one. It was about the courage in software development. I had listened to a JavaPosse roundup episode with the same name and the topic looked quite intriguing. It was also kind of retreat after four days full of hardcore stuff.

I will not try to paraphrase this talk, but will rather point out what I took from it. The first and most important thing – always ask ‘why’. Even the brightest minds are mere humans and you don’t have to always agree with them. Don’t follow movements and don’t create heroes, because this will seize your power think. To be honest, I’m great fan of the software craftsmanship movement, but what Dick said was that blindly following it is not a good idea. If you say ‘no’ to every little detail in your project that contradicts to it, you may end up in a situation where you never ship.

Another thing – a lot of us (including me) are afraid of failure. That’s not too good. It’s good to learn from one’s mistakes, it’s even better to learn from others’ mistakes. If you fail, just go on, but make sure that you don’t do the same mistake again.

Don’t stop learning and don’t stay in your comfort zone. Don’t be afraid of failure when jumping in some new technology – doing new stuff is fun. First study well the best practices and only then start building upon them. If you want to become a good poet, you’ll have to first read quite a lot of brilliant poems before you start writing your own. Each one of us knows the Don’t repeat yourself principle. Dick added and others to it. If you want to build something new, first go in the industry and check whether anybody else has done it before you. If you eventually decide to build it, then open source it at the end.

The quintessence of the whole talk was BE COURAGEOUS. 

After the Devoxx introductory Scala session, about which I wrote in a previous post, I went to Martin Odersky’s talk What’s in Store for Scala. “New developments for Scala: Better tools, full reflection, runtime compilation, and dynamic types.” Based on the abstract and the fact that the speaker is the language creator himself, I was prepared for this session to go into deeper details and provide stronger insights.

Here is a link to the slides from this session.

Overview and Features

Scala is used today in a large number of enterprises, and on a large number of cloud platforms. The main adoption vectors are Web, Trading, and Financial sectors. The main value proposition of Scala is being very fast to first products and scalability afterwards. The language is getting increasingly popular – Martin mentioned that last time he did a talk at Devoxx his talk was the only Scala one, but this year there are so many Scala talks that there is a conflict.

The latest release Scala 2.9 introduced many important new features, such as parallel and concurrent computing facilities yet to appear in Java, faster REPL, progress on IDEs, and better docs. The Play Framework 2.0 is an open web application framework inspired by Ruby on Rails. The Scala Eclipse IDE 2.0 is being completely reworked with the major goals being to make it reliable and responsive. The ambition of Martin is to eventually make it better than Java based on Scala’s excellent type system.

The new release Scala 2.10, which is scheduled for release early 2012 is going to introduce a few major new features:

• New reflection framework, much more powerful than native Java reflection
• Reification – types are persistent at runtime, but not as radical as in .NET, since that’s very expensive and complex, on programmer demand with “manifests”
• Type Dynamic – will help in the interfacing with dynamic languages, lets the programmer selectively suppress errors, similar to “dynamic” in .NET, but simpler
• More IDE improvements, among them a debugger
• Faster builds
• SIPs – string interpolation, simpler implicits

Scalability and Parallelism

Scala comes from “scalable”, and its name brings the promise of scalability. This is why the in the remainder of the talk Martin focused on two important aspects of “Scala in the Large”, large in terms of both many cores and large systems.

Regarding scaling to many cores, Martin repeated again what other speakers at this conference said: Moore’s Law is today only achieved by increasing the number of cores. It takes 24 000 running threads to keep a modern GPU fully loaded. The need for easier and safer parallel computing is sometimes called “PPP (popular parallel programming) grand challenge”.

Here, Martin made a differentiation between “Concurrent Programming” and “Parallel Programming”. The first is about executing programs faster on parallel hardware, while the second is about managing concurrent execution threads explicitly. But both are too hard to do using the familiar Java model with threads and locks.

The root of the problem is in the non-determinism caused by concurrent threads accessing shared mutable state, as demonstrated by the following code snippet:

var x = 0
async { x = x + 1 }
async { x = x * 2 }
// can give 1 or 2


According to Martin, the only way to really solve the problem is to get rid of the mutable state. But this means programming functionally, and this is why Functional Programming (FP) has become mainstream and popular only very recently. FP here has the advantage of offering a completely different mode of thinking: if you think imperatively, you think in terms of time, while if you program functionally, you think in terms of space. If you look at space, solving a problem in a parallel way is easy, it’s like building a cathedral with 1000 workers each of them working on its own piece. But if you look at time, it’s much more complicated, so you need to think about protecting your resources from concurrent access. However, we as humans are much better at thinking optimistically rather than pessimistically, that’s why from a thought perspective the functional way is much simpler than sticking to an imperative mindset.

In this space, Scala has many appealing features – it is not only agile, both object-oriented and functional, and both safe and performant, but also offers excellent parallel processing facilities. In Scala’s toolbox for parallelism there are parallel collections and parallel DSLs as core language features, and for concurrency there are actors, STM, and futures, all available in the Akka framework.

Since Akka was already presented in a previous talk, Martin focused on the parallelism features that are provided by the core language. First, he outlined parallel collections. He showed a simple Scala class Person with a name and an age, and then used it to partition an array of people to minors and adults sequentially. He compared the Java and the Scala code, outlining again the much more concise syntax of Scala, closer to the problem domain – a simpler pattern match, an infix method call, and a function value.

val people: Array[Person]
val (minors, adults) = people partition (_.age < 18)


He then came to the parallel case, which in Java would be rather hard to implement, while in Scala you can just add .par on people and the job is done.

val (minors, adults) = people.par partition (_.age < 18)


The above code converts the array into a “parallel array”, and then all operations that make sense to be executed in parallel suddenly are executed in parallel. There is a hidden contract, however – you give the system permission to execute operations in any order it likes. This means there should not be any side effects. But fully avoiding side effects means that you need to be functional, otherwise it would just not work. Martin said that he is very curious what will happen in Java after the announced introduction of similar features in Java 8 – according to the speaker, if Java doesn’t morph into a functional language, it’s way too dangerous to use that.

The parallel collections in Scala use Java 7 Fork/Join framework to split the work by the number of processors and introduces an adaptive mechanism in which the number of slices is changed dynamically depending on the workload, to get an optimal performance out of the box. The bottom line: they are easy to use, concise, safe, fast, and scalable.

But still, how can we reach the mentioned tens and thousands of threads in an application to fully load a modern multi-core processor? Parallel collections and actors are not sufficient. Here Martin makes a “bet for the future” that one possible solution could be parallel embedded DSLs. The idea is to capture the parallelism from the problem domain, which the compiler is not able to extract automatically, by using a Scala-based DSL.

Here Martin showed an example from EPFL / Stanford research. Liszt is a DSL for physics simulation, which is used for example to simulate airflow in hypersonic jets. It is mesh-based, with very irregular meshes. Liszt is implemented by a functional program that constructs a representation of itself with AST (abstract syntax trees) which is then converted to code which is optimized by the size of the problem and the hardware. According to the speaker, the performance of this implementation beats that of hand-written C++ code; problems tend to be so complex that humans can’t do an optimal job anymore.

Reflection

In the remainder of the talk, Martin focused on another new feature in Scala 2.10 – its reflection facilities. The goal here is to achieve the analogue of Java’s reflection, but with Scala’s full types. Programmers should be able to ask an instance for its Scala runtime class, then ask the class for its supertype, obtain its members, etc.

Reflection in Java is limited – for example it doesn’t tell you if type A conforms to type B. Why wasn’t this done in Java? It turns out this would only be possible if the reflection implementation would duplicate essential parts of the compiler, which is too hard and may lead to serious consistency issues.

How to do better? Martin looked at dependency injection and introduced the The Cake Pattern for solving cyclic dependencies in dependency injection. It turns out this approach can be used to achieve better reflection, as Martin put it to “bake a cake that’s both compiler and reflection”. There are three cakes: reflect.internal.Universe, extended by nsc.Global (scalac) and reflect.runtime.Mirror. To avoid exposing too much detail, the API facade scala.reflect.api is introduced on top of reflect.internal.Universe.

In conclusion, Scala is a very regular language when it comes to composition – everything can be nested, everything can be abstract – methods, values, types, and last but not least the type of this can be declared freely. All this allows us to solve previously unsolvable problems, such as achieve better reflection.

Conclusion

Although I was not able to fully grasp some of the more intricate technical details of this talk due to my limited knowledge of Scala, after it I felt even more motivated to further explore this language. Yes, it is more complex than other JVM-based languages (not to mention Java itself), but I think it’s quite possible that this complexity reflects the essential complexity of the problem domain, rather than being accidental. Based also on other Devoxx talks, I believe that the much praised Java simplicity is indeed a myth, since it offers programmers seemingly simple, but often inadequate language facilities in terms of conciseness and expressive power. In this respect, Scala has taken the opposite direction, and has so far positioned itself as the most promising “potential Java killer” (as other speakers called it) in the new JVM languages space.

In the afternoon of Devoxx Day 2, the new language parade continued with Andres Almiray’s overview of The Groovy Ecosystem.

Unlike Scala, I have some previous experience with Groovy. I studied the language earlier this year and was really impressed by its richness and expressive power. You could think of it as “Java on steroids” or as “Scala with a Java-compatible syntax”. On the downside, in my experience its dynamic typing, Eclipse support and performance were not that great. At the time, I thought Groovy might still be ideal for internal use, in any case much better than ant, batch files, or other scripting languages we use so far in this area.

The session abstract says that “Groovy is the fastest growing JVM language out there. It might be because it is so easy for Java developers to pick it up, but also because there’s an increasing number of projects and libraries that make use of Groovy as the starting point.”

Instead of presenting language or framework concepts on slides, Andres showed just a single slide per framework, and moved straight into coding to demo their features. Most of the demos went flawlessly and were quite impressive. You could check the slides here.

Grails

Grails is a popular Web application framework similar to Ruby on Rails. It builds on top of Spring and Hibernate and has more than 600 plugins available. In a few minutes, with the help of few console commands and a text editor (no IDE), a new “Book / Author” application was born and then enhanced by adding custom actions, views, and even tags. One could use the built-in Grails console as an interactive playground to test various dynamic methods (added by the framework), or other behavior of the application. Finally, it could be further enhanced by adding more plugins, and even by creating a custom plugin, all with very little effort.

Griffon

Griffon is another framework that brings the power of Grails to desktop applications. It also has a very rich plugin ecosystem, and is “polyglot aware”. Using Griffon is very similar to using Grails, just the grails command is replaced with griffon. Swing or SWT components can be created and wired with a special DSL, instead of custom code. The same Griffon application can be started as a standalone app, as an applet, or with Java Web Start by just using a different command for launching it. Properties of UI controls can be easily bound to other properties or the model with very little code. With a simple annotation one could control if the controller code runs in the same or in a different thread than the UI (event dispatcher) thread.

There are also archetypes that allow you to bootstrap applications in a different way. In the demo, one of the built-in archetypes was used to create an application with a predefined set of models, views, and controllers and a richer set of features. Griffon also has a very lightweight event bus. With it, you can publish an event and then listen to that event following a simple convention, in the same or different threads.

What if you are not allowed Groovy, but forced to use Java? You could still use Griffon by specifying the correct “file type” and “archetype” when creating your application, which creates Java code instead. If a certain plugin is installed, Groovy annotations such as @Bindable could be used as well. The Java version took a few rounds to compile correctly since the speaker didn’t use an IDE. As one might expect, it had twice the amount of lines of code compared to the Groovy application.

With Griffon, you can package your applications as a zip file, or as a different distribution type (dmg, izpack, rpm, …) with the help of the installer-plugin.

Gaelyk

Gaelyk lets you access Google App Engine (GAE) services by lightweight abstractions. According to Andres, it is “the PHP for GAE”. It also has an emergent plugin system.

Gradle and Gant

Gradle is a better way to build. This is a Groovy DSL for building projects, which harnesses the power of Maven conventions. It is actually similar and compatible with Maven, just much less verbose. If the conventions are followed, a simple application can have a build script which contains just a single line of code. In the demo, this simple build finished in 6 seconds the first time and much faster after that, because Gradle is smart enough not to repeat the steps that are not needed. If conventions are not followed, Gradle still gives you the full power to configure what you may need. Unlike Maven, it uses a very clear and concise syntax, typical for Groovy DSLs. Multi-projects in Gradle are also much easier than in Ant or Maven. Just by calling install, Gradle generates pom files and install the artifacts in the local Maven repository.

Gant is a “groovier” version of Ant – take away the XML and substitute it with a real scripting language. Although both Grails and Griffon still use Gant, it’s now somehow fading away because of Gradle.

Easyb and Spock

Easyb enables Behavior-Driven Development (BDD) for Groovy and Java. Some claim that BDD is TDD done right. When doing BDD, you define expectations from your customer’s point of view, write it in a natural language, and finally sprinkle some code inside. With Easyb, you could test both Java and Groovy code. It follows the usual BDD “given / when / then” syntax for defining stories and scenarios.

Spock is a testing DSL similar to RSpec. It hijacks the Groovy syntax to create something really “funky” using features that are available in the JVM, but not really exposed in programming languages. Did you know that you could have method names that are strings? With a simple @Unroll annotation, one could have a single method test multiple inputs, which is “unrolled” into multiple tests. Good bye @RunWith(Parameterized.class).

More …

CodeNarc is Groovy’s version of FindBugs and PMD. It enables static code analysis for Groovy code, and has plugins for Grails, Griffon, and Gradle. Andres showed how to add the plugin to Gradle and analyze the Groovy code with it. You could define what rules you want to apply using either XML or a Groovy-based DSL.

Concurrency is a new hotness. GPars brings concurrency management abstractions and facilities to Groovy, including actors, dataflow, and fork / join.

Ratpack is a clone of Sinatra for Groovy. It’s a nice way to create REST-based API for a command line tool.

GContracts provides “contract-oriented development”, which allows you to define pre-conditions and post-conditions to methods in the form of annotations (@Requires and @Ensures). This should not be seen as an alternative for testing or semantic validation.

Groovy++ is an attempt to make certain extensions to the Groovy language such as static compilations, traits (similar to Scala), immutable data structures, etc.

Conclusion

It seems that not only the Groovy language has all the features you may not see in Java in the next 10 years, but also that those Groovy guys have built up frameworks comparable (and to a large extent compatible) with whatever is in the Java SE / EE space, just much easier to use. And despite that they are built as open source by different people, they are still amazingly consistent. How did they manage to do all of that without JCP?

The keynote

Last year this was my first Devoxx session. This year I’m here for the university days too, so before the keynote I was not as excited as in 2010. Stephan Janssen, the Devoxx guy, came on the stage wearing a Brazilian flag and thus bringing some association with the always strong Brazilian groups on Java conferences. As Petyo mentioned – we should bring some of them on Java2Days. This year the conference is about three topics: Java, Android and HTML 5. There are 3350 attendees from 40 countries (at least four people from Bulgaria, yaaay). We have now seven halls in the cinema, which means seven parallel tracks.

Parleys.com will stream live one of the tracks (in the big hall number 8). However, you need to have registration to watch it (it costs 79 euro a year). The cool thing tough is that all the attendees will have one for free in a couple of weeks. So starting from Christmas we’ll be able to watch all the recordings – conference, tools in action, university days.

As in every keynote, we had a big announcement. In April 18 to 20 2012 there will be a Devoxx edition in France. Unfortunately for people like me, most of the talks (75%) will be in French. Good work Paris JUG!

Then on the stage came Henrik Stahl from Oracle to talk about Java SE. Apparently all the big news (if at all) were announced at JavaOne, but we had an announcement though – JavaFX was approved by OpenJDK, so we expect it to be open sourced soon. The topic of the talk was “What Java needs to do next”. In the near future we’ll have modularity (project Jigsaw) as well as lambda expressions. The latter will creep also in the Collection API by providing map and reduce methods as well as means of parallelizing the data structures (it happened that I will hear this two more times today). We are expecting also JavaFX 3.0. JRocket and HotSpot virtual machines will converge (not on 100% though, but pretty enough). We heard the promise: “Java will be there for you”. So, Oracle is not killing it

The final presenter in the keynote was Oracle’s Cameron Purdy. His talk was on Java EE. The focus of the technology in the next year or so will be on cloud, modularity and HTML 5. Modularity can come after Jigsaw is implemented, which means Java EE 8 at earliest. As HTML 5 is still quite fuzzy, it wasn’t surprising that most of the talk was concentrated on the cloud. The platform as a service (PAAS) paradigm is becoming Java EE as a service. You should be able to declare what kinds of services you need for your enterprise application to run (database, JMS, etc.) and they will be provisioned to you by the cloud provider. We saw a demo how Oracle’s own PAAS implementation infers the needed types of resources without reading manifests, but just by looking at the type of the archive being deployed, the availability of certain files (persistence.xml), etc.

It was not only the cloud though. Cameron vaguely mentioned what everyone expects – migrating some of the EJB model features (like transaction provided by the container) to the CDI model. Will we have both models in Java EE 7? Hope not, but I didn’t hear it from nobody from Oracle. At the same time JBoss guys are pretty certain about it.

The last part of the talk was not so very interesting to me and I believe this is the same for most of the other geeks at the conference. The speaker advertised Oracle’s own Java EE server (Weblogic). Besides a few employees of companies providing similar PAAS solutions, nobody really cares about how far is Oracle in implementing Java EE 6 and in integrating its server in the cloud.

Java: the good, the bad and the ugly

I stayed in the same place for the next slot. I watched the talk by Josh Bloch, who always has something interesting and unconventional to say. No surprise that the biggest hall was more than full. The topic was the good, the bad and the ugly parts of the Java language and the Java library. Josh actually looked at the state of the language when it was created 16 years ago (JDK 1.02). He started with the virtues of the platform. To name a few:

• Tightly specified language primitives and evaluation order – int is always 32 bits and operations are executed always from left to right, without compilers messing around
• Dynamic linking – when you change a class, you need to recompile and rebuild just the jar that has it and not the whole application
• Syntax  similarity with C/C++ – most existing developers at that time felt like at home
• Object orientations – it was cool at that time as well as functional programming is today
• It was statically typed language – helps in faster runtime, better IDE support, etc.
• No operator overloading – well, I’m not sure why it is good. Scala has it for example and that’s why it is far better for defining DSLs. But I will not argue with Josh

Of course there were some bad things in the platform, like inlining final variables (or constants) – it violates the dynamic linking principle, so if you change a constant you have to recompile and rebuild all the other classes and jars, where it is used. There were also other bad and ugly things, but I will not list them here. I’m pretty sure that the slides will be available soon, so everyone will be able to review them.

The second part of the talk was dedicated to reviewing the JDK 1.02 library. It may sound surprisingly, but it contained just 7 packages (java.lang, java.util, java.io, java.net and three java.awt ones), 117 classes and 18 interfaces. What I took away after his review (I will not discuss the details here) is the following:

• Why do we need algorithms for hash code and pseudo random number generators specified in the Java language specificatio down to the last bit? If someone comes with a better alternative, it can’t be integrated into the code any more
• The negative attitude towards checked exceptions today is mainly due to the fact that all the important classes and interfaces throw them and you have to always take care of them
• Most of the important stuff was then synchronized. At that time it was fine, but not anymore today
• Non-deterministic behavior of functions is not fine. If it is non-deterministic, then why do we need the function at all?

Despite all the criticism Josh still loves Java and its small and simple libraries. Looking forward to his next talk on Friday to see how these evolved throughout the years…

Java 7, 8 and 9

To be honest, I was not sure why I went to this session. Initially I thought about going to the Kotlin talk, but finally decided to see what Mark Reinhold has to say.

He started with, guess what, Java 7 features review. I must say that I am fed up with reviews of diamond operator, strings in switch, fork join framework, invokedynamic and all the rest. I’m pretty sure that most of you think the same. Luckily it was quick browse and then Mark continued with Java 8. Looking at the history of the language, its eighth version looks revolutionary. It should be out somewhere in 2013. The most prominent features will be lambdas and modularity. It was exactly what the speaker presented in more details.

Mark showed an algorithm of determining a list member, which has maximum value. It appears that this can be parallelized and with the help of lambdas the boilerplate can be largely reduced – you don’t need to create anonymous inner classes anymore when you can pass code blocks as if they were regular variables. Another feature that walks hand in hand with lambdas is availability of default implementation methods to interfaces. Thus you can add new operations to existing interfaces without bothering to extend the implementations out there. Having that in hand, you can extend the existing collections. But for that a little bit later.

Another important feature that will be part of Java 8 will be modularity and project Jigsaw. There will be a new language construct, called module, which describes library’s (i.e. jar’s) versioned dependencies. Thus you eliminate the need of declaring these in the classpath, which becomes really appealing in case of transitive dependencies (the dependencies of my dependencies). A new packaging format is also proposed. It’s called jmod and is way better than jar when talking about distributing the libraries (I don’t know why, but I guess that I can find it on the internet). The essential thing is that it will be used just for transporting the files – jmods will have to be “installed” before executing. This much resembles Linux packages and Ruby gems.

Project Jigsaw actually is not about modularity, but rather about applying that on the existing JDK. The goal is to split it up in modules with clear dependencies and then use just the ones that apply for the current scenario (you will not have CORBA module if you just need to copy files for example). The topic of already existing module system – OSGi, was slightly scratched. Mark mentioned that both systems will be able to co-exist. Personally I like the proposed modularity more than OSGi, but it is not a surprise for people who know me.

The last part of the talk was a quick overview of what may be in for Java 9:

• Self tuning JVM, which can figure out its settings by inspecting the machine capabilities
• Improved JNI – fix the initial plan to make it hard so that developers don’t use it
• Support for really big arrays and collections (with 2^63 elements)
• Reified generics – the type of the elements inside is known at runtime, rather than erased. Doesn’t that mean breaking backward compatibility?
• No more primitive types, autoboxing and unboxing
• Tail recursion and continuations
• Multi tenancy
• …

I wonder whether such a comprehensive list can be implemented for two years, which is the intended schedule. Or maybe we’ll have another Plan B for Java 9?

Finally, Mark confirmed that SAP is part of OpenJDK. Was it because my colleague Krassi Semerdzhiev reminded him about it the day before?

JRuby introduction

I had great doubts for this time slot. This time it was not a clash of titans, but rather no topics of particular interest to me. I didn’t want to go to yet another review of project Coin, even though I knew that Joe Darcy and Maurizio will enter in the implementation details area. The partner talks were also of no interest to me. The same applies for HTML 5 (I promise not to attend any session on the topic until the end) and Android. So what only remained was the JRuby talk by Hirotsugu Asari. I must say that I am not at all interested in the Ruby topic. To me this language has nothing that can gain me on its side. The combination Java+Groovy looks much more promising. But anyway, I decided to give it a chance.

So, the guys are giving their best to attract developers: they have a web page, where you can try the language. For those of you who are on my level of understanding: JRuby is a dynamically typed language with single inheritance. It is method oriented – everything is a method, even the constructor (it’s called initialize) and the new operator. The @ symbol is the same as “this.” in Java. As in Scala, Groovy and co. you don’t have to explicitly say return at the end of the method. JRuby has closures, but their syntax doesn’t look very similar to that in Scala or Groovy. The language supports operator overloading. It also supports changing existing classes – even those which are part of the core.

JRuby applications can be deployed on Rails. JRuby code can be deployed as part of a Java Web application – alone or together with Java EE code. The language has its own servlet and servet filter.

After Hiro gave this short introduction to the language, he continued with the tools and frameworks based on JRuby. There are several testing frameworks quite similar to Groovy-based Spock and easyb. I’m not sure whether they can be used to test Java code though. Because this is one of the safest ways to learn a JVM language – write the test for your Java application in that language’s test framework. JRuby has also quite a few build tools that integrate well with Ant and Maven. It can install maven artifacts in the same manner as it installs its own gems.

As we heard from Mark Reinhold JNI was designed deliberately hard so that Java developers avoid writing native code. Well, JRuby has much better alternative in that area, and it’s called FFI. To be honest, I didn’t get much of it from the presentation, but I hope Google search would know better than me how it works.

I’m pretty sure now that when you create a new JVM language, after it gains some traction, you will inevitably create the wholly trinity: web framework, testing framework, build framework. It is even better if they integrate seamlessly with existing Java solutions in the respective area. A great plus for the language is if it offers to the world something very specific that is not present in other “competitors”.

NoSQL for Java developers

After a very intense attendance of Spring sessions at Java2Days a couple of weeks ago, I must confess that this was my first talk at Devoxx. Well, it was not exactly on Spring, but more about NoSQL (which means Not Only SQL). The speaker was Chris Richardson, who is the founder of CloudFoundry, which was acquired by SpingSource several months before it was acquired by VMWare.

So, why is NoSQL so popular these days? Well, it addresses some issue of RDBS like storing complex object graphs and semi-structured data, it handles very easily schema changes and scales both out and up. Well, it doesn’t support ACID. If you want faster, relational and ACID-ful database, you may look at a new proposal on the market – NewSQL.

So…., the presentation was about NoSQL. Very good approach by Chris. He chose three different kinds of NoSQL databases: Redis (key-value store), Cassandra (column oriented database) and MongoDB (document DB). Then he explained in detail what are their advantages, how they store the data, what are the commands to be executed for regular operations like inserting and reading, what are the usecases where they shine and which companies are using them productively.

After that Chris went on with a case study on how you can implement two simple scenarios in the three data stores. The first scenario was quite straightforward, but the second one was quite more complex – it would be implemented with three joins in standard SQL. It seems that most of the data stores have problem with such type of queries. I’m pretty sure that I didn’t get it, but it seemed to me that for the Redis and Cassandra examples Chris tailored the data store structure to follow the query logic, so that it can be executed. If it is true, then what would you do if you have to implement a second query. Apparently you cannot restructure in runtime your database before running each query. Anyway, MongoDB didn’t have problems with this, as it has very powerful JSON based query language. BTW InformIT has a great review on this data store.

The conclusion was that each NoSQL solution solves a particular set of problems that RDBMSs have. But none of them solves them all and all of them have a drawback – they are not ACID-compliant. So Chris’s advice was: be very cautious when you decide to use NoSQL. If at some point of time you decide that you need ACID, then you’ll have to rewrite the whole data access logic.

Language/library co-evolution in Java 8

The last session, which I attended today was by Oracle’s Brian Goetz. It was about adding lambda expressions to Java and the enhancements in the libraries that follow that. It’s always better to solve a problem by contributing code to the libraries rather than by adding new language features. However, sometimes the latter is inevitable.

This presentation followed what Mark Reinhold presented in the morning about project Lambda, but in more details. Brian started with the same code example – looking at a list of students and finding the one with highest mark. Right now it can be only implemented by writing a sequential algorithm that runs outside of the list – iterate over all of is elements and find the one with maximum mark. However, this solution tends to be non-thread safe and inherently serial. And serial algorithms are the root of all evil. Then Brian proposed a better algorithm that uses the Java 7 fork/join framework. But the code looked quite unreadable – with three inner classes representing the different functional concepts like predicate or mapper. The lambda functions solve exactly that – remove the boilerplate by providing the possibility to treat code as data and let it be passed as parameter.

The Java team at Oracle didn’t stop with adding the closures to the language. They searched actively for their application inside the existing libraries. And the collection framework seemed like a perfect fit. Having sort or filter methods in the various collections would be perfect and will eliminate the need to implement sequential means of sorting them. However the collection API interfaces are already very stable and touching them is not the best idea, as all the implementations in the world have to be adapted as well. So, the solution here is to have a new language construct – default implementations defined in the interfaces. Thus the extending class does not have to implement this method – if it decides not to do so, the default application will be executed. This means that if you add sort method in the List interface with implementation that calls Collections.sort(), then if some of the existing List implementations doesn’t override this method, that default method will be executed. As I already mentioned, this small feature is not less important than Lambdas, as it enables adding methods to existing interfaces without breaking compatibility.

Then Brian went on to present the convenience methods that will be added to the Iterable interface. Just to mention filter, sort, map, reduce among the rest. The default implementation of each of them simply calls the respective method in the Collections class. The next question is which of the methods are lazy (i.e. they don’t change immediately the collection) and which are eager. It appeared that all the operations that return as a result an Iterable (like filter for example) are lazy. While methods that return anything else are eager. Usually when you would call the collections API the sequence is lazy, lazy, …, lazy, eager.

The last part of the presentation was dedicated to parallelizing the collections. Fork/Join will definitely be used for that. Each Iterable implementation will have a method called parallel(), which will return a corresponding Spliterable interface implementation.

I will not go into more details. Hopefully Brian’s session will soon be made public as it is very useful for understanding the benefits of both features – lambdas and default methods.

I am interested in the “New Languages on the JVM” theme at Devoxx for two reasons. Firstly, I tend to be rather enthusiastic about programming languages. I’ve switched them few times during my career and it was mostly a rewarding experience. I fully buy into the idea that we programmers should be familiar with several languages even if using actively only one, simply because the different concepts in each language provide useful “thinking tools” for approaching problems. Secondly, however, I am a bit overwhelmed by the current boom of new JVM-based languages. Groovy, Scala, JRuby, and Clojure, are only some of the more popular at Devoxx, and this is by far not an exhaustive list. What should we do with all this diversity? As beautiful, concise, and runtime interoperable with Java as they may be, how does this help us with that half a million LoC legacy Java stuff? And as enthusiastic as I and my colleagues may be, how could these newcomers possibly penetrate the corporate product standard fortress that often declares the “one language to rule them all”?

In the first part of the Crash Course into Scala session, Mario Fusco presented an introduction into the Scala programming language. What is Scala? The abstract really got me hooked: “Scala can be used both as an object oriented language, more elegant, concise and powerful than Java and a pure functional one as rigorous as Haskell. Moreover, despite of having all the safety of any other statically typed language, it allows to have also all the expressiveness and flexibility of a dynamic typed one like Groovy. In a word Scala can be many languages in one, but where it really shines is the way it seamlessly combines all these paradigms together”.

In the beginning of the session, Mario outlined the language philosophy of “Do More With Less” against the Java “Keep It Simple” mantra. He then proceeded to compare Scala with Java, Groovy, and Haskell, revealing its “object-oriented”, “scripting”, and finally “functional” features. This included a brief overview of constructor syntax, operator overloading, override keyword, default parameter values, named parameters, singletons, companion objects, traits, case classes and sealed traits, pattern matching, implicit conversion, structural typing, functions as parameters and return values.

To put all of that together, Mario created a simple DSL for looping, which also nicely demonstrated Scala’s power to create DSLs. The end of the session contained an overview of some more functional programming concepts such as tuples, list manipulation operators, higher order functions, and for-comprehension.

The talk itself was well structured, full of technical details but at the same time also understandable for Scala newbies (like myself).

In the second part, Kevin Wright proceeded to outline the Scala’s perceived role as “agile enabler”. First he tried to amaze the audience by executing the following “expression”:

A long time ago in a galaxy far far away

This demo took a few compile attempts before it could actually run, but still it was intriguing. After that Kevin presented a few examples of language features where he pointed out Scala felt “natural” and helped developers translate their ideas into code more easily, without boilerplate, and still in a type safe way. One particular example referred to Kevin’s gist at http://gist.github.com/1262988, in which he showed how by overriding the “+” operator for chaining filters one could capture business domain knowledge in a way that is both more concise and more readable.

At the end of the session, Kevin answered questions from the audience based on real experience. We learned that:

• Scala is best introduced in the team by creating tests against the existing Java codebase
• Scala practitioners may pay a bit higher one time upfront cost to get a substantial payback later
• Some of the powerful language features could be abused (“you can cut deeper with a sharper tool”) and not doing that takes discipline.

Overall, this talk contained some pretty interesting ideas and examples, even though it was a bit too unstructured for my taste.

Although this talk did not address all the concerns I expressed in the beginning, it was still quite helpful. It did convince me that Scala could be a really great language that is worth trying out. As a first step, I could probably write a few unit tests for my project and share them with my team. Then, if enough enthusiasm is born, we could together find also other ways to adopt Scala. But wait, should that again be Scala, or Groovy, or JRuby, or … well, let’s see how the other new languages will fare in the Devoxx parade.

Posts in other blogs about this session:

• styledideas.be
• Remain Clam
• RealDolmen

In this blog series, I will be writing short summaries of some of the Devoxx 2011 sessions which I attended, mainly focusing on topics that are not covered already by Ivan’s posts.

Devoxx this year is a big. More than 3000 attendees, 5 days, 150 sessions, all packed with rich and interesting content. It’s a great chance to get an overview of the latest technology trends and do a crash course in all those topics you missed so far while focusing on your specific problems, and maybe also an opportunity to see those problems from a different, refreshing perspective.

When choosing which sessions to attend, I chose to stick to the following themes:

• Methodology – Sessions here to be more “timeless” in nature. Also, I was until recently responsible for managing agile teams, and improving processes and tools is still a significant part of what I do.
• New Languages on the JVM – I tend to be rather enthusiastic about programming languages in general, but I am also a bit overwhelmed by the current boom of new JVM-based languages. How could we possibly use all that diversity?
• Java SE – The evolution of the core of the language is going to affect all of us in many significant ways. Also there are some really great speakers – Joshua Bloch, Mark Reinhold, and Brian Goetz among others.
• Architecture – My current job title is “architect” after all …

Each post will cover a single session or a small number of related sessions, and unlike Ivan’s posts, they won’t necessarily come in chronological order. Whenever I am aware of published slides and other relevant material, I will link that. Read everything if you would like to follow the conference or chose whatever topics are most interesting to you. Any feedback would be great.