The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

What's the downside of Java?

I've been developing for the past couple of years in scripting langauges--I'm largely self-taught. I've avoided lower-level langauges such as C/C++ because Tcl/Tk and Python do pretty much everything I need.

Scripting languages, however, have their drawbacks. Tcl and Python both suffer from a lack of quality development environments, limitations in the widget sets, and complexities with deployment. So I've been looking at alternatives for cross-platform programming.

I've been playing a bit with Java--I downloaded Netbeans 5.0 and have been working through some tutorials--and it seems light-years ahead of the average scripting language. Netbeans is the most polished development environment I've tried--much slicker than Emacs. There's an almost embarassing range of good, usable GUI builders--free as well as commercial. And there are good free/open-source install builders as well as the commercial kinds.

So what's the downside? I understand the arguments about Java apps being slow and that doesn't bother me. I also understand concerns about users having to download a JRE--no problem, I'll just ship one with my apps. (Stuffing Python + Tcl/Tk + extensions into an installer results in a pretty large package anyway.)

Java just seems like a really *cool* environment for cross-platform development--and you don't have to give an extra hundred bucks to Real Software every six months for the latest subscription to RealBasic.
Ready for Robust
Wednesday, February 22, 2006
 
 
Right now it seems that some of the people driving Java are competing against the perceived (actual or not) improvements that come with .Net.  Therefore, some of the newest features read like a checklist against what .Net offers.

In terms of IDE's, I've been extremely happy with Eclipse.  What it and the plugins can do is simply amazing.  I don't know if NetBeans is better.

Configuration of components is one of the arguements against Java right now.  If you want to use something like Hibernate, Spring, Struts, Ant, etc, you're going to have to learn some basic syntax of those tools before you can do much.  While these tools offer huge functionality, the configuration management can be a pain.

One of the up sides is the sheer number of available libraries out there.  Almost anything you want to do... there are libraries out there and the vast majority are open source.  This means that even if you need classes that aren't complete, you could have a good starting position/partial solution.
KC Send private email
Wednesday, February 22, 2006
 
 
Most of the big ugly drawback of Java are server-side rather than client-side. Having to deal with Tomcat, Spring, Hibernate, etc, etc make server-side development in Java more of a pain in the ass than I'm interested in.

But on the client-side, there is only one drawback I can think of, and it's very minor. The JVM might take a few seconds to start up (as opposed to Python which instantiates itself a bit more quickly, or a native win32 app which starts up instantly).

Some people will tell you that the GUI isn't responsive, but I've done a decent amount of programming with the Java Swing GUI toolkit, and you can definitely make responsive GUIs (especially if you use Java's advanced threading to put long-running tasks into the background).

Some other people will tell you that the GUI isn't native. And with Swing that's true, but you can always use SWT instead and get native widgets. (And at any rate, the widgets you use with Swing or SWT will be as good as or better than the widgets you'll get with wxPython or with Tcl/Tk).

For the stuff you're doing, it sounds like Java will be a great fit. Have fun :)
BenjiSmith Send private email
Wednesday, February 22, 2006
 
 
If you like Python but want a better IDE than emacs, check out SPE (free), PyDev (mostly free) or Wing IDE ($).
Jonathan Ellis
Wednesday, February 22, 2006
 
 
Java's claim of "Write Once, Run Everywhere" often becomes "Write Once, Debug Everywhere", especially if you are doing anything with a GUI.

And just because Java has garbage collection, this doesn't mean you're not going to have to learn a whole lot about tuning your JVM to get this to happen nicely.

Running java applications often involves getting the classpath set up just right -- and this is a nuisance. For our enterprise systems, we always have a shell or perl script that sets up the environment before launching java.

It's not a bad platform, that said, but it's not the panacea to cross platform development that many would have you believe.

And, running in the JVM gives you the opportunity to use Jython, which just sounds cool. Haven't had a need to do it in production yet, but someday...
Gustavo
Wednesday, February 22, 2006
 
 
Actually, I forgot one more thing...

To run a Java application, you generally have to invoke it from the commandline, with something like this:

> /path/to/jdk/bin/java.exe -CP /path/to/app/myclasses.jar net.benjismith.MyCoolApp

And that's cumbersome. Especially for a GUI application.

You can eliminate the necessity of typing the commandline argument by providing users with a shellscript or bat file. But that's still cumbersome because it will open up a DOS window while your application launches, and it looks really dumb.

But there are a few alternatives. You can package your Java application inside of an EXE wrapper. The wrapper prevents the DOS window from opening. It can pass arguments to the JVM. You can wrap all your JAR files into the EXE as well. And you can even give your application its own name so that it appears in the Windows Task Manager with its own name, rather than just as "javaw".

Here's the wrapper tool that I've been looking at (though I haven't ever used it, so I can't attest to its quality):

http://www.dobysoft.com/products/nativej/index.html
BenjiSmith Send private email
Wednesday, February 22, 2006
 
 
Sun has (largely) solved much of the issue with client deploy through java webstart.  If you are writing gui applications to deploy to clients, I highly recommend looking into this tool

Wednesday, February 22, 2006
 
 
"To run a Java application, you generally have to invoke it from the commandline, with something like this:"

That's one of my biggest beefs about Java. Especially since developers who provide batch files to kick off the application often don't program them correctly. If you close the second command shell window it closes the application. Most users not only don't understand why this happens, but they don't like the idea of having to have more than one window open for a single application.

This is also one of those places where Java is not truly "cross platform". You often have to provide alternative batch/shell scripts to launch your app depending on the target OS.

But Java is still a great platform. I just prefer targeting a specific OS with a language that is optimized for the task (.NET). But we don't always get that option.
Turtle Rustler
Wednesday, February 22, 2006
 
 
Just wrap your application in a .jar file with an appropriate MANIFEST file. Then you and your users can just double-click the .jar file to launch your application.

Also, if you need to start your application manually or from a shortcut use javaw.exe rather than java.exe to stop the console window from appearing.
Omer Send private email
Wednesday, February 22, 2006
 
 
Compare Perl's CGI.pm with the endless endless trek that writing for Servlets or JSP gives you.

Just too much complexity: What gives with a language that throws an exception when a file open fails? Overkill to my mind. The whole exception regime seems much too complicated to my way of thinking.
dot for this one
Wednesday, February 22, 2006
 
 
Java is a pretty nice language to program in, much cleaner than C and C++. Although it's significantly slower in terms of performance it's perfectly acceptable for software that's not time-critical. 

Netbeans is also a very nice IDE.  I prefer it over Eclipse, which I use at work for C++ (using the C++ plugin).  Unfortunately I think Netbeans4.6 was better than Netbeans5, particularly for building GUIs.
Moobar
Wednesday, February 22, 2006
 
 
>>"What gives with a language that throws an exception when a file open fails?"

Call me old fashioned, but if I cant open a file Id quite like to know about it so I can maybe take some alternative action or at least inform the user that their data wasnt saved or loaded...
Java GUI Programmer
Thursday, February 23, 2006
 
 
I'm not a big fan of Java for GUI apps, but I like Servlets and JSP. I also prefer Netbeans to Eclipse.

The problems I see with Java are:

Configuration is a PITA.
All the really cool stuff like Commons and Jakarta require additional downloads and installation.
It is not a unified environment.

.NET solves most of these problems.
MBJ Send private email
Thursday, February 23, 2006
 
 
I have had quite a lot of problems with Java at my customers (I have a small IT help/service company), where some of the most common seem to be:

1 - Incompatibility between different JVM's. This really, really sucks big time, as the error messages never seem to display anything that gives any sort of clue as to what's going on. I think this is mostly application programmers not bothering to check JVM version and as such not exactly Java's fault, but from my pov that's hardly an excuse.

2 - Sucky GUI's. The biggest gripe I have with this is that many Java gui's look like Java gui's instead of a native app - I don't really care that it *isn't* native, but it should at least look like it. Why not respect the user, and use his/her choice of colors and fonts?

3- That XML shite. For cryin' out loud, get over it already! Not everyone wants to edit xml files and restart their apps every time they want to make a change to some setting. Not everything needs to be stored as xml "because then it's compatible with any other software". Yeah right, if only every app developer didn't use their own weird mapping style, naming conventions and change the xml file layouts every, oh, two months or so.

One thing that I've been wondering is, that for the past five years or so, about half the job postings I've seend include Java, so apparently there is a huge amount of Java software written - but where does it all go? I don't have any Java apps on my computer(s), and I don't really know of any that isn't trivial and stupid (IBM laptop configuration stuff) or just add-ons to Java development tools (like Eclipse) or some other trinkets (games, addons, plugins and so on). Anyone have any good examples of real-life, end-user Java apps?
Antti Kurenniemi Send private email
Thursday, February 23, 2006
 
 
Once you program in Python, Ruby or Delphi you will forever be changed. Java will seem like a less productive language.

It's like getting off from a BMW and getting into a cheap 1970 car.
Jackson
Thursday, February 23, 2006
 
 
Java is certainly a valid choice for development, although you must keep some caveats in mind, most of which have been mentioned above, but which can mostly be taken care of in one way or another.

My personal issue with Java is that it's too much trying to be a "middle of the road" language, trying to appeal to everyone and become an "end all, be all" solution for all your development needs. For example, it's an OOP language,but directly breaks the open-closed principle; it wants to be cross platform, but still is compiled (the bytecode compilation in itself is the most nonsensical compromise for me -- if you want speed, compile to native code; if you want flexibility and speed of development, interpret); it has garbage collector, but is still statically typed...

Basically, all the compromises it offers make it an inferior language overall. If languages were that difficult to learn, it would make a lot of sense to learn one and stick to it; but as things are there is no reason for a developer to learn C++ and employ it for low level development, and some scripting language like Python or even PHP for Web development and other "glue" tasks.
Berislav Lopac Send private email
Thursday, February 23, 2006
 
 
I don't know what you mean by "open-close principle", and your other two complaints make no sense.

Why is JIT compilation a "nonsensical compromise"? You don't want interpretation because it's unusably slow for any real algorithmic work. JIT compilation means you only have to implement a fairly simple bytecode compiler on each target platform, as opposed to a full language compiler.

Static typing has nothing whatsoever to do with garbage collection. Static typing is about error checking at compile time, it's not about technical limitations. And
you can always refine static typing by inferred typing, as in LINQ and F# for .NET, although we'll see if Sun ever gets of its lazy butt to actually implement that.
Chris Nahr Send private email
Thursday, February 23, 2006
 
 
PS: Static typing also gives you IntelliSense (or whatever Java guys call it) in the IDE, which is not a small advantage. Writing a Visual Studio macro is much more painful than regular VB.NET programming because the VS macro API mostly just returns objects, so you have to look up their real types and members in the documentation. Unkown variable types at editing time is a defect, not a feature.
Chris Nahr Send private email
Thursday, February 23, 2006
 
 
PPS: JIT compilation not just simplifies implementation of the compiler, it's also fast enough and fully automatic. That means you can effectively distribute bytecode binaries. With real compilation, you can't distribute unified binaries (not cross-platform compatible) and source code is too much of a hassle to compile. JIT compilation is a great compromise.
Chris Nahr Send private email
Thursday, February 23, 2006
 
 
To the OP,

The biggest shortfall I think you'll find, since you come from scripting languages, is that it is a general purpose language/platform.  Some things that are simple in scripting languages take some more effort in Java.  That is one reason why you see so many frameworks all over the place in the Java world.  Everyone is trying to solve the basic infrastruces of application so developers can concetrate on solving the requirements.  However, often these frameworks add too much complexity.  Some people even feel that way about much of J2EE.  None of this means that scripting languagea are better than Java.  They are just tools that certain situations demand one or the other.  Learn Java and .NET too if you can and understand for yourself when one is better than the other.
Bill Rushmore Send private email
Thursday, February 23, 2006
 
 
I have had good experiences doing java GUIs with Swing.  Use JGoodies Looks to make your app look nice.

The downside to java?  Applications have a much larger memory footprint than native apps.  Startup time is longer (though much better in current versions).  Most of the rest of the gripes you see on this thread are because of choices the developer made or didn;t make.
name withheld out of cowardice
Thursday, February 23, 2006
 
 
Quote: " One thing that I've been wondering is, that for the past five years or so, about half the job postings I've seend include Java, so apparently there is a huge amount of Java software written - but where does it all go?
...
Anyone have any good examples of real-life, end-user Java apps?"

Who says Java has to end up being a client side app?
Most of the good examples I have seen are server apps running out of Weblogic (or another server) where the end user has no care that it's Java because to them it is just some html being served up instead of a client.

Still, end user java applications (ones that start up the JVM on a local desktop) are something I have rarely seen as well. About the only one I can think of that I have used is the Bittorrent client Azureus. You would think that with Java WebStart, Java apps would be more common because they could be easilly pushed and updated. I'm currently using JWS for a personal development project because it makes keeping testers/users update to date easy.
John Goewert Send private email
Thursday, February 23, 2006
 
 
reason java sucks...

1. too large

2. tries to solve too many problems

3. try{ }catch(Exception e){} handling is needed from
almost every function. this adds like millions of lines of code for no reason...better way to handle errors is just return null...and write to standard io some message.

4. easily hackable..forget shipping anything secure in java to the desktop...i decompile and steal code all the time. If you have real technology; then you probably don't want it stolen.

5. Barrier to entry for ordinary users...hmmm...somethings i think you people are morons...the average person who uses a computer could give a shit about 'classpath' and environment settings. they want to click an run...

6. SLOW...if you have to do real processing with multiple threads on a desktop; good luck. hence the argument: photoshop will never be written in java.

7. Proprietary -- its control and owned by sun...which has no business model and is slowing going the way of the dinosaurs...i don't want my company to use technology which is becoming extinct.

8. BORING...java developers and the technologies it is used for are the bottom of the barrel when it comes to cool. Anyone say IT
Lemon Obrien from portable Send private email
Thursday, February 23, 2006
 
 
"...i decompile and steal code all the time..."

Lemon, you are a bastard.
BenjiSmith Send private email
Thursday, February 23, 2006
 
 
+++++ Java IDE's really spank the llama's ass. They just do.
------ Sub standard out of the box newbie ability of running apps on a user's computer.  Sure it works, but it takes experience to make it work -good-.
+++++ Opening a Java IDE feels like coming home with a cozy fireplace already started and a glass of your favorite drink poured out.
+++++- Java IDE's sometimes take their sweet bloody time while they pour through your 0.5GB of libraries and class files and source files.
+++++ swt is native
+++-- don't believe a word anybody says about the prohibition of subclassing swt.  Swt & jface is designed very promiscously.  Classes can be tightly bound inside packages.  Myself, I run a bytecode modifier to alter packagerestricted methods to protected for a select set of classes.  This alleviates some of the pain swt inflicts.
++--- programming swt has painful parts.  Be prepared to do some minor lifting to alleviate said pain.
----- If you have peculiar platform specific needs, you will need to become experienced in opening up API functions to the java application.
Dave
Thursday, February 23, 2006
 
 
"Static typing has nothing whatsoever to do with garbage collection. Static typing is about error checking at compile time, it's not about technical limitations."

Bull. If you don't have garbage collection (i.e. if you have to collect your garbage by hand, as in C/C++), you need static typing to know how large your variables are so you can plan for memory. With garbage collection, you absolutely don't *need* static typing -- it may come in handy for various things, such as error checking, but that's a side effect (not to mention that it cannot catch all typing errors).

Don't confuse effect with the cause.
Berislav Lopac Send private email
Thursday, February 23, 2006
 
 
it's just a horrible brain-dead pigs ear of a language. Good for people learning to program, but a blunt instrument for most real purposes where software-law-enforcement isn't the prime concern (perhaps because you have devs you trust ...)

It forces to to do everything *it's* way because of some god-awful dogmatic idea that *everytjing* has to be an object.

So : you want a decent data structure (resizable arrays, hashes, anyone?) - go dig around in the ****ing class library. Why not put these in teh language (like people that were designing languages to actuallt be used did).

Likewise regex's. Or file handling. Or any one of a hundred other fundamental computing concepts.

And why no function pointers?

It's just a grim, barren landscape designed to satisfy a mindset which is so frightened that a dev might accidentally break something that they took most of the useful tools and stuck them in a high cupboard in case the kids cut their fingers accidentally.
revert my buffer
Thursday, February 23, 2006
 
 
"You don't want interpretation because it's unusably slow for any real algorithmic work."

And so is bytecode. I'm not saying let's ditch Java and do interpreted -- I'm saying ditch Java and go for what is required. If your program is highly algorithmical, go for compiled languages, like C.

"Static typing also gives you IntelliSense (or whatever Java guys call it) in the IDE, which is not a small advantage."

I'm sorry, but most of the advantages in both Java and .NET appear to be aimed to the "lazy" programmers, ie. those who are not interested in what happens below the surface. Point and click, IntelliSense, I don't have to think about what I'm doing. It's not my fault if something goes wrong...

"JIT compilation not just simplifies implementation of the compiler, it's also fast enough and fully automatic. That means you can effectively distribute bytecode binaries."

Also, all arguments point to only one side of the road. Yes, with compiled languages you can't distribute a true cross-platform binary. But with bytecode you need a runtime engine -- why not all the way over and use an interpreted language? Java seems to me like that donkey who died of hunger because it couldn't decide between two stacks of hay to eat.
Berislav Lopac Send private email
Thursday, February 23, 2006
 
 
You'd better give evidence supporting static typing is not designed for better error checking and catching type errors at compile time.

The reason you need the type of the variables to allocate and free memory is for some languages type information is not carried with the objects in the memory. In theory nothing stop a language to have both static typeing and type-annotated objects in memory.
Rick Tang Send private email
Thursday, February 23, 2006
 
 
"You'd better give evidence supporting static typing is not designed for better error checking and catching type errors at compile time."

Because it vastly predates objects and OOP. In a non-OOP language, what function does a variable type serve except for preventing an incorrectly-sized value to be placed to a wrong place in memory? Indeed, in C you can easily swap a struct for another of a different type if their sizes are the same; I've used that trick myself...
Berislav Lopac Send private email
Thursday, February 23, 2006
 
 
Berislav, what can I say? You're simply wrong on every account.

JIT-compiled byte code as slow as interpreted code? Completely untrue. JIT compilation is faster by a factor of 100 if C# vs Python is any guide.

IntelliSense is for the "lazy" programmer? Demagogic caveman bullshit. Why not tell everyone to use vi?

Static typing...? I can't even make sense of the garbled argument you're trying to make here. Have you ever heard of C++ RTTI or ML inferred typing? You seem to confuse a lot of things here.
Chris Nahr Send private email
Thursday, February 23, 2006
 
 
Incidentally, one of the benefits of bytecode compilation is that the JIT compiler can use data gathered at runtime to perform a more-efficient JIT compilation of the code than could be accomplished using static compilation.

At any rate, I routinely write code in Java that outperforms the C++ equivalent written by others on my team. Then the C++ guys will add a few optimizations so that their code outperforms mine. Then I'll teak a few lines of code, putting mine in the lead. And so on.

It's fun.

Sometimes their final version is faster than mine. But not always.

It's my expectation that the C++ code will end up a little faster than the Java code most of the time, but the difference in speed capability is slim. And I think the Java programming language is altogether a more pleasant programming language than C++, so I think the slight speed tradeoff is worth it.

Keep in mind, too, that I'm talking about complex statistical analysis applications that process hundreds of megabytes of data, calculating probabilities from hundreds of thousands of input variables and performing clustering in n-dimensional space. In other words, this is not trivial stuff. And Java is easily as capable as C++, with a speed difference of maybe 5% to 15% (at worst).
BenjiSmith Send private email
Thursday, February 23, 2006
 
 
BenjiSmith,

You are throwing numbers :)

How about I claim that Java programming usually takes 500% more memory?

Nevertheless, it's amazing how managed language C# and Java can be so fast coming with less than double the speed of C++  for most programs.
Rick Tang Send private email
Thursday, February 23, 2006
 
 
>Sun has (largely) solved much of the issue with client deploy through java webstart.  If you are writing gui applications to deploy to clients, I highly recommend looking into this tool


Thank you no name!  I have a swing app I built for some non-technical users to automate some tasks for them.  I haven't wrote a Java GUI app in almost 5 years so I forgot about Webstart but after I read your post this morning I gave it a try.  It is awesome!  I just email them a URL and they are in business.
Bill Rushmore Send private email
Thursday, February 23, 2006
 
 
"How about I claim that Java programming usually takes 500% more memory?"

That's often (though not always) true.

In response, I'll just shrug my shoulders and say that I don't care. My analytic applications typically consume less than 32 MB at any point during their execution. If a C++ implementation can do the same thing in only 5 or 6 MB, then more power to 'em.

If I were in a more memory-constrained environment (like an espresso machine), I would probably prefer to use C or C++.
BenjiSmith Send private email
Thursday, February 23, 2006
 
 
>>"...i decompile and steal code all the time..."

>>Lemon, you are a bastard.

great artist steal. Picaso...an yeah; i'm a bastard.
Lemon Obrien from portable Send private email
Thursday, February 23, 2006
 
 
noone mentioned startup time, which is eons in java, and often matters much more than raw speed (java isn't that slow afaik).

There are implementations that will run in small memory (I know someone that works with an OS version that will run on an embedded platform with 4M RAM, 4M ROM).

None of this matters in many cases. I just don't like the language.
revert my buffer
Thursday, February 23, 2006
 
 
"Berislav, what can I say?"

Just about as muvh as you know about the underlying principles.

"JIT-compiled byte code as slow as interpreted code?"

I never said that. I said that it's slower than compiled code, at least in general. In any case, compiled code can be optimized for the target platform better than any bytecode-compiled code.

"IntelliSense is for the "lazy" programmer? Demagogic caveman bullshit. Why not tell everyone to use vi?"

It's not about which editor you use -- it's about understanding the underlying principles. I also use, say, Dreamweaver to help me write my HTML; but I damn well understand what each tag means.

"Static typing...? I can't even make sense of the garbled argument you're trying to make here. Have you ever heard of C++ RTTI or ML inferred typing?"

This is a circular argument my friend -- I was not talking about C++ and how it handles dynamic types. I was talking about why static typing appeared in the first place. Error checking came later as a side benefit.
Berislav Lopac Send private email
Thursday, February 23, 2006
 
 
a) muvh => much

b) In that last point: I wasn't talking about C++ at all -- I was talking about C.
Berislav Lopac Send private email
Thursday, February 23, 2006
 
 
But static typing and C are different concepts!

