The Future of Java? 624
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).
Languages for the Java VM... (Score:5, Informative)
It doesn't mention SmartEiffel, though, which does generate byte codes. There are probably many others as well.
a lot (Score:1, Informative)
see http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.h
Jython (Score:5, Informative)
Allows to write programs in python and compile into java bytecode. Access to awt for sure. I think there is also a port where you can write Tkinter applications in jython as well.
Microsoft Appeal (Score:3, Informative)
Ada 95 to Java bytecodes (Score:1, Informative)
Google Search (Score:5, Informative)
Here's [tu-berlin.de] a nice list of languages that work within the Java VM. I'd like to point out that its a very long list.
Also, Java on the desktop has always had issues. Everytime someone brings up the "future" of java, they tend to forget that Java's current strength is on the server side where the average user doesn't see it and doesn't know about it. Java's competition is
Language popularity ranking (Score:5, Informative)
I find it more fascinating that Perl is growing faster than PHP. I dig Perl, but I keep thinking I need to get on this PHP bandwagon. Apparently, it's not much of a bandwagon.
Tons (Score:3, Informative)
This page [tu-berlin.de] links to a whole whack of projects.
To give a smattering: Forth, Ruby, Cobol, Eiffel, Prolog, Basic, Lisp, Tcl.
LOTS of languages compile to Java bytecode (Score:3, Informative)
This page [tu-berlin.de] lists over 150...
Apple Cocoa (Score:5, Informative)
Both languages share so much of the same concepts that both languages can call in each other, allowing a project to be composed of both Obj-C and java.
Given Apple's recent extensions to Obj-C, the so-called Objective-C++, you can actually mix C, C++ and Obj-C source code in the same file and interchangeably make cals to and from C++ classes and obj-C classes. Then, calling Java is nearly as trivial.
These changes are finding their way back into the GCC compiler, which is the standard compiler for the Project builder environment.
Jython (Score:5, Informative)
Jython [jython.org]
# Dynamic compilation to Java bytecodes - leads to highest possible performance without sacrificing interactivity.
# Ability to extend existing Java classes in Jython - allows effective use of abstract classes.
# Optional static compilation - allows creation of applets, servlets, beans,
# Bean Properties - make use of Java packages much easier.
# Python Language - combines remarkable power with very clear syntax. It also supports a full object-oriented programming model which makes it a natural fit for Java's OO design.
Java applications I've SEEN are unimpressive... (Score:2, Informative)
Yes, yes, yes, I know that theoretically these problems could all be solved, and that no doubt it's because they're not using version the latest version X.0165 of Java GUI technology flavor Y... and it's all Microsoft's fault... and so forth...
And I still experience a feeling of dread whenever I go to a web page and see "Applet loading..."
couple of comments on that article (Score:2, Informative)
Also, it always irritates me when they ask only the most biased people imaginable whether such-and-such a technology is going to survive. It's like asking the Pope and the Ayatollah which is the best religion...and leaves us no clearer as to what is really going to happen...
Re:Who wants multiple languages? (Score:2, Informative)
Sun has $5 billion and minor debt (Score:1, Informative)
Re:The Future of Java? Even Brighter!! (Score:5, Informative)
Sure Swing is a little sluggish, but when everyone is running a p4 2GHz, it really doesn't matter....
But it does matter, if other programming languages still run relatively faster than Java. I agree that it's not as clunky as it was a few years ago though... *shudder*
Two things I feel you've left out are:
1 - The embedded systems market. When I was at Uni this was being touted as the next best thing. I don't have any real statistics for you, but I'm sure Java is doing well in this field.
2 - The mobile phone market. Pretty similar to my first point, the KVM (Kilobyte VM - a cut-down version of JVM) and related APIs in J2ME are a big player in the mobile phone business. The company I work for is developing mobile phone games, and Java has got the support of the handset manufacturers, which will give it superiority over other technologies that havn't had as good an uptake.
Re:Ada (Score:1, Informative)
ftp://cs.nyu.edu/pub/gnat/jgnat
Not really feasable (Score:3, Informative)
Microsoft's CLR (common language runtime; part of
Personally, I am not convinced that such a common runtime is always an advantage. The CLR basically defines its own machine language, with all the basic instructions you'd see in any other assembly language. I don't like that approach because it is too low-level, and makes optimization harder. Allow me to explain...
It is a rather common misconception that bytecode-compiled languages must necessarily be slower than native compiled languages. The opposite is actually true in many cases. If you are running your bytecode on some sort of interpreter, then yes, it will be slower, but typically bytecode is re-compiled to native code at runtime. When this happens, the compiler can perform all sorts of optimizations specific to the host machine, OS, and the exact library set in use, which would be impossible if the software were distributed as native code. Thus, the code actually ends up faster... in Java's case, it can approach the speed of C, which is surprising considering all the abstraction in the Java language -- based on the languages alone, you would expect Java to be much slower.
Anyway, getting back to the point, higher level bytecode descriptions allow more optimization on the host machine. I am actually desiging a programming language right now, and my bytecode is only a little more than a parse tree. I like it that way.
Just think of the language runtime like a library. Different programs use different libraries. What's wrong with that?
AspectJ (Score:3, Informative)
Of course, it's not a true departure from Java... it even recommends that program filenames end in .java . It can compile java code, but not the other way around.
JVM actually has more languages than .NET (CLR) (Score:4, Informative)
Not what the marketing folks at Microsoft would have you believe, huh?
Re:Ada (Score:2, Informative)
Re:Yes they did... (Score:5, Informative)
Sun's annoucement almost 6 years ago that they and Rockwell Collins would be making picoJava chips [sun.com]
Re:Languages for the Java VM... (Score:3, Informative)
There was a lot of talk about this in the various Java newsgroups in the mid-to-late '90s (here [google.com] is a typical thread on the subject). From what I remember, Sun originally thought that specialized Java processors, or even coprocessors on a daughterboard, might be a good idea. But, because the Java VM is a stack-based machine, implementing it in silicon turned out to be harder than expected, for less benefit than was hoped. I think they ultimately decided that it would be more cost effective to improve the JIT than to develop a Java CPU.
I don't have any hard data or links to back any of this up, it's just what I remember.
JiL - java in lisp ... compiles to the jvm (Score:2, Informative)
Here's another language JiL that compiles to Java Byte Codes. It's a language that's better than Java but worse than Common Lisp, so it kind of sits there in the middle.
It allows Java programmers to get around one of Java's biggest weaknesses - the lack of a macros.
http://www.franz.com/support/documentation/6.2/doc /jil.htm [franz.com]
Re:Java is NOT in danger, sun is. (Score:1, Informative)
You have a wrong view of the GPL.
(Assuming all of Java is GPL) If I modify the core java APIs and write a product with it, I can SELL the product, but I'd have to supply everyone with the source to my modified java apis (not the source for the product).
Re:Languages for the Java VM... (Score:5, Informative)
www.ajile.com (and www.systronix.com has a few boards built witht the processors).
www.ptsc.com
Also, the Jazelle technology from ARM embeds a java processor section into an ARM chip:
http://www.arm.com/armtech/jazelle?OpenDocument
Re:Java is NOT in danger, sun is. (Score:3, Informative)
Oh, FUD and nonsense. Perl is GPL, and nobody has even hinted that this means that perl programs must be GPL'd. Tcl and TK and GPL, and the same applies. If you bother to read the GPL, you'll find language that explicitly covers things like libraries (which is what the JVM amounts to), and it is made clear that GPL licensing for libraries doesn't extent to things that use the libraries.
Methinks people are falling for Microsoft's anti-GPL propaganda.
Actually, this isn't a frivolous worry. I worked on projects at several companies, including Digital, where the lawyers advised strongly against basing any products on Sys/V or any ATT libraries. They thought that ATT's licensing did imply that if you linked to ATT's libc.a, then ATT could claim to own your software. The story seemed to be that the lawyers thought this could be challenged in court, and you'd probably win, but if ATT wanted to press the issue, it could cost you a decade and a billion dollars to get the case decided. Better to go with BSD or OSF or roll your own (or now use linux), and be safe.
This was widely believed at Digital to be the primary reason they went with other kinds of unix. It was much of the reason that the BSD gang decided to eliminate ATT code from their system. It was also a serious concern among the GNU people, which is why they explicitly address the issue in the GPL.
Re:A duck (Score:3, Informative)
I don't know why no one has called Miguel on his claim that you have to translate everything to Java, but .NET provides a happy shiny world where all of the languages are well-supported. Clearly that's untrue.
Re:Languages for the Java VM... (Score:2, Informative)
Re:Who wants multiple languages? (Score:5, Informative)
There was a game written in perl and C - perl for most of the game for garbage collection, bounds checking, etc. and C for the low level graphics to make it fast.
Many more programs mix a really low level, low level and high level language. Games mix asm, C/C++, and lisp/prolog/made-up language. Intranets often have a mix of a javascript, java, C and some high level pure functional language (that would be like SML or Haskell) (Like lotus domino has - forget what it's called.)
Being able to mix languages is a wonderful thing.
That Adahome page is quite out of date (Score:1, Informative)
The GNAT (open source) Java bytecode version was in fact released, but then support was subsequently dropped for lack of paying (for support) customers. I have not heard of the Aonix and AdaMagic (both based on AdaMagic) versions being dropped.
As to whether your Ada training would become useful, the full Ada language is not available under the Java Virtual Machine, only the subset of capabilities that are also supported by the JVM itself. So yes, your Ada training would be useful, in understanding the limitations of the JVM environment !
Re:Java is NOT in danger, sun is. (Score:5, Informative)
Huh? I think you'll find that GCC is most certainly licensed exclusively under the GPL. [gnu.org]
I think you need some education on what the GPL requires. The GNU FAQ explicitly covers the question of whether programs compiled with GCC are GPL'd [gnu.org] (they are not).
Re:Languages for the Java VM... (Score:2, Informative)
Re:Java hype (Score:2, Informative)
WTF is that? There was one -- ONLY ONE -- regular expression in the entire Perl script. But of course since the authors will be appealing to people they figure won't understand regular expressions yet, they can win them over by pointing out the ugliness of that one line.
I nearly burnt the book after reading that one (I collect old books, so that expression doesn't come lightly to me). If you Java advocates want to win people over, you should start doing it on the merits of the language, not by bashing others. It just makes you look ignorant.
I can code "enterprise" apps in lots of languages other than Java (and no, they aren't C#, C#, and C#). It comes down to the right tool for the job, and each language has merit. That's why Perl isn't far behind Java, and C is still popular today, so many years later.
Re: Ada (Score:3, Informative)
> I thought about learning Ada for a while. I did the usual net research, but discovered that data types like integer didn't have standardized sizes. So, I didn't bother learning Ada.
That's an odd reason. Did your research tell you that it will give you a default size, but you can coerce any size you want if you have special requirements?
The whole point of the numeric representation business is to allow you to specify your programs so that they will run correctly on any hardware you port them to. But if you don't need that kind of power, you just take the default.
VB source compiled to java byte code (Score:3, Informative)
Halcyon changed it evidently to a middleware which converts ASP to Java. I don't know why they dropped the VB compatible source compiler. I think it would have been a terrific product had they released it since all the VB coders would have been able to code on multiple platforms with no learning curve. It would have been a huge market for them too, so I would love to hear the real story behind their dropping it.
They have since merged with a company called Stryon [stryon.com] if anyone wants to check it out.
Re:Java hype (Score:2, Informative)
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.
Really? Java makes it so easy to know the length of an array that I would think over-running it would be a relatively rare occurrence.
Re:Universities (Score:2, Informative)
Next Year, they're switching the course to java, Apparently all of the AP Computer Science courses are required to do it next year by order of the college board.
I couldn't tell you if it means anything about future java dominance, but it's probably an interesting tidbit nonetheless
Programming for the Java Virtual Machine (Score:5, Informative)
So speaking as a nominal expert, while you certainly can translate non-Java languages into bytecodes, the machine clearly isn't designed to be general-use. It has a lot of object-oriented instructions that fit the Java object model and not a lot else. You can adapt them to your language, or you can ignore them and code everything up as one big method call (except that you'll run out of space, since function size is limited, and you can't modify it once written).
I've successfully adapted languages like Prolog and Lisp, and taken advantage of Java objects to provide the continuation-like features of these languages. I've even found a couple of places where you can generate code which could not come from Java code but which is legal and verifiable (e.g. crossed loops).
I use it mostly for small projects. For example, Ontology Works [ontologyworks.com] generates Java APIs for its custom database description languages. It generates the bytecodes directly, since the APIs are too large to be conveniently compiled from Java. But that's not a general-purpose language, so the code is actually fairly simple.
I've only glanced at CLI, but it appears to be somewhat more general purpose than JVM bytecodes. (In the end it's all Turing tar pit.) However, CLI a bit more heavily oriented towards calling out to native code, which makes the code less portable and harder to optimize. The JVM also supports native methods, but they receive a lot less encouragement.
Mostly, I'm a huge fan of the way JVM does verification. It's brilliant that you can restrict code to safe code and still be Turing complete by eliminating a large class of safe-but-invalid instruction sequences. You can make huge optimizations to verified code that you can't make to generalized code. Verification also allows much more fine-grained authorization than the Microsoft way, which is all based on signed code.
You always want to choose the best language for the job. C/C++/Java are largely identical, and I think in general a group should pick one and stick to it. But there are languages (Lisp, Prolog, Haskell) which are genuinely different, and I consider it a good thing that you can write compilers for them. That has yet to completely fulfill its promise on the JVM platform, where there are proofs of the concept but they are little used.
Kawa: Scheme, XQuery, Emacs Lisp etc to bytecodes (Score:2, Informative)
JVM limitations (Score:2, Informative)
In my line of work I need to deal with binary data structures received over UDP/IP from DSP based systems. A lot of the data structures contain 16 bit signed and unsigned fields (it's a 16 bit DSP, so this is natural). These can be directly represented as records or structures in languages such as Delphi or C++, but a business associate using Java must use all sorts of tricks to access these fields.
From my research on the CLI it seems to have instructions for 8, 16, as well as the common 32 bit accesses into arrays and structures, as well as the support for unsigned data as well as the common signed data.
This may be one of the main reasons that Borland is coming out with Delphi and C++ compilers that produce CLI, whereas they never did so for JVM.
Re:AspectJ (Score:3, Informative)
BTW, when compiling standard Java, the AspectJ compiler produces the same bytecodes that are produced by a standard Java compiler because the same compiler is used.
The first incarnation of the compiler produced Java code that was then compiled by a standard Java compiler. The second produced bytecode directly, and the current version -- I believe -- uses a modified Eclipse compiler.
Re:Java hype (Score:4, Informative)
Well, I am not a java programmer, so I don't know about java, but It seems to me that you are using C arrays in C++. The STL provides several data structures that are indended to replace C arrays. These include vector, and list, both of which dynamically allocate their size and automatically resize if you overflow thier bounds:
int main(){
vector<MyClass> vec_myclass;
MyClass temp;
ifstream fin;
while(!fin)
{
fin >> temp;
vec_myclass.pushback(temp);
}
cout << vec_myclass.size();
return 0;
}
The user doesn't even need to check the size, although that is provided.
Multiple Languages on DotNet not a Good Thing (Score:2, Informative)
enterprise applications (Score:4, Informative)
Enterprise application is a software system that is:
1. Distributed (with all the requisite problems of distributed computing)
2. Secure (authentication, authorization, auditing, and encryption)
3. Scalable (can handle increasing load without a re-write)
4. Heterogeneous
5. Fault tolerant and/or Recoverable
6. As a corollary to (5), usually involves one or more transactional DBMS
Each of these topics by themselves can take years to master.... which is why people tend to hold well-designed "enterprise applications" in high regard.
Re:Languages for the Java VM... (Score:5, Informative)
Rogers Sessions took the time to investigate every single one of the projects on the JVM languages page. He posted his results to the ObjectWatch [objectwatch.com] site. After long research, he found only 8 that were actual implementations of a non-Java programming language for the JVM. Of those 8, in his opinion not one was available or suitable for professional development.
In his conclusion he states "I believe that Simon Phipps and other Sun luminaries have greatly exaggerated the degree of language neutrality supported by the Java platform".
Re:Yes they did... (Score:2, Informative)
I disagree on both points.
If you are writing enterprise applications then with java you have a **substantially** larger set of class libraries to start from, so the amount of code that you personally have to write is a lot less, so I disagree on your first point. Go take a look around the Apache Jakarta project some time. If you can show me python equivalents for a quarter of the projects there, I would be surprised.
On the second point (speed) I can say that according to Bagley's computer shootout, you are objectively wrong. Java uses substantially less CPU than Python to do 25 standard computing tasks. Of the languages Bagley tested, Java placed 9th and python was 13th, although Java scored closer to first place C than it did to Python.
Java's reputation as a "slow" language seems to be based on hot air. Swing is perhaps somewhat slow, but if you really want to write blazing fast GUI's you can always use the Eclipse SWT.
Re: Ada (Score:2, Informative)
C is far worse about unspecified integer ranges than Ada.