Friday, October 19, 2012

Notes on JavaOne 2012

Make the Future Java was the slogan for JavaOne 2012.

After spending 5 days x 12 hours of different session trainings at JavaOne I couldn't help to blog about my impressions on the pure technical side of the event. Please note that a significant portion of the presentations were handled by community driven projects and not precisely by Oracle so some of my notes below reflect information acquired from external to Oracle entities.

Garbage Collection optimization is still a time consuming and complex process that demands a lot of trial and error. The hope is that G1 will come to the rescue of mere mortal programmers

Troubleshooting JVM performance issues: Oracle is working on having all features from Flight Recorder plus JRockit Mission Control into Hotspot Mission Control. JTRockit will be deprecated in 2013. For commercial purposes JVisualVM will not be integrated with Mission Control. Java Mission Control is a graphical tool that provides information about the JVM, the client side of Java Flight recorder if you will.

From the origins of RMI all the way to WebSockets we are still trying to get distributed computing right. WebSockets is pure TCP, the same way REST is pure HTTP and with pros and cons it looks like the community will only keep using both in the next years.

Use the new generics enhancements to make sure a specific class is returned by methods which operate only on interfaces. Guava and Goldman Sachs collections are recognized as great enhancements to the JDK library.

Use command line tools (and of course script them) to know more about your JVMs: jps to find JVMs running in the system (-m and -v options); jcmd which is similar to jps for listing but it can send commands to the jvm so it can be used to diagnose the JVM (jcmd VM.version for example). A list of commands can be passed in a file via -f flag. Out of the box it allows for deadlock detection as it can pull stacktraces from the application (This creates a possibility for some interesting monitoring right?); jstat is used to list counters from inside the jvm. JVisualVM can be use to take a JVM core dump files and analyze them but jstack will do the same from command line (you get more power we would agree). Again jcmd is useful here: jcmd GC.heap_dump file.dump).

Inspecting the JVM can be done through several methods: JMX (jvisualvm as jconsole uses JMX for remote access), daemon (jstatd is a daemon that can be run in the server and then use jstat to connect to the it - There is no permissions here, so be careful where you run it), attach (It is used by jmap, jcmd and lps. Only available locally and for the same user). The file /tmp/hsperfdata has lot of JVM runtime information which is constantly updated by the JVM. Use jstack command for core files or non responsive jvm. Use it as last resort, it uses the debugger to pull information. JVM built-in profiler and tracer use a circular buffer with low overhead. It collects info from JVM.

Command jcmd should replace in the future jstack, jmap, jinfo. Improved Logging for the JVM like garbage collector logs have rotation but not the rest so the plan is to unify them.

The Java Discovery Protocol (JEP 158) will be used to broadcast information from the jvm so tools like jvisualvm can be notified.

JRockit Mission Control can be used to find duplicated Strings for example (those candidates for interning right :), we know we can use tools like Eclipse memory analyzer (MAT) for that but certainly it would be nice if the JDK itself comes with the tools we need as developers (the one-stop shop concept saves time of course)

Intel presented their SPECjbb2012 results for JDK7. They found no issues with most APIs: New I/O, JAXB, Try-with-resource, Catching Multiple Exceptions types, Type Inference for Generics Instance creation, Underscores in constants, Concurrent Utilities. However the Fork/Join Pool was found to be the big problem: Contentions and network throughput issues. JDK8 according to Oracle is simplifying this API so probably they will correct these detected issues.

The need to move to Java7 is clear. Just to mention a fact even though there is commitment to patch security bugs for JDK6 the support for it will cease in 2013. But there is more.

Find out from the jdk7 release notes website what is new in jdk7. Here are some of those features: string switch, diamond operator, simplified exception handling, better garbage collection (the basis of G1), multi-catch and try with (exceptions improvements)

G1 is specially designed for big heaps (above 6GB). It is better than CMS especially for fragmented heaps. It works dividing the memory in different regions which are heuristically selected for garbage collection (Divide and Conquer right ;-) It can be tested in JDK7u4+) with "-XX: +Use1GC". CMS GC will be deprecated soon.

Contention is avoided in Date (from Hashtable to ConcurrentHashMap). There are BigDecimal improvements. String to byte conversion improvements.

Java upgrades are supposed to come now every two years. Skipping versions means a bigger update gap. IntelliJ was presented as the only automated refactoring capable tool for migration to java 7. Personally I recommend looking into current open bugs before deciding for an upgrade to java 7 of course but you should be planning for it.

There are performance improvements in JDK7 specifically in JDBC, JAX-WS, JAXB, java io, async io

Here is a recipe for your JDK7 migration: Compile to java 6 using jdk7 first. Test for some time, then upgrade the Runtime to Java 7. Finally migrate code to Java 7.

Java 7 has a more strict API so expect some assumptions you have incorrectly done to break parts of your code for example SortedKey must have as input an Object which implements Comparable Interface.

Opencl is used today in jdk7, the integration inside jdk8 will continue just to finalize in jdk9 bringing full abstraction to the developer while the JVM takes advantage of GPU computing. Sinatra project promises to bridge the gap between Java and GPUs. MMUs can allow sharing virtual address space (Heterogeneous computing). There is important collaboration with Intel that might lead even to ship Java in hardware in the near future ;-)

JDK8 will remove PermGen space with the data going to the heap and native memory.

The London Java User Group has been praised for their work on 'adopt a JSR' and their contributions to the JCP. The message is: Oracle is taking very serious the interaction with the community so they are demanding us to contribute.

Java embedded had a Perrone Robots presentation (demo failed as expected - Murphy Law)

Java embedded best moment IMO was when Liquid Robotics (presented by Gosling) showed how they can control thousands of little ships which are moving using waves energy in a mechanic fashion. It auto-generates the energy to communicate data from its sensors via GSM or satellite depending how close they are to GSM networks. A piece of engineering.

