Sun Lowers Barriers to Open-Source Java

Shyane writes "Sun Microsystems is making it easier for open-source programmers to ensure their Java versions meet the company's compatibility requirements, but the deal extends only to those involved in Sun's own open-source Java project. The program grants access to its Java Technology Compatibility Kit to anyone with an open-source Java project that is based substantially on Sun's open-source Java software and governed by the GPL. Programmers need access to the test kit to prove that a project is in compliance with the Java specification. Projects that pass Sun's compatibility kit tests also can use the official Java logos for free."

Comments

Re:Java == Nice Toy

[Marcus Green]

Go to your job web site of choice and key in the names of your favorite programming language. Notice that there are a huge number of jobs for Java skills (usually more than any other language but always a very close run match). Then ask yourself, if it is such a toy why are so many people prepared to pay good money to advertise for these skills?

Re:Openness!

[LWATCDR]

Yes it really has. I have run the same Java application on Windows, Linux, and Mac OS/X. If there is a good JVM you have a very good shot at your java application working.
Yes you have to have a JVM but that is sort of a given.

Java Programmers == Typists

[Anonymous Coward]

Java programms are nothing more than typists who can understand how to string together bits of code from the latest
'Type and Learn' Java Book.

To Me, a Programming Language is 'Real' When it can fully bootstrap itself. That is, Compile it's own Compiler. Java of Course, being an interpreted language, fails that test miserably. I've once seen a student project, a java interpreter, written in Java. I've seen frozen molasses move at a faster pace.

Java is nice if you don't want to worry about complexity, or managing algorithms, etc. I think of it like VB, nice for building proof of concepts, fast 'throw-away' prototypes.

Re:Java Programmers == Typists

[AKAImBatman]

You fail it.

That is, Compile it's own Compiler.

Failure #1: Java's compiler is written in Java. The first use of the early Oak/Java VM was to get the compiler self-compiling.

To Me, a Programming Language is 'Real' When it can fully bootstrap itself.

Failure #2: Java *can* bootstrap itself just fine, thank you very much.

http://www.jnode.org/
http://jikesrvm.org/

"A distinguishing characteristic of Jikes RVM is that it is implemented in the Java(TM) programming language and is self-hosted i.e., its Java code runs on itself without requiring a second virtual machine."

being an interpreted language, fails that test miserably.

Failure #3: You called Java an interpreted language. Java is a compiled language that runs on a virtual machine. Like most VM-based platforms, that provides two options. The first is to interpret the bytecodes directly. The second is to compile the bytecodes into native code at runtime using a Just In Time Compiler. The most common JIT compiler for Java is the HotSpot VM. HotSpot is quite capable of keeping pace with and even exceeding the performance of native code.

http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html

I've once seen a student project, a java interpreter, written in Java.

Failure #4: You see these things, yet you fail to take the time to understand them. You have failed as a geek. Turn in your member card immediately and leave in shame.

Re:Java Programmers == Typists

[AKAImBatman]

And how do you propose to run them and their JIT compiler without another VM?

How you think Linus wrote the first version Linux? By flipping switches on the front of his Honeywell? Of course not, fool! He used Minix as a host platform to compile the first versions. You always need a host platform to bootstrap the first copy before it can become self-hosting.

Modern interpreters compile the language and then run the bytecode. Early interpreters work the way you describe because memory was at a premium.

These words come out of your mouth, but you obviously don't understand what they mean. Early interpreters started the concept of "compiling down" interpreted code because memory was at a premium. It's not a Virtual Machine, it's a symbolic language that makes it easier to execute the code.

Hell, I have a Commodore 64 sitting at home that keeps all its programs in a symbolic form to preserve its mere 64K of memory. I know you have no idea what a Commodore 64 is (I'm pegging you at somewhere around 12-14) but programmers often wondered why their programs were being reformatted by the machine. As it so happens, it wasn't reformatting them. It was translating the programs to symbolic codes, then translating them back when the user asked for a program listing.

See Parrot, the VM for Perl

Parrot is a VM. Period. Languages like Perl can be compiled for it if desired. Jython also exists to target Python execution in the JVM environment. The existence of these tools does not make the languages any less of interpreted language. It merely provides a specific implementation which is compiled. Just as many companies used to offer BASIC compilers, even though BASIC was technically an interpreted language.

Tamarin, Mozilla's JavaScript VM.

Taramin is the latest version of the Virtual Machine designed for the Flash platform. The Actionscript language was evolved toward ECMAScript compliance, thus making it an excellent platform for JITing Javascript code.

Again, you fail it. Go back to high school, graduate, work your way through a college education in CS, then come back when you know what you're talking about.

Re:Java Programmers == Typists

[AKAImBatman]

You mean like what Perl uses? :-/

Perl has always had a compiler: your source is compiled into an internal form (a parse tree) which is then optimized before being run.

From my understanding of the engine, SpiderMonkey works along similar lines, using a combination of byte codes and parser information to perform execution. This is a bit different approach from the Flash VM, which pre-compiles the source into a representation executable by its "Actions" VM.

The difference between interpreted languages and compiled languages these days is largely academic.

I will agree with this. True interpreters are a rare find these days. Interpreting bytecodes is becoming a common method, and even JITs are showing up in a lot of interpreted languages. That being said, the one distinction is that interpreted languages rarely give up their interpreters. If you give them a dynamic piece of source code, they will execute it whether it does a strict interpretation of the source or a full compile to its internal VM.

In comparison, Java is a strictly compiled language designed for the Java VM platform. Furthermore, it is JITed at runtime and is no longer interpreted as most VMs designed for "interpreted languages" do.

Hell, even Java has JSPs, which use Java like a scripting language.

Scripting is not the same thing as interpreted. JSPs are compiled before execution. The file is turned inside out by the parser (all that HTML becomes output.write("") statements) then compiled by JavaC, loaded by the ClassLoader, and finally executed by the HotSpot VM. It's an involved process, but it's much faster than the traditional interpreted approach of PHP and pre-.NET ASP.

You failed programming, didn't you?

[Dancindan84]

Java is a nice toy programming language, for those people who can't afford a 'real' compiler, Like Borland, or Even Microsoft. Hell, even GCC does a better job than most java interpreters. That's just golden.

Re:don't need this

[Anonymous Coward]

Bullshit. Unit tests can at most prove that a single piece of software "works" in an internally consistent fashion. They might be marginally sufficient when you're building a single-platform doghouse-sized app. They're a very small part and hardly sufficient part of the process of building a skyscraper, though, and can't verify that an app will work in any specified environment.

This Sun tool seems to validate your implementation against some standard.

By validating your code against some reference standard where that standard is defined as meaning cross-platform safe, your code is cross-platform safe.

That's a huge part of "write once, run anywhere". Denigrating that validation with some pap about small unit tests is asinine.