The Ten Most Important Lessons from JavaOne: The 20th Edition
The Ten Most Important Lessons from JavaOne: The 20th Edition
Java Champion Peter Pilgrim provides 10 takeaways from the JavaOne 2015. Learn why Peter believes Java has the ability to be a viable option for another twenty years.
Join the DZone community and get the full member experience.Join For Free
Java-based (JDBC) data connectivity to SaaS, NoSQL, and Big Data. Download Now.
We have just had the twentieth edition of JavaOne in San Francisco. This would be my twelfth attendance in unbroken series since 2004. What are the biggest takeaways from the conferene that potentially shed a light on Java’s future?
- Modularization; the effort – it has taken almost nine years from the first mention of modules at Java 2007, or rather by the time that JDK 9 is released in September 2016 as general availability. In fact, it will be 11 solid years, ever since JSR 277 the Java Module System. When we think about this effort, it will be more a decade of activity and thought (See Stanley Ho’s original announcement). Oracle’s modularization of the JDK effort requires a biography of its own. Perhaps, Mark Reinhold, will get around to writing it one day, may be as the mythical man-month of the 21st century.
It is frightening to think rewriting, effectively, Java so that it follows HIGH COHESION and LOOSE COUPLING took almost decade. Everyone else not in the JDK engineer should be extremely scared, especially if the business that you are involved in, has it own humongous mountain of TECHNICAL DEBT. Many institution cannot afford to upgrade, rewrite and reorder legacy classes, packages, let alone modules. Indeed, the cost of maintainability is about to go astronomical for those businesses that struggle under the weight and remain entrenched with Classic Java (JDK 1.0 to 7.0) For Oracle, they had no choice to pay the entire cost of development, design and architecture for the benefit of the entire Java platform and community in order to move forward to better and greater deads in the future. Oracle ought be immensely congratulated when we do reach JDK 9 GA in 2016.
- Modularization, the future – the new proverbial no brainer – I do believe Java and the practicing developer, designer and architect community have a LINE-IN-THE-SAND (aka DEMARCATION POINT or DISRUPTION LAYER), which we will pass through in 2016. A modular system can change faster than the JDK platform. If Project Jigsaw is designed correctly, then you no longer have to contend with CORBA or the old fashion IBM derived java.util.Date and java.util.Calendar. In theory, you ought to be able to replace these module services and remove them if they are unnecessary. If you do not need Swing, then that module can go, same for JavaFX and AWT for server only deployment. Whilst backwards compatibility for Java platform is guaranteed, then it means opportunity for experimentation and new ideas.
For recruitment sector, I predict, in 2017, JDK 9 will be CAMEL’S BROKEN BACK. I believe nobody will want to touch Java SE 7 or before (Classic Java) with a barge pole when they can move ahead quicker. The top engineers will look at your job specification and run hundred miles if there is even an hint of classic Java there. You can offer £1000 per day for 6 months, but who seriously would go through technical debt and attempt to re-modularise ancient Java code, when the next women in the business down the road, is cracking on with the modern modular Java frameworks, gaining considerable experience, moving ahead of the pack, building the next greatest thing on JDK 9. On the other hand, Modularisation does not solve the technical debt, mountains or hill of it. If your business’s mission critical software is an unassailable ball of mud, then you will continue suffer the debt unless there is Agile change of behaviour. I think this is reason why the Oracle JDK 9 team want us to be the early-access early adopters in order to test their enterprise software as much as possible.
- More Push Java in the Cloud – At JavaOne 2015 there were a lot ideas and conference talks on Micro services and building Cloud enterprise applications. The exhibition had a few cloud vendors like JElastic, Red Hat, Pivotal and CloudFoundry. Oracle released its own long-awaited cloud offering called the Oracle Java Cloud. Ironically, their PaaS solution offers server clustered with Oracle Coherence, which used to be called Tangasol. Cameron Purdy, a very recent ex-Vice President of Oracle, created this early distributed grid and caching solution and, actually, one of his advocates, Brian Oliver, came to the JAVAWUG BOF 26 back in 2007 and gave a talk on Coherence.
Arun Gupta for Refactor your Java EE Applications with Microservices and Containers (CON1700)
- Kubernetes and Docker – Arun Gupta was one of three technical speakers who discussed Kubernetes (Google’s cluster of Linux containers). There is new terminology. Pods are collocated group of Docker container that share an IP and storage volume. A Service is a single, stable name for a set of pods, also acts as load balance. A Label name value pair is assigned to a pod. Unofficially, the old application server marketing wars between LIGHTWEIGHT versus HEAVYWEIGHT, which usually took the mode of Java EE versus Spring, took a back seat at this JavaOne conference.
If you happen to use Docker or Vagrant and configuration management tools such Chef or Puppet, you probably would spit on the old argument, because if you are stopping and (re-)starting a virtual machine that is configured from Soup to Nuts with a deployment profile, you could not care how light or how heavy WildFly server is? It is more important to know that WildFly 8.2 can be launched with said ACME.WAR already deployed, and the HTTP Undertow module is attached to a secret port 4123 that is mapped externally port 80 on some virtual machine. You no longer care how large the WAR file actually is, if the WAR file is 10MB or is 1MB.
- Dreaming of Microservices – Dianne Marsh’s talks about NetFlix dev ops were completely full. Many people are thinking about these ideas, I suspect that few, very few have the business support, let alone acumen, inside their organisations to actually practice these ideas. Micro services requires operational teams that work at cross function and usually across divisions. SILO-DRIVEN ENGINEERING, which can found in many traditional USA and UK investment banks, other large commercial institutions, retail organisations, digital design agencies are an anathema to Micro services. So keep on dreaming if you are fortunate or unfortunate to be a working part of these … The best you could hope is not Microservices at all, but you can rethink your MONOLITH and attempt to get to COMPONENTISED APPLICATION, and if you can get to this point in your enterprise architecture, then you should be able to get a MODULARISED MONOLITH, which is better than a (spaghetti built) MONOLITH.
- Scala and Groovy – there were less alternative JVM languages talks this year. I went to the Apache Spark talk with Ted Malaska, which was very interesting. I also attended Cedric Champeau’s Domain Specific Languages talk in Groovy.
Rafael Benevides (L) and Antoine Durandt (R)
- JavaFX progressively mobile friendly and business as usual on the desktop – There was no keynote innovations around JavaFX, which showed off new functionality. JavaFX adoption is stronger than before, because Swing is on maintenance mode for several years. Gluon are investing in mobile cross-platform support for JavaFX. Gluon has taken over the effort to port JavaFX applications to iOS and Android. For the desktop, JavaFX probably needs rich text editing components. For the mobile, there is JavaFXPorts. I suspect the next huge chunk of the work for this software team is help with the JavaFX 3D and the media libraries.
With Micro services and their close brethren Containerless builds in WildFly Swarm and Spring Boot this high interactive mode (I’m channeling in Bret Victor – Inventing on Principle here) is taken away. In the case of WildFly Swarm, the biggest issue is their no such thing as an exploded-dynamically-reloadable ShrinkWrap implementation yet, which would allow JVM reloading of classes and web resources. The only way round it is to possibly write applications in the APPLE-IDIOMATIC-SPLIT-TEAMS-SECRET methodology. The user interface design team develop a new front-end that just has a responsibility to show a list of products by title, headline, graphic and description. The server side teams writes the remote endpoint services to query the database. The front and back team agree on a REST API or web interface, but they no clue about the products themselves or descriptions. They will test with mock data.
The executive will fill the product database just before the launch with the Apple iPhone Invisible Edition 5150 and all of the relevant information, headlines, titles, hero graphics, comps, descriptions and prices to go with it. This is a great solution for Apple, because it is a Kool-Aid company, it is not so good for smaller teams, small medium enterprises and even one-man (and one- woman �� bands, because more often than not, you want a full stack solution that you can entirely play with it from front to back and vice versa. Containerless then are great for RESTful endpoints and server. Code Hale’s DropWizard showed us how to get us there, but there are not so good for web front-end work in Java (yet).
Stephen Chin soldering at Raspberry Pi and the Oracle Demogrounds and JCP Hackergarten
- James Writes Java: What I Have Learned by Reading James Gosling’s Code [CON3563] – this was a fantastic session. I’m glad I saw this live, because it reminded me of notion not to become complacent in my coding. James Gosling absolutely continues to stretch his coding with knowledge that he is gained. There is also room for improvement.
Java has another 20 years of life at least. It is possible to have a career working entirely on the Java platform from 23 (Graduate Junior engineer) to 63 years old (Chief Architect of ACME / PEABODY and still code). I think that this is certainly achievable. It is the other industry practices outside of the Java programming language and JVM that will have profound effects on this ecosystem. Hardware is going to scale up and across. The JVM will have to cope with 1TB RAM and garbage collections. Indeed, this is the next growth area for the JVM engineering team. JDK 10 should hopefully see Value Types to help with memory allocation. On the server side, cloud is still the new frontier, because it still unsure how blue collar Java developers will decide on the value for the cloud.
The huge opportunity is the Java MODULE system. It is the ultimate DESIGN-FOR-REPLACEMENT feature not within the Java programming, but into the Java Virtual Machine and JDK distribution. Will we, developers, designers and architect, use it for good? Will we use it in the modification of SOLID? Or will we abuse it somehow? Modularity probably lies in two opposite ends of the ruler, at different scales: the Internet of Things and Micro-services distributed application modules. The future is difficult to predict in terms of hardware and software. The only thing that we can do is get involved, get into it, and keep pushing the envelope. Let’s enjoy the ride.
Published at DZone with permission of Peter Pilgrim , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.