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.
What is happening to the FSF's java project now?
Regards, Martin IT: http://methodsupport.com Personal: http://thereisnoend.org
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?
I so want a native Java compiler. I like Java but the loading of the runtime is a bit of a pain. The option of compiling a native version would be very nice.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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
Forget Linux, Java works much better on Windows than on Solaris.
I found Java on Solaris to be rather buggy.
Java is no longer "interpretted". see Just In Time compilation (JIT). Development time is much faster than Java (and also C#) than with C++ due to the faster time to run. Have you ever built a 500,000 line C or C++ program from source? May as well go out to lunch. With java or C# that can be done in a fraction of the time. Want to talk about "Garbage collection"? It has an added benefit of defragmenting your memory which leads to fewer CPU cache misses. There is no reason that a compiler for java could not be written in Java. Did you know that your x86 "machine code" is actually interpreted? see "microcode" and "complex instruction set". Ever write assembly/c/c++ program to write compile and run its own code? see dynamic class loading
Wish I could mod the parent post up...
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
How dare you present a link that makes the OP look like a tool!
Website Hosting
Sun can still do better ... and easily.
[...]
I'm not expecting Sun to necessarily release its own implementations in source code. However, any test kits for compatibility need to at least be made available to any and all open source developers. For Java compilers, clearly that much of it must have source code available. For run time engines, the test kit can be class files (compiled on Sun's official Java compiler, perhaps). Sun could perform the official certifications test runs themselves to validate the tests pass with official unmodified tests, or grant that to an outside entity with whom they have an agreement to do such tests.
now we need to go OSS in diesel cars
HotSpot on the server VM is not particularly "Just In Time" -- it compiles ahead of time. What's truly annoying though is that it doesn't cache the compiled at all, which partly accounts for its glacial startup time. Java runs circles around other bytecode-interpreted languages like perl and python, but the startup time is still tied as the #1 deal-breaker alongside the larged fixed heap that makes everything in Java look like bloatware even if it isn't.
Done with slashdot, done with nerds, getting a life.
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
Stop Computers/Cars Analogies on S
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
the issue is of letting Sun decide what is compatible or not. Let an outside body working from the published standards do that. And this Sun package is a set of unit tests. And as for cross-platform, of course well designed unit tests can check that.
"Suck it, IBM"
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
> Actually hotspot compiles code after it has been interpreted for a while and it has noticed that it is a "hotspot" in the code
I stand corrected -- my confusion came from looking at a possible set of configuration defaults for the server VM where it can effectively compile everything ahead of time by dialing down all the profile thresholds way down. These probably aren't particularly sane defaults either. It looks like the main difference is that the server VM performs more aggressive optimizations.
Still, wouldn't it be nice if it cached? I understand That Other VM does it (and also has much nicer versioning).
Done with slashdot, done with nerds, getting a life.
Wow, you must have seen some low quality programmers, then.
No managing algorithms? Huh? In what way do you not have to manage algorithms?
Better not tell the MoD (Ministry of Defence, UK Government) since they have Java as one of their approved languages. Yes, C and C++ are also approved, but AFAIK C# hasn't been yet (and hopefully neither has VB!)
Yes, you can write fast prototypes in Java, but that's just one of the things made easier by Third Gen/high level languages and object orientation.
I wouldn't even want to use VB for a prototype, though. Far too ugly and Windows-based a language for that
Idiot remarks about Java are actually rare these days. Most understand the power of Java these days, but some like yourself stay in the dark ages for unknown reasons. Practically everything you've just barfed up is incorrect. No need for me to elaborate, you've got your @ss kicked by all the other responses already.
JAVA IS GPL now.
Tell you what write me an IDE suing ANSI C or ISO C++ that is portable. Do it without using any libraries that are not part of the standard... Then you can get back to me.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Native (.so) libraries are loaded using mmap. The means that even though every program links to libc, there's only one copy of it in memory. It also means that a new process that gets to run doesn't have to reload libc from disk.
Since java has to decompress/JIT it's libraries each time a program runs, each process will have its own copy of all the libraries. Making better use of the shared memory facilities provided by the OS is one possible benefit of compiling java to native code.
YHBT YHL HAND
The
The server options do perform far more agressive optimizations under the assumption the the code will run for far longer then normal client apps (it can afford the extra overhead of the optimizations as they are offset over a longer period of time). It is a bit wierd watching your server get faster over time and often not particularly desirable for servers (you often want them pretty fast from the get go) so you have the option of increased startup cost and its corresponding increased performance from startup.
There has been talk about caching the compiled code but I don't think it has happened yet. One of the complications is that Java has the ability to dynamically load new code at runtime. This means that hotspot has to be able to back-out any optimisations it has made if newly loaded classes make them incorrect.
Java also has pretty good version handling of packages however it is often not used correctly. OSGi can help with this and provide many other benifits.
matfud
Great idea, because if it's portable we can make it start suing the *IAAs! That'll teach 'em.
Programmers in mirror are brighter than they appear
Anonymous Coward I suggest to just let it drop.
Parent explained it to you in so many ways. Confusing an interpreter with compiled code is embarrasing to watch.
I hope you are not in a position of authority where decisions are made and people would have to pay for your mistakes.
Embedded C/C++ also hide many of the details. Why arn't you writing in assembly?
i ndex.jsp
e ssor&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB: official&client=firefox-a
Joking aside, Java is making inroads into embedded realtime systems.
http://java.sun.com/javase/technologies/realtime/
Thats not counting the processors available that have java bytecode as thier native instruction set.
http://www.google.co.uk/search?q=native+java+proc
matfud
Yes, you are probably right its the rest of the world that is out of step, not you.
Based on this non marketroid page, it seems that apple's jvm compiles the java standard library at install time. Then it can just mmap the library at execution. It also seems to mark all memory in this file as uncollectable. It would be nice to do this for other java libraries as well, but then you may start to wonder why, exactly, you were using JIT in the first place.
New and innovative? Hardly. Shared libraries were implemented by Multics in the 1960's. Apple's just doing what everybody else (except, I guess, some folks at Sun) realized was a good idea years ago. As for making some objects uncollectable, Lisp was doing that and many other very cool things, long before java.
"Ever see how many VB jobs there used to be"
I suggested going to a job advert site and doing a little research. If you do that you will find there is no "used to be" about the availability of VB jobs. Try making informed comments.
Congratulations on an informative and interesting series of comments and elucidations. I'd read about most of what you covered in this weird "flamewar" previously, but hadn't seen everything tied together quite so well in the past. Remember the old saying that goes somewhat like: "Don't argue with a fool because a stranger might come upon you and fail to know who is who" Though in this case, I don't think you're in trouble of being taken for a troll. :P
Gravity Sucks
Machine code also is just a special byte code which happens to be interpreted by the CPU hardware (or even by microcode running inside the CPU).
If someone built a CPU which processes Java bytecode natively, would that suddenly turn Java from an interpreted into a compiled language?
The Tao of math: The numbers you can count are not the real numbers.
However, the creation of such a CPU would only demolish the "interpreted" mark against Java. The language itself would still suffer from a lack of power and expressiveness, relative to the language it is a dumbed-down version of.
Attention zealots and haters: 00100 00100
Java could have been everything on Linux. Total domination, but licensing being the issue, lots of Java-friendly projects found happy homes among the ranks of Python, Mono, Ruby, Perl, what-have-you. Java is here to stay, but it's not an essential part of GNU, Windows, Mac OS, or anything like that. That means it may not actually live forever. It might get crowded out by better tools. Maybe.
They switched to the eclipse front end. Still use GCC back-end for native code compilation.
I started with PHP too a long time ago. I've tried Perl, Python and Java. I'm a (very satisfied) Ruby programmer right now since it has a good balance of nice features taken from other languages, in my humble opinion. Learning Ruby has motivated me to know more about programming languages and now I'm looking to try SmallTalk, LISP and Haskell.
If you like Java's object orientation, you'll love Ruby's real object orientation. OOP as it was intended[1]. It's like Java done right, and without the verbosity.
The reality is not that categorical. Static versus dynamic typing benefits is debatable[2]. Incidentally, Java seems not to be type-safe [3]
You realize that code reusability and portability is not Java's exclusive, right?
Yes, you do, of course.
Don't stop at Java. Keep trying other languages. You'll be surprised.
My humble suggestion: Ruby.
[1] Dan Ingalls: Object-Oriented Programming - Google Video
[2] Static and dynamic type checking in practice
[3] Java is not type-safe
The best way to predict the future is to invent it
You mean what C and C++ were like 15 years ago?
Perhaps you need a dictionary because that's not the definition the rest of the world seems to use.
If your job is managing algorithms that's nice. Many of us get paid to deliver software, not dork around with sorting, searching, and memory pools.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.