Now that I am a little rested from three frantic days in Antwerpen, I’ll start to structure my notes and write summaries about presentations I attended at Devoxx 2012.
Once again a big thanks to Stephan Jansens and his team. You rocks!
Now that I am a little rested from three frantic days in Antwerpen, I’ll start to structure my notes and write summaries about presentations I attended at Devoxx 2012.
Once again a big thanks to Stephan Jansens and his team. You rocks!
This is my summary of a BruJUG conference given bar Uberto Barbini about “How to boost your object-oriented programming with functional programming”.
This is maybe the first time I disliked a conference this year. Everything that Uberto said is true and relevant to the subject. But having read the title and the introduction, I expected something more practical on how to include functional programming concepts in my daily object-oriented experience. Instead of that, I got a strong advice to study functional programming and some good best practices about immutable objects and avoiding side-effects.
Anyway, I’ll write what I remember of that presentation, at least because talking in front of specialists is an uneasy exercise that deserves some attention and respect.
Let’s start with two interesting questions:
Even if those questions may seem awkward at first sight, it is worth thinking about it and go beyond the standard answers that were hammered inside our heads while we were learning programming.
Bugs are inevitable at some point of our development. They cause frustration and delays. Many are easy to fix ans some can cause big troubles. A good code is thus not a code without bugs but rather a code where bugs are easy to find and to fix.
From the presenter point of view, worst bugs are often related to the state. I totally agree with that. So one solution is to defend your state like a castle so that state effects are limited to the object.
But even these days, even if we say or even sometimes think, we are still writing a lot of procedural code that is, code that describe a story like “do this, then do that, if the result is like this, do this other action” and so on. Take a look in a presentation layer based on Struts and chances are you’ll see what I mean.
Some framework seem to induce procedural paradigm which:
Lisp is one of the first language to implement the functional paradigm and was published in the early 1960’s. In the early 1970’s, Smalltalk introduces the object-oriented paradigm.
But what is object-oriented programming?
The idea of messaging if very present in Smalltalk itself.
A big problem is that a lot of programmers think they do good object-oriented programming because they use a lot of interfaces and design patterns.
To get some good advice about how to design an object-oriented application, one can read “Domain-Driven Design“, the Eric Evan’s famous book. One of this book concepts is to put emphasis on immutable value objects and avoiding side effects. Those practices makes object-oriented and functional paradigms not far from each other.
Rebecca Wirfs-Brock classify software architecture into 3 different designs according to the way they locate data and behavior:
This is like procedural paradigm: one class controls the behavior and other classes provide the data.
This is also what Martin Fowler calls an anemic domain.
Despite from that, this kind of design has the advantage that all the logic is concentrated in one place. You don’t have to look everywhere to understand how a process is carried on.
Here the logic is spread across every objects. Each one does something very short and with as few dependencies as possible.
The drawback is that to have the complete point on something, you must navigate all the participating classes.
This kind of design is a compromise between the first two. The logic is spread into some classes that controls the behavior in collaboration with other small classes. They are thus pools of responsibility that can be used in relative isolation.
Learning new paradigms is interesting because it often leads you to a better understanding of the ones you use daily.
Functional paradigm has some very good best practices to include in your daily object-oriented programming like avoiding side-effects and using immutable objects as often as you can.
But besides those good pieces of advice, I must admit that this conference didn’t meet my expectations.
Anyway, the section below has very good books to read. Especially, don’t hesitate to order your own copy of domain-driven design which is a book I really appreciated.
The two presenters were Bert Ertman and Paul Bakker, both working for Luminis, Bert being an official Oracle Java Champion.
They began their talk by stating the following two trends:
Those trends bring new challenges along with them:
As applications are moving to the cloud, other non functional requirements enter the game too:
Modularity is the answer to those issues.
Every decent programmer must probably remember this from his classes: a good design has loose coupling but high cohesion.
Coupling is prevented through the use of interfaces and by hiding the actual implementations. Each module has its public and private parts and other modules cannot “touch its private parts”.
But then comes the issue of instantiating the actual classes. A popular way to solve that problem is to use dependency injection. But you can also do it with some kind of service registry which you can ask to provide you with an implementation of type X. Each module notifies the registry about the interfaces he provides implementations for and which interfaces he consumes. That service registry can manage multiple versions of interfaces and choos the best match.
With a little help of design-time modularity, we can thus tame the spaghetti syndrome of the most complex application.
When we analyse the same issues from the runtime view, the JAR file becomes THE unit. So how do we deal with module versioning and intra-module dependency management? How can we replace just 1 module at runtime?
The first part of the answer is: put the architectural focus on modularity! If you don’t group coherent functionality together, there’s no point using the second part of the answer. So that second part is: use a modular framework like OSGi (Jigsaw can be seen as an alternative to OSGi but is far less mature). But keep in mind that a modular framework is no guarantee, the key is a modular architecture.
JavaEE is high level. OSGi is low level and provides no enterprise services (transactions, security, remote access, persistence, …) on its own. So you’re left with 3 options:
The first option involves application servers that publish their services as OSGi modules. Glassfish does that. There is now a concept of WAB (Web Application Bundle) files that are WAR files whose servlets are deployed as OSGi resources. A similar system exist for EJB bundles but there is no standard yet.
The second option can be implemented with Weld as CDI container to provide CDI inside the bundle and consume and produce OSGi services.
I’ll complete the description of the third option when I get access to the Parleys’ video (sorry, I ran out of ink at that moment and writing this article 2 weeks after the conference doesn’t help either).
The main concern here is that a modular application may involve hundreds of bundles. But hopefully, something like Apache ACE platform can help you manage this and gives you the option to redeploy 1 module at a time.
I won’t go into the details of the demo. The easiest is to wait the Parleys’ video as this will be far more interesting than me trying to write what I’ve seen.
Here is another article on a BeJUG conference. This time, Sander Mak, software developer and architect at Info Support, The Netherlands, gave us an overview of two concurrency frameworks: Fork/Join and Akka.
Fork/Join is a framework that was added to the standard libraries starting with JDK 7. Akka is an open-source alternative with emphasis on the resilience of concurrent process.
The CPU speed has been growing up these last years until reaching some kind of a technical limit at around 3,5 GHz. Right now, a CPU is mainly idling while waiting for its I/O. That’s why the new trend is to have multiple CPUs.
But as Sander quote: “the number of idle cores in my machine doubles every two years”. There is an architectural mismatch because developers use to believe that the compiler and/or the JVM can handle parallelism on their own. But unfortunately, this isn’t true.
The first demos are declined around the computation of Fibonacci’s suite whose definition is
Of course, the objective here is not to find an optimal solution to that problem (transforming the recursive definition into an iterative form) but just apply a concurrent computation of the recursive form.
Join/Fork works with an auto-sized thread pool. Each worker thread is assigned a task queue which gets fed by the fork method calls. The interesting behavior is that a worker is allowed to steal work from the task queue of another worker.
Another, more advanced, demo was also perform, demonstrating how to make a dichotomic search on a large set of cities to find which one are within a certain distance from a point. Of course, the algorithm is implemented with Fork/Join.
All the code of those examples is available on http://bit.ly/bejug-fj.
The algorithm must be acyclic (no thread can work with another thread that is already present in its call stack) and CPU-bound. I/O-bound problems wait a lot on blocking system calls and thus prevent those threads to perform other tasks.
To avoid that the overhead consumes all the computation time, you must set a threshold to decide whether the problem should be solved sequentially or in parallel. This leads to define work chunks that are processed in parallel but each steps inside the same chunk are processed sequentially.
Some algorithm implementations allows to reuse the current thread to do come computation instead of forking a new task, thus limiting the overhead.
There exist convenience methods :
invoke()is semantically equivalent to
fork(); join()but always attempts to begin execution in the current thread.
invokeAllperforms the most common form of parallel invocation: forking a set of tasks and joining them all.
Fork/Join creates threads. It is thus currently forbidden in the EJB spec. When it comes to CDI or servlet specs, we are there navigating in some kind of grey zone. Maybe this could work with JCA work manager. @asynchronous could be used as an alternative.
Anyway, it is foreseen that JavaEE 7 spec may contain java.util.concurrent package.
Compared with Fork/Join, the more classic ExecutorService doesn’t allow work stealing. It is better suited at coarse-grained independent tasks. Bounded thread pools supports blocking I/O better.
MapReduce implementations they are targeted at cluster and not single JVM. While Fork/Join is targeted at recursive working, MapReduce is often working on a single map. Furthermore, MapReduce has no inter-node communication and thus doesn’t allow work stealing.
The popular critics about Fork/Join are:
With the availability of JDK8, the Fork/Join API could be extended with methods on collections working with lambdas. There is also a CountedCompleter ForkJoinTask implementation that is better at working with I/O-based tasks and that is currently contained in JSR-166-extra).
Akka is a concurrency framework written in Scala that offers a Java API. I wouldn’t introduce Akka better than their author so here is what they say about it:
We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it’s because we are using the wrong tools and the wrong level of abstraction. Akka is here to change that. Using the Actor Model we raise the abstraction level and provide a better platform to build correct concurrent and scalable applications. For fault-tolerance we adopt the “Let it crash” model which have been used with great success in the telecom industry to build applications that self-heals, systems that never stop. Actors also provides the abstraction for transparent distribution and the basis for truly scalable and fault-tolerant applications.
An actor is an object with a local state, a local behavior and a mailbox to receive messages sent to it. An actor processes only one message at a time. And as they are lightweight (around 400 bytes of memory per actor), you can instantiate many of them in a standard JVM heap.
The receive method of an actor is called when a message processeing begins and it is where all the processing is done. The framework itself is responsible for the actor management (thread pooling, dispatching, …).
Using a ForkJoinPool with Akka scales very well.
A demo of Akka usage is available on http://bit.ly/bejug-akka.
Refactoring and restructuring are both terms that imply non-functional changes.
Refactoring means changing the code to make it more readable. This also means invasive code editing. It usually involves only a few classes.
Restructuring means reorganizing the code-base without change to the code to improve the modularity and make the code-base easier to understand. This involves minimally invasive code editing but the scope is the whole code-base.
The code-base structure has 3 aspects:
The two code-base quality factors to consider here are complexity and modularity.
Because a better code-base makes your code more understandable. And understandable code is cheaper to maintain and evolve. Changes have a more predictable impact on the code. And, of course, your code-base have a better testability, reusability. At the end, your code has a better value.
Complexity can be measured by different means. Two of them are fatness and tangles and can be used to measure complexity.
Fatness is when you have too much code in one place (number of method in a class, number of class in a package, number of package nested under the same package or in the same component, …).
Tangles occur when some code in a package reference code in another package which itself references code in the first package (cyclic dependencies).
Both fatness and tangles can be approximated by automatically by metrics which make them good candidate for automatic checking using thresholds (e.g. in your build system).
This diagram shows the link between tangles and fatness. This means that you can eliminate all tangles pretty easily by moving everything to the same place. But then you get 100% fatness. To the contrary, you can eliminate fatness by partitioning your code-base. But then you create tangles. What you seek is a compromise between the two. What you really don’t want is a code-base that is both fat and full of tangles.
Modularity is best-defined by the mantra “high cohesion, low coupling“.
Modularity can show itself by multiple means. One of them is well-defined public interfaces while the remaining internals are kept private. Another one is when your packages have a clear responsibility.
Unfortunately, the best way to assess modularity of the code is to make it checked by a human software architect.
Usually, the methods and classes are OK. But there is almost no logical organisation of classes into higher level modules (= packages in Java). Packages are too often used more like a filesystem and not as an embodiment of module hierarchy.
What you need to have a good code-base structure is to understand neatly the following aspects:
Once you understand all of this correctly, you can define and achieve your architectural target.
There are a lot of strategies you can use. Here are some chosen one.
If you have parallel structure (one for presentation, one for services, one for persistence, one for extranet, one for intranet, etc.), you’d better merge them to minimize the dependencies between packages.
You often find yourself with one or a few large classes tangles spanning many packages. Fixing these will improve your code-base rapidly.
This is a least invasive refactoring you can do to improve your complexity and modularity. Moreover, this requires low effort.
Both are valid but have different impacts.
Top-down approach keeps as much of the existing package hierarchy as possible. This means that the “psychological” impact on the application team will be minimized.
Bottom-up approach uses to end far away from the current structure but is often easiest to achieve.
A structure without tangles is way easier to manipulate.
That your code-base is a mess regarding modularity matters is common.
Lack of structure costs money.
That lack can be salvaged.
Restructuring your code-base is not easy but huge returns can happen.
Here ends the “theoretical part” of the presentation and begin the examples, illustrated by the ReStructure101 software which helps the architect to visualize the current structure of his code-base and allows to simulate structure changes and their impacts.
That tool philosophy is to create a task list reflecting the changes done rather than changing the code-base directly. After a restructuring session, the architects ends up with that task list that he can perform himself or plan to be executed by other developers.
Plugins allows to use that task list easily inside IDE like Eclipse or IntelliJ.
I’d say I love this philosophy because it gives you the feeling you’re always in control and that you are not only executing a drag’n’drop session in a GUI but really modifying your code-base deeply.
Thanks BruJUG for this enlightening conference.
See you next time.
The presentation started with a quick history of Java. How it started as a desktop application programming language. How that rich client facet of Java almost disappeared completely behind the Java EE web application years ago for economic reasons. And then how it may come back in a near future with frameworks like JavaFX 2.
But what is JavaFX 2? JavaFX 2 is “a modern Java environment designed to provide a lightweight, hardware-accelerated UI platform that meets tomorrow’s needs”. In this assertion, every word is important. And if JavaFX 2 may address tomorrow’s needs, today, it is still a work in progress. Only the Windows platform has attained the General Availability stage. Mac OS X implementation should get out of the dark in the next months and you can download a quite useable Linux implementation from OpenJDK sources. But unfortunately, iOS and Android implementations of JavaFX are not yet available. This is really unfortunate.
It is foreseen that JavaFX will replace Swing and AWT as a standard graphic library starting with Java 8. But that won’t happen before Java FX becomes JavaFX 3.
So, pragmatically speaking, JavaFX 2 must be considered as experimental at the moment (and that’s also what the demo done during the second part of the presentation confirms). It is the advice of the first presenter too : “wait until Java 8 and JavaFX 3 before reaching production with a JavaFX application”.
There are 2 APIs to JavaFX 2: the FXML API which is a declarative XML interface; the second API is a Java API similar to the Swing interface.
A big difference from the former Swing API is the ability to render HTML content through the use of the WebView component. This makes it possible to enrich a classical web application with behaviours (such as Near Field Communication or eID reader integration) that are only possible in a rich client.
The first part of the presentation is ended by a Hello World demo which looked to me a lot like the tutorials I’ve made with Swing. At least, JavaFX looks more polished than its predecessor and simple things seem simple to program.
The real-world demo features healthcare software to manage patient’s dossier and made by the HealthConnect firm.
A lot of CSS was used to style UI controls. The CSS properties are proprietary to JavaFX (they all begin with -fx- …) but look similar to HTML properties.
The accent is put on the calendar and dropup (with auto-complete) controls developed and heavily customized by HealthConnect.
It is also put on the observer pattern which allows binding a UI control to a model property. Once done, every change on one of the UI or the model is reflected instantly on the other. Unfortunately, to achieve this, JavaFX 2 has created its own JavaBean-like API with, for example, SimpleObjectProperty and ObservableList.
There also exists a Task API to ease concurrency management while running service callbacks only in the main UI thread.
Here are the various lessons learned from the development of the application:
Here are now some resources mentioned during the presentation:
I hope you enjoyed this third article. See you soon for the next one.
So here is my second post. This time, I cheated a little. As I was sick at the conference time, I had to catch up with the recording of the presentation that BeJUG team put on parleys.com. Big thanks to them!
So, what is PlayFramework?
PlayFramework is a web framework. It features Java and Scala as programming languages for both controllers and page template. As you’ve probably already figured out from the terms I used, this framework is more action-based than component-based.
With the framework comes a philosophy.
First, everything is put in place so that the developper can keep focused on what he’s doing. Meaning that you can use only a text editor (or an IDE if you prefer) and a browser once the PlayFramework server has been launched. Every feedback the framework gives you (and it gives you plenty of feedback) appears in the browser. And every change you make in the code is reflected immediately in the browser.
Second, the framework uses a compiler to validate all your files (even page templates and configuration files). If there is a syntax error in your Scala or Java file, a compilation error is displayed in the browser with an indication of the error and the line it occured. This is kind of standard behaviour. Nothing special about it. When it becomes really cool is when you get the same type of error for your template pages with indications relative to the original file (and not the generated class). So here we get to something similar to what we can get with a JSP interpreter. That’s cool. What is really cool is that we even get the same feedback detail level for configuration files. That rocks!
Third, the framework tries to not fight the HTTP protocol. That means that it doesn’t hide the inner bits of the protocol. Quite the contrary. You will thus find methods to ease the usage of HTTP response codes, the usage of cookies, …
From the given demo, it really seems to be a framework easy to use and easy to learn. And as it doesn’t try to hide technical details of the HTTP protocol and the browser rendering, I have good hope that everything you know about web development is directly useable with this framework. Good point thus for a framework that lessens the amount of plumbing needed to get started and still succeeds to not get into the way.
After that first impressive demo, came a description of the Enumerator – Iteratee pattern. This pattern actually comes first from Haskell (http://hackage.haskell.org/package/enumerator). It is composed of:
Instead of controlling the information flow from the source, in this pattern it is the iteratee that is in charge of telling the enumerator if it wants to get more data or not.
That pattern is featured heavily in Play. You can use it for example to manage Comet connections (HTTP connections that “never” closes and that streams data to which the client browser can react in real time). You just define your enumerator on the server and tell him what callback method to call on the client when it has data to process. This really ease the concurrency management and allows the server to keep up with thousands of connections with a reasonable hardware.
The presentation ends with the show of the sample applications embedded within the PlayFramework 2.0 distribution.
This is only a small summary of the presentation. If you wants to have a look at it, you can watch the complete presentation on Parleys.com (http://www.parleys.com/d/3143 for part 1 and http://www.parleys.com/d/3144 for part 2).
Hibernate Spatial is a Hibernate extension for storing and querying GIS data. Thus for those like me who have heard from GIS but don’t really know what hides behind the acronym, the first part was a nice introduction. Continue reading Hibernate Spatial BeJUG conference