You know, static typing appeared first in Fortran and Algol.
Rick Tang Send private email
Thursday, February 23, 2006
 
 
Ok, I'll give you that in FORTRAN the reason for static type is for efficient compilation.

But if you want to argue, do it with accuracy :)
Rick Tang Send private email
Thursday, February 23, 2006
 
 
I found that java "Hello world" apps have a 15MB memory footprint on Windows.

That's 15 MB for each instance. No shared memory. So run 10 hello worlds and there goes 150 MB.
dot for this one
Friday, February 24, 2006
 
 
"But if you want to argue, do it with accuracy :)"

C was an example. FORTRAN is a proof.
Berislav Lopac Send private email
Friday, February 24, 2006
 
 
Benji:
"You can eliminate the necessity of typing the commandline argument by providing users with a shellscript or bat file. But that's still cumbersome because it will open up a DOS window while your application launches, and it looks really dumb."

Try javaw instead of java


Berislav
"I never said that. I said that it's slower than compiled code, at least in general. In any case, compiled code can be optimized for the target platform better than any bytecode-compiled code."

The interesting thing is that the JIT compiler can actually optimize the code for it's own installed run-time environment, because the JIT compiler that is installed is the specific compiler for that environment. For instance, the JIT compiler knows whether its P3/P4/Athlon, or whether there is a dual processor, or a hyperthreaded cpu, etc etc.

