Posted
by
Soulskill
on Friday November 12, 2010 @10:14AM
from the can't-we-all-just-get-along dept.

snydeq writes "Fatal Exception's Neil McAllister writes about what could be the end of the Java Community Process as we know it. With the Apache Software Foundation declaring war on Oracle over Java, the next likely step would be a vote of no confidence in the JCP, which, if the ASF can convince enough members to follow suit, 'could effectively unravel the Java community as a whole,' McAllister writes, with educators, academics, and researchers having little incentive to remain loyal to an Oracle-controlled platform. 'Independent developers could face the toughest decisions of all. Even if the JCP dissolves, many developers will be left with few alternatives,' with .Net offering little advantage, and Perl, Python, and Ruby unable to match Java's performance. The dark horse? Google Go — a language Google might just fast-track in light of its patent suit with Oracle over Android."
Reader Revorm adds related news that Oracle and Apple have announced the OpenJDK project for OS X.

They are the one and only company that can pull this thing straight. They have the money, they have proven their commitment to OSS, so I sincerely hope they step in and fix this. It's too important to let Oracle mess everything up.

Apache will only break the JCP if they don't win. There is logic behind them trying to stone wall Java 7 and they want Java to be Free or the JCP to end.
IBM is after the test kit to get the patent rights so that's how they get Java to be theirs if they win, but it requires a test kit.

I prefer Googles route and just want to see the patents burn on a legal bon fire, but I'll go with Apache if they are successful too. IBM sounds too much like the friend of my enemy who looks poised to stab my enemy but mi

Maybe I don't know enough about JCP's value to Oracle, but it seems to me that Oracle is the kind of company that would happily get rid of other people's input in their product, and then blame it on Apache.

What google is doing is very different then what ms did.
MS made a Java Virtual Machine that would run java complied code and run custom MS only stuff like DirectX if you compiled it with there stuff and thus wouldn't work anywhere else.
Google is using the java language to allow people to write android code that isn't java byte code at all but rather compiled to work on their OS. If you try to run java on an Android it won't work because it's not really a Java Virtual Machine sitting on it. It's the Dalvik Virtual Machine [wikipedia.org] which isn't even using the Name Java to claim anything or imply that it runs Java Compiled byte code. Google is treating Java as if it were a Language and not as a platform which is what you have confused.
People like you who say Google is doing the same s--- clearly didn't write Java code for the Sun and MS JVM back with Java 1.1, and don't understand what it is that MS did that hurt Java in the first place.

For 'MS Java', Microsoft gladly took Sun's code and proceeded to use it to build an incompatible version with a vast market share behind it. Essentially it was an attempt to use Java to break cross-platform Java - all the while secretly cloning it so that they could eventually use their market share to promote something else that isn't cross-platform at all. They paid a big fine, chalked it up to cost of doing business, and got all the benefits of Sun's R&D in the process.

Not trolling, but is Java really worth the fight at this point? Years ago it had the promise of the 'programming panacea' but now it's just another programming language. Yes, it's deeply ingrained in the internet and server landscapes, but that isn't going to change if Oracle wants to start charging fees for integration with their middleware and for some advanced utilities.

The mobile/embedded world is a different animal but Google certainly has something in the works to dodge the Android uses Java mess. Once Google releases a new VM that avoids the Java comparisons the rest of the mobile/embedded world will transition to it and leave Oracle holding an empty bag.

It won't be easy but look at how far Android developers have come in the short time Android has been available. Google isn't flawless but they won't want to pay any licensing and they'd rather spend the cash on developing an alternative.

Well it never had the promise of the "programming panacea". But really all this shouting is really just everyone fighting over the "its mine" java pieces.

When java first came out there was no JCP. Sun just decree what was and what was not "java" (with some hilarious results). The parts of the "for" pay JVM have *always* been this way (Jrockit), but some features are going to be made free. And finally we have a proper apple/"java" JVM. Its lots of good news for people in the know.

99% of the comments and cries of the death of java are clearly said by people who just don't work with java as its really done (at least commercially). This is a storm in a tea cup, meet the new boss, not as bankrupted as the old boss.

My only hope is that the patents get ruled invalid. Hopefully that will pave the way for more software patent invalidation.

Not really. By itself C++ is more portable than Java et al. In fact, the problem is rather that C++ is too portable (ie general)!

For example, for I/O there is the basic notion about files for example, but anything more specific (like, directories or how to get a list of files etc. And don't even mention graphical thingies!) the standard is completely silent, precisely too keep things as portable as possible.

That means if one wants non-general things, one has go outside the C++ standard. Preferably there is

Honestly? You're better off abstracting off all of your business logic into the library of your choice (as long as there are hooks on each platform - C is dead safe, almost anything would work if you did it as a little 'server' type application and communicated over sockets, your choice). Then write your GUI, from scratch, for each platform.

Why? For one thing, design guidelines are different on every platform. An OSX app, a Linux app, and a Windows app shouldn't use the same controls in the same places

The language is portable to any platform, very powerful, and isn't at-risk of suffering the same fate as Java.

The criticisms of it are mostly fluff in my opinion...people trying to say that their personal stylistic perferences should be industry standards, or justifying their own lack of skill by saying C++ makes things harder than they should be, etc.

C++ is not an application-level programming, but a systems-level one. Java plays both roles. Furthermore, it is not the language that is of value, but the enormous (and standard) class library; a defined component model standard for distributed computing; a defined component model standard for thin-client development; a defined standard for persistence; a defined transactional model; etc, etc, etc.

Many of the things mentioned above (sans the hiccups and false starts) have been refined, tested and tried on

C++ has an astonishingly complicated grammar, which means that compilation takes forever and other tools don't work as well as they do for languages with simpler grammars, like C or Java.

C++ doesn't really have compile-time encapsulation: if you add a private member to a class, you need to recompile everything that uses that class even though the class's public interface didn't change. That woudn't be so bad in and of itself except that C++, again, takes forever to compile.

C++ also doesn't have run-time encapsulation or really any serious run-time error checking that you don't do yourself. Yes, it's for performance reasons, but some people are working on problems that aren't performance-critical and would prefer a language that doesn't pound nails through our dicks. (if it doesn't have encapsulation, why do they call it "object oriented?")

C++'s exception support is hilariously broken. 1) If you've allocated some memory for an object, and then you throw an exception, you don't have that pointer anymore, and because C++ doesn't have garbage collection you've just leaked memory. The only way around this is to implement garbage collection yourself; C++ weenies call this "RAII" and if they're really far down the rabbit hole they sometimes don't even realize that it's just them implementing shitty reference-counting garbage collection. 2) You can't throw exceptions in destructors. Well, you can, but when an exception is raised, all the destructor for objects on the stack are called, and if one of them throws an exception while you're already handling an exception the program terminates. Seriously, that's what the standard says, I'm not making this up. So you can't throw exceptions in destructors, or call any function that might throw an exception. 3) In every major compiler I've used, exception handling support is implemented in such a way that it slows down every function call you make. Yes, it's only slightly, but it means if you really care about performance, you can't use exceptions, and if you don't care about performance why the hell are you using C++? And even if you want to use them they're almost worthless; I mean you can't even get a goddamn stack trace out of them. You can throw arbitrary objects, but the catcher can't figure out what the hell the object is because of C++'s lack of reflection. Etc.

C++, in an effort to be sort-of compatible with C (except where it's not compatible with C, which makes you wonder why they bothered in the first place) keeps all of C's features while creating duplicate features with their own new, horrifying problems. So you have C++ templates, but you still need to deal with C macros. You have std::vectors, but you still need to deal with arrays. You have std::string and char*, and neither is particularly good. Making things even funnier, C++ doesn't like to use its new features and prefers the C stuff: a string literal is a char*, not a std::string, the arguments to main() are int argc, char** argv, rather than something sensible like std::vector args, iostream does not take std::string for its filename arguments, etc.

While we're on the subject, the standard iostream is pants-on-head retarded. The streams are stateful, which means that std::cout foo; depends not only on the values of cout, foo, and the overloaded left bit shift operator, but also on whatever's been sent to cout in the past. You send values like std::hex or std::setw(int) to set parameters, so when you grab a stream you don't really know what the fuck will happen. This is supposed to be an improvement over printf? They're verbose as hell, too: say you're printing some hex numbers. In C, you'd use "printf("0x%08xn", x);" for int x. In C++, you use "std::cout std::hex std::setfill('0') std::setw(8) x std::dec std::endl;" It's absurd.

The standard library is completely anemic. I'm not even talking about GUI stuff, here: there's no platform-independent way to do some really basic stuff like pausing for a length of time, or starting a new thread. You can use so

You could have stopped here and avoided a lot of TL;DRs, but I must say I agree with everything you wrote.

In the 1980s I started programming in C and fell instantly in love with it. It's still my favorite today, even if I use a lot of Python where it can do the job.

Imagine my disappointment when I first met C++. I had heard people mention this "improved" C and was curious to use it. I got a book named "Turbo C++ Disk Tutor" which came with four 5.25" floppies with the compiler included. The book itself was

I'll add one more thing: debug performance. Most C++ libraries (certainly the STL) are written for prettiness more than performance and thus rely heavily on compile-time optimizations. Now, it's true, a fully optimized iterator generates the same code as a raw pointer, but that's irrelevant when you've got a debug build that runs several orders of magnitude slower than a release, and the bug you're tracking down is on the third pass over vertex 892,472 of a 2,00

C++ has an astonishingly complicated grammar, which means that compilation takes forever and other tools don't work as well as they do for languages with simpler grammars, like C or Java.

Modern c++ compilers are extremely fast; not as fast as Java compilers, but considering they do much more many things (templates for example), then they are quite fast. They are so fast that compiling large code bases with them is extremely viable, and it's a task done everyday by millions of developers.

C++ doesn't really have compile-time encapsulation: if you add a private member to a class, you need to recompile everything that uses that class even though the class's public interface didn't change. That woudn't be so bad in and of itself except that C++, again, takes forever to compile.

How is that a big problem? you make it sound like it's a colossal problem, but in reality, it's not. Unless your class is used by every other class or function, the recompilation is minimal.
The benefit of this is that you can use value classes in c++, whereas in Java you can't, every class is by reference, which is stupid.

C++ also doesn't have run-time encapsulation or really any serious run-time error checking that you don't do yourself. Yes, it's for performance reasons, but some people are working on problems that aren't performance-critical and would prefer a language that doesn't pound nails through our dicks. (if it doesn't have encapsulation, why do they call it "object oriented?")

If you refer to arrays, vector::at() is your friend. If you are not disciplined enough to use it, then you don't belong in programming. You can even use smart pointer classes that throw a null pointer exception, if you really want it. In any case, it's not anything like you say it is.

1) If you've allocated some memory for an object, and then you throw an exception, you don't have that pointer anymore, and because C++ doesn't have garbage collection you've just leaked memory. The only way around this is to implement garbage collection yourself; C++ weenies call this "RAII" and if they're really far down the rabbit hole they sometimes don't even realize that it's just them implementing shitty reference-counting garbage collection.

RAII is actually superior to Java's garbage collection. It's much more critical for big applications to release as much memory as possible upfront.

2) You can't throw exceptions in destructors. Well, you can, but when an exception is raised, all the destructor for objects on the stack are called, and if one of them throws an exception while you're already handling an exception the program terminates. Seriously, that's what the standard says, I'm not making this up. So you can't throw exceptions in destructors, or call any function that might throw an exception.

How is that even a problem? Java's unpredictable finalization order is way more of a problem.

3) In every major compiler I've used, exception handling support is implemented in such a way that it slows down every function call you make. Yes, it's only slightly, but it means if you really care about performance, you can't use exceptions, and if you don't care about performance why the hell are you using C++?

Read this first: http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf [open-std.org]
Exception handling has a cost only if there are non-trivial destructors to execute. Since C++ allocates most objects statically, the performance cost is factored into the program as if no exception was thrown. On the other hand, in Java, you pay the price in garbage collection.

And even if you want to use them they're almost worthless; I mean you can't even get a goddamn stack trace out of them.

Modern c++ compilers are extremely fast; not as fast as Java compilers, but considering they do much more many things (templates for example), then they are quite fast. They are so fast that compiling large code bases with them is extremely viable, and it's a task done everyday by millions of developers.

That depends on who's header files you have to include. Often someone's API will be so template-heavy that it takes a full minute (per compilation unit) just to parse their silly headers. Which is sad because I've never had the same issue with enormous C headers or when referencing a good half of the.NET runtime in a C# compilation.

And yeah, that's a minute on a modern compiler on a fast machine.

How is that a big problem? you make it sound like it's a colossal problem, but in reality, it's not. Unless your class is used by every other class or function, the recompilation is minimal.

The real problem there, which the GP missed, is the fact that every type must include the header of every type i

Often someone's API will be so template-heavy that it takes a full minute (per compilation unit) just to parse their silly headers.

Simply not true. I use boost heavily on a 120 kloc project, and it takes under a minute to compile everything from scratch. And I use quite a lot of boost features.

Which is sad because I've never had the same issue with enormous C headers or when referencing a good half of the.NET runtime in a C# compilation.

You are comparing apples with oranges. Neither C or C# have templates.

The real problem there, which the GP missed, is the fact that every type must include the header of every type it contains a value member of in its own header. So if I want to keep d3d11.h out of my UI code, then my bridge renderer classes must either dispatch through virtuals, a tedious PIMPL, or not actually use any D3D types as value members, complicating other code for no good reason.

It's not a problem at all. First of all, the compiler will only parse a header once, if guarded by #ifdef. Secondly, you can use precompiled headers.

Link-time code generation is old news, object sizes could be resolved then.

The number of things that can be done in link time is limited. Object sizes play a big role in optimizations, and you can't do so

Big Blue is probably one of the biggest Java development firms in the world. I'm guessing here, but their expenditure on the JVM itself probably rivals Sun's, plus most of their apps either support Java, are partially written in Java, or completely written in Java, and often ship/embed Java (if you have 10 IBM products installed on your machine, you probably have 11 copies of Java).

Their dependence on Java is, I think, obvious. As is their long-running feud with Oracle in the database sphere. On the other hand, as recently as about 7 or 8 years ago, from what I can tell, AIX spent more money optimising their platform for Oracle than they spent optimising for DB2. Not sure if that's still the case. IBM competes fiercely with Oracle (software) and works closely with them (hardware). I'm not sure why IBM wants to allow the balance of power to shift more in Oracle's direction, actually.

Or is open source just too tribal and fragmented to coordinate on something so big and cross-disciplinary?

I'm tempted to respond to this with "Hammer, mean head-of-nail", except that we have projects like Linux, FreeBSD, KDE, Gnome. Even though they are competing, they are big and seem to be quite cross-disciplinary. Likewise there's GCC, which could be considered the same (and lacking serious FOSS competition).

More likely, nobody has felt the need, given what is currently available.

>You know, this is very puzzling. Why hasn't FOSS come up its own managed runtime+language stack?

The strength of Java is less in the language and more in the widespread adoption of enterprise frameworks. I have less appreciation of the language itself than I do for the ASF toolchain and for Spring. I realize that Python has parallels for these things, but they tend to not be used in the places where Java is used, by which I mean places that have ever given me paychecks.

When these threads come up, I'm usually shocked by how little awareness there seems to be of just how much business software is in Java, and how much of that responsibility rests on various Apache projects over the years. It would be a real surprise to see any Enterprise Java that doesn't link at least some ASF libraries, and usually there are *many*.

Apache, not Sun or Oracle or IBM is the big name in Java. I hope the Apache group can make a unified front and play their cards effectively, but so far they are acting like victims.

Understanding that the entire toolchain and widespread adoption is the most important part of getting it. We all (at least, if we were there for it) know how Java happened - the short version is that Sun positioned it as an alternative to the MS Borganism that many companies were rightly afraid of back then.

I still think Java pretty much sucks. But it has the tools, and perhaps more importantly, a huge number of able bodied code monkeys who can write it.

Enter Oracle. The entire strategy that they've pursued forever is not much different than what Microsoft tried - build or buy essential parts of the stack, and then march up and down it to dominate your category, then extract as much rent as possible. It works better in the enterprise space and is bloodier because there are fewer players. (Microsoft's ecology was too varied with too many players to really dominate like Oracle can.)

So, Oracle's strategy is obvious. They own Java, and thus indirectly can manipulate the terms of output of thousands of developers. They don't care about people liking them, and inertia means they can extract rent for a long time (Even if a second Sun/Java moment happened - say, Parrot v. Java, ramp-up for Parrot to fill the niches, get solid, debugged libraries for everything, get widely deployed, and get thousands of developers up to speed takes how long?)

They don't give a shit about Apache, or developer goodwill [tbray.org]. The for-profit players like IBM have different strategies, but keep in mind that their goals are profit maximization, too.

So there are some potentially interesting strategic plays to be made between the various players, but anyone with a bit of experience with the business side of the industry has seen this show before.

You mean, apart from Perl, Python, Ruby, GNU Smalltalk, Pharo, Lua, Io, and so on? Probably because they solve a problem that is only really applicable in the closed-source world: needing to run the same binary on multiple operating systems / architectures. If you have the source code, [Objective-]C[++], Pascal, Fortran, or whatever is just as portable as Java, if not more so.

[Objective-]C[++], Pascal, Fortran, or whatever is just as portable as Java, if not more so.

Show me a GUI "Hello, world!" that'll run on every platform Java does - even if Java windows look like shit. Java isn't just a cross-platform language, it's also a cross-platform toolkit that hides all the OS specifics, far more than any of the languages you mention.

Anyone who's developing thick-client GUIs in this day and age is a fool.

Right, except when you want to do anything more advanced than basic text/form manipulation. If you go beyond that, it takes 10x as long fighting with javascript/dom/css/etc wedging your UI into html, than the effort it takes to port it to 20 different platforms. There is a reason html is adding a canvas tag. The problem with canvas, is that its the equivalent of giving a modern UI programmer an assembler.

It's an excellent point and it's well-taken, but none of those are really what the OP is talking about. Parrot is really the pertinent example, though it has arisen out of Perl (more-or-less); none of the other systems you name are really a generic managed runtime.

The answer to the question, why isn't Parrot more widely-used is to look at context. We're not comparing Parrot to (say) Python's bytecode; if we did, Parrot looks like a runaway success. We're comparing Parrot to the JVM, but that's not a fair comparison, because people write languages that target the JVM to make life easier in Javaland, not because the JVM is a technical achievement.

