With the rise of microservices or large scale distributed systems and communicating through HTTP and NoSql databases, we also see the rise of eventual consistency. The focus on reliability or the perfect operation at all times had to shift to resilience; the ability of an application to recover from certain types of failure and yet remain functional. All-or-nothing and reliable transactions were paramount, data had to be safely stored above all, sacrificing the user experience and cost. The objects on those transactions could also be very complex, frequently using multiple tables and even different databases. Typically, if a transaction failed, the user would receive an error requiring his action; usually to resubmit the request or contact support. To keep response times low, vertical scaling with costly “big iron” was common.
JavaOne, the first two days
It’s again that time of the year when you cross an ocean to hear people talk about Java (!?), see some friends and wake up at 4am because of the jet lag.
About the sessions… The use of lambda expressions in the construction of new APIs or in evolution of the existing ones is becoming widespread.
The new JSR-354, Money and Currency API, was one of the nominees for this year’s JCP Awards, and has a very elegant use of lambda expressions. I plan to take a detailed look at this API in the future.
JAX-RS 2.1 will also use lambdas to make it easier to use Future<T>, InvocationCallback<T> and CompletableFuture<T> for non blocking writes with REST endpoints. Server side events and extension points to use RxJava were also announced.
A standard for asynchronous stream processing, like RxJava, has been mentioned. Take a look at Reactive Streams.
Also JMS 2.1 is coming with major changes to message driven beans (MDB). Multiple queue listers per MDB are being planed, non durable topics, callbacks will be able to auto un-box the message payload and set message headers and properties, following the JAX-RS way. Other features being discussed are the CDI beans as JMS listeners, a standardized way to deal with the dead letter queue, the delivery of messages in batches and also an API for connection factories.
And… If you are planing microservices, please make a favor to yourself and follow to what Adam Bien has to say about it.
Integration Tests Presentation
This are the resources of the Integration Tests presentation from April, 16 2015 at Coimbra JUG.
– Slides (Google)
– Demo source code (Github)
JavaOne Java EE
I managed to find some time to write a bit more about JavaOne. This time about the Java Enterprise Edition (EE).
This area has been very active in the last couple of years. Java EE 7 (JSR 342) was completed on May 2013 and the Java EE 8 (JSR 366) is well underway now, the final release is predicted for the end of 2016. The draft proposal was driven by the feedback from a community survey and the contribution of industry experts, commercial and open source organizations, Java User Groups, and many individuals. The JCP has conducted a very open process in here. Congratulations to them!
Here are my sessions highlights.
On “Jee7 soup to nuts” we got a great overview of the current application servers compliance with the standard, some great tools and the top features, like:
- WebSocket client/server endpoints (JSR-356).
- Batch applications (JSR-352).
- JSON processing (JSR-353) for parsing, generation, transformation and query of JSON messages.
- Concurrency utilities (JSR-236) provide a standardized way to use concurrency in application components without compromising container integrity.
- Simplified JMS API (JSR 343).
- More annotated POJOs, including transactions.
- JAX-RS Client API (JSR 339). The API for RESTful web services.
- Default Resources.
- Faces Flow.
Some other important features of Java EE 7 not emphasized during the session were:
- JCache (JSR-107). This API was 13 years in the making until a final version was settled to specify the temporary, in memory caching of Java objects.
- The Web Profile, introduced in Java EE 6 was also updated. This defines a configuration of the platform suited for web applications and allows light weight containers like TomEE.
One of the best sessions I saw was “Developing Java EE 7 applications with Scala”. In a nutshell, you can use @BeanPropery @Inject on Scala! …And even test the application using Arquillian and Glassfish. How awesome is that?
Some sessions gave us insights on concrete applications developed using only the standard APIs, like in “Lessons Learned from Real-World Deployments of Java EE 7” and “Java EE 6 Adoption in One of the World’s Largest Online Financial Systems”. On this last one they described the case of Rakuten, a large vertical company on Japan, spanning businesses from banking, credit card and online retail. Here, a team of around 20 people developed in 3 months a complete financial application using Java EE 6 technologies. They perform the highest number of daily transactions in Japan.
Another really great talk was “Applied Domain-Driven Design Blueprints for Java EE”. Wikipedia does a good job explaining the subject of Domain Driven Design (DDD). In the presentation a parallel is made between the concepts of this architecture and the relevant APIs to use while implementing them with Java EE 7. An example application was open sourced and can be used as a reference.
Now, heading for the future with “Java EE 8”. In this session we got a best guess of what might be included in the next version of the platform:
- JSON-B for binding. An API to automatically marshal and unmarshal JSON documents. It will have defaults like in the case of the JPA and annotations for overriding. Behind all this is JSON-P.
- JSON-patch might be introduced. It is a format describing changes to a JSON document. It can be used to avoid sending a whole document when only a part has changed. A typical example is an update to a field.
- Server sent events based on a long lived http connection to push notifications from the server side. This will use Jax-rs, the API for RESTful web services.
- Action based MVC for web applications. This follows a similar approach to Angular JS.
- HTTP/2 support. Multiplexed streams on a single HTTP connection. They will be prioritizable. Header compression support. See JSR-369.
- CDI. New security interceptors. More then just users and roles. Repositories for rules information will be introduced allowing a more fine grained control like, “is the user allowed at this time?”. Possibility of password alias.
- Improvements in the messaging service JMS 2.1.
- Pruning. Eliminate some unneeded, legacy client interfaces.
- Management. Revamp JSR-77 and give it a REST interface.
On “Java EE 8 Community Update and Panel” we got a glimpse of the vision for the future and the challenges ahead. There are some ongoing discussions about a configuration JSR and to change the XML based RPC JSR-101 to improve service discovery.
The ongoing trend around Microservices and asynchronous processing to create modular and scalable applications. The need to create a cloud and a mobile profiles were also mentioned. The challenges introduced by other programming languages and the need to continue the evolution of the JVM to accommodate other languages apart from Java .
JavaOne Java SE
Here I start a series of posts resuming some of the interesting parts of the conference. I decided to organize them by subject for future reference.
We also learned a bit about what might be included on Java SE 9:
- A Dedicated Json-P (processor) API.
- A Http2 client and a Web Sockets API.
- Parallel compilation.
- Modular source code affecting the build and partition of the JDK. This is a part if the endless Project Jigsaw.
- Project Valhalla. Introduction of Value Types. Like a Class but with a Value like behaviour. They might be passed as an array on the stack and be used with Generics. They will not have object identity, hence no inheritance or polymorphism. We can expect a big performance boost from this.
- Project Panama. Improvements in the interconnection of the JVM and native code.
Also about Streams was one of my top 5 session, the Parallel Streams Workshop. A Stream is an abstraction that represents zero or more values. It’s not a collection or a series of values. It can be started in a sequential mode, be transformed to parallel and again to sequential. This is particularly useful when used with Lambdas.
Photo from myself.