by Ivan St. Ivanov
Today was JavaOne’s first conference day. I went to many sessions, some of which were really geeky. The speakers spent most of their time in the development environment showing cool techniques in the respective topic. So it is pointless to report anything lengthier there. But in a few sentences:
Adam Bien talked about writing enterprise apps with… JavaFX. Besides giving some insight in the enterprise patterns, he showed a neat way how you can implement dependency injection when you are not in the managed environment of an application server.
JBoss’s Andrew Lee Rubinger and Aslak Knutsen presented their new book and showed some interesting approaches in testing non-Hello-World Java EE applications. I could learn how you can test asynchronous methods with java.util.concurrent.CyclicBarrier and how you can verify that your RESTful web service follows the HATEOAS principles.
At the end of the day I attended an hour and a half long tutorial on writing given DSL in Scala and Groovy. It showed the constructs in the two languages that are used for implementing one and the same thing.
Here are some more details about the other sessions:
Groove your SAAS
I visited a session about using JVM languages to configure your application. And I was positively surprised on how interesting it appeared to be. It was given by two Amadeus employees. Their company provides IT solution for the travel industry. They offer hotel/ticket booking application together with its hosting on their data centers. Initially it was pure Software as a Service (SAAS) allowing the customers to only change things like colors and themes. However, soon they realized that in certain countries specific features were required. For example in Sweden they wanted to be able to book a taxi together with their plane ticket (otherwise they may freeze to dead while waiting outside the airport ;)).
However, this was not all that they had to do. The customers were sharing common hardware resources. Not only that, but some of them were running inside one and the same JVM. So theoretically if the customization written by one customer calls System.exit(1), this will bring down the whole server, together with the applications of the other customers. That’s why they decided to implement checks on script compilation level before deploying the script into the server environment. They used Groovy’s Abstract Syntax Tree (AST) manipulation capabilities in order to prohibit some non-allowed method calls (part of a black list). The same functionality was used to add wrapping code that would check at runtime if there are bad code constructs that was not caught on the previous step.
This was really an eye opener for me. If you are server provider and want to let your application developers use different languages, you don’t have to write a different server in different programming language for that. You can do that in Java and use JSR 223. The specification is available since Java 6, but unfortunately lacks things like giving access to the binary code after it is compiled (so that it is not compiled again the next time the same script is executed) and you have to take care about the security concerns by yourself. But if there’s a will among the big players in the industry, this can be improved with the next version of the spec. And with the growing popularity of the scripting languages I think that it’s really time to look at that JSR.
Last year’s JavaOne I got intrigued by the Adopt OpenJDK program, which aims at individuals, JUGs or even companies to implement certain features from OpenJDK and to contribute them to the central repository. And thus helping Oracle with testing, improving and delivering faster the new releases of Java’s reference implementation. Unfortunately in the last year I didn’t do much to get our JUG involved in this effort, but I may say that with the help of another JUG member we are already there and soon will present to the Bulgarian Java community what we have in mind. However, we had some questions before that and my JavaOne attendance was a perfect fit for finding the answers.
This morning I went to an introductory talk on this topic. Even though I have read numerous wikis on the topic, it was interesting for me to find that 75% of the code in the repository is Java, 12% being C++ and other 8.5% – C. A good step in Java-ifying more and more code is project Graal, which goal is to re-implement parts of the JVM in Java. Projects like Sumatra are built on top of that.
The OpenJDK project has done a lot in the last year to attract the developers with the facilities like mailing list, twitter account, blog aggregator. There is even a wiki page and a modern bug tracking system. You can read all of those freely, but you have to have OpenJDK account if you want to post.
After the session I caught the speakers and posed the questions that I planned to ask before I left to San Francisco. And now I am pretty confident that soon we can bootstrap our OpenJDK effort in Sofia.
Java EE 7
Every conference in the last couple of years had at least one or two talks on What’s new in Java EE 7. Even my fellow blogger Stoyan has written a post on it. So I didn’t plan to write much on the “Java EE 7: making easy even easier” session that I attended. But at the end I was happy to find that there were a lot of things that were new to me, which I will happily share with you.
The speakers were Oracle’s Arun Gupta and the lead of the JBoss Forge project Lincoln Baxter III. I will not repeat here things like JMS 2.0, REST client API or web sockets. You can read about them in almost every Java EE 7 article issued in the last few months. Here are though some things that are worth mentioning:
- As of Java EE 7 all the APIs are accessible in the central maven repository under the javax:jee-api:7.0 GAV address
- You can @Inject now everything, not only CDI beans
- beans.xml is not mandatory anymore to enable CDI. However, if you create it, you can specify inside whether CDI should be turned off or should be turned on just for some of the beans
- The server providers must provide default JTA data source. So if your persistence.xml does not contain the jta-data-source tag, that default data source will be used
- You (or your DBA) can write your own DDL scripts and let the entity manager use them for creating the tables schema instead of building it based on the entities declaration
- You can add index declaration to your @Table definition
- It is no longer necessary for a component to be an EJB in order to be run in a container managed transaction
- You can declare a method as @Transactional and the container will automatically execute it inside a transaction
- You can declare a bean as @TransactionScoped and the container will create a distinct instance of it for every new transaction (and will fail if it is called outside transactions)
- Remark: Hello, Spring!
Batch processing (JSR 352)
- Again something that was heavily influenced by Spring
- You define an XML that contains a sequence of steps. Every step has one or more chunks. A chunk has three stages: read, process and write. For every stage you specify which bean should be called
- You write @Named beans for every stage (its name should match to the configuration in the batch.xml) that respectively read the data from a certain input source, process it if needed and write it back into the output source