Use the process to change the process is what Oracle is expecting from JCP. We certainly are looking forward for it.

A considerable part of JavaOne talks was dedicated to the promise of Lambdas (closures) in Java8 . Lambda is nothing more than anonymous functions but with not just new syntax, look for the use cases they can cover inside the JDK code itself. Java has been behind of most of the programming languages in this regard BTW. You can learn more about Lambda project using the lambda-dev mailing list. I heard more than once the statement: Developers are looking into Scala for features that are not supported in Java. Oracle is listening to the community and we can expect Java to get richer. Lambdas abstract behavior just like Generics abstract type. The code is treated as data (behavior can be stored in variables). Lambdas are more about the what and less about the how. For example with lambdas instead of the client being in charge of managing the loop, the library is in charge of the internal iteration. The way lambdas have been implemented is providing a default() method in interfaces. This rapidly brings a lot of questions about multiple inheritance and here is the explanation from the JDK team: Interfaces already provide a multiple inheritance mechanism for types, lambdas enhance multiple inheritance to behavior BUT not for state which is the real problem with C++.

JavaFX is the de facto standard to build native applications. AWT while providing OS specific native components lacks a lot of bells and whistles that Swing came with but on the other side the latter lack of support for specific OS native UI features is calling for its end of life.

JavaFX web view and jfx panel create a good opportunity to construct hybrid applications (Native UI with JavaFX + HTML5 + Javascript). A clone of the jVisualVM done with JavaFX was presented.

Use Solaris truss and Unix/Linux strace to debug database performance issues.

Nashorn (Naz-horn is the right pronunciation) brings javascript inside the JVM. A demo was presented using Mustache as javascript templating engine. It scales well and runs in small devices like Raspberry PI. The engine is 20 times faster than Rhino. Nashorn implementation relies heavily in Invoke Dynamics. Of course shebang is supported and so nashorn can be run from command line as well. There is node.jar which is a port of the nodejs API. These are interesting news that could benefit Node from the existing Java Services and Java itself from the power of NodeJS.

JEE 7 includes in the platform key features "to avoid the use of proprietary frameworks" and I quote it. I will be posting soon my notes about SpringOne BTW ;-)

Cleaner API is a mission for JEE. JMS is so simplified that it looked to me like Apache Camel code.

I heard the word POJO a lot, and not just Beans ;-)

The web socket API looks really clean, same for batch with annotations and Java Temporary caching.

DI is heavily used across the whole JDK.

There was a demo on web sockets called Angry Bids. All built on top of JEE using a REST approach.

Doing a remotely retrospective we reviewed DCE, COM, CORBA, RMI, RMI/IOP, SOAP, REST, Websockets (web sockets is just plain TCP)

Look into JDK secure coding guidelines

Software Archeology is unfortunately a common challenge, especially when you are a consultant or simply switching jobs. The amount of legacy and undocumented code makes your life difficult and we discussed how to mitigate this reality. Finding behavior is reduced to documenting using activity and sequence diagrams. Finding structure is about deployment, component and class diagrams. I would add to the equation (if not favoring it as highest priority) User Stories. Some tools can help here like trace based analysis using byte codes or aspects. Tools like mission control can help but it does not provide the order of method calls. There are tools that allow to have an output like the one from strace but from the JVM. We can generate system dumps and then analyze them after. IBM hosts in their website some of these fee tools (JVM trace for example)

Codename One presented how to build iPhone Applications from Java. I share Martin Fowler's opinion on this issue

Verisign presented JEE security in practice. You can find information they maintain in here. They discussed the use of HttpRequest#authenticate(), @ServletSecurity, session#logout(), HttpServletRequest#[getRemoteUser(), getUserPrincipal(), isUserInRole()]. Not always possible but white listing is always preferred. Use declarative security first then as needed use programmatically security. It was clear to me how ahead Spring Framework is in terms of security in comparison with JEE in the Web Tier. IMO vendor locking is precisely where Spring excels so to claim that spring security cannot be compared with official JEE just because the later is a standard is not a wise statement as far as I can tell. For one all vendors after all add security features in their application servers for example, so you will be locked of course.

In Java 8/9 we can expect a Modular Java Platform (Project Jigsaw). It allows to package ME and SE together, it will try to resolve the the jar hell problem, the scalability (down to small devices like Rasberry PI and up to the cloud like Oracle Exalogic Elastic Cloud T3-1B). Performance is expected to increase both in terms of download and startup time. A couple of comments on language keywords: the module keyword allows for organization of Java packages and the the public keyword loses its meaning as it is not longer public to the outside unless exported.

A presentation promoting agile JEE development using JBoss, IntelliJ and JSF including the use or Arquillian for testing which basically had to restart a servlet container every time a JUnit test was triggered. It was really IMO not that agile.

JDK Enhancement Proposals (JEP) promise to bring more community participation to Java as an open standard. The OpenJDK project is after all the incubator for new features of the Oracle JDK (Hotspot). Boxing will be removed at some point as an example of one of those current JEP. Just search for JEP to get an idea of the new features and enhancement proposals.

JEP 159: Enhanced Class Redefinition is in implementation phase. This will allow the hotspot to support redefinition of classes, method signatures and more.

A clarification for the meaning of @deprecated within JDK code: For the JDK team it does not mean it will disappear from the source code. The reason is backward compatibility.

Check your application is correctly using all cores. Modern computers use NUMA so use the optimization Flag -XX:+UseNUMA to allow a more optimal usage of memory. Bunch of other flags for you to look at: -XX:StringTableSize, (interned Strings), -XX:+UnlockExperimentalVMOptions to use even in JDK 6u21+ -XX:+UseG1GC between others.

No comments: