Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Who's driving Java?

02.19.2008
| 5384 views |
  • submit to reddit

Ted Neward has a good post asking who is the moral leader of the Java language, particularly with respect to Java 7 and the future of the various closure proposals.  I think Ted makes a fair point and certainly there have over the years been any number of strong and influential leaders that guided these kinds of decisions (like James Gosling, Gilad Bracha, Peter von der Ahe, Neal Gafter, and Josh Bloch). 

Officially, the future of Java is in the hands of the JCP but can the language itself evolve without a single guiding mind?  It certainly seems that the majority of languages out there are built around a core vision espoused by (usually) a single creator.  Java may even be unusual in having a series of visionary leaders over time.  Are committees where languages go to die?  What do you think?

Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Osvaldo Doederlein replied on Tue, 2008/02/19 - 7:29am

Yes, this lack of strong leadership - and personal, not committee/corporation-driven leadership - is sometimes a problem. Java 7 is not the worst case just because Josh and Neal disagree on closures. I was much less happy years ago, in the looong hiatus between JDK1.1 and J2SE 5.0 without any substantial language improvement. Even Tiger was relatively anticlimatic, with the compromises of erased generics (I accept most of these compromises in the name of compatibility - but I *sorely* miss efficient support for unboxed primitive types; I could put up with everything else, like wildcards... but, no ArrayList<int> sucks deep).

All languages controlled by a "benevolent dictator" suffer in the compatibility or portability, though. C++ is a major disaster in the portability between compilers of different vendors (even in the same platform), for various reasons like compiler vendors with their own agendas (e.g. Microsoft trying to kill templates for years), but mostly (IMHO) because Stroustrup was a total failure in "complexity management". He would just add piles over piles of features, without a process to mature new stuff, and always trying to keep some insane level of compatibility with 1970's K&R C. Guido's Python 3.0 will be massively incompatible with 2.x as I've read, it seems that not a single page of current Python code will even parse on 3.0 without some changes. Larry's Perl is a fiasco in evolution in the last many, many years - Perl 6 is some of the most famous vaporwares, together with Duke Nukem Forever; and judging from the Wikipedia article, it looks like a new language, to scare the hell out of any Perl devotee who has ten years of legacy code to care. Anders' C# has the better evolution of this group, but the language is growing too fast and too big, typical of marketing-driven products of Microsoft... C# 3.5 (with LINQ etc) is still manageable, but already out of reach of Joe VB Developer, without much grasp of sophisticated programming languages, and this is a huge share of VStudio users.

Right now I'm taking a good look at Scala. It contains many great ideas, especially the OO+functional integration which is the way to go, I've been convinced for years that the future needs the functional paradigm. But Scala is also more complex than Java or C#... I'm not yet convinced that I can use that on an average J2EE project, i.e. one where not all developers are very experienced and talented hackers with a solid CompSci education. A few years ago Haskell was on the rise, but I think its complexity killed its momentum. When a language becomes a playground of PhD thesis on obscure typesystem tricks (even though incredibly elegant for those mastering it), it's doomed to failure in the real world (I hope Haskell' can bring some sanity back). Scala is one of the few languages explicitly designed for good integration with Java and great performance on the JVM. I liked Groovy for having these features and also having optional static types (I abhor dynamic-typed languages), and having high-level features like closures (hopefully coming to Java 7 in their full glory - if we're not too stupid and coward, and let Java go the way of COBOL). But now I think Scala is much much much better. It's decently specified, has a mature toolset (only IDE integration needs a lot of work), and seems to run just as fast as Java, which is quite impressive if you've seen its features... and humiliates Groovy, which is still so desperately slow that makes you with for Ruby (ouch!).

Casper Bang replied on Tue, 2008/02/19 - 10:52am

The thing I dont understand is why we do not have a Java 3 today?! In the software business, we are not really hurt by wear and tear, but we are very much hurt by software entropy. A language is our main tool to get the job done, but it is also just another piece of software which needs to be maintained and refactored as lessons are learned.

