Slashdot Mirror

Don't believe for a minute that Oracle would purchase JBoss to "help it shift customers to a subscriber-based model". Oracle already has a superior J2EE server based on Orion technology. Far more likely is that Oracle wants to pull another PeopleSoft aquisition. They'll buy up JBoss, kill the company, then let the product die on the vine. All while pushing how "Open Source Friendly" they've become.

It's not so much the release process, as the development process, which still requires the distinct build and compilation stages.

As I said, you can automate it with ANT or Maven. :-)

Or making changes to a bean and needing to restart java.

Don't use Tomcat. Seriously. Use Orion or something. With hotdeploy enabled, you can deploy an EAR file just by copying it to a directory. Everything will reload automatically. You said you use JRun? It has that feature as well.

And I can't (as far as I know) make a separate bean class (component) as a jsp file that can be treated as a bean by the rest of the system.

You can, and you can't. You can create a include JSP with an anonymous inner class, but it's really kind of dirty. You're much better off using an automated build and hotdeploy.

I really fear what's going to happen when the PeopleSoft merger is completed. I hope they don't crapify it too.

You should try Orion sometime. Everytime I'm forced to work with JBoss, I can't help but wish I was using Orion. ;-)

Why is Orion cool? Because it combines simplicity in design with all the features you've come to expect in high end commercial app servers. For example, Orion was the first server that I'm aware of that had *working* hot-deploy for EARs, WARs, and EJB JARs. (JBoss supposedly had hot-deploy for EJB in earlier versions, but it never seemed to work *quite* right.)

No other app server has managed to stay as focused on keeping the essentials working well instead of adding ancillary features out the wazoo. :-)

I suggest you start with a small project on your own. Download a copy of Orion as it's a full-powered J2EE server but by far the easiest to get running. Write a JSP or two, and build a simple servlet. Use the built-in hsql database, and learn some simple JDBC access. Don't fret taglibs yet, they're rarely used. Try to avoid the temptation to use jakarta projects, except for ant. After you get comfortable with all that, then learn EJB.

Instead, you should quit using JBoss because of this

Either you are one of these alter egos, or you never tried any other app servers. JBoss is one of the worst app servers actually. My personal favourite in Orion.

I'm sorry, but this is pathetic.

Number 1 priority is to get yourself a decent cryto lib. Bouncy Castle makes a very nice free one, but if it doesn't meet your performance needs you may want to look for a commercial one from the likes of RSA. And in case you're wondering, several of my associates have used cryptography as an example of how fast Java can be.

A straightforward implementation of a Java crypto lib usually outperforms a similar C implementation thanks to the VM optimizing the code behind the scenes. Even the most optimized C code only outperforms the Java versions by one or two percent. The problem with most Sun libs is that they're built for absolute correctness, not speed. Besides, it's not like the JVM comes with any *useful* crypto libs in the first place.

Number 2 is that you seem to have spent all of 5 minutes shopping for a servlet container. Tomcat is known to be slow. It's supposed to be slow. It's a reference implementation for Christ's sake. Orion Server (the basis for Oracle AS) is a great performer, plus is very cheap. Resin is great if you don't need an EJB container. Hell, even Weblogic does a pretty good job at performance.

Memory is really your biggest enemy. The amount of crap that you sometimes need to keep "in session" for a client is absolutely astounding. Still, this is not a Java only problem, and there are multitudes of solutions (such as using a database table as a cache and trading page render time for memory usage).

Because pretty much the main drawback of Java is that it severly limits which platforms you can distribute to, ironically.

The only other option is distributing a 50 meg JVM with every app

and increasing support costs by having to walk people through tedious installation procedures, for the JVM and your app.

If you can compile a native binary, you can distribute it to any binary compatible platform, regardless of what other software they have installed.

You don't have to explain CLASSPATH to your users.

You don't have to explain why they can't type "java filename.class", but instead must type "java filename".

GCJ is the only hope Java has of actually being more than an acedemic curiosity, and "something that Sun used for a few apps".

Are you even aware of the number of web sites exist whose server code is completely written in Java? Most likely you visitied a couple before you came here today.

The .NET Framework has a SLIGHTLY smaller footprint than the latest version of Java (46.5 vs 47.3 on my workstation). And it does more stuff -- a lot of the add-on packages for Java, including all of their J2EE crap, parellels what's already in the Framework. Not that it matters...including the framework on an install CD is trivial, and most Windows Update and XP users have it already.

You said it yourself. You can't really compare size like that since there is more to .NET than just the libraries and the VM. .NET uses a huge amount of bread&butter stuff in the Windows libraries, something which obviously can't be used by Java. At least not in the same way, since Java has to work on more than one platform.

.NET does NOT integrate the web into windows applications. .NET allows users to create web apps in much the same interface as standard windows forms, using a system called WebForms.

