Slashdot Mirror
The Coming War Over the Future of Java
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.
Google is trying to force the legal issue and end this with a court battle.
Apache is trying to end it using the JCP
IBM is trying to be all chummy and get Oracle to support OpenJDK
If Google wins then Java is Free, if Apache wins then Java is Free, if IBM wins then Java is theirs.
Something like http://www.parrot.org/ you mean ? A whole new VM which can run multiple languages.
New things are always on the horizon
http://en.wikipedia.org/wiki/Parrot_virtual_machine
Dilbert RSS feed
http://llvm.org/ and http://clang.llvm.org/
Dilbert RSS feed
Is there any high-level, easy language today that's not threathened somewhow by f%^&%ng patents from the big guys?
Well, presuming you want something fast, as opposed to say Python or Ruby, there are some options:
Craft Beer Programming T-shirts
Yes, the announcement that IBM joined OpenJDK development really meant that IBM left Apache Harmony.
Why hasn't FOSS come up its own managed runtime+language stack?
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.
I am TheRaven on Soylent News
I wish that C# had the same Linux kernel support as Java does.
It does. None.
The word is not destroy but kill.
http://www.justice.gov/atr/cases/f1700/1762.htm#N_57_
"Naturally, we would never do it, but it would give us some idea of how much time we have to work with in killing Sun's Java."
Sneak teach kids Algebra using a game
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.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
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
I've upped my standards, so up yours.