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."
To read all comments associated with this story, please click here.
Member since:2006-02-05
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.
Member since:2006-01-18
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!#
Member since:2006-12-07
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
Member since:2006-01-18
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.
Member since:
2005-07-06
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...