Typically, with a C++ compiler, you'd set optimization settings according to the typical machine you'd expect the application to run on.
Chris Welsh Send private email
Friday, February 24, 2006
 
 
@Chris:

Excellent point. But that means that there have to be either a different JIT compiler for each platform (or a group of them), or one very clever compiler which has an overhead of the code needed to recognize and adapt to a platform. Even more compromises.

So, let's look at it not from the technology POV, but from a practical one:

Let's say you have a product that will be widely distributed, and you don't have any idea what it will end up running on (AMD, Intel, dual-processor etc). It is a choice of going for a pre-compiled binary which has to compromise for a wide area of platforms (thus sacrificing some performance) on one hand, and a probably more efficient JIT distribution, which however depends on a largish compiler being present on the user's system (or distributed along with it). I'm not saying either is inherently better -- the vendor has to decide which poses a more of a potential inconvenience to the end user.

On the other hand, if you have full control over the target machine (as in, e.g. Web application), you can compile as precise as you wish, while there is no concerns on JIT compiler distribution.

In the end, neither has (in this area at least) that many inherent advantages over the other; it all comes to the preferences and skills of the development team.
Berislav Lopac Send private email
Friday, February 24, 2006
 
 
VM does not only provide better compilation for different platform, but also runtime diagnostic of running code.

Its advantage is not as big for server software. That's true.

Back to static typing. Historically you are right; in the beginning its advantage for better error checking is a side effect.

But when it becomes not strictly necessary, error checking at compilation is the reason why some language adopted it. But garbage collection is an orthogonal issue.
Rick Tang Send private email
Friday, February 24, 2006
 
 
"But garbage collection is an orthogonal issue."

It's orthogonal to type-checking; it's not to memory handling through type sizes.

In any case, in OOP, types are irrelevant. What matters are interfaces, and static typing can't discover these.
Berislav Lopac Send private email
Friday, February 24, 2006
 
 
Um, so why exactly did the sister thread ("What is the upside of Java" by Rick Tang) get deleted? Last I checked there was plenty of on-topic discussion going on there...
Chris Nahr Send private email
Monday, February 27, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz