November 20th, 2011

By Stoyan Rachev

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.


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.


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.

November 20th, 2011


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.