JDays Day 0 - Docker Workshop

JDays

I've had the opportunity to attend JDays 2015. Both the regular conference but also one of the workshops that was held in conjunction with the conference. To help me remember what I've learned and what cool new suff I came in contact with at the conference, I've decided to write a short blog entry about the talks I attended each day. Let's start with day 0...

JDays Day 0 - Docker Workshop

As a prequel to the regular JDays conference I attended a one day workshop on Docker. It was held by Fredric Wendt from Growing Agility and Marcus Lönnberg from SpeedLedger. The aim of the workshop was to learn the basics of what Docker is, how it can be used to to deploy various servers/services and to practice doing just that.

The teacher had prepared a Vagrant box that we, the pupils, were required to download the day before the workshop started. On the Vagrant box, Docker and some other useful software were installed. This was a really good thing as it enabled us to start working on Docker-related things directly from the start of the workshop without wasting unecessary time on downloading and installing stuff. Another upside was that the common Vagrant box made the environments of all the attendantees equal, which made debugging of the exercises easier (equal environments for many is by the way on of the main benefits of Docker).

The actual workshop as split into lecturing sessions and practical exercises. Each (lecturing session, exercise) pair started with the teachers giving a short introduction to a specific Docker-related topic for about five to ten minutes. Then the attendees got the chance to try out the things descripted in a practical exercise, which most of the time took about twenty to thirty minutes. The teachers were available for helping out with problems or questions all of the time.

This way of working worked out very well I think. Me and my fellow workshoppers were on approximately the same level and held more or less the same pace when working with the exercises, which minimized the waiting times (which I, as the impatient person I am, appreciates ;)

The following topics were covered:

• Introcudion to Docker
• Images
• Containers
• Dockerfiles
• Tagging
• The registry
• Volumes
• Linking
• Datacontainers
• Docker compose

I think that that the pick of topics and the order they were presented was an obvious and good one. I did not feel as I missed something from the topic list.

My overall impression of the workshop is that it was really good. The course materials was fairly good, altough it contained some bugs and/or unclear stuff. The range of topics covered was excellent and I feel that I after the workshop have a quite good overall knowledge of what Docker is and how it can be used to create various execution environments.

I'm planning to play around a bit with Docker as I think it is a really nice and interesting piece of technology. One idea I have is to create one Docker container containing a MongoDB server and connect it to another Docker container having this blog running in either the Django development server (as a start) or Nginx (later on). This was I can play around with different versions of MongoDB and different webservers without having to be afraid of breaking something. This sounds really interesting and I hope I get around to doing it.

Links to Docker related sites

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! ;)

JDays Day 1

About JDays

JDays is a two-day conference held in Göteborg annually since 2012 (I think). It is primarily focused on Java and related technologies. Some language agnostic sessions are also held. This year the conference was held at the Clarion Post Hotel, which I must say had really nice facilities.

The conference was split up into distinct 45 minutes sessions separated by coffee or lunch breaks. Two or three parallel sessions were held simultaneously, so one always had to prioritize which session to attend.

The following text is a summary of what I remember from the sessions that I went to. In the end, there is a summary of the first day.

1. The Future of Programming

Speaker: Ola Bini, Thoughtworks

The keynote given by Ola Bini touched on a wide range of objects. From programming language philosophies to information security and programmer location. Its main focus, however, was to predict how programming would be done in the future. The speaker talked about some of the things he thinks will form the programmer profession in the future. He gave a lot of examples. Some of these were:

• Polyglot programming - using more than one language in the development of a product.
• The continued usage of Java (yeah! ;)
• The importance of resisting government insistence of building in back doors into the products.

Overall, I think that it was an interesting talk from an interesting person. Ola mixed in a joke or two here and there, and the talk touched (briefly) on many different topics. On the downside, I think that the material presented would better have suited a longer session. Perhaps 50% longer or something like that.

Quotation: "Java is the new Cobol."

Summary: Interesting talk touching on many topics. Not much code was shown.

Rating: 4 (Very good English, good content)

2. Testing your Android app

Speaker: Filip Maelbrancke

As I am an hobbyist Android programmer I thought I should attend at least one of the two Android related sessions so I went to the one that appeared first on the schedule. The topic of the session was how one could test ones Android app in various way. Normally testing is not one of my favourite topics, but I must say that I liked this session. It gave an overview of different frameworks that can be used to test an Android app. Both unit test and other types of test was covered.

