So that Devoxx is now nearly over, here are some reviews of talks of the last full conference day. Day 5 is typically a phase-out day with only a handful talks and everybody is an hurry, our Devoxx 2013 wrap out will be published on Monday.
## “Java Microbenchmark Harness: The Lesser of Two Evils” by Aleksey Shipilev (mario)
At day four I had to decide between a spring four talk and a talk about Java Microbenchmark
and my decision was completely right to go to the benchmarking one. It proofed me
completely wrong in knowing something (right) about JVM and hardware performance behavior.
The talk was not an easy one and it was really hard to follow, but it was amazing.
The speaker is Oracle Java Performance Engineer and he is working all day to improve the JVM and the Java-Core-Libraries.
He has a rich knowledge about the internals of the JVM.
In the talk he offered a lot of information about the behavior of the JVM and the hardware per example the CPU.
One of the main expressions was, that it is very unpredictable what happened exactly in your hardware if
you run your code. There are so many different things that can make your Test-Results useless.
He also introduced the tool JMH (Java Microbenchmark Harness) which helps you to get around some of the pitfalls.
His talk was a little bit to fast at the first half. At the second half of the talk he realized it
and he slowed down the speed. The talk was originally created for the JVM Language Summit, so it is targeting Language-Designer and
JVM-Core-Developer.
He showed Microbenchmark-Code and asked the audience to predict the results. Then he showed the results and
asked why they were so completely different from the expectations. The explanations were a little bit
to fast in my opinion, but I think there was not enough time to make this clear for none JVM-Core-Developer.
One funny thing he said was about blogs who shows benchmark test-results. He said they must be really happy
people because they don’t know the truth about there (for sure wrong) test-results.
The last question of the talk was who were scared now and nearly everyone (including me) raised his hand.
I realized that all my performance-testing I have done were wrong in many directions. I will have to see the talk
on parley again and maybe read some extra documentation to get the whole bunch of information right.
On day 4 of Devoxx Sam Brannen talked about the the changes we have to expect with the upcoming 4th version of Spring Framework.
With the presentation not focusing on deeper details, I’ll summarise the features this version will bring to us.
With Spring 4.0 you will be able to take advantage of the new Java 8 language features like Lambda expressions, method references, repeatable annotations and the Date/Time additions. Beside that it will support Java EE 7.
Groovy will be more integrated into Spring, providing the possibility of creating Spring bean definitions using the Groovy DSL. That shall make it possible to write Spring applications completely in Groovy.
It will be possible to “override” fields in meta-annotations with your custom annotations by using naming conventions, there will be enhanced WebSocket support and you can now define lazy initialisation on the injection point rather than at the bean definition.
The feature that I personally expect most is the full type matching of Generics with Dependency Injection.
Along with those new features, other things will be dropped.
Java SE and EE versions 6 or higher will be required and also support for older versions of third party packages like Hibernate 3.5 or Junit 3.8 will be no longer continued.
With that all deprecated packages from Spring 3.x and many deprecated methods and fields will be completly gone in Spring 4, so it would want to check your code for usage of those before migrating to version 4.
What to expect from Spring 4.0 and especially how to migrate from 3.x? Sam Brannen talks about the next generation of the famous application framework.
First fo all a short Sping 3.x review. The Spring component model has changed in Spring 3.x to a more powerful annotation based nature. SpEL which stands for the Spring expression language was introduced and especially used in XML config files. Web support with comprehensive REST support and additional MVC fetaures were added. Furthermore Spring declarative features in terms of validation and formattinng (JSR-303 bean validation), scheduling and caching were added to the box. Spring testing features with several XML namespace components to simplify the configuration fit in nicely in Spring 3.x. And last not least the integration of Java key specifications like @Inject, JPA annotations and web.xml.
A lot of stuff going on in Spring 3.x in the past so now I am very curios on what’s new in the box for 4.0 and I hope you are with me.
New baselines and all deprecated packages are removed, so it is time to stop ignoring those deprecated annotations in 3.2 Spring code! It is time for us to switch to new implementations and classes provided as alternative to the deprecated stuff. In 4.0 those deprecated classes are gone. In addition to that all third party libraries were updated and in general to major versions around mid 2010.
The Spring team put a lot of effort in creating a smooth out-of-the-box Groovy-based Spring experience. AOP adaptions as special handling of GroovyObject calls for instance. Also nice the new Spring bean definition Groovy DSL. So everything you can do right now with XML bean definition and Java annotation based configuration can be done with Groovy script DSL in 4.0.
In Spring 3.x we had profiles to conditionally load bean definitions based on the environment we are running at (e.g. development vs. production environment). Now we have a even more powerful way to load bean definition based on some condition. Basically this is an extension to the profiles but more flexible and it can be used for smart defauflting (see Spring Boot project).
@Conditional and Conditional interface are new constructs to use in order to conditionally add bean definitions to the applciation context. Actually the well known profiles now are converted to some ProfileCondition.
Custom annotations may now override specific attributes of Spring meta annotations like @MyTransactional and @MySessionScope. This is a convention-based concept which is great to encapsulate a group of Spring annotations in a custom annotation.
You can load bean definitions in lacy nature when they are requested in the application context. In Spring 3.x this was done directly on the bean definition and affected all occurences of bean references of this particular lacy bean. @Lazy is now set on injection point rather than definition point. So you can do a very particular lacy dependency injection of a bean, that not necessarily has to be lacy loaded in other situations. In general this is an alternative to the Provider<MyTargetType> construct.
This feature of injecting a list of beans of same type that are present in the application context is not completely new. Now you are able to specify the order of beans listed. So you can inject a list of candidate beans with order by sorting the list before injection.
Dependency injection and generic types are now even more fine granular in matching bean candidates. Type matching is now based on full generic type (e.g. MyRepository<Customer>). Generic factory methods are now fully supported in XML configuration which is very useful when using Mockito and EasyMock beans for testing.
Spring messaging is a completely new module which is basically an extraction of the separate Spring Integration project. The concepts and components offered there are now available in this new module representing core message and channel abstractions.
Spring offers new WebSocket support with endpoint model along the lines of Spring MVC. Not only the WebSocket JSR-356 is supported but also beyond that covering SockJS and STOMP. In terms of that a new RestTemplate variation called AsyncRestTemplate comes for non blocking REST calls on the client side. This is based on ListenableFuture concepts.
Things gone: JUnit 3.8 support, @ExpectedException, @NonTransactional, SimpleJdbcTestUtils
Things new: SocketUtils (scan for free UDP TCP ports), ActiveProfileResolver, custom meta-annotation support for tests
In Java SE world Spring now supports JDK 6 up to JDK 8. The IDE support for IntelliJ IDEA 12 was already released in December 2012 and is up to date right now. Eclipse users have to wait till June 2014 :-( while the Spring Tool Suite might find earlier Eclipse based support for you Eclipse users out there.
JDK 8 language features like lambda expressions and method references do fit naturally with the Spring API. Spring API is already designed to work with separation of concerns in terms of one method interfaces that are perfectly capable of lambda expressions. Automatic candidates are JmsTemplate, TransactionTemplate and JdbcTemplate methods and operations (e.g. MessageCreator or RowMapper).
Spring 4.0 will be available in December ‘13 and I am looking forward to that.
This morning, I attended the talk on “Cloud Patterns”, by Nicolas de Loof of CloudBees. The announcement was promising: It said that the talk would show how to refactor legacy single-server applications to make them ready for distributed cloud deployment. The announcement also said that the talk would present the experiences made when porting the Devoxx call for papers application (single server app based on Wicket, Spring, MySQL) to CloudBees.
Given that the talk was targeted at a senior audience, I expected a lot of code, database dumps, tricky unexpected errors, and how to solve them.
However, the talk was more a high level presentation of some commonplace thoughts on cloud development. Some examples:
The presentation was all PowerPoint, and did not include any demo. Not a single line of code was shown.
The talk may have been good for people who wanted a general overview of what should be considered when moving an application to the cloud. However, given that the talk was explicitly announced as being a senior talk on real-live lessons learned, I was a bit disappointed.
The problem with Http is that it is half duplex, verbose and client initiated. There is no support for server push. Hacks exist such as long poll, comet, etc. It doesn’t scale due to the verbosity, especially with headers.
WebSocket is a full-duplex, bi-directional protocol over a single TCP connection. It solves the two problems of scalability and server to client communication.
It uses the existing http upgrade mechanism to upgrade a http connection to a WebSocket connection.
WebSocket consists of the protocol RFC6455 (2 years old). It defines the wire frame which is very lean and the upgrade machanism from http to WebSocket. Additionally W3C defines the WebSocket JavaScript API which is in stage “Candidate Recommendation”.
Client-Server connections are established by a handshake request/response contained in Http headers. “Upgrade” and “Connection” http headers are used for that. Additional headers for security etc. are also available.
Upgrade: websocket
Connection: Upgrade
The response is mainly a Http Status “101 Switching Protocols”.
Client and Server become peers by upgrading the Http to a WebSocket connection. They both can be considered equal partners that can send and receive messages over the WebSocket connection.
W3C WebSocket API at www.w3c.org/TR/websockets
SubProtocols can be used over the WebSocket connection. The API offers networking callback handlers for open/close/error events. Text and binary messages can be send over WebSockets using existing send methods.
Support for WebSockets have to be build in the browser. It is not possible to use websocket with a library. Chrome, Safari, Firefox have WebSocket support. IE doesn’t.
WebSocket is not supposed to replace Rest. WebSocket is very low level. There even isn’t a Request/Reponse pattern. However a (simple) performance comparison benchmark shows :
Sending 10 messages of 1Byte takes 220ms with Rest and 7ms wit WebSocket.
Sending 5000 messages of 1KB takes 54s with Rest and 1s with WebSocket.
The JSR 356 specification is the standard API for creating WebSocket pplications with Java. It is part of Java EE7 and available in GlassFish, WildFly, Tomcat and Jetty.
Annotated with @ServerEndpoint and @ClientEndpoint or use a programmatic endpoint which gives more control and extension hooks. Handshake negotiation e.g. can be customized.
Hello World example:
import javax.websocket.*;
@SeverEndpojnt("/hello")
public class HelloBean {
@OnMEssage
public String sayHello(String name) {
return "hello"+name
}
}
This example actually implements a request/response design pattern.
Available Annotations:
@ServerEndpoint
@ClientEndpoint
@OnMessage
@PathParam
@OnOpen
@OnClose
@OnError
The ServerEndpoint offers support for custom payloads by adding Encoders/Decoders to the Endpoint using a annotation attribute. Decoder simply has to implement the Decoder.Text interface. Each decoder has a willDecode() method to allow to find the “right” decoder. Same applies for the Encoder.
Optional Url Path parameters can be used in method signatures. Also optional Session parameters can be used in Endpoint methods.
Note: A single Server Instance is created for each incoming request (Uh!).
Authentication is done using standard Servlet security mechanisms. Use it before the upgrade from http to websocket. The security model is the same for ws:// requests as for http://. Transport security can be obtained by using wss:// for ssl websocket connections.
To see what is going over the wire Wireshark is a good tool. Chrome also has good debugging support for websocket requests.
Three years ago I first heard of WebSockets in a talk at Devoxx from a Kaazing guy. I was really exited and tried to use the technology in a real world projects. It was a pain at that time. For me it was very interesting to see how WebSocket finally made it to JEE and will be usable in real world projects. I’ll give it another try…
This talk is all about the Myo, a wearable gesture control armband that senses the movements of the muscles of the forearm to control digital devices. It is based on Electromyography, which is a technic to measure the electrical activity when muscle contracts.
It is a 9-axis inertial tracking system with tacktile feedback. It communicates with BT 4.0 LE. The muscle sensor do not have a contact to the skin.
The API is still in pre alpha state and will change for sure until the first release. The supported language for the API will be C++, .NET, iOS, NodeJS and more. Every Myo hub starts as event producer to which listener can register for one or more Myo connected devices. The initially supported events are
A Motion event is describe by a timestamp, acceleration, angular velocity, orientation and associated pose (if any). A Pose has a start and finish time, the type of the recognized pose (“fist”, …) and state (holding, released, started). The API comes with a predefined set of poses. A Gesture is more dynamic and has a timestamp, type (circle, swiping, …) and state (start, recording, end).
The live demo uses the Node.js API. He shows how to fetch the raw data from Myos. For detecting poses or gestures, machine learning algorithms a re used. I think, that will become the real hard part. An iOS Client was shown also.
This gadget is quite impressive, but seems to be still in an early stage.