True, but it does integrate .NET into the web. It makes it very easy to build applications with much more "intelligence" on the client side, similar to building a XUL application using Mozilla.

The downside (or advantage, if you're Microsoft) is that you will only get these "rich" client experiences when running Explorer, preferably on Windows. But that's the whole point. Lock-in by pretending to be open, it's brilliant.

It also allows regular ASP pages to be compiled into faster versions a la JSP/Servlets.

True again, but they are still slower than JSP's on fast app servers, for example Orion. (disclaimer: I don't have the latest benchmarks so things may have changed).

What's cool about .NET is that the IDE supports all sorts of really useful data transformation and reporting mechanisms using SQL/XML/etc built right in...no rolling your own data access methods (though I end up doing it anyway).

These things has been available in Java IDE's/libraries/toolkits for longer than I care to remember. I believe it started with Sun's JavaBlend (which agreeably wasn't very good, but a lot has happened in the 6 or so years since it came out).

Today we have several frameworks, suitable for different needs. For example Hibernate, JDO, or, if you simply want a fast persistance layer: Prevayler. There are more, of course.

Also note that the the JDO specification allows different vedors to plug in different implementations so you're not relying on a single vendor. This goes for pretty much all of the J2EE specifications as well. I'll take that over Microsofts solutions any day.

.NET is better than Java for apps that will always be used on a Windows PC, because: - It has a much faster graphics interface, while maintaining a robust graphics toolkit.

And how do you know that your apps will always be used on a Windows PC? Do you have a magic crystal ball that can see into the future? Do you really want your apps to be limited to Windows only? Also, with the latest versions of Java, the speed difference (for well written applications, mind you) is neglible. Take a look at IDEA for a good example of a very efficient Swing application. And if you really believe you need native widgets, take a look at SWT, which Ecplise is built upon. But it's a pain to program in, and it's only really cross-platform on Windows. All other platforms suffer from the same problems as Swing apps do.

It has a better messaging mechanism (Events/Delegates are a GODSEND and are the sin

BEA's a good server, if slow, once you get around the absolutely awesomely bad management tools they tout as being so good. (Hint: they're not. If they work for you, great. We've found that we end up deploying the same applications multiple times, with restarts, in order to get the thing working correctly; this is with BEA support riding alongside to make sure we're not doing something stupid. We weren't.

WebSphere... IBM, IBM, IBM. The best compliment I've ever heard about Websphere was from a fan, a developer who loved it: "It's not that bad..." (Yes, it is. In IBM's sales meetings, they crow about how they helped design the entity aspects now-hopelessly-muddled EJB spec... and then later in the meetings they denounce using entity beans altogether because WAS can't give you any good performance with them. Plus, being tied to WSAD isn't my idea of a good time.)

JBoss is really pretty nice - it's built entirely around a component architecture, so you can swap out the Tomcat crap if you need to and replace it with something that actually works. (The default servlet container that comes with JBoss is Jetty, which you should replace with the current version of jetty if you use JBoss. The Jetty that ships with JBoss has a jasper error, jasper being a component from Tomcat.) The only issues I have with JBoss are related to its strengths: the component architecture means that each component chooses how it's administered, so you end up not only learning how to handle JBoss itself, but you have to learn how to configure Jetty, or this product, or THIS product, or THIS OTHER product... I prefer one ring to rule them all, etc.

As far as performance reviews, use google! :) I've done some informal performance reviews, and I've found the two best performers were Resin and Orion, with Resin being a few milliseconds behind Orion in terms of servlet and JSP performance.

Yes, I know it's free. Pay attention.

It does a relatively poor job of implementing the spec itself, and the spec is supposed to be its reason for being. It's gotten faster over time, which is nice, but it's still not very good at handling things. Tweaks abound, but running a custom version of a servlet container isn't likely to bring comfort to you... I hope.

I'd suggest spending some money on the container, myself; Jetty is okay, but I personally prefer Orion, which is fully J2EE, fast as all get out, and very, very easy to administer. Installation of an Orion instance takes three steps: unzip, copy tools.jar, java -jar orion.jar. Done. It's also free for development, so there's no per-seat license cost for you to use it to write code.

An aside: Oracle recently posted ECPerf numbers which were very good, and Oracle licensed the Orion codebase... and Orion costs thousands less. Since ECperf yields numbers based on dollars per transaction, you'd think Orion would kick butt on ECPerf.

I find Tomcat to be acceptable only for compliance testing, because so many people think it's the best that out there (because of the price point). I've spent a lot of time having to work around Tomcat; I'd hope you didn't feel like doing the same.

Another server that is used in the Java arena is the Orion Server. It's very nice and I enjoy working with it on a daily basis, but it's not Open Source which a lot of people consider to be a downside. It's free for development platform and non-profits, but for production it's $1500 USD per host. Cheaper than BEA, but But a lot more expensive than Jboss or TomCat (the Apache JAS).

• ant support (if you haven't used ant yet for compiling your projects - have a look at it)
  
• outstanding jsp support - highlighting, code imports
  
• support for refactoring. If, like myself you have never really thought about refactoring, it's great when you decide that you need to improve a class or method name late in a project. In IDEA that's one click.
  

As already pointed out they are very similar. However I have to say you should check out Orion if you need full j2ee capability in a damn fast server (Oracle licensed it for their own j2ee offerings) or Resin. Resin is cheaper but doesnt include the EJB stuff. Orion/Resin are both free for development use and licenses are $1500/server for Orion and $500 for Resin (I think). give em a look. Tomcat is the reference platform but unless they really did some tweaking Orion and Resin both blow it out of the water.

If you want EJBs, look at Orion. $1500/box for a fast EJB container that meets the J2EE spec fully. Oracle just dumped their own internally-developed J2EE app servers to licence and relabel Orion.

Although Orion may meet the EJB spec it DOES NOT meet the J2EE spec fully. Having used it in a development environment let me tell you that it has the worst JMS support of any J2EE provider I have tried. We aren't just talking bad here, we are talking UNUSABLE. There are various elements of the spec that anre not implemented, or implemented so poorly that they might as well not be implemented (don't take my word for it - check out their own mailing list). Orion is fine for development, but when you want to go live go with BEA. The Oracle announcement was a shocker let me tell you, that they dumped their own J2EE solution to use Orion's says a lot about the spaghetti code Oracle had. ;)

Java trendies: Apache+Jakarta+JSP+Oracle

Resin beats the pants off Tomcat according to third party benchmarks.

Curious__George

I'm also interested in investigating Enhydra.

For more info on Java servlet tutorials, ect. check out my blog: Brainspatter

Curious__George

I had to use Tomcat for about 3 months last year at a dot-bomb and was not impressed. As evidenced by this tutorial, there are too many steps to setup the thing. I also found it to be unstable on Win2000 and Mandrake Linux. I hear and read that it is also very slow compared to other products.

Recently a friend suggested I install a free download of OrionServer (www.orionserver.com) because it was easy and is also an EJB container and all that stuff. I was skeptical, but damn --- it installed and configured in 3 steps: 1=Download, 2=Unzip, 3=Run orion.java. (Their tutorial is 1 paragraph.) Why isn't Tomcat clean enough to install & configure like that?


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ the real world is much simpler ~~

I'm just getting back into Servlets and a friend recommended I try orionserver. He said it is stable and easier to configure. He was right. According to the benchmarks posted on their site (www.orionserver.com) it is also faster than everything else. This is good enough for me because it is free for my purposes.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ the real world is much simpler ~~

More matters than just language. If you were running on an NT/2000 machine you would be best off using either ASP/COM or ASP.Net. (crippleware anyone?) But being on a *nix platform, you would probably be best off going with a Java servlet solution.
Java and the J2EE not inherently any faster than any other technology, but has a huge advantage because of vendor support. Everyone's scrambling over eachother to provide the best and fastest implementation of the J2EE platform, and the results are trickling down to free servers.
A good example would be the Orion J2EE server, which if benchmarks are to be believed is far and away the fastest solution. Find it at: www.orionserver.com
I use it myself, and can vouch for ease of use and speed, though I haven't done any benchmarking.
Check out some amazing benchmarking figures for it at: http://www.orionserver.com/benchmarks/benchmark.ht ml

More matters than just language. If you were running on an NT/2000 machine you would be best off using either ASP/COM or ASP.Net. (crippleware anyone?) But being on a *nix platform, you would probably be best off going with a Java servlet solution.
Java and the J2EE not inherently any faster than any other technology, but has a huge advantage because of vendor support. Everyone's scrambling over eachother to provide the best and fastest implementation of the J2EE platform, and the results are trickling down to free servers.
A good example would be the Orion J2EE server, which if benchmarks are to be believed is far and away the fastest solution. Find it at: www.orionserver.com
I use it myself, and can vouch for ease of use and speed, though I haven't done any benchmarking.
Check out some amazing benchmarking figures for it at: http://www.orionserver.com/benchmarks/benchmark.ht ml

Depends on your means, I guess. Orion Server is very very good. It's free for non-commercial use but $1500 for commercial deployment. It does include a complete, standards-compliant EJB container though!

Also, the authors are often present on #Java on EFNet, so you get a lot of free, timely report. One bug I found was fixed within 2 hours of my reporting it and a patch was available for download!

-Ciaran

As an experienced Java server coder I can vouch that the idea that using Tomcat 3.2 as a benchmark is utter stupidity. Tomcat developers and all benchmarks agree that either Resin or Orion server delivers the best performance for JSP. Tomcat is murderously slow in comparsion (ZDNet tipped it off when they said ASP was faster, which by no means matches my experience or general concensus). I have coded components (Bean) and extensions (taglibs) for JSP a few times and I have yet to come across a better general web scripting technology than this. Now I know that /. is the home of a lot of perl/C lovers but can all those companies who are ignoring M$ solutions and going for the Java solution really be that wrong. Anyway to get to the point a java compiled JSP/Servlet container running a web application of JSPs, Servlets, taglibs and Bean, is a very good and portable solution (I am still forced to develop on Windozer but we deploy on Linux as well as Win2k and WinNT). "Think of something cool and tell yourself it`s my sig" -me adapting a quote from BtVS

Standardized (albeit by Sun), extensible APIs, especially on the server end, and extensible products, is part of what makes Java thrive today. Transaction API, J2EE, JNDI, Java2D/imaging, Java3D, servlets, JDBC, CORBA. Plus a host of pre-packaged libraries for things like sockets and RMI. Products: object databases (Ozone, the Castor O/R mapping framework), transaction managers (Tyrex), web servers (Resin, Jetty, Orion, Enhydra), XML etc.

Above all, Java connect to anything, provides a lot of freebies (garbage collection, a simple object model), is high-level and easy to learn, and lets you be more productive right out of the box as opposed to languages such as C++. No wonder new stuff is sprouting up like mushrooms -- a phenomenon that I suppose Bjarne Stroustrup is mildly annoyed about and doesn't quite understand. Once you've written a C++ app, it's a dead end. It not reusable. Unless you wired it up with magical strings and CORBA and reinventing all sorts of technologies, it just sits there.

This is much the same reason Python is thriving, really. Unfortunately, Java currently does not have anything that comes close to Zope. Turbine and Cocoon sound like two different projects aimed at this area, but they're not even close.

Who cares about Amex or set-top boxes? Unless I can write TiVo-like apps on my desktop computer that controls the box in interesting and hitherto-unrealized ways, it's useless, just another closed implementation. And Amex, well, how do I connect to my card, then?

Now:

• Both Oracle 8i and IBM's DB2 use Java extensively both for their DB administration GUIs as well as for middleware code. If you didn't know, these are the number 1 and number 2 Enterprise database systems in the world

I wish you hadn't mentioned that. Oracle's bloated, clunky Java GUI stuff is their big black sheep. I wish they never screwed this part up -- Oracle's native NT tools used to be at least adequate. Compare Oracle's present, slow, unstable, overdesigned, Microsoft Bob-like Java GUIs with Microsoft SQL Server 7.0's flashy, fast, and hugely functional tools and you just want to crawl into your mama's arms and cry like a baby.

• Java servlets and JSP are used extensively on the web from sites like mail.com to Firstunion.com. Hundreds of sites use Java(TM) to deliver dynamic content these two are simply the most prominent that come to mind.

Servlets is hardly Java's finest moment, same goes for JSP. True, servlets replace CGI in a nice way, and anything is better than ASP and assorted horrors, but that's about it.

Servlets make up a very low-level layer, and servlets themselves are quite isolated entities, compared to the riches of Zope's DTML documents.

Please, developers, do yourselves a favour and read up on how to properly divide content, logic, and presentation. Hint: Putting Java inside HTML gives you no cigar. Look instead at things like Freemarker and Webmacro, or even that bastard son of template processing, XSLT. Even so, these are quite weak tools, and you need to buy a $35,000-per-CPU app server to get any sense of an integrated package.

End of rant.

WML is ridiculously easy to get running using Servlets. Trust me, I've done it.

The main problem the author seems to have is that he hasn't read the Java docs.

Use URLEncode() to automagically store all the session details in the URL.

And use response.setContentType("text/vnd.wap/wml");

And that's it!

This will work on pretty much and servlet-capable server. Some, like Orion Server can even be set up to recognise whether cookies are present or not, and handle the URLencoding with no effort on the writer's part.

Any other problems are most likely due to the various bugs involved in different companies' implementations of WML.

-Ciaran

www.orionserver.com is one of the best J2EE servers out there. It will support servlets, JSP, EJB, JNDI, etc..

• New Atlanta ServletExec 3.0 - I've seen this one used succesfully before, and it was even used for a while with Javalobby.org as a plugin for Apache. It should be platform independant, but it is dependant upon you using a supported webserver (Apache, iPlanet, IIS, etc).
• Orion Server - This is a 100% Java Webserver with built-in support for XML/XSLT/WAP/etc. It also fully supports servlets (of course) as well as JSPs and EJBs. This is the product currently used by Javalobby. Overall, I think that it's a great solution. The performance of this solution is excellent.