Javalobby - Comments for "Who's driving Java?"

Awesome reference! Thanks

puredanger — Mon, 03 Mar 2008 16:05:05 -0500

Awesome reference! Thanks for digging that up.

@Jeroen: Just for the

opinali — Mon, 03 Mar 2008 15:43:12 -0500

@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.

@Osvaldo: "I remember

ahalsey — Thu, 21 Feb 2008 20:48:49 -0500

@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

I don't care who is peddling

cowwoc — Thu, 21 Feb 2008 08:08:42 -0500

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.

@Jeroen: I suppose you're

opinali — Thu, 21 Feb 2008 07:24:53 -0500

@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.

No Osvaldo. 10 years ago

jwenting — Thu, 21 Feb 2008 01:46:09 -0500

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.

@Alex: In regard to Java 7

casperbang — Wed, 20 Feb 2008 08:39:36 -0500

@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: There's nothing

opinali — Wed, 20 Feb 2008 06:38:48 -0500

@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. ;-)

It's quite clear that Java

jwenting — Wed, 20 Feb 2008 02:45:49 -0500

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).

I disagree.If Java3 "drains"

cowwoc — Wed, 20 Feb 2008 00:17:44 -0500

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.

@Osvoldo: To me, talk of

puredanger — Tue, 19 Feb 2008 14:55:40 -0500

@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.

Alex: certaily there's also

opinali — Tue, 19 Feb 2008 13:54:23 -0500

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

My point was just that

casperbang — Tue, 19 Feb 2008 12:26:31 -0500

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, Groovy slow? I

okidoky — Tue, 19 Feb 2008 11:43:13 -0500

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.

I sympathize with this point

puredanger — Tue, 19 Feb 2008 11:34:21 -0500

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.

Javalobby - Comments for "Who&#039;s driving Java?"