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).
can be found here.
It doesn't mention SmartEiffel, though, which does generate byte codes. There are probably many others as well.
Apple's Cocoa framework, based on Objective-C, has all been exposed to Java.
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.
Anyone know of any projects to compile JVM bytecode from other languages?
...
Jython
# 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.
I agree completely with your comments on the future of Java as a server side solution. JSP, servlets, and J2EE are all fantastic.
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.
---
"An eye for an eye leaves the whole world blind" - Gandhi
The page you list shows a hundred or so that run on the JVM. A similar page for .NET shows only 27.
Not what the marketing folks at Microsoft would have you believe, huh?
---- There is a fine line between sayings that make sense.
The picoJava home page
Sun's annoucement almost 6 years ago that they and Rockwell Collins would be making picoJava chips
Huh? I think you'll find that GCC is most certainly licensed exclusively under the GPL.
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 (they are not).
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 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.
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.
...interesting if true.