Slashdot Mirror
Java Success Stories
gark writes "The Java Lobby has a
weblog on Java success stories. Many of the successful applications are servlet based, and several use Apache JServ. Perhaps WORA [write once, run anywhere] really has been achieved, at least for server apps."
I work at Webstakes.com ( http://www.webstakes.com ) - we're a very popular site, on the Media Metrix 500 and so forth...our entire operation runs on Apache JServ and we're very happy with it. We actually migrated from a Java-based application server and this is much better. I'm the UNIX system administrator, and in the past I have worked with many commercial application servers, from Broadvision to NetDynamics, and I have to say Apache JServ blows everything else away...I love how flexible Apache is and how JServ fits into it...it makes me wonder why so many financial companies have such a love for Netscape Enterprise server or IIS
Open source application servers are the best - I can tell you from personal experience over the past couple of years...they really blow away commercial application servers. My friend has mod_perl on Elance.com and I'm curious as to how that's working out...I know PERL is a very web-friendly language, maybe even a little more than Java.
A major part of the game in introducing any new
technology to the MIS-managers is producing a
panoply of success stories in the "trade press".
If you read back issues of "Information Week"
"Datamation" etc. you will find endless gushing
stories of successful implementations of
(pick the fad of the last 10 years).
What is *never* covered are the projects that
got abandoned, canceled, or crashed and burned
in some other way... these are politely buried
and not talked about... the programmers fired,
and the memory traces remain only in the minds
of the survivors - again never talked about, and
never included in survey tabulations...
The only way to find about project failures is to
talk to seasoned survivors over a beer, or
to read anti-patterns books or occasionally
the halloween issue of Datamation - and even
then they never give names and places...
Which is precisely why Sun is pulling stupid stunts like pulling Java out of ECMA stadardization and trying to charge royalties for the use of the J2EE logo. Sun realizes that Java is A Big Thing now, so they want to get their cut, one way or another.
It's the same old bait-n-switch we've grown to know and loathe from Microsoft, only with a different brand underneath.
These little shenanigans, along with the way Sun is milking the Open Source cow with their so-called SCSL and their treatment of the Blackdown fiasco has got them on my sh*t list but good. They had better realize pretty quickly that the industry isn't going to stand anymore for the same old tricks that Microsoft's been pulling all these years and that Sun isn't anywhere near as powerful and influential as Microsoft to be able to pull them off.
It's enough to want to make me give up Java and learn Perl... Well, ok, maybe Python...
Who woulda thunk it a couple of years ago that a die-hard Linux fan who does a lot of Java and database work would today be saying, "At least there's IBM to look to for real support of Java on Linux without trying to screw us over."
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
People who say that there are no Java apps miss the point. For the non-server applications, they're pretty much right: there are very few end-user, shrink-wrap apps written in Java. Why? Because portability is not an issue for most software companies. If it runs on Win95 and NT, then it's good to go.
However, a large number of server-side applications use Java servlets or the related JSP technology. Bought a computer on line? If it was from Compaq, HP, or a host of others (such as those listed at http://corporate.pcorder.com/customers/), then you benefited from the speed and robustness of the Java platform. Even the Ford e-commerce site, which Bill Gates so lovingly demonstrated in his Comdex keynote, is based on Java (and runs on NT).
And don't count corporate software, either. Lotus Notes web mail runs through a Java applet, and companies like Oracle are increasing their use of Java everyday.
The fact is, whenever you need fast development, good networking capabilites, and (I hate to say it) 'enterprise' support, Java is a good candidate. WORA is just a small part of it.
One last thing. With the advent of GCJ, it is possible that more native software will be written in Java. This will be a huge boon because it will allow GUI apps to run natively on a large numeber of platforms without changing a line of code. Java, I think, is a good argument for having a large, all-encompassing library (GUI, networking, database, ORB, etc). If only it was so easy with everything else...
~~~~~~~~~
auntfloyd
Finally an article on the server-side successes of Java. IMHO, Java servlets are the best thing that has happened to Java since its inception, but for reasons completely unknown to me, Java-bashing has taken its place next to Microsoft bashing as an official Slashdot sport. Perhaps the reason is the early failure of Java when Sun touted it as the single platform that will replace everything. Anybody else remember the Java ring and the Java OS?
Dear fellow Java-basher Slashdotters: I know most of you have very little free time on your hands, but please set aside a couple of days to take a look at this exciting server side technology, Java servlets. It is truly write-once, run anywhere; it's a widely accepted industry standard, almost all popular databases and application servers support it, and Java is a very good OO language after all. Take a look at some nice servlet tutorials or better, O'Reilly's servlets book, download the awesome Tomcat or Apache JServ to run with your Apache Web server, get the latest JDK from Blackdown or even better, IBM's JDK, add Jikes for good measure, and explore the beautiful world of Java servlets. Sun's site completely relies on Java servlets, Yahoo uses servlets for some portions of the site, a host of smaller Web sites and e-commerce companies completely rely on servlets and/or JSP (which is based on servlet technology), (epinions.com, mercata.com come to my mind; there are lots of others)
Whatever server-side programming technology you're using, you will like servlets. Most likely you will want to forget about CGI.pm, sell your books about Netscape's proprietary server-side JavaScript on Ebay, erase memories of hours of fiddling with ISAPI/NSAPI extensions, shred your printouts of ASP error message explanations from the Microsoft knowledge base, and lament about the time you spent posting aimlessly on every bulletin board about those pesky, undocumented Oracle functions of PHP. You will easily have time for all these when you start to use servlets.
--
BluetoothCentral.com
A site for everything Bluetooth. Coming in January 2000.
Zigbee Central: A Zigbee weblog
I developed and wrote WebMacro which is a free (GPL) Java servlet framework.
I use Java for about half my web projects. The other half of the time I use perl. In my opinion, here are the strengths of Java for server side development:
1-- It allows clean and clear design. Since you can declare compiler-enforced interfaces, you can easily separate out functionality in well defined chunks. This allows you to plan for the long term, hand different parts of the project to different people, and so on. This tends to be what makes me choose Java over Perl: If I want to enforce a long term design (such as re-usable constraints on busisness logic), or break the project up into several different segments, then I choose Java over Perl.
2-- It's fast and scalable. Java is often criticized as being slow, but on the server, it's not. It's fairly fast compared to things like perl (which are usually fast enough to begin with), and add to that the threaded nature of servlets, plus the built in scalability, and you have a big performance gain over other scripted solutions. In particular the ability to automatically distribute a single servlet across multiple webservers, without modifying the servlet itself at all, is a big win. You can be sure that whatever you do will scale.
3-- You do need to make an effort to keep your HTML and your SQL and your Java program code separate form one another. The whole reason for using Java was to get clean, well designed code, and you don't have that when you have HTML obscuring your servlet. This is what prompted me to write WebMacro, which is an HTML template system, but you could also do this with FreeMarker, or XSLT, or if you are very careful, with JSP.
4-- Write once, run anywhere is fairly real on the servlet. I routinely develop under FreeBSD, deploy on FreeBSD, Solaris, and Linux, and I have about half the users of WebMacro running it under NT, even though I myself hardly ever use NT. And it all works.
5-- On the downside, the free Java solutions don't appear to work very well for servlets. I have had lots of trouble with kaffe, and the free JVM's are not as fast as the non-open ones. This is too bad, and it's something I expect will change over the next while. I always try kaffe every time it comes out, but it hasn't yet been stable enough for me.
6-- You do need an experienced designer around if you are going to use Java. Unlike perl, where your goal is to hack out something working ASAP, in Java the point of the language is to allow you to do clean design. Well you won't get clean design without an experienced designer. Without a good designer you are probably better off with "write-once" perl-code that you throw out and rewrite whenever you need to fix it. While Java allows you to do really good design, I have seen some really nasty Java code. If you aren't going to use it right.. don't use it.
The company I work for recently programmed an SMS (cellular phone text-messages) server complete with a fancy web based user interface and a vCal integration that allows you to synchronize your cellular phone calendar with your desktop calendar automatically with SMS's as the carrier protocol. One team had worked on this for months and months using C/C++ and Perl. The deadline came closer and the app was still packed with bugs. So a hail-Mary manouver was performed only days before the deployment date and the whole thing was re-engineered in Java with parts of the vCal integration being Visual Basic. On the deployment date, we had a ready package which was actually FAR better than the C/C++ & Perl version. It had more features, was more easily integratable with other systems, featured a pluggable SMSC (short message system center) driver architecture, had a fancy self-repairing system which did self-monitoring of the whole thing. We had a home-brew RMI based distributed debugging service that allowed us to receive stack-traces and exceptions that occured at run time, from several servers at once and view them on the web. We had about a million other equally cool things, all put together in less than one week by a handful of programmers.
A few weeks later, there are still no major bugs reported and everything seems to be running perfectly smoothly.
What does this prove? Absolute nothing. However, it does raise some questions about how it's idiotic to just do everything with C/C++ because it's traditionally "the right thing to do". By using "traditional" programming languages, you will often be forced to spend so much time thinking about language issues, memory allocation & leaks, complex threading issues etc. that the application logic will suffer and become a secondary priority.
Pick the right tool for the right job. If you develop a web browser, you would probably be insane if you did it in Java (I would love to be proved wrong) because it would be so much slower. If you develop a complex server side application in C/C++ or Perl, you're nuts because there's NO WAY you will achieve the same quality in the amount of time you can achieve it in Java.
If you diss Java because of some stupid web applets programmed by some 13 year olds who know nothing about programming, it's just very sad because Java can do so much more. Unfortunately we see lots of "write once debug everywhere" statements by people who have little or no first hand experience with Java. The experience I have with Java tells me that while the Win32 platform still has the best virtual machines, Linux is gaining FAST, mostly thanks to IBM. Linux users: don't just use Kaffe because you've heard it's the right thing. Try running Java on a Win32 platform so you see what it CAN be like. I'm quite sure you will be amazed of the speed.
There are not many platform inconsistencies left, and if you know what you're doing, you can easily move a Java app from one platform to another without having to change any code or recompile anything. I've done this several times, even for very large and complex applications.
If you read the Java 2 Enterprise Edition Application Programming Model specification which now has an even more complex name which escapes me at the moment, you will see how SUN has worked hard in the EJB specification to define a great component architecture that is scalable, clusterable and avoids many common causes for platform specific bugs. Please read it!
A friend and I have just released a Java application. We use encryption to password protect web pages securely (plug: www.guardbot.com). The software comes in 2 parts, a Java applet decoder which performs the on-the-fly decryption of web pages, and a Java encoder which performs the encryption.
Without the Java's write once run anywhere capability, the decoder would have been impossible to deliver succesfully (without resorting to platform specific browser plugins, which would have put off a lot of users). Writing the encoder portion of the software let us deliver the software simultaneously to any Java supporting platform - without Java, we would probably have limited our software to Windows (at least initially).
Client side Java is not worthless, and I'd say that write once run anywhere is an extremely worthwhile goal - I'd very much like to see Sun deliver on this. As it stands, only Solaris and Windows have working Java 2 implementations, which is extremely disappointing.
WebMacro will gradually kill JSP :-) In fact, it was recently selected in a Java Report survey as one of the best three servlet products of 1999.
:-)
:-)
:-)
JSP is not a good use of the Java langauge. It's non-standard, and requires extra junk in your webserver (whereas WM works in any pure Java environment, without requiring add ons). On top of that, it doesn't take advantage of Java's features. It looks and smells like ASP, and as a result, obscures your ability to write good clean Java code.
If that's the kind of programming you want to do, you should look into EMBPERL. It does a much better job of mixing script codes into HTML.
My view is that you should NEVER mix program logic and HTML together. WebMacro implements a template langauge, the idea being that all your rendering logic and HTML goes in the template--leaving your servlet as pure and simple Java code.
JSP's model is the opposite, though they claim you can do MVC programming with it. (A claim they started pushing *after* WM was announced, by the way
With JSP you can do MVC programming, keeping your busines logic separate from your display logic, but you have to enforce it yourself. Every time you do anything everywhere you have to follow self-imposed rules. Late some tired night you'll get fed up and sick some Java into your HTML--like a cancer it'll grow, until the point in separating them is lost.
WebMacro, or any other template system, supports the model/view/controller way of thinking architecturally. It's analogous to doing OO programming in an OO language, as opposed to in C. Separating display from logic in JSP is like doing OO programming in C--it's possible, but the language doesn't really support it.
It is worth repeating that I created WebMacro in response to JSP. I had come from a perl/C++ background, and had made extensive use of good template systems in both langauges. Coming to Java, I naturally expected to have a good template system, so I looked at JSP. When JSP turned out not to be a template oriented system, I naturally wrote one and GPL'd it
Of course I'm biased. However, I will say that the bias caused me to write WM, and not the other way around
I've worked extensively in C, C++, and Java. Given my choice I will take Java virtually every time.
The reason why comes down to pure productivity. On average (we're talking about over the course of years) I'm 300% more productive in Java than C++. In some cases (particularly networking code) that number is more like 1500%.
Just think of what things you can do if you can write your application three or more times as fast as the other guy. You have time to write it, rewrite it, and optimize it before he's even done the first time.
And that, my friends, translates into huge market advantage.
Now, lots of people say that the reason Java is more productive is because you don't spend your time tracking down memory issues. That's not the case for me, at least not in large part; it's really not that hard to write a clean program in C++, and memory leak issues still exist in Java (which sells a lot of Optimize-It licenses, lemme tell you). Rather, Java is a lot more stringent in enforcing interfaces than is C++, to say nothing of C.
Consider, for instance, that Java enforces handling or passing of exceptions. In C++ you can silently ignore them, usually resulting in bugs or reliability problems that don't show up until late in the development cycle (or, worse, in the field). In Java you have to explicitly deal with exceptions; you are forced to make a conscious decision as to what to do every time you use an interface that throws an exception. What that means In The Real World is much more robust code on the first effort -- if it fails, it usually fails gracefully.
There are actually some problems related to this. In beta test programs, for instance, it is a lot harder to get people to report problems because they usually manifest themselves as a feature that doesn't always seem to work rather than a complete application crash. On the other hand the application can notice the problem and report it nicely rather than just disappearing or dumping core. These kinds of problems I can live with.
There are other development advantages. Java is dynamically linked at runtime. This makes it slower to start up than a C or C++ application but it means that there is no link phase to deal with at each compile/edit/debug cycle. On a large C++ project I used to wait as much as fifteen minutes per link; with Java that time is always zero. That translates into many more cycles in the same timeframe, and that translates into product going out the door faster. (I must note that I used to work on a C/C++ debugger with an incremental linker and it had many of these same advantages. It was, however, rather expensive.)
So: we have a case here were random heap crashes can't happen, where interface enforcement is stringent enough that you get more reliable stuff together on the first try, and where you can run through a compile/edit/debug cycle a lot faster. There is a hell of a lot to like there.
There are some downsides though.
The compilers still suck -- at least all of the common ones. Oh, projects like Jikes are yielding compilers that build code fast, but none of them build good code. They don't even do simple peephole optimizations, to say nothing of what you get in your typical C++ compiler. It's like going back and looking at code produced by 70s C compilers. Apparently the idea is that the JIT system takes care of that -- but JIT systems are severely limited in how much time they can spend compiling the code, plus they don't have anywhere near as much semantic information. The end result is worse code. This was true of C++ for quite some time too, of course, and is expected to get better, but for the moment you get to optimize a lot of things by hand.
JVM stability has been something of an issue. Big programs that push the environment hard (like, say, a web application that's handling tens of millions of hits per day, which is what I do with Java) tend to find the dirty corners that don't show up in your typical "hello world" applet. Things like limitations on the number of classes and methods you can have in your application (low tens of thousands prior to JDK 1.2), heap lock contention overhead as the thread count scales beyond a hundred or so, and other things have pushed us towards designs that are less convenient to build (although arguably much more scalable and fault tolerant).
Some people speak of JDBC being really nice. It's a good idea, but practically speaking very few of the JDBC drivers are particularly reliable, cross-compatibility leaves a lot to be desired, and performance is often not so hot. You have to spend more time on optimization. Luckily you have more time to spend on optimization.
So Java has its problems, but in my experience everything has its problems. Java's problems can be worked around with architecture and optimization and productivity improvements are so good that you have the time to do it. The end result is often a better product out the door faster.
Now, for all you guys who say that Java just isn't fast enough, several of the largest sites on the web run Java-based applications (you almost certainly have used some of them without even knowing it). And they do it on a lot less hardware, and less expensive hardware, than any of the competition manages with C/C++. This is in direct contract to the popular opinion that Java is slow.
There's nothing stopping someone from writing the same kind of thing in C/C++ other than time. We've had the time to write, optimize, rewrite, and optimize again several times over in the time span it has taken most of the competition to just make their product stable. Unsurprisingly this results in a faster and more stable product even when we've had to work around problems that the other guy wouldn't have had to deal with.
Java isn't for everything. You'd be insane to write drivers or operating systems in it, and runtime environments are really way too big for most embedded applications today. But when it works it's great, and it is working on a whole lot of servers out there on the 'net. You don't hear about them because nobody talks about the stuff that works, only the stuff that doesn't (like, say, eBay).
jim frost
jimf@frostbytes.com
jim frost
jimf@frostbytes.com