by Ivan St. Ivanov
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?
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.