It’s been a long time coming, Java SE 7. After years of development, one major company acquisition and at least a hundred thousand discussions over the future of Java, yesterday Oracle and the OpenJDK community finally released the updates they’ve been working on all this time. There are a lot of changes in this version, not the least of which is the switch in naming conventions: The OpenJDK is the basis of Java SE 7, and its the project where all work has been done on the language, rather than within the JCP.
So, let’s all grab ourselves a nice symbolic cup of coffee to tide us over while we examine the biggest changes in Java SE 7.
Core proliferation has been an issue for a while now. With every new PC and server including more cores than the last, developers are constantly receiving more horsepower for their applications. Unfortunately, as enterprises have learned over the last 10 years, developing parallel and concurrent software is not as easy as adding all those new cores to a server farm.
Doug Lea, the Java genius from SUNY Oswego, headed up the design of JSR 166y, also known as the Concurrency and collections update. He designed the Fork/Join functionality that’s used in this update.
Perhaps the best way to describe the new functions is to take a clip from the project’s wiki:
Parallel*Array (often referred to as PA) and its planned follow-ons for sets and maps, provide an easier/better way of routinely programming to take advantage of dozens to hundreds of processors/cores: If you can think about a programming problem in terms of aggregate operations on collections of elements, then we can automate parallel execution. This generally pays off if either you have lots of elements (in which case, it works well even if the operations are small/cheap), or if each of the operations are time-consuming (in which case it works well even if there are not a lot of elements). To take advantage of this, though, the aggregate processing must have a regular structure, which means that you must be able to express things in terms of apply, reduce, filter, map, cumulate, sort, uniquify, paired mappings, and so on.
So that’s what Parallel*Array does. Some people (especially those with experience with either database programming or functional programming) like this style anyway, and might use this API even without the parallelism benefits. But in turn, the fact that this style can be awkward to write out has led to all the language extension controversies about closures, function types, and related syntactic support.
Like all lightweight-task frameworks, Fork/Join (FJ) does not explicitly cope with blocked IO: If a worker thread blocks on IO, then (1) it is not available to help process other tasks, and (2) other worker threads waiting for the task to complete (i.e., to join it) may run out of work and waste CPU cycles. Neither of these issues completely eliminates potential use, but they do require a lot of explicit care.
For example, you could place tasks that may experience sustained blockages in their own small ForkJoinPools. (The Fortress folks do something along these lines mapping fortress “fair” threads onto fork/join.) You can also dynamically increase worker pool sizes (we have methods to do this) when blockages may occur. All in all though, the reason for the restrictions and advice are that we do not have good automated support for these kinds of cases and don’t yet know of the best practices, or whether it is a good idea at all.
#!
The smaller the world gets, the larger the character set becomes. Unicode isn’t just for companies dealing with Chinese, Japanese or Arabic countries anymore, however. It’s for developers working with medical journals and records, or for financial analysts who want to translate foreign documents and trends on a daily basis to search for tidbits of information not available in the Western press. Unicode is everywhere, and for a long time it’s been a real pain in the proverbial backside to deal with it in Java.
In a language like Perl, it can be simple to handle the 21 bits per character. Heck, Perl offers up to 72 bits per character, if anyone ever comes up with a way to use that much information space. But with the update to Java SE 7, Unicode becomes a first-class citizen in Java land. This update supports 21-bit characters, as well as extra symbols and formatting that makes Unicode legible to native readers and speakers.
For Unicode-intensive shops, the Java SE 7 update is an absolute must. According to some reviews of Unicode across languages, Java SE 7 comes in second only to Perl in terms of its Unicode support.
Remember when everyone complained that there was no easy scripting layer in Java? There were two ways to solve that problem. The first solution was to create Groovy, which has been fairly successful in the build and deploy circles, but still left the underlying problem: Just to script simple things, a developer still needed to learn an entirely new language. Though Groovy is based on Java, it’s still not a language any developers would have ran into in college or high school, like a Perl, Python or, these days, even Ruby.
The next best solution was for language stakeholders to port their languages to run on the JVM. And this is exactly what’s been happening for the last four years. Ruby made the first jump with JRuby. Then came the new-fangled functional languages, which effectively take the blended approach: built from scratch, like Groovy, yet run on the JVM like Ruby.
The real benefit of this “on the JVM” approach has long been that developers can access the massive array of libraries available for Java. Ruby, for example, was only recently able to handle all the various server-side scenarios Java has put up with for years, simply because the Ruby libraries for TCP, enterprise databases and other minutia have only really been under construction for five or so years now. Compare that to 15 years of Java development, and it’s obvious which language has the most mature collection of functionality.
With the inclusion of InvokeDynamic in Java SE 7, developers will now have a much easier time porting dynamic languages to the JVM. That means there’s no reason every other language in the enterprise can’t eventually be run on the JVM. JLisp, anyone?
#!
Why should anyone in the enterprise care about the new MIDI synthesizer in Java SE 7? Because it is exemplary of just why an open-source Java is better than a proprietary one.
When the OpenJDK kicked off in 2006, the biggest issue for those involved was the fact that a portion of the Java SE codebase was proprietary. Not just proprietary, but commercially proprietary. The font rasterizer, some of the encryption algorithms, and even the sound system for Java were all owned by other companies, and there was absolutely zero chance that their code would be released under the GPL.
So, work began to rip out these bits and replace them with GPL-compliant code that had been written from scratch. The effort yielded a number of interesting new packages of software, but the Gervill Software Synthesizer is undeniably a major improvement over the previous versions in Java.
So anemic were the original MIDI libraries for Java that they hold the distinction of being the first portion of the Java SE platform ever to be deprecated and destined for removal. Now, with Gervill, Java has a first-rate sound system. You may not use it in your day-to-day work with Java, but some day you’ll have to interact with it, and trust us, it’s a major improvement.
When you get right down to it, all of these fancy changes to Java don’t matter one single bit to most developers. At the end of the day, a real Java wizard just sits there and cranks out functional, simple code. And that’s why Project Coin is the most interesting and important addition to the Java platform. So large was Project Coin’s scope that its implementation was divided between Java SE 7 and Java SE 8.
Project Coin, you see, is an effort to make many small changes to Java. The kinds of changes that bring more uniformity to syntax and remove ambiguity between similar functions that may currently have to be written in different manners.
The final set of changes in Java SE 7 were as follows: Strings in switch statements, try-with-resources statements, improved type inference for generic instance creation (“diamond”), simplified varargs method invocation, better integral literals, and improved exception handling (multi-catch).
Those may not be as earth-shaking as the other changes in this list, but one thing is absolutely for sure: Before you even come near the other changes in this list, you’ll probably already have used some aspect of Project Coin. The whole point of this project was to make life easier for the day-to-day developers by simplifying the busywork.
