Domain: sablevm.org
Stories and comments across the archive that link to sablevm.org.
Comments · 12
-
Re:Java vs. Mono now
Well, no matter what Sun will do, we are wery close to a free software Java implementation anyway. There are free JVMs and compilers. All that is missing is the class libary, but the gerics branch of GNU Classpath are at 95.13% on JAPI tests. After all Sun did keep their word about opening Solaris and they are talking to the developers behind the free Java implementations, so I think we can trust them.
-
Java is already fragmented
Java is already fragmented. The result of open sourcing Java will actually be consolidation, i.e. killing of competing VMs. And a huge open source test suite will greatly benefit all surviving JVMs, which is a good thing.
How can you not see this?
Javas problem is not that it might get fragmented, the problem is that it IS fragmented. Do something about it! Let Java free! -
Re:Scripting language talk...(logged in and reposted)
Taking that into consideration, then, would Java with JIT qualify as an interpreted or compiled language? I'm not sure, myself---any thoughts?
That question is non-sense. You confuse programming languages with compiler implementation techniques.
A language is a syntax (how do I write it?) and a semantic (what does it do when I run it?). Languages never say anything about you are supposed to implement it, and so asking if a language is interpreted or compiled is just non-sense.
There are many implementations of the Java language, with many different execution strategies.
- Sun's implementation of Java is a Just-In-Time compiler (JIT).
-
SableVM is also an implementation of the Java language. It's execution strategy is to interpret the bytecode.
-
GCJ is another implementation of the Java language. It's execution strategy is to compile ahead of time.
-
DrJava is yet another implementation of the Java language. It's execution strategy is to compile the Java source code to Scheme code, then macro-expand the Scheme code to primitive Scheme, then compile that to bytecode, then interpret the bytecode.
Other languages also have a diversity of implementations:
-
The Ocaml language comes standard with three implementation: an interpreter, a bytecode compiler/bytecode interpreter pair, and an aggresively optimizing native code compiler. Somebody else also implemented a JIT.
-
The standard Python implementation is an interpreter. Starkiller is a Python compiler, and Psyco is a Python JIT.
- Last but not least, GCC is a C compiler (of course), and Cint is a C interpreter.
Now go in peace, and never say "compiled language" again.
- Sun's implementation of Java is a Just-In-Time compiler (JIT).
-
Re:Scripting language talk...Taking that into consideration, then, would Java with JIT qualify as an interpreted or compiled language? I'm not sure, myself---any thoughts?
That question is non-sense. You confuse programming languages with compiler implementation techniques.
A language is a syntax (how do I write it?) and a semantic (what does it do when I run it?). Languages never say anything about you are supposed to implement it, and so asking if a language is interpreted or compiled is just non-sense.
There are many implementations of the Java language, with many different execution strategies.
- Sun's implementation of Java is a Just-In-Time compiler (JIT).
- SableVM is also an implementation of the Java language. It's execution strategy is to interpret the bytecode.
- GCJ is another implementation of the Java language. It's execution strategy is to compile ahead of time.
- DrJava is yet another implementation of the Java language. It's execution strategy is to compile the Java source code to Scheme code, then macro-expand the Scheme code to primitive Scheme, then compile that to bytecode, then interpret the bytecode.
- The Ocaml language comes standard with three implementation: an interpreter, a bytecode compiler/bytecode interpreter pair, and an aggresively optimizing native code compiler. Somebody else also implemented a JIT.
- The standard Python implementation is an interpreter. Starkiller is a Python compiler, and Psyco is a Python JIT.
- Last but not least, GCC is a C compiler (of course), and Cint is a C interpreter.
Now go in peace, and never say "compiled language" again.
-
Re:Java isn't free and Sun isn't a friend to OSS
-
Re:The commision is right
No matter how good Gnome and KDE have gotten, if the
.net and JAVA software is lacking (Mono is not nearly complete, and is exactly fighting this catch-up game, JAVA is a nifty SUN Trap)
Between gcj, Kaffe, JamVM, SableVM, all driven by the GNU Classpath library, experimental stuff like Jnode, and the massive wealth of Java code in projects like Eclipse and those driven by the Apache Foundation..
I'd say that Free java is alive and kicking. Yeah, it still hasn't become usable with respect to AWT/Swing. But most of the core is there, even up to some 1.4 stuff. (and work on 1.5 features is underway)
I don't buy the "catch-up game" argument. Most people don't write programs for the absolute latest and greatest. Platforms tend to reach a certain level of maturity which is 'good enough' for most people, and then it slows down. I think that soon enough, the free Java implementations will be able to compete with Sun's.
For example, how many compilers can you name which fully implement the C99 standard?
Everything is a catch-up game... it's just a question of what the game looks like. MS can arbitrarily change things in the Word file format just to screw with people. APIs don't work that way though, you don't change an API unless you have to.
-
Re:Testing the waters?
Open source won't use Java until Java is open source. Most OSS developers are wary of traps like that.
(Which caused reluctance to using Qt, which sparked the Gnome project. Now Qt is free, of course.)
Java is certainly going open source. Not Sun's java, but there are plenty of open-source VM:s, and compilers, and a full implementation of the class library in the works.
I predict that, when these projects reach sufficient maturity (AWT/Swing support being the achilles heel in all the above), we will see widespread adoption of Java in the OSS community.
What Sun does will have little impact on the OSS community unless they get serious about open source and put Java under a tolerable license.
(If someone's curious about what is bad about the Sun license, see Dalibor Topic's post here, containing a point-by-point comparison to the Open-source definition.)
-
"Java" doesn't play nice?
GNU Classpath
GCJ/GIJ
Kaffe VM
Jikes Java compiler
SableVM
Java-GTK
Documents about how to compile and use QTJava and KDEJava
What else do we need? How does all this not play well with Free software? We've got the tools, why not use them? -
Re:Because I like PHP was: Um...
neither Java nor Flash are Open Source and as such I don't care to learn them unless I specifically get paid for it.
Sounds like you need to check out OpenSWF, Kaffe, SableVM, GNU Classpath, GCJ, etc etc. -
Re: GoodFirst Rick and Roll (672077) wrote: we believe that open sourcing Java is the only way for Sun to fulfill their promise of Write (and compile) Once Run Anywhere.
Then gidds (56397) responded: Wy do you believe this? I see no reason to, and many reasons not to.
At present, Java's platform-neutrality is pretty good; better than almost anything else. Not just the handful of mainstream desktop OSs, but all sorts of other niche platforms, from phones to mainframes. And it's not just that something runs, but that the platforms are similar enough that software can run on them all. Unchanged.
Simply put, FOSS supporters believe this because it's already been done at least twice. If you have a Java application that uses the J2SE APIs (and none of the "sun.com" APIs), then chances are really medium-to-high that both Kaffe and SableVM can run your app. If they can't, it's because FOSS developers are still working on implementing the entirety of Sun's API set (a moving target) in a cleanroom setting.
Give FOSS developers enough time, and they'll complete their *own* Open Source implementation of the Java standards. They won't be able to use the trademark "Java", but they'll be WORA-compatable (except for bugs in Sun's implementation). They're asking Sun to open up Java just so they can speed the development, gain access to the trademark, and stay current with the lastest API releases.
The irony is that Sun's biggest stated worry about opening the source is breaking WORA through forks.
The truth is that FOSS developers are actively working on a fork because Sun won't open the source, and WORA remains an elusive goal that is never achieved because Sun keeps shifting the API target, and Sun's implementations of the APIs are all buggy. If Sun were to stabalize their APIs and open their source (and only allow use of the "Java" trademark to apps that pass their open source compatability toolkit), then the distributed power of FOSS could kick in, wipe out the bugs, and provide true WORA.
-
Huh? There's a proprietary Java?
-
Re:How can we fracture it?
you do not distribute additional software intended to supersede any component(s) of the Redistributables
As long as Sun's Java is non-free, Debian and other distributions need the right to distribute replacements for the compiler, class libraries, and Java Virtual Machine.