Post a Comment
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.
- 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.
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.
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!#
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
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.
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.
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.
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
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 :-).
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?)."







