Slashdot Mirror
The Future of Java?
Todd AvErth writes "Judge Motz recently ordered Microsoft to distribute Sun's JVM with every Windows product. Salon decided to pipe up about it with an editorial musing about whether or not it's too late. Most of it isn't all that interesting, but some of the comments from Ximian developer, Miguel de Icaza point to the advantage of being able to compile from multiple languages. Anyone know of any projects to compile JVM bytecode from other languages?" Update: 01/23 16:00 GMT by M : Comments were disallowed when this story was originally posted; fixed now. My mistake (although KDE3's stupid mouseover-activates-form-elements user interface, now finally fixed in the latest versions, has to take some blame too).
I'm prepeared to bet a great deal (well, my career, in fact) that Mono will never reliably run .NET applications produced by Microsoft (or indeed by other people using Microsoft tools). If you write for the JVM, you will have a reliable ful-featured runtime both on Sun platforms and on platforms which compete with Sun platforms. We know this from Sun's historic behaviour: Java runs extremely well both on Linux and on IBM RS/6000 boxes. If you write for .NET, you will never have a reliable, full featured run time on any platform which Microsoft sees as a serious competitor. We know this, too, from Microsoft's historical behaviour. The leopard has not changed its spots.
I'm old enough to remember when discussions on Slashdot were well informed.
I doubt that this qualifies as objective since it is my personal opinion, but I hope it isn't cliche-ridden.
There are several features of Java that I really miss when I have to code in C or C++:
Class.forName
To dynamically load a class, I just do Class.forName(classname). Combined with the Factory pattern, this makes it much easier to create pluggable implementations. You can still do that in C++, it's just harder.
exception.printStackTrace()
C++ has exceptions, but you can't get a stack trace on-the-fly from one. In a Java program, I can handle exceptions and log them to a database for later debugging. That makes it easier to find bugs.
Also, Java lets you know when you have the potential for unhandled exceptions (some people hate that, too, but I like it).
Built-in thread awareness
This one is probably closer to laziness, but I like being able to declare a method or block of code as synchronized, which is essentially the same as protecting it with a mutex. Using something like QMutex in C++ isn't really too much extra work.
Array bounds checking
This is another that C++ can do, but you have to do extra work for it. There are plenty of times when a Java program runs off the end of an array. Instead of giving me a core dump and killing the program (if I'm lucky), I get a nice little exception that I can handle. The same goes for referencing a null pointer (reference).
Garbage Collection
Okay, it's a blessing and a curse. On one hand, I don't have to worry about keeping track of references. On the other hand, you still get memory leaks, and your Java programs consume a lot more memory. Still, I really miss it when I start having to write destructors and copy constructors. In a large system, it is more difficult to keep track of who is supposed to free what memory. You end up using reference-counted pointers, which solve a lot of problems, but not all of them.
Reflection
I don't use reflection very often when writing business logic, but it comes in handy for writing frameworks. It is great to be able to dynamically access methods and fields at runtime (you locate the method/field by name, so it doesn't have to be known at compile time). Many of the networking and database frameworks use reflection to keep you from having to write tons of custom methods just to support the framework.
The libraries
Java has a great set of libraries that come with the standard JRE/JDK. While you can find the equivalent libraries for other languages, with Java you don't have to go searching as much. Plus, you know they're going to work when you move the application from platform to platform.
Java isn't perfect, the runtime is huge, the programs take a good bit of memory, swing still seems clunky to me, but when I have to do a large server application, I'd much rather be coding it in Java than C++.
Greetings Tablizer,
I've read many of your posts here on Slashdot as well as your web site. I've found your arguments to be well-written. However, many of your arguments are as subjective as some of the posters here. You say in your own writings, in fact, that you have difficulty thinking about things as objects with behavior. And that, in my _opinion_, is what it's really about.
Programming languages should be built for people, as they represent a communication channel between people and computers. Software texts often must account for communication to other humans, hence the need for comments.
Experienced language designers take this into account. Their experience also leads them to add things to the language to prevent or at least deter common mistakes. Those "good features" in Visual Basic you mention, have produced a history of unreadable and buggy code.
Where would you suggest today's application programmers spend their time? Is it more valuable, more marketable to learn a single OS / OE, a single database (and be a one-trick pony), or should they spend their time on learning a single, rich API that applies to multiple platforms?
I'll make no pretenses that Java is more machine-efficient than C, or that O/R mapping is faster than embedded SQL. I will say that I find domain logic easier to unit test in isolation when you use an O-O domain model with mapping. These test can be automated and even serve as a kind of usage guide to the software.
The point of this is, the Java language has an accepted and refined way to work at a reasonable level of abstraction. If machine-efficiency were always 'better' then we'd all use CPU specific assembly languages.
BTW: The popularity metric does have merit as an argument. Popularity leads to communities. Communities can work together to advance the state of the practice, to share techniques. You complained about this very fact in your essays. 'Not enough people are contributing to the advancement of Procedural/Relational practice,' you said. I believe you are correct, and the reason for this is industry support and community.
Regards,
Michael Murphree
The opinions expressed in this post are my own, and not necessarily those of my employer.