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.
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.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
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.
They seem to be on the side of Oracle. They left Apache behind.
New things are always on the horizon
Something like http://www.parrot.org/ you mean ? A whole new VM which can run multiple languages.
New things are always on the horizon
They said the same thing about Java, now look we're we are.
That's what the lawsuit is about, isn't it?
That only deals with copyright problems. It's irrelevant to patents (And Google claims to have already effectively done it).
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
http://en.wikipedia.org/wiki/Parrot_virtual_machine
Dilbert RSS feed
If Perl, Python, and Ruby are unable to match Java's performance, I'll take their portability, ease of development, lack of overhead and succinctness over Java any day.
Rich And Stupid is not so bad as Working For Rich And Stupid.
to Open JDK.
http://blogs.sun.com/theaquarium/entry/the_story_of_a_tweet
Basically, the original news about Oracle splitting the JVM to open/free but crippled and premium/fast commercial one were wrong and based on misinterpretation of a tweet.
Apple just today announced they are contributing their java/jvm implementation to the Open JDK project, so there will be JDK for OS X in the future as well.
So, everyone calm down and enjoy JVM + your favourite language (Scala, Clojure or what ever else you like).
As the island of our knowledge grows, so does the shore of our ignorance.
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.
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?
With respect to its languages and development tools, no, not so much.
Whether Silverlight
"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."
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Java is not an interpreted language. The very first thing that happens is that you compile it from .java files to jvm bytecode files (.class files). Those files are in turn later compiled into native code on the fly as the application runs.
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.
wxWidgets - helping X-windows newbs like me since at least 1997.
TODO: create/find/steal funny sig.
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.
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.
Having to work for a living is the root of all evil.
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.
Sooo... since when?
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 some other standard to follow then, such as POSIX, or maybe QT.
"Give me six lines of C++ code written by the most competent programmer, and I will find enough in there to hang him."
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).
Hydraulic pizza oven!! Guided missile! Herring sandwich! Styrofoam! Jayne Mansfield! Aluminum siding! Borax!
http://llvm.org/
The LLVM Core libraries provide a modern source- and target-independent optimizer, along with code generation support for many popular CPUs (as well as some less common ones!) These libraries are built around a well specified code representation known as the LLVM intermediate representation ("LLVM IR"). The LLVM Core libraries are well documented, and it is particularly easy to invent your own language (or port an existing compiler) to use LLVM as an optimizer and code generator.
JIT compile or batch compile to native or run in interpreter.
>but until they learn what a compacting garbage collector is Tada! http://www.mono-project.com/Compacting_GC 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.
From ZDNet coverage of the trial
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.
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 it's not as wide spread (I deploy my software on Solaris, AIX, HPUX, Linux, Windows, AS/400 and OS X).
As the island of our knowledge grows, so does the shore of our ignorance.
Yes. Real-world Perl is fast in large part because good Perl programmers make extensive use of modules, most of which are highly optimised in C.
Also, the Perl community has got itself together over the last few years, both in terms of the engineering of the language and the recognition of the need for marketing.
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 provided by the MMU, which is a relatively simple bit of hardware. You don't need some restricted subset of C, the language is entirely irrelevant. The CPU runs the binary in non-privileged mode and the program can only escape from the CPU-provided sandbox by going through the OS.
I am TheRaven on Soylent News
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.
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 to do the same things. They should look, think, feel, and be usable as native platform applications doing things the native platform way. This is the problem that every "cross platform" GUI development system - that I've seen at least - fails to address. You don't want your app to feel like a Windows app running on a Mac, even if the menus are positioned at the top of the screen (hello, Eclipse). Or a Mac app running on Windows (hello, iTunes). Bleah.
So when you get down to it, it has nothing to do with the language you choose. Make your GUI do GUI things and do them well, and do them natively. Its not that hard to write uncomplicated GUIs on each platform, it will take a few days to digest the style guides for OSs you're not very familiar with. But the end result will be a far superior end product.
You're special forces then? That's great! I just love your olympics!
Posts like this make me wish I had mod points and could repeat-cast them for the same post. +1 True, +1 Informative, +1 Interesting, +1 This makes me want to cry. C++ is an awful language. If you haven't seen this, I think you'll appreciate this rant by Linus Torvalds.
You obviously write smaller apps only. Write a large app (such as my current work project) and C#'s cross-platform limitations become apparent very rapidly.
While I agree to some points (in particular about compile times and somewhat complicated grammar), the rest is just BS.
1. C++ also doesn't have run-time encapsulation or really any serious run-time error checking that you don't do yourself.
I presume this statement is about memory management; you are not forced to do manual new/delete and to use raw pointers. Boost, TR1, C++0x all have better constructions for that. It's not 1999 anymore.
2. C++'s exception support is hilariously broken.
No it's not. Again - a question of proper memory management. Use smart pointers. There nothing wrong with RAII, It works perfectly and not only for memory blocks but for resources as well (resource management on Java or any other GC-based language is a pain in the ass meaning a LOT of code with try/catch/finally that makes the source unreadable).
By the way, if you really need a GC for C++ - you can use Boehm GC.
As far as I know exception handling only slows down every function call under MSVC with asynchronous exception handling enabled (when all OS exceptions are caught). Normal application exceptions don't have such an overhead for 'every function call', unless you use exception specifications (which are crap I agree and not recommended anyway).
3. So you have C++ templates, but you still need to deal with C macros.
With a good programming style using macros is minimal - only #include and perhaps a small part with some conditional compilation for cross-platform modules.
4. You have std::vectors, but you still need to deal with arrays
Only if you use raw memory management and you don't HAVE to. See answer above. Besides, there is a Boost wrapper for arrays and a native C++0x type. If you really need to deal with raw memory I am afraid you can't really complain about it in the language.
5. You have std::string and char*, and neither is particularly good.
I only use std::string and have no problems with it. Boost has a nice string algorithm library that extends the std greatly.
6. the arguments to main() are int argc, char** argv
Whatever, there is only one main function so who cares. Use Boost::program_options if you need a wrapper.
7. While we're on the subject, the standard iostream is pants-on-head retarded
You don't have to use iostreams if you don't like it; boost::format gives you all the benefits without the printf risks; don't use ios manipulators if you find then verbose - format manually or with the boost::format.
8. The standard library is completely anemic
Yes but it's getting much better with C++0x and there is Boost out there which is a wholy grail for C++. For the GUI Qt is probably the best library in existence at the moment.
9. STL also just loves to dump gigantic unintelligible multi-kilobyte error messages
Agree on that, GCC diagnostic messages suck.
10. you realize what an unholy mess the language is.
If you can't afford the garbage collection (and a LOT of projects can't for different reasons like limited resources, RT or deterministic behaviour), you find out soon that C++ is one of the very few choices left (C being another one but honestly I don't see an advantage of using it).
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 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.
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.
Java is stupid, agreed. But C++ is retarded too. Link-time code generation is old news, object sizes could be resolved then.
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.
Superior? With GC I pay a fixed performance cost (and not even a very large one on modern VMs) upfront for the whole project and start writing code. With RAII I have to go around making sure everyone is actually using shared_ptr (or whatever) at every single call site.
Now Finalization, I agree, isn't the most amazing thing, but I've spent no more time chasing down finalization bugs than I have going after people who use a raw fopen despite having a nice file class with a destructor available. Depends on what you're used to, I suppose.
Exception handling has a cost only if there are non-trivial destructors to execute.
Leveraging RIAA kind of demands that such destructors exist.
C++0x will have this.
Sure, if they don't delay it another five years while all the compiler vendors run off and implement incompatible subsets of the proposals because they're tired of waiting for the committee to stop bickering.
ACE? what, are you stack in 1999? you know the Boost libraries, don't you?
Boost? I thought we were being careful about what we include so as to keep compile times down.
Templates are, for me, the single reason I prefer c++ over Java. Java's generics are stupid.
Templates are useful, until someone goes nuts with traits types and multiple levels of tag-type-param-to-overloaded-function and your debug build ends up six or more orders of magnitude slower than your release because inlining is off.
Yes, I use them, but the time spent making sure they aren't being misused is non-trivial and needs to be counted against the time saved by using them.
Funny that you say that, because I've worked on million lines of code c++ codebases that didn't have any memory leaks or other problems. But that's because we used the right libraries.
So have I. But don't forget the bit where someone spent countless hours making sure everybody else was following the rules and sticking to those libraries, rather than wandering off into std:: or inventing their own little subdoma