alt
October 6th, 2014

by Ivan St. Ivanov

 

The last day at JavaOne started as usual with the community keynote. I didn’t go to it, because I wanted to have a rest after the Aerosmith and Macklemore & Ryan Lewis concert last night and also wanted to catch up with my blogs. However, the people that I follow on twitter were kind enough to update me with the most interesting bits of the session. Additionally, there’s already a blog from Ben Evans about it.

Basically Oracle understood their mistake from the opening keynote on Sunday and let Mark Reinhold and Brian Goetz on the stage to do their technical talk that was cut so abruptly a few days ago. Apparently Java 9 was the central topic. Modularity, value types, primitive types in generics, native data and code access, array rework, etc. are the most prominent things that will hopefully come with the next Java release.

The keynote continued with a panel moderated by Mark Reinhold, having Brian Goetz as well as James Gosling (the father of Java), Charles Nutter (the JRuby guy, from RedHat), John Rose (JVM Architect, known for things like invokedynamic and the value types in Java) and Brian Oliver (Oracle’s in memory data grid architect). They answered various questions marked hashed with #j1qa on Twitter (BTW, it was trending in top 10 on the Thursday morning). The most tweeted statement from the conversion was that James Gosling was not sorry for introducing null in the language.

The final part of the keynote was dedicated to the community (at the end, this was the community keynote). The most important news was that like last year all the JavaOne 2014 sessions will be on Parleys.

JBoss Forge

I don’t know whether there is a reader of this blog that does not know what JBoss Forge is (check out its new cool website). But still: it is a rapid application development enabler tool, built on extensible platform and as of its second version with abstraction over its user input. Yes, as of Forge 2 you can run the tool both on the command line as well as with wizards in your favorite IDE. Actually a Forge generated or managed project doesn’t have any dependency to the tool. It builds all the knowledge from the pom.xml for Maven projects and build.gradle for Gradle projects. The extensibility of Forge is because of its modularity. No, it’s not OSGi, Forge is based on JBoss modules and has quite some machinery based on Maven on top.

Where does Forge help, you would ask? In any areas, I would answer:

  • Figure out for you the right dependency that you have to add to a Java (EE) project
  • Put the right entry for your JPA provider in the persistence.xml
  • Help you declare a bi-directional one-to-many dependency
  • Plumb for you the boring CRUD classes
  • Prepare a mock UI (a.k.a. a scaffold) out of your domain model

This is done by already existing Forge addons, but you can very easily create one of your own to help you in your daily job activities. If you have a tedious task, where you constantly copy and paste artifacts from one project to another, then you can think of implementing your own addon. It’s built with Maven and you can use dependency injection for the dependencies from the Forge core that your addon might require (CDI or the service loader). Once you have developed your addon Forge gives you a way to test it in the Arquillian way, i.e. in-container without any need to mock anything, and then deploy it on the Forge runtime. You can also develop listeners to observe events before and after Forge command executions.

Go and try Forge and then join us and contribute! And you might get one of these.

Be reactive with Java 8

The next logical step after applying functional programming practices to your APIs is to make your modules containing those APIs reactive. Well, this might sound as the next buzzword, but in fact it is not. The reactive programming style was something that was invented long ago, we forgot it and now we found how cool it is.

How does your program become reactive? Well, if it serves requests from external clients and if these requests take longer than expected, the call on the client side should not block on one side and on the other side the server should respond in timely manner that it is processing the request. It is very important to not spawn a separate thread for every request – if the client retries the request again and again, the threads may quickly expire and the memory could be filled up. Using futures is not a solution to that: yes, they seem asynchronous, but at the end you have to wait on their get() method. Callbacks seem a neat solution, but the problem with them is that they cannot be nested.

So, how do you achieve the efficiency of the reactive programming style in Java 8? There are quite a few libraries, but the last session that I happened to visit at JavaOne (by Venkat Subramaniam) focused on one of them: RxJava library from Netflix.

Its API is built around the Observable class. You create an instance of that class on the server side. It receives kind of recipe as a parameter, telling the RxJava library what to do upon an event happening on the server side. This recipe is an implementation of the Observer interface and you can call any of its methods inside the create() method body. Then the client can call one of the subscribe() methods of the received Observable to pass lambdas that will react on a given event happening on the server side. The types of events that the client can react upon are success (the onNext event), error (onError) and completion (onComplete). For each one of them there is a special subscribe overloading method, as well as a method receiving a full blown extension of the Subscribed abstract class.

You can call the unsubscribe method of the Observable on the client side to stop “receiving” updates from the server part. Besides those, Observable class has lots of other methods that make it look like a real [functional] lazy abstraction: skip() and skipWhile() for skipping the first events happening on the server, take() to take some of the events and then stop observing, combine() to combine this with other Observlables, etc.

