Modern Java? Isn’t that an oxymoron?
At XPDay this year Julian Kelsey and I presented a session entitled “Refactoring to Functional Style”. It seemed to be pretty well received and drew a lot more people to the room than, I think, either Julian or I ever expected. The theme of functional style in Java, and other common languages, continued throughout the conference. The ideas showed up in several other sessions as side topics and in one more session specifically about testing functional style programs that was led by Nat Pryce. There seemed to be a new way of working in Java that was starting to emerge.
Unfortunately there wasn’t much for other people get their heads around. Even between those who were part of the conversations at XPDay I don’t think it was clear what was meant by ModernJava. I took a first stab at trying to define it (somewhat curtailed by the number of people being mentioned in the tweet, though).
Julian expanded on it a little with the ideas that he kept trying to hammer home during the conference.
The origins of my definition
I’m an unashamed Perl guy. Much of the way I think about programming is informed by my use of that language. One of the formative moments for me was when I read MJD’s Higher Order Perl:
A well-known saying in the programming racket is that a good Fortran programmer can write Fortran programs in any language. The sad truth, though, is that Fortran programmers write Fortran programs in any language whether they mean to or not. Similarly, we, as Perl programmers, have been writing C programs in Perl whether we meant to or not. This is a shame, because Perl is a much more expressive language than C. We could be doing a lot better, using Perl in ways undreamt of by C programmers, but we’re not.
Then you can stop writing C programs in Perl. I think that you will find it to be a nice change. Perl is much better at being Perl than it is at being a slow version of C. You will be surprised at what you can get done when you write Perl programs instead of C.
Those few paragraphs at the start of that book changed the way that I saw languages forever after. “Perl is much better at being Perl than it is at being a slow version of C.” How many times have we seen our favorite language languish as a slow dialect of C than what could be achieved if we just opened ourselves up to all of the features available?
The profound impact that HOP had on me caused me to start pushing at the boundaries that I saw in languages. Why do I need to write a C-like for loop? Do I need to limit myself to the primitives available in the language? How else could I do all of these things that the language asks me to take for granted?
Several years ago the seeds sown by HOP (this is my interpretation of events) in the Perl community blossomed into a movement toward a new way of view what had become an old and tired language. A period of stagnation in releases and slow adoption by distros of new releases when they did happen had caused people to stop noticing new features of the language. A proliferation of CPAN modules that tried to address some of the deficiencies in the language caused confusion about where to start for those new to the ecosystem.
Damian Conway put a stake in the sand with his book “Perl Best Practices.” For a community that was based on TIMTOWTDI, being told that there might be a set of standard practices acted as a bit of a wake-up call. The stake was driven a bit deeper with “Modern Perl.” Some consensus started to form around the idea that perl 5.10 is not, and so should not be treated like, perl 5.005. The community started to talk about how to use this new language that they had been neglecting.
This all brings us to Java. A language that in no way has languished like Perl did. However, it has moved on like Perl did. New libraries have come out. Small changes to the language have opened up new possibilities. Old features start to get ignored. Taken as a whole what does a modern Java start to look like? I can’t answer that question completely, but I can say what I think it includes.
The definition that I put up on Twitter hinted at using what we have to its fullest extent. That is what I am looking for and I want libraries and frameworks that support me in those endeavors. So here is what I see right now as Modern Java:
- Adopting a functional style and using functional techniques.
- Limiting mutation to small, controlled scopes supported by a library like Guava.
- Pushing OO to the edges of the system. Eg smaller, immutable value objects and larger, limited-mutable behavior objects held together by functional style “glue”.
- Using the language to express our domains rather than our implementation. Compose from technical building blocks to the business domain without leaking the technical details through.
The first 3 points are all there to support the last one. Modern Java is about pushing the limits of the language not to get more clever code, but rather to allow us to express our programs at a higher level of abstraction. I want to be able to read my domain in the code and limit the amount that underlying frameworks and libraries leak through. These techniques seem to get closer to that ideal.