I guess we can continue to patch Java up for a few more years, add more layers to the toolchain and more DSL's in the annotations... but go take a look at the class count of a JRE (17.000 last I counted) and the growing puzzler count... is anyone disagreeing that we are headed only one way and it is not for the benifit of the developer?

Osvaldo Doederlein replied on Tue, 2008/02/19 - 11:30am

Casper: we do have Java 3. In fact we have many such languages - Groovy, Scala are the best choices, while others like JRuby are promising except by inferior integration with Java code. If the Java community was to set up for a breaking-changes update, starting from scratch, trying to preserve the values of the Java SE platform but without any compromise for backwards compatibility with the Java language, the result wouldn't likely look closer to Java than Groovy or Scala... perhaps it would be much, much more distant than that, if you count Fortress, which btw is another JVM-compatible language and is also from Sun!

Now, elaborating on this idea, the problem is that none of the Java 3 candidates have gotten their act completely right. Groovy is the best in Java-like syntax and integration, has a JSP standard, but it's a dynamic-typed language,  and bets too heavily on metaprogramming... these two items make it definitely in the category "not in the spirit of Java". Groovy will NEVER succeed Java, except in niche areas where languages of its kind are good - templating, GUI development, scripting / DSL'ing, etc. This is of course a large market, for one thing I'd happily dump all Servlet/JSP/Struts code in the universe in a large black hole, and replace it with something like Grails, or even a more traditional MVC framework but with Groovy code. So Groovy may become popular enough to be considered wildly successfull, but become Java 3, no it won't. As for Scala... I'm still studying it, but it seems to miss at least one important factor - no killer frameworks. Scala will only stand a chance when they move some focus out of the language and into some cool framework/platform/blueprints/whatever that make people say, Wow, this is terrific and it's only possible because it's Scala. But please, not yet-another CRUD+web+remoting framework... I'd bet on the back-end of SOA apps, something to help writing the heart of enterprise business applications.

Mike P(Okidoky) replied on Tue, 2008/02/19 - 11:43am in response to: Osvaldo Doederlein

Osvaldo, Groovy slow? I wasn't sure myself. I assumed after not having tried it for a while, it would have been the exact same performance as Java for primitives at least.

I won't go in to the details how I did a quick and dirty test, but not measuring startup/warmup, when doing some straight forward looping and math, Groovy appears very roughly 450 times slower. Changing the primitives to Integer/typeless, Groovy appears roughly 13 times as slow. Perhaps the Groovy mistake is to assume we're all only interesting in doing some straightforward business logic. End of day, yes, I now also perceive Groovy as a performance pig and I'll think twice of using it for anything that requires any somewhat substantial amount of processing (desktop and server apps, whatever), no matter how delicious the syntax sugar is. It reduces Groovy to uses where you would otherwise use Javascript perhaps...

ps. even when using primitives, a decompile of the generated class file reveals things like:
ScriptBytecodeAdapter.compareLessThan(i, new Integer(0x989680))

pps. a quick Google led to http://www.jroller.com/rants/entry/why_is_groovy_so_slow
It's bad, it's really bad.

Going with Ruby... lol.

Can't say I like Python either.

Hopefully there will be some progress in Java soon, and hopefully it won't become convoluted in a way where it becomes difficult to work together with my less experienced colleagues.

Alex Miller replied on Tue, 2008/02/19 - 11:34am in response to: Casper Bang

I sympathize with this point but question whether it's the right direction or not.  I definitely agree with your point about entropy but not all software is created equal.  Some software can handle dramatic changes to it's surface area (like an in-house app where you completely control the environment).  Some can handle measured evolution (like an open source library).  And some should change slowly with great consideration (like a language).  At least that's my opinion. 

People tend to rally behind the Java 3 / Java restart idea but I think there is enormous value in having one Java.  The value comes from the vast set of enterprises that employ Java developers and use Java technology.  They are the reason Java is successful.  If you make a Java NG, you endanger that by muddying the waters.  Employers aren't sure which Java a developer knows, OSS projects would need to target one or both platforms, you add yet another dimension for every testing and deployment scenario out there, effort at improving and fixing Java is split, etc.  