The RxJava library provides APIs for other languages on the JVM besides Java: Groovy, Scala, Clojure to name a few. I guess that this is a really great new topic as of Java 8, so it deserves much more exploration than these few paragraphs.

Java2Days preparation instead of map, flatmap and reduce

I was really interested to visit another functional talk as well. It would go at another level comparing others that I’ve seen in the recent couple of years. It promised to not only go through the usual stream collectors and reduce methods, not stop at forEach and filter or at the simplest map methods. It would go into other functional terms like flatmap or more complex reduction (foldleft probably?). All in the Java world.

However, this was the only slot when I could meet Reza Rahman from Oracle to discuss what we are going to prepare for the Java2Days conference that we are running in Sofia the week after Devoxx. So I decided to watch that talk on Parleys later and had a beer with Reza during the closing ours at the Duke’s caf?. I can promise you that if everything goes fine, we’ll have a really cool agenda for our Bulgarian conference: hands on labs covering the latest Java SE 8 and Java EE 7 technologies plus tools like Forge and Arquillian, Java SE 9 hacking, talks on Java EE 8, etc. Can’t wait it to happen!

October 3rd, 2014

by Ivan St. Ivanov

 

This post will be covering days two and three of JavaOne. The reason for that is that yesterday morning I had to prepare for my first ever talk at JavaOne.

The batch talk

In March this year I had great time at the JavaLand conference. Along with other great people, I met there the freelancer and blog author Roberto Cortez. He told me that he is going to send a few session proposals to JavaOne and asked me whether I wanted to join him for the Java EE Batch talk. I hadn’t heard much about that topic at that time, but I agreed. Then the proposal got accepted and here I am at JavaOne now. What do you know…

Our intention for this talk was to introduce the audience to the Batch applications as a whole with topics like what is batch, why do we need it, is there batch processing in real life, etc. Then we wanted to continue with a review of the JSR 352 (Batch Applications for the Java platform) APIs. And last but not least, we wanted to live code a real world application. The topic that we chose was aggregating World of Warcraft auctions data per realms, processing and presenting some statistical data like minimum, maximum and average bid for the items at various auction houses. We (well, mostly Roberto, to be honest) even prepared that application beforehand.

The risk here was that the topic is so broad, that we were afraid that we may not have time to deliver everything as planned. We also made the things even more complex by letting the audience ask questions anytime they have it. And of course the time was not enough and we could not do the live coding session. On top of that I was surprisingly to myself extremely nervous during the session and delivered one of the poorest performances in my talk-giving history. I will not go into details on what is batch and what’s the patch processing in Java API, Roberto already uploaded the slides.

The coolest thing about this is that we (and especially myself) have our lessons learned. And the next time we give this talk we’ll be much better prepared. And this next time will be the Java2Days conference in Sofia mid of November. I would love that the order would be the other way round, but…

Java concurrency internals

A while ago I read a brilliant article by Gleb Smirnov about how setting and reading volatile variables in Java works under the hood. This year at JavaOne I had the opportunity to see the author of this post live on stage explaining all these things for the mere mortals as me.

In a nutshell, javac and then the JIT compiler make optimizations of the executed instructions. Sometimes these optimizations are more aggressive (in the server VMs for example), which means that the compiler would make more assumptions on the program flow. One of these optimizations is reordering instructions to avoid cache misses when a variable value is read or written. To make things even more complicated, in a multicore environment we have multiple level of caches on every core.

So if we want to make sure that the most recent variable value is read by all cores at any time, we declare that variable volatile. This would make the compiler emit memory barrier instructions. What a memory barrier ensures is that all the read operations above that instruction will stay there and will not move below it. The same if the read operations are below the barrier and the same with the write instructions. The other thing that the volatile keyword implies is that long and double variables that have it are written in atomic fashion.

This might sound very simplistic, but if you want to get into more details go and read the article. The slides are also available online.

After the talk I asked the speaker whether the synchronized blocks have the same effect. He told me that in principle yes. But they do also many other sorts of things so for something as simple as telling the compiler not to reorder read and write instructions, volatile is a better option.

Java EE. Again and again

I visited a lot of Java EE talks these days most of them given by distinguished luminaries from the industry.

First, Dave Blevins of Tomitribe gave one of those talks that only he is capable of on Java EE game changers. Let alone the fact that his “slides” were actually in the IDE, he again managed to present the topic without just boring us with endless rumbles on the other cool feature in the platform. Amongst the biggest game changers he mentioned the introduction of annotations (heavily inspired by XDocklet) which allowed the revolutionary change in Java EE 5 that returned the people back to the platform. Being able to package almost everything in a single (war) archive was another important turning point in the Java EE history. It removed the impression of java web applications looking like Russian dolls. The embedded EJB container functionality introduced in Java EE 6 makes it possible to very easily create a microservice out of a Java EE application. Even now you can take the TomEE server and run a Servlet, CDI, JAX-RS and what not in your public static void main class as described in this great blog post from Alex Soto and can be showcased in this simple Java class. Dave shared also his regret that Spring is not on the JCP. The talk finished with an outlook on the future: how the Java EE APIs can be adapted with respect to the big thing in Java 8: the lambdas and especially the method references.

This year I went to only one talk by Adam Bien. In that he challenged a lot of practices considered as a norm in most of the Java EE projects these days:

  • Too many layers. He made a joke that in a project he deleted most of the layers and the app was still working
  • Thinking about wrong thing first: create all the exceptions (and putting them in an exception package) or deciding on what framework to use prior to even thinking about the domain model and requirements
  • Including all sorts of external dependencies without even checking whether the JDK or Java EE has the same functionality

Among the good practices he mentioned having a simple design and implementation (there are even tools that measure that), continuous quality, short development cycles, bottom up approach on architecture, boundary-control-entity layout of the application, etc. In his opinion Arquillian is a great tool, but is overly used these days. For simple tests he proposed having a simple unit test with some mocks. It wouldn’t be Adam Bien if the talk didn’t contain live coding part.

Manfred Riem (very well known in the JSF world) gave a talk on one of the newly proposed JSRs for Java EE 8 – JSR 371, the Model View Controller specification. It provoked a lot of comments in the java world these days: why do we need another MVC solution in Java EE as we already have JSF, do we want to have Struts again, etc. So Manfred went on to explain the difference between the Component-based MVC (JSF being of this type) and action based MVC (e.g. Spring MVC). The main difference is that in the first type the request processing is responsibility of the framework, while in the other case the application developer should take care of it. At the end, it was the community that wanted this in the survey done by Oracle a few months ago. Manfred showed what his view of the future API will be. The second part of the presentation was on some extensions in Jersey (the JAX-RS reference implementation), which allow to have real action based MVC in Java EE even now. I think it is a very good opportunity for JUGs to adopt this JSR, as it is on one side a cool thing to work on and on the other side it is something very important for the industry. That is why I will propose it to our JUG once I get into Bulgaria, hoping that we have some experts in the area.

Finally I went to a talk describing various recipes for concurrency in Java EE. As of Java EE 7 application modules can get the good old java.util.concurrent.Executor service (managed by the containers of course) and do things like executing jobs in the background (also showcased in our Java EE batch presentation), scheduling tasks for executing later or repeatedly at a certain interval, etc. You can even obtain and execute plain old Java threads now inside a Java EE application using the ManagedThreadFactory.

Hacking @ JavaOne

This year I spent quite some time at the Hackergarten area in the exhibition hall. It becomes a tradition for me to make contributions to the Arquillian group of projects at JavaOne. This year I worked on something new: a Groovy DSL for running the tests. After some help from the project lead (happy birthday, Aslak!) I was managed to come with my pull request: added support for modelling deployments to different runtimes (just modelling, not real deployment).

I took part in the Adopt OpenJDK  hands on lab as well. Not too many showed up, but I helped Martijn from LCJ to introduce how you download the sources, configure and build them. I wanted to show the people how they can change a class (StrgingBuilder for example) and then run their program against JDK built with that change in. But things were running a bit slow, so there was no time for that final step.

At the end we sit together with George Gastaldi from the Forge team. He helped me with FORGE-1610. Unfortunately we did not complete it. We must work on making Furnace test run faster on Windows (Really? OK)!

So much good things to come…

September 30th, 2014

by Ivan St. Ivanov

Java EE 7

The first day of JavaOne conference started with a Tutorial talk, where Arun Gupta decomposed the Java EE 7 soup to nuts. For the most part he was comparing via SWAT analysis the different servers that implement Java EE 7 as well as the IDEs that support it. On the server side, besides the usual suspects Glassfish and WildFly, I was surprised to hear that there is a new kid on the block providing a developer preview version. It comes from a Korean company and its name is JEUS. Unfortunately Arun could not show much of it for various reasons: it does not work on MacOS (so Arun used a VM with Fedora installed), it does not have integration with any IDE and he could not deploy and start even a simple web application. The support that the company provided on its forums was basically by a single person answering by random.

The other two servers are very well known to most of us, but still here are some remarks from the presentation:

  • Glassfish is always on the bleeding edge being the Java EE reference implementation, so it adopts all the new features first
  • It has great command line and also REST interface for monitoring and management and comes bundled with NetBeans
  • Wildfly on the other hand is commercially backed by Red Hat and 99.9% of the code is the same in the commercial version JBoss EAP, which implies very easy migration of the applications written for the free offering
  • It has much more active community around it (with Glassfish having almost none) and very well established contribution processes
  • The clustering in Glassfish is not tested and most probably is not working as expected
  • A threat for both servers is the Tomcat + Spring combination

In the IDE area we all know that IntelliJ IDEA rocks, however unfortunately its Java EE development modules are not free. If you are an open source project developer, teacher or student, you can request a free license though. Although widely used, Eclipse is the hardest of the three IDEs to develop Java EE, that is why Red Hat have created the JBoss Development Tools bundle, which eases Eclipse development and also provides support for the various JBoss projects. NetBeans has very pleasant experience out of the box, great Maven support and comes bundled with Glassfish and WildFly.

Besides that, Arun showed how easy it is to develop with JBoss Forge (tell me about it), how you can setup Arquillian (with Maven archetype and with Forge) and how you can create an account and deploy an application on OpenShift (Red Hat’s xPaaS offering).

An interesting use case with OpenShift is to use it as a continuous integration server. You can install a Jenkins cartrage with one click, i.e. a virtual machine bundled with web server running Jenkins, then push your changes to it, which will trigger running the integration tests and if they pass, it can deploy automatically everything on the productive instance. Arun promised that he will provide videos about this process on his blog.

Functional thinking and streams

I went to two talks from Venkat Subramaniam in the afternoon. Their topic was Functional Programming styles in Java. You cannot easily describe Venkat’s talks; you must go and see them!

His first session was on the functional thinking. It touched the topic of pure functions: those that do not modify external state and are not changing because of changes in the external environment. They provide same output when they get the same input and thus have no side effects. Among all the other benefits of the pure functions, there is one that is a little bit more subtle. If we have two such functions that execute in sequence, then the compiler might easily decide to reorder their execution to reduce the CPU cache misses for example. It wouldn’t be a safe operation if those functions had side effects though. The declarative style of programming tells the computer what to do, not how to achieve it. Venkat also touched things like function composition, memoization (the other word for caching), difference between lambdas and closures and laziness in functional programming.

One of the biggest benefits that Java got from the introduction of the lambdas was the streaming API. The stream is such an abstraction over the collection, which we should just tell what we need to do and it knows very well how to do it. It is not a data structure by itself, it’s rather a view on the data as it is being transformed. The basic operations that we can do on streams are:

  • Filtering: with a given input of items, output only those of them that satisfy a certain condition
  • Mapping: return the same number of items that come in, but apply a transformation on each of them
  • Reduction: return a single point (a value or a list) from all the items in the stream. Examples of reductions are finding the sum of all the items in the stream (provided they are numbers), returning the minimum or the maximum item, etc.

Filtering, mapping and other such operations are intermediate – the items are still in the stream. While reduction operations are terminating: the items get out of the abstraction and can be operated again in the usual way. The coolest thing is that the intermediate operations are fused together and the evaluation on the items in the stream happens only when a terminal operation is executed.

Java performance

I went to this session knowing that I have to catch up a lot in the performance area. I was attracted by one of the speakers: Charlie Hunt, whose book I read recently. The talk started by some hints on where to look for performance issues. People tend to look at the processor time, but waiting time is also important – maybe I/O operations need optimizations. Cycles per Instruction and Instructions per Cycle metrics are also good to monitor. If the first one is high, this means that the data structure in use are efficient, while on the other hand, if it is low, then the algorithms used to manipulate those structures are good.

The Java developers are very happy to have the VM as our companion as it does a lot of optimizations for us (no surprise!) and it knows very well the underlying CPU architecture. The compiler has hundreds of intrinsics: decisions on what assembly code to emit based even on the version of the CPU instruction set.

At the end Charlie went on to explain how he broke down a profiling information to find inefficient use of data structures: using TreeMap in applications where items are mostly pushed into the structure, while it is more efficient for rare insertions, as well using arrays as keys and values of a map to minimize the cache misses upon read operations: array elements are laid out in consecutive addresses in memory and memory is always read by the processors in chunks.

Hacking and BOFs

I went to the Hackergarden at noon and worked a little but together with Roberto Cortez on our live coding samples that we want to show on Thursday. The Hackergarden is a great opportunity for everyone visiting a conference to hack something and to contribute to an open source project of their choice. You have most of the project leads here and plenty of books to consult. I wanted to do something like this last year at Java2Days, but it failed as nobody besides the project leads showed up. Today I will go again, this time for Arquillian.

I visited also a couple of Birds of a Feather (BOF) sessions in the evening. First Roberto and Simon Maple from ZeroTurnaround and virtualJUG shared their developer horror stories. The coolest thing here was that half of the session was dedicated to horror stories told by people from the audience. At the end the best one won a signed copy of the Java 8 in Action book.

Last but not least, I went to the Forge BOF, where I finally met in person George Gastaldi – core Forge developer, who helped me so much in my contribution efforts in the last few years. I also got some ideas about our upcoming hands on lab at Devoxx.