Submitted by Now that Java has a fully open sourced implementation in RedHat’s IcedTea, Neil McAllister questions whether an open Java even matters: “Even as Java has stretched outward to embrace more concepts and technologies – adding APIs and language features as it goes – newer, more lightweight tools have appeared that do most of what Java aims to do. And they often do it better.”
Does Open Java Matter?
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
Nothing is more grating then reading a diahrretic commentary with no “proof in the pudding” to proclaim superior, more lightweight products.
Either this person know jack about the market for J2EE architects and senior developers of Java tops on the list or he’s just a Linux zealot pandering to his constituency hoping the crap he throws on the display sticks to the masses.
Write some software of varying tools to match the specs requirements of at least a 3-tier client with regional call center needs to connect millions of clients.
Then talk.
I couldn’t agree more. I am not native English speaker, so I couldn’t put it as good as you did.
DG
– Performance that is (in most situations) acceptable compared to natively compiled C/C++ code: check.
– Comprehensive class library, proven third party libraries and application server platforms: check.
– Hosts of well-trained programmers available: check.
– Taught in most education institutions: check.
From the article:
Imagine if Java were released today, brand-new, as is. That’s almost how it is for the Free Software community. Java is now an option for Free Software development, for the very first time.
No it’s not, Red Hat-ish (and other distributions) had provided Eclipse, Tomcat, and others running on top of gcj for a while. It’s just that OpenJDK is complete, has a fast VM, and verifies against the TCK. So, for most it is a better alternative than gcj now.
Now ask yourself this: If Java really were released today, brand-new, would it be a tool you’d choose?
But that is not the situation. Java was released more than a decade ago, has a high-performance virtual machine. There are good frameworks, and programmers are in high demand. Like C, C++, and Cobol, it’s not going away, and even if it doesn’t become more popular on free software platforms, it will continue to form a chunk of widely used infrastructure (e.g. J2EE, Eclipse).
To be honest, I think Java (as a platform) will only grow. There is a lot of movement to have dynamic languages run better on Java (e.g. JRuby, Groovy), which will make it more attractive to some programmers. Additionally, it’s currently the only serious free software competitor to .NET.
Edited 2008-06-26 19:49 UTC
> Additionally, it’s currently the only serious free software competitor to .NET
Actually, according to TIOBE:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Neither C#.Net nor VB has the pervasiveness of Java (despite what Microsoft marketing would like you to believe). There’s a fair bit of VB out there but even Microsoft would consider it ‘legacy’ for the most part (most new .NET stuff seems to be C#).
Java may not always be the best tool for the job, but it is a tool that can do almost any job. If you only felt like learning one programming language to be your ‘swiss army knife’ then Java should be the one (and perhaps C as number two for dealing with hardware).
Back on the topic proper. It is great Sun’s Java implementation is 100% free/libre. That removes a whole bunch of risk using it in free software projects. I hope that the Free Software movement adopts it for use, instead of clunky and fragile scripted messes, or cobbled together native libraries with wildly diverging design philosophies.
There is several things rudiculous – first is obsession with speed. As for client side, your app is either fast enough, or not, so the obsession for C++ like performance is just funny. The second thing is obsession to run various dynamic languages upon Java. Gee – why? Those are better than Java. Java might be well established, supported, having some APIs, but – as an innovation technology it completly failed to fullfill what it was meant for. Dynamic and scripting languages run circels around Java productivity. So save Java’s ass, they came-up with JavaFX declarative aproach. Some ppl finally realised, that all that object stuff might actually pretty much suck.
And before you would try to educate me of the OOP advantages – beeing there, done that.
I learned python recently and love it. Going back and having to touch Java code that I wrote is really sad. I look at some things and I say, man… I could do those 30 lines of java code in 6 lines of python and it would be easier to understand.
At some point I should look into jython.
Or you could do it in six lines of Jython maybe? At the moment the Java platform is exciting – not only from the open source point of view – but also because of the push for dynamic languages – namely Ruby, Python, Groovy, Javascript. So now you hava a choice of language to target what is still an excellent platform and sophisticated VM.
No, Java is NOT exciting – it is those languages that are exciting! If Java is exciting, code in Java, not those languages.
There are many extension of Python that need to be compiled from C code and linked with source code of other libraries and extensions. Imagine that you need to deploy an application on server at customers premises running Windows server. There is no C compiler, and no one would let you install one on production machine, which is quite sane. You have no control over dynamic libraries resident on the machine and they will not let you add and remove existing, which is very sane, too.
Imagine that you need to access LDAP from Python application, and LDAP server is no OpenLDAP. Or you have to connect to a database which is not MySQL or Postgres.
The strength of Java is that it is rather isolated from the rest of the machine and almost all extensions are written in Java. One can add additional driver or library by simply dropping a file in a particular directory. Developer can deploy an application without interfering with other functions of the host machine.
DG
The question was whether to use Java vs something else for a web app.
I was a Common Lisp hacker, Python fan, Scheme enthusiast, FP in general kind of guy.
And yet I still chose Java for our group over PHP, over Perl, over Python/Lisp/Scheme, ASP, etc.
This was back pre-WARs. We had Servlets and crude JSPs. Java 1.2.
And I still picked Java.
Why?
Servlet API. That bone headed, brain dead Java web API.
What’s so special about the Servlet API? Nothing. Well, one thing. Stateful on a single server. That was nice.
Also, it was all Java. JSPs were Java, Servlets were Java, generic service code was Java, head to toe it was all Java. I could easily see if we picked something like ASP (no .NET at the time), we’d have had to write code in C++ and VB. I didn’t want VB and C++ coders handwaving each other off because “they didn’t know C++/VB”. Can’t say that when it’s all Java.
Oh, and one other thing. Minor thing, but still.
At the time, again, this is early, there were already 4 or 5 implementations of the Servlet API available. Tomcat, JRun, Netscape, others.
That was the kicker.
The fact that we had a standard API, and several supporting implementations, from different vendors, was key. Same with JDBC. Even in the short term of that project we went from Solaris/Oracle to NT/SQL Server, and then back (the CTO was fired), from Tomcat to Netscape to JRun.
We never needed to run another JVM, but even then we had IBM available as an alternative to Suns.
Nothing else offered that flexibility. Nothing else today offers that flexibility. We have JVMs on everything from Gumstix to 128 CPU beasts, several implementations of the major infrastructure, both free and pay (sometime even both), from a wide array of vendors and projects. Java along with MS is driving the SOAP standards for interoperability, and keeping up with the Joneses with REST frameworks and capability, until JAX-WS releases and adopts it.
Several commercial JVMs, just on the x86, plus several others on other architectures.
It’s fast, it’s cross platform, it’s portable.
JRuby is clocking faster than CRuby, it implements several scripting languages for the “lighter better faster” crowds. Java even has PHP! The Great Satan itself! Now running in a JVM near you.
Just like there’s a huge amount of software that targets the Unix runtime, a huge amount that targets the Windows runtime, we have a huge amount that targets the Java runtime — which happens to run everywhere.
The world keeps shifting around it, but Java keeps up.
It’s biggest threat right now is JavaScript, but it will run that too…
I disagree with you about the flexibility.
As long as you stick to common denominator stuff, you don’t have a problem. But when you want to use a database to its fullest (or, as soon as you start using stored procs), you quickly step out of the ANSI world and create a vendor dependency. Sure, it will run anywhere, but there are not only platform specific bugs, but platform specific optimizations. On an enterprise system of any complexity, switching out the OS is a big deal. Even more so with Jikes (and I would imagine Iced Tea too, don’t have experience with that one though). There are also appserver quirks and oddities.
Java is a very PORTABLE language, but I would not call it cross platform, at least for non trivial apps.
[/q]
It is indeed, I once moved half a million lines of code from Windows to an RS6000 the Windows machine was running on the Sun VM the RS6000 on the IBM vm both being 1.3…
One line of code had to be changed due to a bug in the IBM VM the rest ran out of the box…
So much for non cross platform!#
I moved a 1.2 million lines from linux to windows, and it just died, no exception, no nothing. A month or so later it was running, just way slower. Another two months of optimization work, and it was the same perf as it used to be on linux.
Actually what was the problem for causing those problems which vm, this is not normal, the biggest bugs usually which can be encountered, are the / \ wich are hardcoded into the VM.
Also being slower is not really normal, the Linux and Windows VMs to my knowledge are not to different performancewise.
Every TCK compliant VM has to run through millions of unit tests before being branded as java so portability especially on newer vms unless you custom app has native code should not be that much of an issue, and in my experience it isnt really especially if you move from windows to linux. Vice versa it can become more of a problem due to case sensitive filenames etc…
What ANSI ? Java has nothing to do with ANSI. It is not C. The whole Java API IS common denominator stuff, and one should not step away from it. One should stick as closely to as possible.
There are best practices to be followed, too.
If one does try hard not to write cross platform application, eventually would succeed to do that.
DG
ANSI SQL. any non trivial application in java is going to dependancies on external infrastructure, which was the whole point of the origional post.
SQL issue would apply to any language, I have not tried Hibernate. JDO and EJB 3, but they are supposed to deal with it. There is LDBC driver, that is supposed to be universal JDBC driver for a number of engines.
DG
You misunderstand this conversation. The origional post was about how many choices you have up and down the java stack, which means you are not tied to one vender. My point was that java flexibility is over rated, as soon as you start using more advanced features, you end up tied to the product.
In the case of sql, it is not connection drivers that are the problem, that should be trivial to change in a well archetected application. The problem is when you start using database features that are DB specific. The standards for databases are not all that encompassing, so as soon as you start writing sprocs, you end up with a dependancy.
Javascript is not javas biggest thread not as long as it does not have decent namespacing and as long as it doesnt have decent inheritance instead of every library running its own inheritance on top of the prototype maps.
Anyway javascript runs in the JVM it even is one of the default implementations of the Scripting API (EcmaScript that is). The reason no one really uses it on the server side is, that there are way better suited scripting languages running happily compiled in the jvm are readily available. Pythin, Ruby and Groovy just to name the currentl most popular.
Maybe my college was right after all about dropping C++ as the main language in favor of Java (while maintaining VB.NET as the other language)…
c++ is good to know, but hardly that marketable nowadays. java is hands down the most used language on the planet.
Edited 2008-06-26 23:54 UTC
A C++ app, written with good use of templates and avoiding virtual functions, compiled with (in GCC terms) O3 and profile-generate, profile-use, and with inter-process-optimization (or for G++, concatenate all source files into one) will outperform Java every time. It will also use less memory.
Java does not have real templates. You can’t avoid virtual functions. Java will always use as much memory as it ever needed to allocate, it never returns it (at least, no jvm I ever used did).
And the part I dislike most: Java starts up like a pig and doesn’t get going well for almost a minute.
I wasn’t talking about the relative merits of java vs c++, just the marketability of the skillset. There are WAY more java jobs out there then c++.
However, since this kind of discussion is one of my favorites, I’ll bite 😉
VM compiler magic and traditional compiler magic tend to leapfrog each other every few years. I do not know if your statements are correct, but if they are (or even if they aren’t) they wont be for long. Also, I don’t think there has ever been a more benchmarked comparison since the beginning of comp-sci, when it comes to raw perf, the difference almost always ends up being negligible.
As for templates, sorry but I’ll have to say good riddance on that one. Every function being virtual I will agree is stupid. As for memory allocation/deallocation, I haven’t used java seriously for about 3 years now, and when I was I was writing enterprise apps where that isn’t such a big deal. I do remember a big stink from awhile back though about some guy prooving that .Finalize() does jack all, even though sun docs said that it would free up the object.
App startup times are better then they used to be, but still not that great. In the .net world, the VM loads once, and each app runs in its own sandbox (or “AppDomain”). IMO java should behave like this by default, with the option of one vm per app like how it is now
It is very easy to throw stones. Sure, there are downsides to java. There are many advantages to it to though.
The managed memory model, while having issues, gives you immunity to whole classes of common exploits, decreases code complexity, and makes it harder to leak.
The VM sandboxing makes it very easy to completely lock down an application from doing anything it isn’t supposed to be doing
While I do think that java threw the baby out with the bathwater in many cases, it is still a far cleaner and more object oriented language then C++.
The typed exception model means that if you do not write error handling where you should, at least you are forced to think about it.
The whole SUN ownership and mammoth library thing means that once you learn how things work, they will work the same way on every project you ever work on.
While I don’t really think java is all that, I do think that managed languages are the next level of evolution in coding. Sure, you sacrifice some perf, but what you get counter-balances it. Same thing happened years ago when C started gaining dominance over ASM, and many of the same arguments were made in both directions. Nowadays, ASM is only used in the most performance critical of situations.
What exactly are these magical benefits that a managed runtime is supposed to bring? Please don’t say garbage collection, since you can get that on any language without the need for a VM. Or you can stick to well known idioms, e.g. RAII.
Languages like C++ have a very steep initial learning curve. However, once you get beyond the early pains, you’ll see that it actually works bloody well and is far more expressive and readable than anything around. Yes, all these functionality (operator overloading, templates) can be abused but so can any other language feature.
But all this focus on how C++ is hard is great for us developers. Short supply (of C++ programmers) coupled with high demand means that the salary of a C++ developer is pretty decent and has a very good career progression
Security is the other big one.
Beyond that, it just has to do with syntax. C++ is showing its age. I want generics, lambdas, try/catch, interfaces, nullables, and all the rest you kind of expect from a modern typed language.
Problem is with C++ we have been there in the 90s, many projects failed in C++ because the language caused a load of problems in those projects. Have in mind most projects have a fair amount of mediocre coders and only a handful of good people. If you drop onto them a language with more than thousand pagues of language specification alone and a myriad of constructs which can be misused you run into problems.
There is a reason why the development time once people moved from C++ to java went down significantly and this reason has not gone.
Add to that that the standard C++ library still is a shame while javas library probably is one of the most extensive in existence and you know C++ has lost the game in many ways for many applications. C++ still has its nieche but for big business applications C++ is not the language of choice anymore and rightfully so.
Objective C could have made it a much cleaner nicer language but the marketing force back in the 90s was behind C++ and everyone had to suffer from it.
Smalltalk also had a choice but Parkplace single handedly killed the entire Smalltalk market within one year (read about the Parcplace Digitalk buyout and the dropping of the Digitalk codebase for political reasons, this killed the entire Smalltalk market within a short period of time)
“Problem is with C++ we have been there in the 90s, many projects failed in C++ because the language caused a load of problems in those projects.”
The C++ of today and the C++ of the 90’s are much different. The first full official specification did not even come about until 1998. Also, this is when the Standard Template Library came about. Having an official spec, and the STL, and generic programming, have made C++ programming much much easier, safer, less error prone, and less prone to memory leaks and buffer overruns.
“If you drop onto them a language with more than thousand pagues of language specification alone and a myriad of constructs which can be misused you run into problems.”
“The C++ Programming Language”, by Stroustrup, is over 1000 pages. But only about 350 of that is language description. The rest is about libraries and techniques. Thus, learning the core C++ language is not beast people make it out to be, nor is using it.
“There is a reason why the development time once people moved from C++ to java went down significantly and this reason has not gone.”
True, Java is generally easier, but this phenomenon is mostly due to C++’s use in business apps was mostly in the 90’s, before the spec, before the STL. People were doing C style coding with C++, and not using proper higher level constructs. Nowadays, there is rarely a need to use pointers in C++, and rarely a need to do much direct memory allocation (use auto pointers, vectors, strings, where the classes do their own clean up). Really, if learned properly, C++ can be quite productive, and much like a higher level language. Everyone who bashes C++ for difficulty and not being safe should read “Accelerated C++” by Koenig and Moo, which takes a top down approach and has the reader using strings and vectors (from the STL) right from the start, writing useful programs with nary a pointer or direct memory allocation, right from the start.
“Add to that that the standard C++ library still is a shame while javas library probably is one of the most extensive in existence and you know C++ has lost the game in many ways for many applications.”
Java’s library is pretty excellent, no doubt. But C++
s STL is pretty spectacular itself. And while C++’s standard libraries is generally dwarfed by Java’s, there are a multitude of non-standard libraries, free to use, cross platform, available to use, such as Boost, Qt, Gtkmm, wxWidgets, Tao, and many others.
As far as real world use, for big business, internal applications, Java is king, with .Net close behind. For big business internal apps, having a managed runtime like the JVM has huge advantages (as covered in your excellent post).
But for public facing applications, it’s a different story. Responsiveness is very important here, as is look and feel. For desktop apps, that people buy or download, C/C++ are still king. For web apps (not internal big business), it’s more a mixed bag, with PHP being a huge player (again, for public facing apps). Look at Yahoo, Facebook, Wikipedia, and others. For those type apps, dynamic languages, particularly PHP (which is designed specifically for solving common web problems), are key.
But for programming jobs, it’s internal corporate apps that provide the most jobs. And for that, it’s Java and .Net.
Just to further what you have said…
C++ will be one of the few languages – namely C and C++ – that will always be around. Can’t necessarily say the same for Java. Eventually Java will fade away when something better for its space comes up. Can’t say the same for C or C++.
I’m not so sure that C or C++ learning curves are really that high. Perhaps the debugging learning curve might be theoretically higher, but I would still say that it is still just theoretically. Why? You end up with the same problems (memory leaks, etc) in other languages – even Java – and the presence of a GC makes them that much harder to find. The results are just different.
Granted for Java you won’t see it really until you try to scale what you’re working on; while C/C++ you’ll catch it earlier since the result will affect you faster. But that’s a good thing, IMO.
I don’t agree with that at all.
C++ is well into its decline, what makes it different from every other language that gained prominence?
Taking manual memory management out of the equation reduces complexity, bugs, and leaks. Memory leaks are not harder to find, people just have much less experience tracking them down since they are no longer a daily issue.
Nowadays the common view in the developer community is even things like java have needless complexity and too much code surface area. In another decade or so, java will be used where c++ is used now, and dynamic languages will be considered the only sane choice for major projects.
Remember, when UNIX came out, people thought it was insane to write an os in C rather then ASM. Nowadays, writing an entire application in assembler seems nutty.
Difference is C++ can still be used for systems development. Java, while some have managed to mangle it enough (using C++ extensions!) to do so, just isn’t cut for that market. So it’s vulnerable where C++ isn’t. (Though C++ still competes with C and Assembly in that market too. Needlessly, they are all interchangeable.)
And those developers are lesser for it.
Java will never really be used for everything that C++ is. It’s limited by the JVM in that nature – and binary compiling the bytecode won’t resolve that either. For example, Java will never replace a device driver written in C or C++.
C won out over Assembly because of a great advantage over it – portability – that also kept the performance and usability of Assembly in the market. So there was no real disadvantage to moving to C – or even C++ for that matter. Additionally, you could move part of your code from Assembly to C without sacrificing interoperability.
However, Java doesn’t fit that profile. So it’s not really an apples-to-apples comparison. There has yet to come along a better systems programming language – which C and C++ both fit well. (Though C better than C++, namely since there is less to setup before the native environment of C++ can take over.) For example, if you’re going to start using Java on a project, you need to convert the whole project to Java – you can get away with not converting other applications and doing one application at a time, but you still have to convert the entire application. That wasn’t true with Assembly->C, nor C->C++, nor Assembly->Ada/Pascal/ObjectiveC/etc. (And yes, I’ve worked on projects where one part (server) was in Java and another part (client) was in a different language (VB).)
The closest competitor to C and C++ is probably ‘D’. But there’s not much momentum behind that yet. Time will tell; but more likely than not, D will just fall into obscurity.
Actually I doubt that dynamic languages ever really will take over. They have their own set of problems especially the heavily untyped ones.
I have been in the dynamic language domain for quite a while and the dynamic those languages give also scream for problems and misuse in bigger systems.
And reports from rails projects having failed because of exactly that reason seem to indicate my persona guessings and experiences of the problems those languages cause. The biggest advantage those languages give are a non restart hot deploy of web applications due to their mainly interpreted nature. But that advantage basically is resolved in the java domain with tools like java rebel.
Or in other words of a former smalltalk guy (a language btw. which i hold in high respect), he was so glad that he was moving away from smalltalk because of the dynamics the language provided it was a constant problem in bigger systems.
The main issue is that there is a lot of hype in dynamic languages currently, the next step will be that there will be a lot of flames due to failed projects and afterwards after the dust has settled they will have their place and everyone will use them correctly. This happens every time with every technology introduced.
Honestly, I see the benefit of dynamic languages being less lines of code. That being said, I can see where you are coming from, and mostly agree with you.
As a C# dev, with each release of the language we seem to get a new feature from dynamic or functional languages (lambdas, implicit typing, extension methods). Maybe dynamic languages will not take over in the form they are now, but more traditional strongly typed languages will get more dynamic.
Yes it matters … but most new exciting (open) projects don’t flock to it like they use to. A few years back it was all the rage to use Java, and a little less than 10 years ago it was even sexy.
Today it seems to be ruby(and jruby), python(and ironpython/jython), .Net(and mono).
It matters, but a lot like COBOL matters. I myself am happy to not be using it any longer but that is my personal preference :-).
The “java trap” only mattered to a tiny number of open source purists. It’ll make no difference one way or the other to the use of Java that such a thing as “open” java exists.
Does Neil McAllister really matter?
http://blogs.sun.com/jonathan/entry/rocking_the_free_world#comments
“…on PC’s alone, Java’s popularity has grown in the last few years, as measured by runtime downloads – we routinely download 40 to 50 million new Java runtimes a month, and update more than a billion every year. The adoption of the Java platform exceeds the adoption of Microsoft’s Windows itself – Sun’s Java runtime environment (JRE) is preloaded on nearly every Windows machine (from HP, Dell, Lenovo, etc.), but also runs on Apple’s Macintosh, Ubuntu, Fedora, SuSe, Solaris and OpenSolaris desktops. In addition, a JRE is present on billions – yes, billions – of wireless and mobile devices, from automobile dashboards and navigation devices, to Amazon’s Kindle (did you know Amazon’s Kindle is a Java platform?).”