I know C, C++, Perl, Python, Ruby, LISP, BASH, awk, FORTRAN (don't ask, math departments like their FORTRAN) but none of these can take the place of Java's speed comparable to C++ (3 times slower), portability including GUI (compile once and run anywhere), availability of cross platform mature tools (even though I love my VIM), availability of mature libraries and frameworks etc.Really, if JVM went away currently there is nothing that can replace it. C#/.NET is the complementary counterpart of Java/JVM but

Not really: they also solve the problem of delivering compiled code in a form that can be easily sandboxed

Sandboxing is the job of the OS. Every program that runs is isolated from others and from the hardware by the OS. Every interaction with anything outside of its address space has to go via the OS.

Take a look at the list of security vulnerabilities in the JVM, CLR, Mono, or any JavaScript implementation. These bits of code are all incredibly complex - they have to be to get good performance - and small bugs in them can allow malicious code to escape. The operating system's protection, in contrast, is

Maybe I'm being naive, but right now C# looks fairly tempting. MS aren't pulling strange "premium VM" tricks, Mono is well developed and generally works as expected, and it's not a huge leap in terms of language. Many libraries in Java have C# equivalents (Bouncy Castle, iText, etc.). If we were going to leap from Java, C# would definitely be top of my likely destinations.

But no, obviously we're more likely to jump to a language I've never heard of before, with none of the libraries we use, and no experience base to pull from...

Not to mention that C# already has a ton of useful features that are, at best, planned for Java 7 and 8 (or later).

I've done significant cross-platform.Net/mono development and 99% of the stuff "just works". I'd argue that Mono is actually a better cross-platform development environment than Java *right now*. Java often requires tweaks because different builtins work differently on different platforms, even though they're not supposed to.

I can second this. Whenever I have to write a cross-platform project, I almost always go with C#. Unless you use something totally Microsoft Windows specific (like WPF or Windows Services), it should run fine on Linux or Mac.
I almost always do testing on the Linux platform as well, but even my simple HTTP server ran fine on Linux, and you can do reflection to detect and implement platform specific Mono instructions (such as doing a Mono.Unix.Native.Syscall.Chown on the aforementioned webserver).

With Microsofts history over the past 20 years, I'd say they won't pull any strange tricks until enough people have adapted it and are locked in, then they will suddenly have a change of heart. It's only Microsofts kind heart that keeps C# and Mono open enough, not *anything* legally binding.

"The world was abuzz with HTML5 and Silverlight innuendo after the SL platform was all but ignored at PDC10. Silverlight developers were furious over what they deemed to be something of a betrayal by Microsoft, nullifying endless hard work."

I think C# is well poised to scoop up the niche Java filled in businesses/enterprise -- when Java stagnated, it was the existence of a constantly-improving C# that forced Java to improve as well again. Similarly, I don't see any reason that C# isn't a good replacement for the kinds of web applications that previously would have been written in Java. (Note that this is not all web apps.)

I'm less sure about C# in the embedded/mobile space -- I don't have a lot of expertise with either, and these have been h

The way I see it playing out (I'm a.Net developer that works heavily in the London, UK market) is Java becoming the Cobol of the future in that it takes the position of the top end of the enterprise market (London Stock Exchange level of operation) while.Net takes a significant chunk of Javas small to medium enterprise work (we sell a heck of a lot of ASP.Net sites, no one asks us for Java even tho we have the capability and we get a few PHP/Python/Ruby queries, again even tho we have the capability).

>but until they learn what a compacting garbage collector is
Tada! http://www.mono-project.com/Compacting_GC [mono-project.com]
The new GC is bundled with 2.8 and will become the default in 2.10.
Mono's VM is pretty nice overall, its the GC that caused pain in long running process scenarios. Its not so much that the GC wasn't compacting either, it was more an issue because it was a conservative scanner which lead to leaks.

Yes, you are incredibly naive. People are looking to flee Java because of the greedy and proprietary corporation behind it, Oracle, and you think they should run into the arms of Microsoft? Get a clue.

For this specific kind of thing, Microsoft has never been the kind of antagonist that Oracle is.

Bwahahhaaa. Hahaahahahahaha.

Sorry for being crass, but this statement is just so ignorant. Are you saying that Microsoft doesn't have free versions and for-pay versions? Are you saying Microsoft doesn't have a past history of being an abusive monopoly? Are you saying Microsoft has never sued anybody over patents?

Before Mono, all their language and development tools were based around the Windows operating system. Given the history of Microsoft, trusting them to behave nicely with cross-platform computing is foolish. At the end of the day, the only thing they care about is locking people in to Windows.

Antitrust prosecutors showed the CEO being asked about a May 1997 email in which Microsoft manager Ben Slivka said he soon would publicly disparage a Java product provided by Sun Microsystems.

"JDK 1.2 has JFC, which we're going to be pissing on at every opportunity," Slivka told Gates in the email

MS did want to hurt Java, to make it a Windows-only thing (or at least, keep Java-on-Windows developers entirely on Windows and not port their apps to other platforms). At no point did MS want to get rid of AWT or Swing, which are the main parts of Java that are shit on any platform and replace them with their own Java GUI technology.

So, as the actual problem with java is the corporation that "owns" it decided to misbehave, you propose to switch to another language, from another corporation, for which misbehavig is their way of life?

I'm a big Objective-C fan, but running against you are the fact that most of the modern features that give it some parity with Java -- like the GC and the functional programming features -- are only supported by one extremely mercurial vendor that has a nasty tendency of making no 5-year roadmaps. Also the framework and libraries just don't offer the same coverage as Java. A lot of people at the turn of the century bet on WebObjects, which was a serious platform at that time, and now it's abandonware. Nobody wants to get burned like that again.

Really? As competition to Java it is fairly comparable. It has some features that, used improperly will lead to slower code (though, they are nice as a convenience), it is missing some features, has some features that Java is missing, and the free version of Visual Studios, at least in my opinion, is a nicer IDE than Eclipse, Netbeans or Anjuta. And it's not being used in a bunch of lawsuits by it's owner.

As a point of reference as to where I'm coming from with this post - Sysadmin + Java programmer at work, C/C#/Python Programmer at home.

Really? As competition to Java it is fairly comparable. It has some features that, used improperly will lead to slower code (though, they are nice as a convenience), it is missing some features, has some features that Java is missing, and the free version of Visual Studios, at least in my opinion, is a nicer IDE than Eclipse, Netbeans or Anjuta. And it's not being used in a bunch of lawsuits by it's owner.

This is exactly why Oracle has to stop what it's doing. ByOhTek has exactly the same mentality as most Windows developers/shops, i.e., the view that now Java is embroiled in lawsuits while Mono is stable and safe. Microsoft would never lock you into a platform.

Incidentally, I've worked in Java and.NET. Visual Studio is a big disappointment when you been working in NetBeans or Eclipse. Maybe I just don't see the appeal.

So assuming the JCP does dissolve, I fail to see why folks couldn't find a way to fork Java. Are there patents in place that would completely moot any such effort? What about clean-room reverse-engineering of the JVM, wouldn't that open some doors?

In this case, I think it's an important to draw a distinction: there's really no reason why you couldn't, except that Oracle will attempt to (right or wrong, and probably wrong) sue whoever tries into bankruptcy.

They'll be able to put a good enough case together that won't initially appear frivolous, even if it would ultimately be doomed to failure with good legal representation, and lawyers aren't generally free.

This may actually be a good thing in the long run. Changes to the language or libraries will likely be delayed, improvements will hopefully be made in the JVM.This whole situation is basically what open source groups were warning about years ago, but now we have an open JDK. Eventually, one of two things will happen:1) Oracle maintains control of Java in the enterprise, while an open source group maintains the Java that "everyone else" uses. The two languages will fork, leading both to a slow death.2) Oracl