Now, it still may be worth doing.  But that's a really hard argument for those actually footing the bill due to the built-up inertia in the enterprise.  

I'd say if you really want a different language (or a different JDK), then that's a new language.  Fork the VM or the JDK and do what you will.  Or just use one of the already excellent languages that runs on the JVM now.  I say Java is what it is and despite it's (considerable) flaws, that's what you get.  I still like it.  

Casper Bang replied on Tue, 2008/02/19 - 12:26pm in response to: Alex Miller

My point was just that people (incl. myself) tend to like the feel of Java. The fact that it is statically typed, that it's contractual driven and that it honors C/C++ block semantics etc. I don't really understand those who say "We already have Java 3 in Scala or JRuby or...". What I dream of is not a completely new language or radical paradigm change, I just want Java development catering a bit to KISS again as it originally did, with its flaws fixed and a bit more power in the language assisting me in my daily work. This seems to have been the vision of C#.

I acknowledge the legacy requirement and current investment, but also don't see why it could not be solved by code migration tools or simply running multiple JVM's. That would allow us to push the state of the art without nescesarily being stuck in legacy mud OR being forced to jump to a completely new language altogether.

Why is it better to create a new language than evolving and fixing an existing one, is it all about the name? Don't we already have the versionability problems you describe, i.e. will the question "Do you know Java?" really tell an employer anything in todays world with JEE, JME, JSE and a gazillion frameworks? Personally, I don't think this has been the case the last 5+ years. But perhaps I am alone in thinking this.

 

Osvaldo Doederlein replied on Tue, 2008/02/19 - 1:54pm

Alex: certaily there's also a huge value in preserving the Java language, for both performance and backwards binary compatibility. In my mind, the idea of a Java 3 language (breaking compatibility and changing some compromises, e.g. a bit less performance in exchange for a much superior typesystem) is not a plan for replacement, but for coexistence.

But the "traditional" Java cannot be frozen. For one thing, I'm in favor of adopting, in Java 7, the best, most complete version of closures that are viable to implement with a good compatibility story (that's why we need traits like compatibility with single-method interfaces), even if it's not the simpler, most elegant closure spec in the world. Even though I also want a "Java 3" language that starts when Java ends, and does right what Java cannot due to compatibility, like a modern static typesystem (with type inference and no-compromise generics).

We need both choices. Even if some Java 3 champion emerges as a successfull, popular language, I still need the old good Java... I have projects that are still on 1.4 compatibility, because my client uses an application server that's just recently moving to Java5. In these conservative environments, the odds that my contractor will allow me to use any alternative language in this decade, is a very very small number. So, at least I can move to newer releases of the True One Java, from time to time when they update the appserver. Compared to java 1.4, the relatively modest language enhancements of 5.0 (like erased generics) are a breath of fresh air, and hopefully, Java 7 will give more of that

Alex Miller replied on Tue, 2008/02/19 - 2:55pm

@Osvoldo: To me, talk of "Java 3" implies something that is similar to the Java language and JDK but adds or removes stuff with no regard to backward compatibility.  And my point is that if we had that, it would be draining in many ways on the Java community.  Seems like a better use of energy to evolve Java Classic rather than split off a Java 3, if you know what I mean. :)  And if you're not happy with it, take your pick of already existing JVM-based languages.

BTW, the odds that you'll be using a Java 7 based app server this decade are also very very small. :) I'd say it's optimistic to expect Java 7 even in late '09 plus you'd need a new EE version based on it plus vendors making the shift.  I'd guess more like 2011.  If anyone still uses an app server by then anyways.    

cowwoc replied on Wed, 2008/02/20 - 12:17am

I disagree.

If Java3 "drains" the Java community it means it is having a serious impact (i.e. people want to use it) and eventually it would replace Java2 altogether. This is a goal we should strive towards. There is nothing wrong with breaking compatibility once every 10 years. 

