Slashdot Mirror
Tomcat 5.0 Released
aquarium writes "The Apache Jakarta Project announces the release of the first stable version of Tomcat 5.0. Improvements include performance optimizations, scalability and reliability enhancements, and improved Taglibs handling."
Why should Solaris be the leading Java OS? Only because Sun delivers both?
Following this logic would impose the question why no IBM OS shows up in the first ranks although they provide a Java implementation as well.
I think this figures more or less represent Java's overall OS-related deployment numbers (on Server machines).
The Java VM on Solaris isn't particularly good. Funny enough, Sun's VM written for Windows performs much better.
This could explain that.
I guess I always took 'scalable' in this case to mean someting closer to enterprisish capability.
What I mean by this is it is easier in java to organize and build a complex application by wrapping business logic and typical data access deep inside generic objects (beans)....then you can focus on the framework and organization and the modularity allows you to separate out tasks well.
This is not for every application, but for the big ones that handle lots of access points (procurement/supply chain/accounting/planning) and lots of function (messaging, transactions, forecasting, reporting) that is all part of one big system, then its probably easier for a lot of people to work together on the Java than it is for a bunch of perl/php scripts.
Then again, the chance of your company working on such a system is less likely then them buying into SAP or one of the other big ones.
For most small stuff, perl and php are fine.
With the right programming group, perl and php can work on large projects too.
But for the average large company, with a big system, Java seems to work well in architecture and implementation of the system. It will also probably take LONGER to implement. (expecially if you use beans to encompass all the real logic and jsp just for presentation and servlets just for the HTTP interface) YMMV.
I've written ASP run sites, Java Servlet run sites, currently working on a Perl CGI::APP + template toolkit site, and have messed around PHP and Zope/Python. As with anything else, its all about using the right tool FOR THE TEAM for the job.
Java, though, in lots of corporate development shops, seems to be given an unwarranted buzzword boost from managers who set it as a requirement across the board.
I need a TiVo for my car. Pause live traffic now.
Well, Java is both the language and a virtual machine. Designing a scalable VM is tricky - for example, this article (http://java.sun.com/docs/hotspot/gc/) discusses how garbage collection degrades with the number of processors available. Sun has done a fair amount of research like this to ensure the VM scales, or at least to the extent we understand the tradeoffs when tuning an application (esp. 1.4 VMs).
Packages, as a namespace boundary separating functional areas of a program, do add a nice chunk of metadata for compilers and debuggers to work with. PHP, by throwing everything into one giant flat namespace, reminds me far too much of C -- in other words, fine if you're dealing with legacy code that uses it, but not exactly where I want to be if I'm trying to be produce quality code.
However, I think that the runtime cost of interpreting a handful of source scripts for each webapp request is really quite minor compared to, say, the cost of opening a connection to a remote service, (RMI/EJB, SQL server, or whatever) marshalling and unmarshalling a series of data structures over that socket connection, generating return text from a template, and all the other work that makes up dynamic web page construction.
Pre-compiled modules are much more important for efficient distribution and deployment of code than they are for its execution. Being able to package an entire application into a single network-transferrable file is by far the most useful contribution of the Servlet container specs -- just drop that WAR file into your apps directory, and off you go.
Will this thing ever die?
Two years ago, (almost three), Java performance on Solaris wasn't very good. Why? Because it didn't need to be. As this article points out, Sun had better things to do two years ago than tune the JVM on a platform that it wasn't being used for.
If anything, this memo is an example of how things are working properly. Engineers complained, and things changed. If you look at some of the modern benchmarking linked from the provided site rather than ancient gossip, you'll see that the Solaris JVM is on par with the Windows JVM. Granted, they both need improvement in memory footprint and startup time, but the point still stands, the Solaris JVM is not lagging behind the Windows implementation.
Its time we put this one to bed.
-Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.