2) Oracle will fail to keep control of Java, and everyone will end up using Java as maintained by an open source group (probably Apache). Ultimately something like the JCP will still be needed to keep enterprise involved in Java.

Dear lord, I hope it's not Apache. Any organization that allows new versions of its libraries to target Java 1.4 when 1.5 has been out for over half a decade does NOT deserve to be put in charge of the entire language. Particularly when said library [apache.org] deals with Collections.

As a developer that works primarily in Java, I'm a bit worried. If my company sees Java as being a risk we might end up moving over to.NET, and I just detest the documentation and library design of that platform.

There are some things.NET does better than Java. This includes: Generics, Properties, GUI, Web Services (although JWS is a marked improvement over Axis 1/2, and brings this more in line with.NET's WCF). This does not include: Database access (although the.NET Entity Framework may address much of this; from what I've seen it's a lot like JPA), Concurrent collections

Granted, that list is just things I can think of off the top of my head.

It's too bad that some of the most promising new languages (Scala, Clojure) are JDK based. What we need is a modern lingua-de-franca, a language that's structured enough, with modern features, a good standard library, and that doesnt take 10 years to master. Go is still proprietary shite that will bite you after Google turns evil (and you know they will). Havent looked at D yet. Erlang maybe?

Is there any high-level, easy language today that's not threathened somewhow by f%^&%ng patents from the big guys?

D: Sort of C++ done right. Unlikely to face patent issues, but does have some standard library issues with more recent versions of D being incompatible with some standard library efforts.

Eiffel: High level, OO, garbage collection, generics, closures, and still fast and memory efficient. It might have patent issues from ISE, but they're very small, and the core language and IDE are all GPL.

Its not harder than a OO lang. However finding good help *is* harder. One reason i had to pick java over the many languages I have used was its reasonably easy to find people who know it. Not so much for Scheme or Haskell.

I understand the need to drive page hits by claiming, "In this bad situation $LANGUAGE could step in and fill the void", but Go seems like an odd choice. It's not that I don't like it: I've written some pet projects with it and it's a fascinating language that I doubt I'd mind having to code in as a full-time job, but they're not similar languages at all, it's an apples-and-oranges comparison

Java is interpreted, Go is compiled. Go lacks inheritance, generics, huge backing libraries, and a bunch of other things that Java programmers rely on. Basically, Go is not an application language, it's a systems programming language that happens to have garbage collection; it's closer to a replacement for C++ than one for Java.

In any event, I just don't see people abandoning Java en masse because of this Oracle spat. There's just too much legacy code out there, and too many programmers fluent in Java and nothing else.

I agree with MOST of your post, but your statement that "Java is interpreted" is misleading. Java (at least modern Java) is a compiled language, it's just that it's compiled in two stages; once when the java compiler converts the source code to byte code and then when the JVM converts the bytecode to native code during runtime (JIT). To state that Java is interpreted leaves the impression that it results in inferior performance as compared to a traditional source-to-native code compilation process. This is a persistent that myth has been shot down time and time again in real-world benchmarks.

I'm just sayin'

As far as something replacing Java - who knows, but I don't see it in anyone's interest (including Oracle's) to throw out the baby with the bathwater. Oracle was already heavily dependent on Java long before they acquired Sun.

There are already alternatives to the Sun/Oracle Java distribution (the Delvek VM itself might be a good candidate to replace the JVM) and it really boils down to software patents and how far the courts and the broken patent system allows corporations to claim IP over generally accepted concepts. It may just be a matter of forking OpenJDK and calling it "Coffee" to remove it from Oracle's greedy hands (just like OpenOffice being forked as Libre Office). I have a feeling Oracle won't let this happen with Java however because it has too much interest in it. IMHO the best outcome of this would be for Google to prevail, and take down Oracle's patents along with it. Not only would this teach Oracle a (much needed) lesson in how to deal with the OSS world, but it would also remove current obstacles to the acceptance of Java out of fear of Oracle's legal team.

--> Java (at least modern Java) is a compiled language, it's just that it's compiled in two stages; once when the java compiler converts the source code to byte code and then when the JVM converts the bytecode to native code during runtime (JIT).

Your description points out that it is not compiled by saying that it is compiled twice? So using your description, Java is a language that has to be compiled by the writer and again by the user. I say compiling scripts so the outcome can be compiled every time they are used is just annoying. I think the only reason for it was because some Java programmers wanted the contents of their code hidden. Everyone knows that if you don't want someone reading your code you write it in Erlang and Perl.

I don't know about Ruby, but Perl has damn good performance, such that it still runs a number of major web sites, including this one. The ONLY reason Java is as popular is because Corporate America loves a corporate solution and Java was being sold as a solution by major vendors(think IBM, Sun and for a while Microsoft).

You cannot really sell Perl, or Python, or Ruby as a corporate solution because they cannot hijack a version, edit it and claim it is special. Hell, Perl runs on EVERYTHING what more can IBM add to it? This is really why good open source languages are neglected by large companies, they cannot charge anything for it.

I'm sorry, but I use both Perl and Java daily and Perl is not even in the same ballpark. Sure, for building a website Perl is fine because a web application is generally not a compute-bound application. The difference between Java and Perl in throwing up HTML is probably measured in milliseconds (with Java winning). You might get the impression that java is slower than perl for websites, but this is due to the fact that java based websites many times use some heavy framework (JSF, J2EE, etc) which tend to bog it down. However, this is not due to the language, but rather to the overhead of using an enterprise level framework (which does have significant value despite your premise that it's somehow inferior) vs a perl script that simply spits HTML back to the browser. A java program executing the same logic as a perl script will beat it hands down, everytime.

Your statement "The ONLY reason Java is as popular is because Corporate America loves a corporate solution and Java was being sold as a solution by major vendors(think IBM, Sun and for a while Microsoft)" is pure rubbish.

When Java was introduced it provided features that were previously unavailable and has grown into an extremely powerful platform in it own right. This had nothing to do with being a corporate solution and in fact, it took YEARS for Java to catch on in the corporate world. Many large corporations would not allow it until it finally became such a force it could no longer be ignored.

In case you are not aware, Perl has been in use as corporate solution, especially among sysadmins, long before Java became so popular. And one more thing, Perl (as produced by ActiveState - pretty much the market leader by my reckoning) does sell their product to corporations. While you can get the community edition for free, corporations usually want some level of support for the tools they use so the commercial editions are a good way for them to go. It's a win-win situation as the license fees help fund the OSS effort and the corporations feel comfortable in adopting it as a strategic tool.

So some program you wrote, to do some speed comparisons showing Perl was slower. There was another guy who did the same thing here showing Java was faster than Perl. Of course he used regular expressions in Perl and substrings in Java but why worry about details!

Perl has lots of things going for it, someone just suggested that it is only good for web programming or such while Java is used for business applications. I hate to tell you folks, a lot of business is getting done on the web. Perl has never really had a problem with performance and considering Slashdot gets web traffic that continually crushes other web sites just by posting a link on the front page you might consider that there might be something to what I said.

It might be worthwhile to explore what it would take to make some variation of Lisp (*cough*sbcl*cough*) a workable choice for modern software developers. My own sense is that the major things lacking are a modern, powerful, cross-platform GUI and a general "lack of polish" (for lack of a better term) when it comes to interfacing with the rest of the world, but perhaps there are other fundamental issues? This seems appropriate:

We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.

It might be worthwhile to explore what it would take to make some variation of Lisp (*cough*sbcl*cough*) a workable choice for modern software developers.

Well, we did a little research* and spoke to some programmers, and our design committee looked at different directions Lisp could be taken to make it more workable for modern developers... We were thinking maybe we could cut down on some of those parentheses.

I'm sick of reading slashdot stories and comments that compare dissimilar languages with Java. What makes Java interesting, useful, and modern is the JVM; these comparisons between language features alone are ridiculous. Most of the languages suggested as alternatives in Java-related posts in the last month are merely interpreted. Python, ruby, perl, etc. are all modernish, high-level languages with dynamic typing. They all run (primarily) on their slow, crippled interpreters. This has numerous drawbacks including problematic multithreading (c.f. the arguments about python's GIL and workarounds over the years), if it's even attempted (in perl, separate processes are the only reliable way to do concurrent programming).

