When Should We Use Java

Two-tier database client application development
- Surely more difficult and costly than with VB or ZopeApplicationServer (Zope). What cost are you referring to: up-front, or maintenance? I would argue that both VB and Java are lacking on the maintenance front because of the way most c/s applications are written in them: using hard-coded SQL queries and direct wiring of ADO Recordsets or JDBC ResultSets? to the GUI.For small things, this works wonderfully; for more complex things, an OO framework or business layer would be better. Also, please don't turn this into a LanguagePissingMatch. It's hard to determine cost based on language alone - the developers themselves are usually the primary factor.
Three-tier application development
- This uses an application server or TP monitor in the middle. VB has Windows 2000 (MTS & COM+) as the man in the middle. Java has EJB servers, WebObjects, Gemstone, etc. Smalltalk has Gemstone. Linux app servers are often Java-based (Enhydra, for example). In this model (which is arguably more maintainable and scalable over the two-tier model), Java has the advantage in tool & vendor support.
Web development using applets, HTML, and servlets
- Likewise an ASP/VB or ZopeApplicationServer/PythonLanguage solution will be far easier and more maintainable. Oh puleese... Take a look at JSP 1.1. With TagLibraries? I can do anything you can do better... As for Applets, aren't they an obsolete technology? Applets are not obsolete, and are still used fairly widely, especially on intranets.
Distributed client and server application development using CORBA
- Except for EJB, CORBA is language neutral. Granted EJB is a better large-scale component framework than anything else on the books right now, but the OMG keep threatening to offer enterprise beans in other languages real soon now ...
Reusable JavaBean component creation
- Is there any advantage of JavaBean(s) over TK? Substitute this with "is there any real advantage of JavaBean(s) over ActiveX. How complete is Tk's support for custom controls compared to JavaBeans or ActiveX? Tk is an excellent GUI toolkit, but I never viewed it as a component model.

[From the "What's new" page of Borland JBuilder 3.5 (free! for Linux!)]

Multiplatform GUI application development

I've looked at lots of C and C++ libraries that attempt to provide a tool for multiple-platform GUI development. Java wins by having a standard that actually works. It is not really multi-platform unless MacOS is included.

Well I am looking at this page, last edit July 26, 2000, and it's now Dec 1, 2000, and Sun has definitely got back into the Mac world with Java. JDK 1.3 has very good support for Mac and OS X. Swing now encorporates proper handling of the global application bar even. -- StevenNewton

WhenShouldWeUseJava? When we care about ease of development and time to market, but don't care enough to write it in Smalltalk.

WithAllDueRespect, the confusion over having so many different behaviours with different combinations of JVM and libraries makes the ease of development issue moot. And for time to market Java is easily outcompeted by VB, Perl, & Python. As for Smalltalk ... when should we use SmalltalkInsteadOfPython?

I won't comment on VB for database apps since I haven't used it. However, the amount of hype that Zope is getting is a mystery to me. Zope sounds promising at first, but after reading the documentation, it looks to me like a needlessly confusing framework that uses a proprietary database and doesn't scale.

ZopeApplicationServer provides an OpenSource OODB, but also adaptors to most commercial RDBs. If you need it to scale you can pay for ZEO (ZEO is now free!), which gives you a cute ThreeTierArchitecture. As to "needlessly confusing", that depends on your background. For me, it's frighteningly intuitive. -- PeterMerel

Also, I don't see why anyone would recommend ASP over JSP for reasons other than Microsoft compatibility. ASP lacks portability, type-checking, and exceptions. At work, all the developers want to drop ASP support in our product because it's so annoying to maintain both and not be able to throw exceptions from methods that are called from the web pages.

I also don't see how applets could be "obsolete". They aren't nearly as useful as ordinary web pages, but for what they do, there's nothing as widely supported by browsers.

-- BrianSlesinsky

Java seems to provide a balance between technical, business, and vendor concerns. Does choosing Tk/Python/Perl/Zope really give major business benefits over Java? Do these languages really result in 20%+ productivity gains over Java? I have my doubts.

Sometimes making a business decision involves standardizing on something for a while so you don't have to re-invent the wheel too often. Right now, Java is that language, especially in larger businesses (banks, finanical houses, manufacturing, etc.). -- StuCharlton

The benefits of a particular language depend entirely on the task you're solving. When you need a Perl OneLiner?, writing several dozen lines of Java or C would be ridiculous. On the other hand, it seems equally ridiculous to write a raytracer in Perl or Java, or an applet in C or Perl.

For me, with about a year of experience in both Perl and Java, the productivity difference is closer to 200% than 20%. But at work we are currently moving towards JavaServlets, and I strongly support that move, because I don't think I and my coworkers could be as productive as a group in Perl as in Java. Let's face it, I'm the PerlGuru? around here - the productivity increase for myself would be eliminated in CollectiveCodeOwnership, since I'd have to intentionally simplify my code to avoid it becoming a NoGoArea to those with less Perl experience.

Perl gives you enough rope to hang yourself. It also gives you enough of it to weave yourself a comfortable hammock, if you only know how. Java is more like a wooden chair - less flexible and comfortable, but anyone can use it without risking getting horribly tangled up in it. -- IlmariKaronen

Do these languages really result in 20%+ productivity gains over Java? I have my doubts.

Yeah, I agree. These kind of statements rarely have any value. 20%+ productivity gain for what kind of problem domain!? What solution domain? For parsing text or for server-side processing on WebServer? For enterprise wide business applications? For reactive distributed systems? Workflows? If we are purely looking at the business domain, this field is even so varied it would be hard to say.

As a long time Perl programmer and 2 year java programmer, I can say the following about Perl productivity:

Not having to recompile your code is very nice.
Not having to worry about types is *usually* nicer
Lots of third party modules are available for Perl

The biggest problem with perl was finding good developers.

-- DaveTauzell

CategoryJava