I took a Java 8 training class at Salesforce some years back, but I have not had a chance to play with it much since then. My managing tends to interfere with programming time, and I have been trying to learn Python with the little I have left. But recently I have enjoyed playing with streams, particularly as combined with Java 8’s lambda expression capabilities. One question I have not resolved to my satisfaction is how/when to leverage the parallel stream capability when working with large streams of data.
All of which may have just changed anyway, with the release of Java 9 on September 22nd (2017). I’ll have to experiment the new functionality, hopefully assisted by the new REPL tooling.
One change heralded with this release is that future versions of Java will be released more often, in smaller increments. I suspect this was made possible in part by the major modularity overhaul that took place in Java 9.
The proposed next release will be 18.3 in March (3) of 2018. Don’t wait for Java 10, the old numbering scheme appears to be dead.
The practice of issuing smaller releases on a more regular basis is standard operating procedure for most cloud-based companies, and appealing overall for software engineers. Current best practices suggest that code that is tested and ready for production should be released as soon as possible.
Enterprise customers in particular do not always share this perspective. When code is mission critical they do not want code drops to occur too often. And they might define ‘too often’ as anytime it does not add something they requested. For key installations they may spend staggering amounts of time and money testing each release and retraining staff. At Salesforce we were informed that one customer spent a couple hundred thousand dollars a quarter testing our major releases.
So what will be the impact of more rapid and regular Java releases? Will we love the quick fixes and new features, or will it cause chaos with our code? Time will tell…