2.4 Servlet Spec Reviewed

Greg Wilkins writes "Core Developers Network have reviewed the good, the bad and the ugly of the 2.4 servlet specification being produced by JSR154 . As well as introducing the new features, those that are missing in action are discussed. Also existing and newly added problems in the specification are presented."

Comments

Very nice analysis

[The Mayor]

I hope this is the caliber of work I can expect from CD in the future. These are the folks that left the JBoss Group after the incident concerning Apache's launch of the Geronimo J2EE server project (do a google search on "elba jboss geronimo" if you're interested in learning more about the incident). This is an excellent article on a very timely subject. I wish all new technical specifications had such a thorough analysis of their impact upon their release. Thanks, Greg Wilkins!

Re:java is obsolete

[Graelin]

I cannot believe I'm going to argue for Java....

Java's main strength was supposed to be platform independence. However, due to missteps by Sun and backstabbing by Microsoft, Java has been relegated to the back-end of a web page, running under Unix. In this client-server architecture, speed is crucial, and Javas bytecode doesn't cut it.

Although I would argue that Java's OO implementation is also it's main strength, but platform independence is also a big deal.

Microsoft's antics only really prevent Java Applets from becoming a much bigger thing than they are today. In any other client-side Java deployment you can be sure the JRE ships with the app, is installed on the client machine by the sys-admin (corporate environment) or the installer handles JRE installation for you.

If you truly believe that Java isn't platform independent, go look at any of the numerous Java Apps that have been written. Notice how they run on Windows, Mac, Linux and Solaris? That's not a typo. Here is one if you're too lazy to look yourself.

Native binaries are the only way to get the speed necessary in the post-.com days

This is also wrong. One need only look at the rapid proliferation of languages such as Perl, PHP, Python and (duh) Java as evidence. Asm/C/C++ have their uses - but to use them for everything should get you fired.

Fortunately, Linux is FREE (as in herpes and porn)and makes commodity hardware perform as well as enterprise offerings from Dell, Compaq, IBM, etc.

Linux is an operating system - Java is a programming language. What are you trying to compare? Funny thing is, the Linux and Windows JREs are usually ahead of the solaris JRE - because more java users use... well, Linux and Windows.

Furthermore, all major unices (AIX, SCO, *BSD, HPUX, Solaris, etc) include linux binary support, so linux binaries are more platform independent than Java is.

Wonderful - so your app will run on all these different flavors of UNIX... just slower. Where as the JRE was built for the OS and does not need the same kind of translation. On top of that, it can take advantage of OS features a Linux binary may not be able to.

Oh yeah - and Java runs on all those platforms plus Windows. So by sheer numbers Java is more platform independent.

Java

[Anonymous Coward]

Java - saves the developer's time at the cost of the user's time. No thanks, I take pride in the end result of my work.

Re:Java

[j3110]

I hate always being the one to laugh at things like this.

Java saves the user money at the cost of the developers being ridiculed by people on slashdot that praise PHP (which is generally slower) than Java Servlets (the topic of conversation).

Maybe you think websites should be written in C and linked directly to the kernel? That would be a hard arguement for the likes of you to argue.

Re:Java

[Anonymous Coward]

That would be the One Microsoft Way of doing this.

Re:Java

[Anonymous Coward]

Well, I wasn't refering to web pages, just a comment on Java in general. As for web pages, only a fool would use anything but a scripting language 98% of time. Too many people (and too many phbs) think their app is to goddamned important to be trusted to something like Perl. It's utter bullshit.

Re:Java

[j3110]

I can tell you from experience that Java's API is much more robust than perls for just about anything (even regular expressions are faster than perl). Java has JSP, taglibs, Struts, and Webwork whereas Perl has mod perl, and templates. All of the web scripting examples I gave with Java work well in a MVC architecture (which Perl and PHP only have templates for). So, from a maintenance and development perspective Java is pretty much superior (I know because I've used Perl, PHP, and JSP/Servlets). From a robustness perspective, for anything more than a database driven site, Java has been far more reliable and secure (I can't count the times that despite proper configuration of that perl form mail script, it has been used to spam. JavaMail API supports mime attachments, pop3 and imap with the same API, etc.). From a speed perspective, with the proper JVM (try JRocket, IBM, and SUN's because each web server will preform differently with each) and the proper servlet container (Jetty for free, or Resin for pay), the right database server/JDBC driver (you don't have a lot of options for the driver usually, but they matter more than you can imagine), you can out-do PHP and Perl without a doubt. From a scalability/reliability perspective, you can replicate session variables over a cluster (without hitting the DB, which means very much more scalable on a cluster) which means if a node on a properly configured Java system goes down, the end user will never even know, so I really can't think of a single other system that does this other than Java.

So, I, a developer, can tell you, without a doubt, that using perl or PHP for any application other than your home page is generally a bad idea. It's slower, less maintainable, doesn't scale as well, and is less secure than Java Servlets/JSP on average. You'll have a hard time fighting with numbers or playing with definitions in order to dispute that too. Believe me, because I've used PHP on Enterprise level projects, but only because it was better than ASP, and before I learned Servlets/JSP. I'm in the process right now of converting an application from Perl/C/C++/PHP to Java because it's is a mess to administer. C/C++ calls to the Win32 API are a nightmare because the documentation blatantly lies, and without having a windows client, we would be screwed from the start. Perl and it's DBI mess crashes so much that I had to write a bash script to keep it up (several versions of both the DBI and Perl and MySQL still will crash when you try to keep it up 24/7). PHP, being the best of the three, is being thrown away because once I actually had to learn Java to replace the others, I found that it's just superior to PHP for the kind of work I need it for (user editable web scripting).

I've researched it all from Delphi, C++Builder, VC++, VB, PHP, Perl, Lisp (and frineds), and Python before I started the project. I can tell you the problems you'll run into in each of them. Some of them absolutely have no purpose (VB, Delphi, C++Builder) but others are only suited for other tasks that don't grow beyond a simple program/application into a system of interconnected peices. You can't write a true 3 tier system in PHP, and there are good reasons you would want to. Java technologies include J2EE (a superclass of servlets) that gives you an enterprise application server that you don't have to write yourself. Python is the most promising with Zope, and I keep my eyes on it all the time, but just don't be so closed minded to think that Perl can do anything. It's not meant to, and there just aren't enough good and stable API's to work on a project so large that you need everything from Message Queueing and MIME Email to Serial Port IO and TAPI. Perl doesn't even have a Zope like entity. When Python gets Zope down right and starts expanding it's API's to support all the features I need, then I'll be reconsidering.

You're career could end quick if you fail to let the mentality that Perl/PHP is good enough for any job die. It's just not the true. You may be like

Huh?

[albalbo]

Did nobody else realise that the actual language/technology this story is talking about is missing?

Is this some attempt to make people actually read the article, by providing a vacuous, content-free prescis?

Re:Huh?

[brlewis]

No, I didn't even realize it until I saw your post. But you're right. It should have said "Java servlet specification" to help folks who aren't into Java servlets so much.

For me, "Greg Wilkins," "2.4 servlet" and "JSR" were cues that it was about Java, but I recognize that not everyone knows who/what those are.

Re:commercial java is not portable

[DavidNWelton]

You say Java runs on Linux, but what you really mean is that it runs on x86-linux. It's not open source software, and hasn't been ported far and wide like gcc, tcl, python etc... Maybe gcj will change that, despite the fact that most Java people seem to not be very concerned about running on a non-free platform.

Re:commercial java is not portable

[The Mayor]

What major flavor of Unix does Java not run on? AIX? Check. Solaris? Of course. Irix? Check. MacOSX? Check. PPC Linux? Check. BSD? Check.

As for the non-free bit, Java runs on MacOS X, Irix, AIX, and Windows. I'm sure there are more ports, but that covers all of the major OSes that run server-side software. J2ME even runs on tons of telephones and PDAs.

I'm not sure what your point is. But it seems like your information may be a bit out of date.

Re:commercial java is not portable

[DavidNWelton]

Debian runs on the following architectures:

68k, sparc, alpha, arm, mips, hppa, ia64 and s390 in addition to 'sh' and opteron.

I do not believe that there are non-free (i.e official) java versions available for many of these.

Also, looking around, it appears that PPC Linux doesn't have the latest Java.

BSD - FreeBSD does have Java, IIRC, but how about Net or OpenBSD? On something other than Intel?

My point is that Java the implementation (as opposed to just the language which of course is quite portable) is not yet nearly as portable as a lot of other common software.

Why no multipart/form-data support

[brlewis]

An HttpServletRequest should really handle multipart/form-data requests right out of the box. I shouldn't have to merge in some third-party software if I want BRL to support file uploads. Why has it not yet been standardized?

Re:commercial java is not portable

[jrumney]

It's not open source software

Not true, the source is openly available. It may be non-Free by the FSF definition, but it is certainly not closed.

Re:commercial java is not portable

[DavidNWelton]

When we talk about Open Source, we don't just mean that the source code is available, we mean something along these lines:

http://www.opensource.org/docs/definition.php

which is pretty similar to what the FSF defines as 'free'.

Re:commercial java is not portable

[jafuser]

My servers and my workstation support Java. Works 100% in my environment. That's all I need to know.

Just becuase Java doesn't run on my C=64 or my microwave oven doesn't mean I'm going to stop writing my servlets in Java.

And you know what? Those obscure platforms that it doesn't run on are small markets anyway.

Re:commercial java is not portable

[Anonymous Coward]

I do not believe that there are non-free (i.e official) java versions available for many of these.

There are free versions.

Re:commercial java is not portable

[Anonymous Coward]

You sould use the term "OSD-Compliant" or something that can be legally protected. Promoting an non-trademarked term like "open source" only plays into the hands of your enemies.

PHP is faster

[Anonymous Coward]

than Java servlets 90% of time, and much simpler to write and maintain.

ANY java is not portable

[axxackall]

Linux PPC Java sucks - it core dumped too often to be usefulls. Linux x86 Java still sucks - the more threads used in the app the more chances that something will go wrong or just different than on Java/win32.

The fact is that "Hello World!" is the only platform-independent Java application. Everything else MUST BE carefully tested and most likely patched to adapt on next platform.

Any non-Java Servlets?

[axxackall]

I wonder if there are servlets implmented not with Java. Any Python or Perl servlets? I know that there are applets written on/with Tcl, but how about Tcl servlets?

And when I asked about non-Java servlets I mean it: servlets written without any usage of Java. So Jython won't be an answer for my question.

Re:Any non-Java Servlets?

[MtHuurne]

Webware for Python lets you write servlets in Python. I'm using it for a project at work and I'm very pleased with it. My initial plan was to do the prototype in Python and switch to Java later, but the Python implementation works so well that it is now running in production.

Re:Any non-Java Servlets?

[mbirk]

Of course, people write servlets in just about every language! Including TCL:

Lightweight: mod_tcl
Heavyweight: OpenACS

The Best Pro-Java Rant Ever

[jkauzlar]

there just aren't enough good and stable API's [in other languages]

I often forget, among all of the reasons I use Java for server-side development, the one major advantage, in my opinion, of using Java. The JCP takes commonly-used APIs and moves them into the standard library, so that I, as a developer, must no longer spend time tracking down common APIs. The interfaces are set in stone and there is one place to look for updates to specifications... the java.sun page. This saves a lot of time in development and maintenance.

What worries me most about Java is its future. I'm concerned that the flurry of third-party code generators along with the addition of meta-tags is going to kill Java's code-portability and become a rich source of third-party vendor lockin. I'm afraid that code written by one person may be indecipherable to another person due to reckless inclusion of obscure meta-tags.

Does anyone else see this as a problem? When you follow the "code as the primary development document"-doctrine as I prefer to do, I want to be able to read every line of the actual source code. Then I want to be able to compile the primary document-- the source code. When using meta-tags the code itself is instantly readable by the person who wrote it, but the compilation process becomes fragmented into layers of pre-compilation. The code itself is no longer portable this way.

Sorry, this is incoherent, but its my daily slashdot-with-first-cup-of-coffee wake-up time.

Re:The Best Pro-Java Rant Ever

[j3110]

Well, I do get a little afraid of XDoclet and the likes as well. You can blame most of it on the J2EE spec. You have to create 3 files and modify at least one more in about 3 different places in order to make a single bean. If the spec was more self contained it wouldn't have lead to XDoclet, which is now being used for more than it should be. XDoclet is for those people that don't believe in an IDE, or don't believe that IntelliJ IDEA is worth the price. What we've always needed is just a decent IDE or a more compact spec. for J2EE. I'm sure it will get better eventually, because XDoclet is just a cludge trying to cover the complexity issue of J2EE.