JDays Day 2

The following is a summary of what I remember from the sessions I went to the second day of JDays 2015.

1. Where is Java Going Next?

Speaker: Tomas Nilsson, Oracle

Tomas described the release plan of Java 7, what it was it meant to contain and when it should been released "in six months" (said from 2005 and forward). It was meant to contain: Lambdas, Jigsaw, <> boiler plate code reduction, Strings in switches, try-with-resources and much more.

It was released in 2011. What did it contain then? It contained <> boiler plate code reduction, Strings in switches, try-with-resources.

What should Java 8 contain then? The stuff left out of Java 7. What did it contain? Lambdas, new Date framework.

So what will Java 9 contain...? The stuff left out of Java 8. Particularly Jigsaw.

Jigsaw is modularity for Java. Why? Because Java is a monolith which have a quite large memory footprint. With better modularity this footprint can be reduced. Modularity also promotes better security (because one can reduce the number of loaded classes and internal classes can be hidden).

Java 9 will also contain value classes: classes whose objects represent some kind of value. Such objects will not contain any ID (=> they cannot be compared by identity). value class Foo {...}

Summary: Very interesting! Contained much info that can be useful later on when Java 9 is released.

Rating: 4 (good English, good content)

2. Think async: Java EE and Java SE asynchronicity born to work together

Speaker: Masoud Kalali

The talk gave a general overview of asynchronous technologies in the JavaEE sphere. Servlet 3.0, Servlet 3.1, Java

So why should we produce asyncronous code? The speaker presented some valid points:

• The time freed when we don't hang on a synchronous call can be used to perform something useful.
• Asynchronous coding better models real world situations. The speaker exemplified this by saying something like "When ordering a coffee at Starbucks, we don't just stand there with our hand in the air awaiting the cup after paying. We sit down at a table waiting for the Starbucks personnel telling us when the coffee is ready."
• It is easier to tune asynchronous code.

The rest of the session contained a quick walk through of different Java-technologies and short descriptions of the async parts of them. The following technologies were discussed:

• JMS 2.0: delivery delay, messages can be sent asynchronously
• Servlet 3.0 - async servlets: promotes better throughput, @WebServlet(asynchronous=true...), AsyncListener
• Servlet 3.1 - non-blocking IO: Servlet called back when more data is available to read from the client (reader) or when it's OK to send more data to the client (writer).
• JAX-RS 2.0: @Asynchronous, @Suspend
• EJB 3.1: @Asynchronous
• Java EE 8 and SSE (Server Side Events): Java EE does not support SSE out of the box, but that can be added by using a plain servlet. Jersey supports SSE and Java EE 8 will support it as well.

Summary: Very interesting topic. The speaker went through the technologies very quickly however. The presentation would have better suited a twice as long session.

Rating: 3 (OK English, OK content)

3. Supercharging Java EE applications with JCache

Speaker: Steve Millidge

The talk consisted of a live coding exercise in which a small webapplication that performed calls to a very slow REST service was enhanced so that calls to the REST service were cached using JCache. The application server used in the example was Payara which is a fork of the Glassfish application server. The Payara application server is supported by the company of the same name. The webapplication consisted of a small Java EE 7 application.

It was explained that JCache (JSR-107) is a specification of an API. To be able to use caching via JCache in ones application, one have use a proper implementation. Out of the box Payara uses Hazelcast, which is an open source implementation of the JCache API.

It turned out that is was suprisingly simple to add caching of the REST requests to the example webapplication. An addition of the @CacheResult annotation to the method performing the REST request was all there took. To also get updates to work, an addition of the @CachePut to the method performing the updating REST requests was needed.

The annotations in Java EE 7 related to JCache are: @CacheResult, @CachePut, @CacheRemove and @CacheRemoveAll.

Summary: It was really an eye opener to see how easy it was to add caching to the REST requests. Really good presentation if one is into Java EE 7 development. Of one is not doing Java EE 7 development, one gets rather interested in starting doing it after having seen this presentation...

Rating: 4 (Perfect English, good content)

4. JCache is here. Say goodbye to propriatary caching API:s

Speaker: Jaromir Hamala

This session was a sister session to the session described above. Like in the previous session, an exising demo application was altered to include caching using JCache. In this session, however, no annotations were used. Instead the caching stuff was performed by actual API calls.

The session started with a general overview of what JCache (JSR-107) is and what it is not. As I wrote before, JCache is just an API. The actual implementations are made by third party vendors. The speaker made the analogy with JMS, an analogy I think which is most appropriate.

Currently there are four implementations of the JCache API:

• Hazelcast
• EHCache
• Infinispan
• Coherence

The speaker then explained the main classes of JCache:

• CacheProvider - manages the life cycle of CacheManager:s.
• CacheManager - Factory for caches.
• Cache - the actual cache.

Next the speaker described a feature of JCache that he thought was really useful: entry processors. They provide a way of specifying a piece of code that can be run inside the cache. Why would someone want to do that? The example given was that it was desired to add an amount to an integer kept in the cache. The regular way of doing this would be to retrieve the integer with one API call, add the desired amount to it and writing the new value back to the cache. In a multi-threaded environment, this is not a good approach however, as the program can be interrupted beteen the retrival of the value and the update of the cache. If one is unlucky, another thread may want to perform a similar operation at the same time, and a race condition will result.

Usage of an entry processor avoids these kinds of race conditions. The idea is to define an entry processor that does both the fetching of the value, the addition and the update of the cache. As the entry processor code executes atomically, no race condition will occur. Pseudocode:

EntryProcessor<...> entryProcessor = (entry, args) -> 
{
 // Read value from cache.
 // Calculate new value by adding amountToAdd == args[0].
 // Write new value to cache.
};

int idOfItemToUpdate = ...;
cache.invoke(idOfItemToUpdate, entryProcessor, amountToAdd);

Another JCache concept (which also is present in other cache implementations) is the concept of cache loaders. By using a cache loader, one can prepopulate a cache with values for example retrieved from a database. The cache loader functionality in JCache is located in the (appropriately named) CacheLoader class.

Analogously, if one wants to writes updates to the cache to another place (e.g. a database), the CacheWriter can be used.

Next the author described how JCache could be utilized in a Spring environment. It seemed pretty similar to how it is used in Java EE 7.

Some advice was given at the end of the session:

• If CachingProvider.getCachingProvider() works only if there are exactly one caching provider on the classpath.
• Entries are stored by value, not by reference. This means that if something is added to the cache and that something is updated at a later point outside the cache, the update will not be visible in the cache entry.

As closing words, the speaker said something on what he thought was missing from the JCache specification:

• Eviction (present in the different implementations, but not in the API).
• Async functionality.
• Query functionality. Cache entries can now only be fetched by ID.

Summary: Fact-filled session containg lots of interesting materials. Really good tutorial on how to program to the JCache API.

Rating: 4 (OK English, excellent content)

5. The life of a Java method inside the HotSpot JVM

Speaker: Rickard Bäckman

In the beginning of the session, the speaker explained that the JVM is a Managed Runtime, i.e. it is the glue between the application and the operating system. This has the advantage that it can monitor the application and optimize its execution in runtime.

The talk focused mostly on which parts the HotSpot compiler consists of and how HotSpot decides which part that should be used to interpret or compile a java program and when. It turns out that the HotSpot compiler contains an interpreter and (at least) two compilers: C1 - the client compiler and C2 - the server compiler. The decision of when to use C1, C2 or neither of them (and thus continue to execute the code interpreted) is made by the interpreter which collects profiling information.

The interpreter is always used the first time a piece of code is to be executed.

The C1 compiler compiles fast and have a low memory footprint. It makes some optimizations and is primarily used for programs for which a quick start up is important.

The C2 compiler is used for long running programs where the actual start up time of the program is not that important. It compiles more slowly than C1 and have a larger memory footprint, but produces more optimized code.

The interpreter can after having collected some profiling information decide to compile a piece of code using the C1 or C2 compilier. The compilers can also decide to switch among one another. Perhaps more suprisingly, the compilers can decide to deoptimize a piece of code by throwing away the compiled version and thus indicating that the interpreter should be used the next time it should be executed.

Summary: interesting, but probably not very useful in the daily work.

Rating: 3 (OK English, OK content)

6. Accelerated ORM and SQL reflection: how they work with Java 8

Speaker: Per-Åke Minborg

The speaker is the creator an ORM product called Speedment and the head of a startup company of the same name.

What the Speedment product ORM does differently is that it tries to keep all the data of the underlying database in (JVM) memory. How does it do that then? It turns out that several strategies can be used to handle this. These among others:

• JVM memory can be greater than the physical memory (I guess this means usage of virtual memory...)
• Compression
• Usage of a cloud based Hazelcast solution.
• Deduplication
• Lazy loading
• Layered storage engines: on-heap, off-heap, SSD, disk, SQL

Speedment provides a Java 8-like API for insertion and queries. By the looks of it, the API seems really nice! Configuration is done in Groovy.

What's the downsides then? Well, Speedment is eventually consistent (as many NoSQL-databases), i.e. the C in ACID is not supported at all times.

Quotation: We want to put the Java developer behind the steering wheel.

Some light relief: the speaker illustrates the difference between an in-JVM-memory database and a in-cache-on-DB-server resp. a not-in-memory-at-all-DB by running to the wall of the meeting room and comparing that with running from Göteborg to Borås. In the not-in-memory-at-all-DB case the runner also has to wait in Borås for three days. This was an illuminating illustration!

Summary: Interesting!

Rating: 4 (good English, good content)

Summary of Day 2

The second day provided an interesting keynote in which some stuff that (hopefully...) will be present in Java 9 was presented. The highlight for me, however, was the JCache presentations that I thought was really enlightening. This, however, might have to do that I have implemented a cache in the system I am working with using JBossCache, which is the default caching product in the version of JBoss that we currently use, and that I really would like to switch to something better.

The other sessions that I went to was of course also interesting. It was kind of weird hearing about Speedment an ORM that keeps all its data in memory.

All speakers presented their talks with a fair amount of humor which is a good thing I think.

Just like yesterday, for every row in the schedule matrix, I really wanted to go to at least two of the simultaneous talks and had to pick the one I thought would be the most interesting. It was only the talks on JavaScript that did not really interest me. Most of the times I think I chose the right session to go to. Of course, one can never be certain of course, and I am looking forward to view the recorded videos of the sessions I missed.

Summary: Equally nice day as the first! Focus was JCache.

Summary of JDays

I'm really pleased with having attended the JDays conference. The sessions I went to was all interesting (some more than others, of course) and I had a wide variety of sessions to choose from. Really nice!

If I have to choose one thing as the singular best thing, I have to choose the Docker workshop. It gave me the tools to kickstart my (hobbyist) work with Docker.

During the conference, I wrote down things I'd like to play around with and stuff that I ought to read. These are the things that I noted:

• Create a Docker container containing a webbserver running my blog application. Connect it to a Docker container running a MongoDB.
• Reverse engineer an APK.
• Check out Google Play Services
• Create and deploy an OSGi thingy.
• Play around with Java EE 7. Perhaps on Payara.
• Check out Liferay.
• Test the new Date API in Java 8.
• Try jdeps.
• Study up on Java 9, particularly project Jigsaw and value classes.
• Try Springboot
• Play around with JCache. Perhaps using Payara and Hazelcast.
• Check out Websockets and ServerSentEvents from HTML 5.
• Read the Microservices article written by Martin Fowler.
• Read the Microservices and Jars article written by Uncle Bob Martin.

Puh! That was quite a long list! Luckily I've almost a full year to go through all the items in the list...

Looking forward to attending JDays 2016! ;)