And now Slashdot compares Go to Java. Go is certainly interesting, but it's not in the same space as Java. Java is a portable, networked, object-oriented *application* language. It removes a lot of hassles not necessary to tinker with when writing applications. It has useful, established APIs (servlets, EJBs) for building large-scale enterprise applications. Go compiles to machine code and is therefore not portable. Go doesn't allow inheritance. Go is a language that tries to solve a different problem than Java has solved. Go is no replacement.

Java is by no means the end of all languages and runtimes, but it has set the bar pretty high. It would be wonderful for other projects to adopt Java's features and improve and extend them. It'd be awesome if such an efforts weren't completely nullified by having Microsoft as its boss.

For the naive (and the dude who argues that python is a suitable replacement for Java), below is a list of features Java provides:

Java's JVM does true multithreading. The memory model is tight, efficient, and predictable. The language includes useful mechanisms for writing for concurrency (everything from traditional locking mechanisms to concurrent data structures and the convenient "synchronized" keyword). Productive, predictable concurrency is possible in Java and not in many other languages.

The JVM offers other benefits, including security. The class verifier can sort out malicious code before it's executed. The class loader can check roles granted to a piece of code and a cryptographic signature and decide not to run code on that basis. Even if a piece of code gets loaded and executed, it's sandboxed. Talking about these features is usually relegated to discussions about java applets, but their relevance to other applications is noteworthy.