Jeroen Wenting replied on Wed, 2008/02/20 - 2:45am

It's quite clear that Java is at the moment purely marketing driven. The entire "featureset" for 1.6 and 1.7 (including, and maybe especially "closures") is driven solely by marketing concerns fueled by those who claim that "Java is dead if it doesn't have XXXXX".
This is a sad state of affairs, and is causing many (including myself) to look very seriously at alternatives so that we'll not be the last ones to leave the sinking ship which Java is looking ever more to be turning into with the "leadership" Sun's (and IBMs and others') marketing department is imparting on the JCP.
The problem isn't the existence of the JCP, but the people in it and the people those people are responsible to (who are marketing managers and CFOs rather than programmers).

Osvaldo Doederlein replied on Wed, 2008/02/20 - 6:38am

@Jeroen: There's nothing "marketing-driven" in proposals like closures. I (and thousands of other closure supporters) have been yelling that Java needs closures since JDK 1.0-beta. James Gosling himself admits that the original Java design only missed closures (and generics!) because they didn't have time for that... I think Bill Joy said that closures were even prototyped, but removed due to feedback from some users were worried about the extra, implicit heap allocation necessary to capture non-final local variables (which is today a pervasive cost, e.g. in autoboxing and enhanced-for over collections). If Java was born as an open-source or academic project, and not as a commercial project with marketing-driven deadlines and "customer feedback", then we'd have closures and generics and perhaps other goodies very early, and we wouldn't have to debate the value of these fundamental features as late as 2008. To me, these discussions are stupid, it's exactly like arguing whether a modern OOPL needs to be strong-typed, or to have a garbage-collected managed memory, or be paired with a rich standard class library... there are zero OOPLs designed in the last decade - or even older, but becoming popular roday (Ruby etc.) - that lack such basics. Java cannot be abandoned to become the ugly duck of OOPLs - with or without the options of a "Java 3" replacement.

It's quite possible that Sun, and some fat slow butts sitting in JCP chairs (huge application server verdors etc), waked to the need to modernize the Java syntax due to the competition of Microsoft's .NET and C# - and today, from other sources like the RoR fad. So yeah, perhaps you have a point that the motivation for improving the Java language is marketing-driven. But that's still better than continuing to write code that's polluted by unsafe typecasts and horrible inner classes, as my hair turns gray and then white... I mean, I miss some things from the eighties, e.g. classic rock bands like The Police, but not the programming language technology. ;-)

Casper Bang replied on Wed, 2008/02/20 - 8:39am

@Alex: In regard to Java 7 based app servers being far and beyond the event horizon that's probably true, but perhaps that says more about the drag of the JCP and corporate interests involved than any technical merits we as floor developers would be interested in (and ultimately then also our employers).

So I guess it boils down to the fact that Java tries to cater to too many groups, in the end not really satisfying anyone... sort of like a duct-taped worn down Swizz army knife or leatherman tool, robust and pervasive in the field but not particulary good at any one thing now. All I want is a new one without duct-tape and with sharp blades.

Jeroen Wenting replied on Thu, 2008/02/21 - 1:46am

No Osvaldo. 10 years ago Gosling said Java didn't need closures and they were not included because they were a bad idea.
A few weeks ago he suddenly decided to rewrite history and state that he'd wanted them all along but decided not to put them in because he didn't have the time...

Whichever is correct (and I think it's the first) doesn't matter however. Retrofitting them is a BAD idea as it compromises the integrity of the language syntax and semantics.

And it IS purely marketing driven. All the "proposals" (really ransom notes if you read them) are based around "Java must have closures or XXX will overtake it in the field of YYY".

There's no real need for them, apart from some academics wanting to have their name under a big JSR and a major change in the language, and some marketeers wanting another "feature" in a list they can use in advertising to show off everything Java has.

Osvaldo Doederlein replied on Thu, 2008/02/21 - 7:24am

@Jeroen: I suppose you're talking about Gosling's blog, quote: "Closures were left out of Java initially more because of time pressures than anything else.". But I remember reading similar comments many, many years ago, just couldn't find'em now. But I couldn't find opposite comments either, and I don't remember that JG has ever stated that closures were a "bad idea", just like that. Now, he may have said something slippery and ambiguous, parseable as that, by the time he had to stand behind the introduction of inner classes ;-) "Last week?" the original BGGA proposal is from August 2006 and its subscribed by James, along with Peter von der Ahé and Neal Gafter. BTW it's not just Gosling... all "fathers of Java" - Bill, Gilad, Neal - have been lobbying for closures all these years.

These "ransom notes" that you mention are not FUD. There are reasons why other languages have been gaining momentum, and that an increasing number of top-notch Java developers are considering alternative languages. The major reasons why Java is not yet being severly hitten by competition, are that:

1) The Java  platform is much bigger today than the Java language. I can put up with some outdated traits of the language, because the platform as a whole is great overall, and this overall is what makes my life easy and my projects successfull.

2) Immaturity and repeated blunders of the competitinon. For example, Ruby's core technology (VM and other infra) is mediocre. Groovy's performance is a pig, and the project took too much time to overcome basic issues of design, burning precious momentum. In the funcional camp, Haskell was on the rise but IMHO its momentum succumbed under its own weigh as the language became the playground of PhD thesii. Microsoft .NET languages have their appeal limited to Wintel-specific projects and developers who can put up with Microsoft, don't care about open source and other values. And so on... but you can't write the competition off, believing that they won't ever get their act together.

Anyway, the reason why I want closures is not that language X or Y has them now. I miss closures since JDK1.0-beta. JDK1.1, with inner classes, only made a point that we needed closures. New languages riding the hype wave, like Ruby, are only providing more evidence of that, and allowing us to make a stronger argument.

cowwoc replied on Thu, 2008/02/21 - 8:08am in response to: Osvaldo Doederlein

I don't care who is peddling Closures. The fact of the matter is that Joshua Bloch makes a good point: it has a bad power-to-weight ratio.

Once they fix that I'm more than willing to reconsider it, but not before.

Allen Halsey replied on Thu, 2008/02/21 - 8:48pm in response to: Osvaldo Doederlein

@Osvaldo: "I remember reading similar comments many, many years ago, just couldn't find'em now." Perhaps this account by Patrick Naughton is what you were looking for?

[Bill Joy] was often comparing Oak to more complicated and elegant languages like Python and Beta. He would often go on at length about how great Oak would be if he could only add closures and continuations and parameterized types. While we all agreed these were very cool language features, we were all kind of hoping to finish this language in our lifetimes and get on to creating cool applications with it.

http://www.artima.com/weblogs/viewpost.jsp?thread=173229

 

Osvaldo Doederlein replied on Mon, 2008/03/03 - 3:43pm

@Jeroen: Just for the record, I found that quote. It is actually from Guy Steele, who said:

Actually, the prototype implementation *did* allow non-final
variables to be referenced from within inner classes. There was
an outcry from *users*, complaining that they did not want this!
The reason was interesting: in order to support such variables,
it was necessary to heap-allocate them, and (at that time, at least)
the average Java programmer was still pretty skittish about heap
allocation and garbage collection and all that. They disapproved
of the language performing heap allocation "under the table" when
there was no occurrence of the "new" keyword in sight.

(...)

One of the early design principles of Java was that heap allocation
occurrs if and only if a construct involving the "new" keyword is
executed. Adding full-blown closures violated this design principle.
(Dynamic class loading also violated the principle, but users seemed
to be comfortable with that, perhaps because they believed that
"once the computation got going" no more heap allocation would occur.)

but,
Other features for Java release 1.5 will perform certain kinds
of autoboxing, which also violates the design principle. This fact
will make it easier to argue for restoring full-blown support
for closures in the future.
Enhanced-for also violates that principle (for any collection), and nobody complains.

 

Alex Miller replied on Mon, 2008/03/03 - 4:05pm

Awesome reference!  Thanks for digging that up.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.