Slashdot Mirror
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."
as programmers discover that the test suite only runs on Windows.
Cheers!
Atheist: Buddhist in a Prius
Finally, "open, cross-platform" Java is beginning to become open. Now I just hope it becomes more cross platform, rather than "Windows, Mac, x86 Linux and whatever-you-spend-a-million-hours-developing-an-i mplementation-for."
:(
Seriously, I was pissed when I found out just how bad Java support is for Linux PPC. I couldn't get an iMac to go to Yahoo! games for my grandma.
Now all we need is cross-platform Flash.
Sun's test suite isn't just to verify your code works, it's to verify your implementation of Java complies with the standards before they allow you to slap the Java logo on it. It's a good way to keep things open while still maintaining control over the Java standard, and preventing fragmentation of the language.
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?
Fortunately the GNU Classpath guys are right on board with OpenJDK. One of their most prominent members Dalibor Topic (who's the lead on the Kaffe VM) is on the OpenJDK governence board and works with Sun and other representivies on managing the project. Other promiment members like Roman Kennke, David Gilbert, Mario Torre and others. are active on the OpenJDK mailing lists and submitting patches. They are all interested in becoming regular contributors to the project.
Other GNU Classpath developers working for Red Hat were very quick to produce a version of OpenJDK using pieces of Classpath to fill the wholes of "encumbered" components that havent been open sourced (like the font, graphics and sound engines that were licensed by Sun by 3rd parties). This is called IceTea. Though its more of a quick 'n dirty temporary project to have a completely GPL JDK right now until the holes can be plugged properly. For example, Sun released a more sophistated FreeType based font engine this week, and the rest of the holes will eventually be filled. But for now, IceTea is a great playground for experimentation. And as far as I can tell, Red Hat wants to contribute anything useful back in OpenJDK.
You might that the GNU Classpath guys would be dissapointed, feeling that their hard work is obsolete, but no, they're happy because they know they were a big part of the reason why OpenJDK exists, and they're looking forward to contributing.
Translation: No Microsoft MSJava++ with Sun's Java logo on it.
"Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
I am a fledgling java developer, and so far I'm loving it! Every time I hear about the advances Sun is making towards GPLing java, the more I feel justified in taking the time to learn java.
I came into this business from a bit of a back door (although I suspect it to be a common back door these days). I started with spaghetti code PHP, moved to OOP php with php4, then php5. I am now quite frustrated by the partial OOP implementation of php5, as I develop more complex applications. I become even more frustrated with PHP the more I learn about java. The type safety at compile time makes it far easier to develop bug-free code. Method overloading is problematic in php, I usually end up implementing a single function with all sorts of optional arguments, and checks to determine whether a particular parameter is an array.
Additionally, Java gives me code re-use at it's ultimate. For instance, I write a single been that updates our LDAP; I then use that bean in a JSF web application, in a batch program running on an an IBM iSeries, in a command line application on Linux, and most recently in a Swing application. Having written the bean once when developing the first application, I never had to write a single LDAP query when developing my latter applications. Any bugs I find in the bean from one of the apps means the bug gets fixed for all the other apps.
Not to mention that I do my development on my Mac, and deploy software across our organization to Windows and Linux desktops.
Write once run anywhere for sure - I'm sold!
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.
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.
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."
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/javaCbenchma
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.
Javascript + Nintendo DSi = DSiCade
Yeah, I had a problem with that too. Because they added proprietary extensions that breached the specification (including Windows specific features), as well as omitting required features. Code written for the Microsoft VM wouldnt run on anyone elses. An implementation must be certified as compliant in order to use the Java brand. Microsoft's wasnt, so Sun sued. They won, and rightfully so.
But I'm glad this happened. It caused Microsoft to go off and create rival platform (.NET) and a rival language (C#). Maybe not so great for Sun, but great for the developer community, because it created good solid competition and both platforms are advancing at a rapid pace because of this.
Actually hotspot compiles code after it has been interpreted for a while and it has noticed that it is a "hotspot" in the code (sort of there in the name really). The slow start up is because
a) it loads and validates a fuck load of classes at startup (although the preverified core classes can be cached)
b) it starts running in interpreted mode.
matfud
Simple. It's a stub. Typing "java -cp tools.jar com.sun.tools.javac.Main" all the time isn't very convenient, so Sun provides executables that load the JVM and execute the compiler. If you look in your JDK installation directory, you can find the tools.jar file in the "lib" subdirectory. You can try running it from that directory as above, or look inside the zip file for the mindblowing (eye roll) Java class files for the compiler.
Perfect example of someone who didn't read or take the time to understand. The Jalapeno VM and JNode OS are both written in pure Java. They used their own JIT compiler to compile themselves into native code. That native code is a Java program that runs on the native platform.
Python is not compiled. Perl is not compiled. Javascript is not compiled. These languages are read in, line by line, and executed. You fail it.
This is CS101 stuff we're talking about here. How badly can you fail it?
Javascript + Nintendo DSi = DSiCade
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.
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.
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.
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.
Javascript + Nintendo DSi = DSiCade
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.
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.
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.
Javascript + Nintendo DSi = DSiCade