Java includes a lot of well-organized, stable libraries for doing everything from handling HTTP requests and crafting responses to doing cryptography. Its collections API has many data structures that just aren't present in other languages without looking to a third party.

I too am bothered by Oracle's litigiousness, but running away from Java isn't a solution. We need alternatives, that's for sure, but the availability of such is a lot more limited than the average slashdotter seems to think.

Finally a comment from someone with a clue. The Python and Ruby communities really don't seem to realize how primitive the mainline implementations of their languages are. They're a complete joke when compared to the JVM, the CLR, LuaJIT, SBCL, Clozure or numerous Smalltalk implementations.

Even the mainline implementation of Factor, which is primarily programmed by one person, makes CPython look utterly terrible.

Python, specifically, is crippled by an old-school interpreter unless you're talking about jython which uses the JVM. To get the features of the JVM that my post argues are essential when picking a replacement for Java, you must run python on Java's JVM! I fail to see how jython can be an alternative to the JVM when it uses it...

Again, this isn't about the differences between the Java *language* and the Python *language*. The difference (as I argued before) is in the JVM: Python's (or Ruby's or whatev

that was meant to be a joke right? i've written wxPython scripts, and even perl with wxWidget extensions, specifically to replace sluggish memory guzzling java "gui applications". an example of java app actually outperforming perl, python, and ruby (like google apps for java vs. google apps for python) should be a standard link on such claims.

While Sun may not have had a stellar track record (e.g. their alleged mismanagement of OpenOffice.org), at least they were not trying to actively sabotage things.

I think LibreOffice has a reasonably clear path forward independent of OpenOffice.org/Oracle, but I am still concerned for the future of MySQL and VirtualBox. At least MySQL has the MariaDB fork (and maybe we'd all be better off migrating to PostgreSQL anyhow). I am not aware of an active VirtualBox development community outside of Oracle though; they're probably at risk if Oracle decides to shake things up.

I saw a comparison a while again of 3 sites implementing identical functionality in PHP, Python, and Java, and the performance characteristics were nearly identical, assuming that none of them were interpreting on the fly. (ie, php had a bytecode cash that was hot for the purposes of the test, etc.)

If anything, I'd say that while runtime speed might be similar, Java uses more memory per connection.

Apple will contribute [to OpenJDK] most of the key components, tools and technology required for a Java SE 7 implementation on Mac OS X, including a 32-bit and 64-bit HotSpot-based Java virtual machine, class libraries, a networking stack and the foundation for a new graphical client. OpenJDK will make Apple's Java technology available to open source developers so they can access and contribute to the effort.