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).
when you think about it, MS is really trying to kill java... and in more ways than just the JVM stuff. If you ever visit the MSDN, you might see many items for converting your java code to C#, reasons to use C#.
Take away the business side, what are the advantages of using java versus C#? Looking at Mono it seems to marry both technologies -- correct me if I'm wrong, but they want to compile both.
--------
Free your mind.
Miguel de Icaza point to the advantage of being able to compile from multiple languages.
As a person who've got a feel of writing JVM-targeted compilers, I'd like to notice that it makes extremely poor target for other languages. JVM was designed explicitly for Java, without any other language in mind. Thus, writing translators from other languages takes certain number of convoluted tricks.
If your source language has closures, true lexical scoping, multimethods or multiple inheritance, JVM is clearly a suboptimal vehicle, unless you want to bend over a lot. From performance standpoint, its stack-oriented machine isn't optimal either. JVM architecture also leaves no easy ways to implement proper tail-recursion.
CLR is likely a much better target, but even that one, designed for interoperability from scratch, has some rough edges for non-mainstream programming languages.
Lisp is the Tengwar of programming languages.
Are you kidding? How about an extensive, reliable, tested library of networking, user interface, and I/O code which can be used to create "complex applications" extremely easily.
I look at their code and it appears to me like they don't know how to use a relational database, so they spend a bunch of code on reinventing indexing, joining, multi-user contentent management, persistence, searching, sorting, etc
I can't comment on your colleague's coding standards and style, but it appears that they may have been coding cross platform JDBC code, using only simple DB features so that they could switch databases easily. I know it's not unusual to develop initially using something like Apache/Tomcat and MySql, then switch to 3rd party commercial app servers and databases. Anyway, a criticism of their code cannot be taken as a criticism of the language. The fact that you can replace these DB functions in Java code makes it even more flexible.
I realize that each language has its strengths and weaknesses, but bear with me for a moment. You get hired at a new job, where you inherit a .NET application. As far as anyone knows, it's C#. When you start looking at it further, you realize that it is actually made up of half a dozen languages, all of which you'll have to know at least remotely before you can understand the whole thing. Is this necessarily a _good_ thing? I don't think so. The argument Microsoft uses is "everyone can use what they know, and are most productive in". That's all well and good until those people leave.
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++.
Show me some objective evidence that Java is superior, not brochure cliches.
There's not going to be objective evidence of a subjective comment. "Superior" is ultimately a matter of opinion. I personally think python is the "superior" language of all those I have tried, but that's my opinion.
What I can say conclusively is that a programmer of equal skill in C++ and Java can write the same program in less lines of Java code. Java does lots of stuff "for free" that gets the job done faster, like memory allocation and garbage collection, and handling pointers transparently. If your goal is a good application written quickly, Java may very well be "superior" for your needs.
Another advantage of Java over other languages (except Perl and Python) is the huge and wonderful library of methods and classes. You can accomplish these goals with C or C++, but generally you have to go out and find the libraries to do what you want, then compile them for your particular platform. Java generally includes them, and for those that are not included, they're distributed pre-compiled for the JVM.
So it's not fair to say Java is "Superior", because that really depends on what you're looking for. If you're looking to build enterprise web applications, Java is likely superior. If you're looking to crunch numbers as fast as possible, you're likely to be happier with C or C++. It depends on the project and the goals.
- Vincit qui patitur.
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.
Languages for the Java VM...can be found here...
And that page has been up for at least 4 years, and comes up top on the Google search "Languages for the Java VM." So I think the real question is: why does the meme that Java bytecode can only be generated from javacc continue? Even if you regard most of the things on that page as academic, they're at very least proof-of-concept (and ad naseum at that, due to sheer numbers). Not to mention what the presence of clearly non- academic implementations like Jython.
I don't know whether or not Sun intended to design Java so that this was possible or easy. But it seems pretty obvious to me: you can target a VM as easily as you can target a processor, and that's what any compiler does. Why doesn't the Java-only for Java-VM meme die?
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
However for me Java has not delivered on it's promises. Performance generally is poor, compared to say Perl, and is dire when compared to C.
.ear file...no compiling involved. Any issues I have ever run into have been when the have code makes JNI calls or when environmental differences in the OS are not taken into account during a JDK install (think .so vs .sa). Sometimes poor programming, like hard coding "/" vs "\" in path names, but that is hardly the fault of the language. Even with a few warts, the fact still remains that I cannot compile C or C++ on a linus box and just run it on Windows box. With Java I can.
FUD, FUD and more FUD.
Starting with the jdk1.3.1_x series Java has been pretty peppy. JDK 1.4.1_x is downright speedy. Do a google search. On the server, Java is very fast and even some Swing apps can beat native code. Java in 1998 was slow. Java today is not. Get over it and stop living in the past.
Java also failed to deliver it's platform independence - you just get so many problems running on different platforms and different VMs. Compare this to say Perl - if you avoid platform specifics, Perl just works. Even compare to C when using a library to abstract platform independence (e.g. things like in Gnome/Gtk or Qt), it's not so hard and at least the mistakes are usually yours. I know it's not the fault of Java as a language, but if it can't be implemented well, it won't be much good.
Well I don't know what your experience is but I have never run into any issues with Java being cross-platform. I have literaly just finished doing some bug fixes to a J2EE app for one of our clients. I develop on Win2K, test deploy on Solaris (Sparc) and will deploy it tommorow on HP-UX. All I do is redeploy the
The final major reason Java has not delivered is because it's not made programming any easier or error prone - and much has been made of this promise. Yes, gc does save some bugs (it does cause some more, but on the whole it's good). Java does not save you from uneducated developers or people who simply suck as a programmer. I've seen some steaming piles of turds writted in Java by people who really should be better. This can be said of any language, but much was made about Java being a language to make people make less mistakes - they just make different ones.
I guess this is a matter of degrees isn't it. No Java isn't perfect. But it's a darn site easier to learn and maintain than other, more obfuscated languages like Perl. Java is a language that let's you make less fatal mistakes. No buffer overflows, no pointers, strict type checking and casting rules as well as the Java sandbox go a long way in protecting a system running Java. Can the same be said about C? So even if I'm a bad java programmer, I can't be bad enough to cause the OS to crash or to introduce a system level vunerablility. C give you the freedom to do anything...kinda like giving you enough rope to hang yourself (and two of your friends sometimes).
Despite all that, use the Right Tool for the Job. If that is Java, use it. If it's C (and you can use it right) use it.
But please don't go spreading half-truths and crap to get moderated up.
Never by hatred has hatred been appeased, only by kindness - the Buddha
Roger Sessions ... now there's an unbiased observer. Once upon a time, Roger was a CORBA spec writer, until he basically got booed out of the CORBA camp for non-performance (this spec is going to be SO good when it's finished ... really!) Then he became a COM/DCOM/COM+ apologist for Microsoft. Read through his ObjectWatch newsletters and see if you can spot any unbiased commentary on technologies; you will quickly observe a trend: Microsoft good, non-Microsoft bad. I won't say that Roger is a complete bought-and-paid-for Microsoft shill, but he gets his books published by Microsoft Press... you draw your own conclusions.
As for the JVM's language-neutrality (or lack thereof): so what, big deal.
There is no such thing as a language-neutral platform, be it hardware or virtual. Every computer instruction set that has been developed to date has had biases built in; it's inevitable. The system designer has certain goals, and usually has a target set of capabilities, which may only work in assembly language. Take the X86 instruction set: only a fraction of the X86 instructions are useful to a C compiler. The rest of the instructions can only be used by writing assembly language. The only hardware instruction sets that I can think of that are completely accessible by a higher level language are those that were specifically designed to implement a single language (Forth, LISP), and they make lousy targets for other languages.
The question is: does it matter? There are very good reasons why the JVM doesn't allow pointer arithmetic and pointer casting: the designers wanted a provably secure runtime environment, so they excluded unsafe operations. So you can't implement C/C++ for the JVM; big deal. If you really need those capabilities, you're better off operating outside of the JVM and interacting via JNI or some form of RPC. That said, there are still plenty of languages that are written in Java, compile to Java, or compile directly to Java bytecodes; certainly more than currently target the .NET CLI or any other virtual machine. Use one of those, or write your own.
We call it art because we have names for the things we understand.