Some of the tools that were mentioned in the talk were these:

• AndroidJUnitRunner
• Intento
• Espresso - Build on the Hamcrest framework. Includes support for finding views and asserting different conditions.
• Roboelectric - Contains shadow classes of the abstract types in android.jar. Somewhat obsolote now Google has released new test related stuff.
• Monky - generates events among other things. Can be used for stress testing an app. Part of the adb shell.
• AssertJAndroid - includes various assertion mechanisms supporting better error messages.
• Retrofit - for mocking networks.
• MockWebserver
• Spoon - for taking screenshots. Can be used in a CI environment.

The speaker also talked about design patterns that can be used in Android development. Dependency Injection and Model-View-Presenter were mentioned.

Summary: Interesting session mostly describing frameworks and tools that can help you test an Android app in various ways.

Rating: 3 (OK English, OK content)

3. Be a better developer with Docker

Speaker: Niccola Paolucci

As I attended the Docker workshop the previous day, I went to this session to get a repetition of the stuff from yesterday and maybe pick up a new nice trick or two. And that was mainly what I've got.

The session was not primarily targeted at total Docker newbies. The speaker very quickly described his view of what docker is, but that explanation was so brief that if you hadn't played around with Docker before, I think most of the stuff presented was incomprehensible. Luckily, I remembered most of the things that I learned yesterday so I understood most of the things the speaker spoke about.

Niccola presented some advantages of Docker:

• You can try different versions of your tools.
• Security: a program cannot break out of the container.
• There exists a multitude of Docker images (20000+) that can be downloaded and used.

Some tips and tricks that I picked up during the session:

• Use the -v parameter to the Docker command or the VOLUME to share directories between the host and the container.
• Data only containers are nice to have as a data storage.
• The --link parameter to the Docker command updates /etc/hosts
• To promote reusability, put the dynamic commands (the ones most likely to differ between images) in the bottom of the Dockerfile.
• To decrease the size of the images, one can let it be based on Debian instead of on Ubuntu.
• Due to the fact that a new image is created and stored after each line in the Dockerfile, it is advantageous to combine several commands on the same line. E.g. if the Dockerfile contains several apt-get commands, these could be combined to be on the same separated by the and operator &&.
• The space occupied by the images can be inspected using the docker image image-name command.
• To recursively list the containers the container is based on, the docker image --tree command could be used.
• An container could be flattened by exporting and reimporting it.

Finally the speaker talked a little bit about some tools that can be used in conjunction with Docker:

• Docker machine: create Docker containers on for example load supervisors and in the cloud.
• Docker swarm: controls a cluster of docker containers.
• Docker compose: build multi-container applications in a simple way.

Summary: Lots of ticks and tricks for using Docker. Basic knowledge of Docker required.

Rating: 3 (OK English, OK content)

4. The performace-model of streams

Speaker: Angelika Langer

Angelika spoke about how the performance of the new streams compare to that of old school for-loops. In summary, streams:s often executes more slowly if only primitives are involved. If proper objects are used, the difference is less. If the computations could be parallelized, streams:s could perform better that old-fashioned loops.

Summary: Interesting talk about the performance of streams compared to regular for-loops.

Rating: 4 (good English, good content)

5. Android security for developers

Speaker: Filip Maelbrancke

As I went to Filip's first talk earlier on the day and I liked it, I thought I would go to his next one, which should cover Android security, as well. I was not disappointed.

Filip started by saying that he had this definition of security: security == managing risk.

The Android security model is based on these three pillars:

• App signature verification.
• Two levels of sandboxes.
• Enforcing permissions.

The speaker then went on to describe a wide range of tools that can be helpful for when working with security on Android.

• arktool: A reverse engineering tool.
• dex2jar: Translates from dex to java
• jadx: Program for opening up an apk-file and listing its contents. Does have a GUI.
• proguard: Program for obfuscating, shrinking, and optimizing Android code. Included in the Android SDK.
• dexguard: Similar to proguard

Some useful techniques to discover if your app has been tampered with:

• In runtime, check where the app is installed.
• In runtime, check where the app is originating from.
• Check that the debug flag is off.
• Save a hash of the debug certification in code. In runtime, calculate hash and check that it matches the saved on.
• Check if the device has been rooted.

How to protect in app data (in descending order):

• Do not save data locally.
• Set android:allowBackup to false.
• Save on external server instead of locally.
• Avoid screenshots.
• Log out if the app has been inactive for a certain amount of time.
• Draw a keyboard and use that for input instead of using the default one.

Cryptography related libs:

• Bouncycastle: bundled with Android
• Spongycastle: repackage of Bouncycastle especially for Android.
• GPS (Google Play Services) Dynamic Security Provider
• SQLCipher

Key management: either ask the server for the cert or store in the Android system area.

Keystore provider: Android Keystore, since 4.3, can be hardware backed.

Nogotofail: tool for testing network stuff.

Many good books on Android security (compared to Andoid testing)! E.g. Android Hacker's handbook.

Summary: Really interesting and useful talk about Android security and what tools that exist to help hardening and testing an app.

Rating: 4 (OK English, good content)

6. Java EE vs Spring smackdown

Speaker: Murat Yener/Mert Caliskan

Murat and Mert have written one book each on either Java EE or Spring, so they know a lot about the subject of the session.

The session was set up to be a match between Java EE and Spring to decide which technology is the better one.

The session started with a short description of the different features of Java EE and Spring. The comparison showed that the functionality of the two technologies are rather similar in scope.

Most of the rest of the session was a comparison between two programs constructed to have the same functionality but one written using Java EE and the other using Spring.

One difference that struck me was how much more XML configuration that was needed in the spring version compared to the Java EE version. Otherwise I think the two versions were quite similar.

The smackdown ended in a draw. The conclusion was that the technologies were similar in scope and that they supported roughly the same annotations, but the names of the annotations differed a bit.

It was fairly interesting to witness the Java EE vs Spring smackdown. The authors were humorous and clearly knew their subject very well. The quality of the spoken language was, unfortunately, not perfect, which made the presentation hard to follow from time to time.

Summary: Interesting comparison between Java EE and Spring. Good to know that they are similar in scope. Will be nice to get the slides of the presentation, which will be useful as a translation guide between the annotations of the two technologies.

Rating: 3 (Fairly OK English, OK content)

7. Microservices and modularity or the difference between treatment and cure

Speaker: Milen Dyankov

The session consisted of two parts: first a general discussion about what a microservice is and pros and cons of a microservice compared to a monolith, then a live refactoring of an application from a monolithic architecture, via a "standard" microservice architecture to an OSGi microservice architecture.

If the need for a microservice architecture is not obvious and overwhelming, the speaker recommended starting with a monolithic architecture, but where the monolith is divided into modules which, if the need arises, can be refactored to microservices later on.

The speaker recommened two articles on microservices: Microservices by Martin Fowler and James Lewis and Microservices and Jars by Uncle Bob Martin.

The live coding session took as starting point an example from the Java EE Tutorial of Oracle's. The example program was first modified so that a business logic component was added. As that component did not need/should not have to know about persistency details of the entity model, a separate hierarchy of DTO:s duplicating the entity model was created. When that had been done, the business component could then, quite easily, be refactored out to be a microservice. The speaker then proceeded to refactor the component so that it became OSGi compliant. This step did not seem to be particularly hard to perform either, which was kind of nice to see.

As I haven't been into the microservice world very much, it was interesting to get a short introduction to microservices in general. The live coding session was also interesting, but it is often hard to follow (and even more difficult to remember) all the steps as they often are executed quite rapidly. The main take away from the live coding session was therefore: it does not seem very hard so it should be possible to perform the steps at home. Given a sufficient amount of time...

Summary: Interesting talk and live coding session about microservices. Some materials on OSGi as a bonus.

Rating: 4 (good English, good content)

Summary of Day 1

The first day of JDays was filled with interesting talks. It's a pity that one can only be in one place at any given time. Often I would have liked to attend two or all three of the sessions. I prioritized going to the sessions covering Android and Docker, and this I don't regret. The sessions on microservices and Docker was probably the most useful from a job perspective. The session on the performance of streams was very interesting, but maybe not that useful. I think that if you have the oppertunity to use streams (i.e. if you use Java 8), then you should do it because streams offer a cleaner and more expressive syntax. It does not matter if it is a little bit slower than using old-fashioned for-loops, the more expressive syntax more than makes up for that.

Summary: Really nice first day! Focus was Android and enterprise Java.