“Classpath hit 98% of 1.4 [yesterday], and I think we’ll see another big bump tomorrow since the XMLEncoder patch went in [yesterday]. I think we’re in the 90s against 1.5, though it is hard to say since there hasn’t been a branch merge in quite a while. Of course, japi isn’t the final word on how we’re doing, which is why Mark is going to talk about this at FOSDEM. The coming year looks as though it will be a very good one for gcj and Classpath. I think we’ll finish 1.5.”
Apart from ideology, are there any reasons to use Classpath over SUNs and IBMs offerings? Spped, stability, cross-platform capaqbility etc?
“Apart from ideology, are there any reasons to use Classpath over SUNs and IBMs offerings? Spped, stability, cross-platform capaqbility etc?”
The ideology of open source is a great selling point to foreign governments who want to rely on U.S. corporations as little as possible.
I suspect that as of now, the IBM and especially the Sun offerings are better in all other respects. However, the open source nature of Classpath — once it’s stable — could provide computer scientists a test bed for new bytecode optimizations. Just look at how GCC has improved at the hands of research!
Edited 2006-01-09 13:37
Apart from ideology, are there any reasons to use Classpath over SUNs and IBMs offerings?
It is easy to maintain Classpath/gcj on linux/bsd servers/desktops.
Classpath/gcj can run out of the box on Linux distros
i.e. you can install it during installation process or after installation with yum /apt-get install command
and it can be updated automatically.
while with sun jdk you’ll have to download it each time(installation/update) for each server.
Ideology is not the only point here. The important thing is not depending on your major competitor´s technology. That´s what Redhat is thinking when it supports the development of GCJ and GNU Classpath.
Actually, OpenOffice is also largely controlled by Sun so I don’t think this is an issue. I believe RedHat is more concerned about being able to provide QA support for technology. With OpenOffice, that can release patches even if Sun balks. With Java, they have to wait for Sun and take the flack while the issues are unresolved. Customers don’t care *who* is responsible for the problem, they just want it fixed and they pay for a specific distro to care care of the issues. Open Source basically gives RedHat less headaches.
Interesting thesis but… if Redhat sponsors Classpath in order not to depend on Sun’s technology, then by the same reasoning it should support mono in order not to depend on Microsoft. Instead redhat is hostile to mono. How come?
Edited 2006-01-09 18:06
For me, the major advantage of Classpath, apart from the ideology, is the cross-platform capability. The philosophy of Java is nice – compile once, run anywhere, but really, there is no support from Sun to have Java running on less known architectures. Linux/PPC, for example, is one of them.
98% is great news, but I have one question: Is this 98% API compatibility or 98% functionality compatibility. The difference is important. You can quickly achieve 100% API compatibility by focusing solely on getting the APIs defined and stubbing out all implementations. With functionality compatibility, you have to actually do the API says you’re doing.
98% is great news, but I have one question: Is this 98% API compatibility or 98% functionality compatibility. The difference is important. You can quickly achieve 100% API compatibility by focusing solely on getting the APIs defined and stubbing out all implementations. With functionality compatibility, you have to actually do the API says you’re doing.
I think you just answered your own question. 100% API compatibility isn’t something worth anouncing.
> I think you just answered your own question.
> 100% API compatibility isn’t something worth anouncing.
Actually, I don’t think I have. I couldn’t remember if it was WINE or Classpath, but I do remember that one of these projects does announce use stubbed logged API compatibility as a measure of progress simply because it helps linkages and helps determine what to work on next (e.g. APIs that are rarely called get low priority).
To me, 98% functional compatibility (with a focus on APIs that are actually used) basically means that I can run just about any Java app using classpath and expect it to work flawlessly (because that final 2% is probably API cruft that only one or two apps actually use).
If Classpath has reached that stage, then it’s great news!
I’ve browsed around Classpath site and it’s 98% of functionality.
But you can just look closer at the “Results of comparison between jdk14 and classpath” mentioned in the article: “minor” must mean “it could have been implemented better but it works” and “bad” is “implementations sucks but it works” and only “missing” is really missing functionality.
If you’re not convinced think about it: how could could “bad” or “minor” stub look? ;P
So – it really is good news but I’m already looking forward to Classpath’s implementation of JDK 1.5.0.
I believe Classpath provides method stubs for some of it’s API. That’s my experience when using JTable a while back, where the methods were stubs eventhough it was reported on the Classpath site as working.
Hopefully, that’s changed now and if I’m wrong I’m sure Dalibor Topic will be along shortly to correct me 😛
Since you summonned me …
Indeed, some things still are stubs, and the code has its own share of FIXMEs in places.
The 98% above translates into the total number of symbols (packages, classes, interfaces, methods, fields) implemented, and not into a statement of relative compatiblity to some proprietary implementation. Without running the official compatibility test suite, it would be hard to make an exact claim of relative compatibility, and noone working on GNU Classpath has access to such a test suite yet, afaik.
The only freely available verifiable measures of compatibility with proprietary implementations, like the Mauve test suite, and test suites of free software applications like JOnAS, do indicate that the compatiblity with proprietary implementations is getting better all the time, though, and the experiences from packaging applications and libraries written in the Java programming language are increasingly positive. Regular visitors to http://planet.classpath.org know the success stories already, though.
Ocassionally, development starts out with a stub, and gets fleshed out as the implementation of a class improves, but that’s usually only the case for hot & fresh development areas, like currently some parts of swing are. Free Software development works that way, and I personally prefer to see a class gradually growing better and better in the CVS tree, over classes being dumped finished into the tree.
The GNU Classpath project dearly appreciates patches to improve the implementation. If you are using an API extensively, and find bugs, please do not hesitate to feed the bug tracker, or to submit patches of your own making, but make sure to read the documentation. and of course, there is #classpath on irc.gnu.org for the first hand information.
cheers,
dalibor topic
There are a few stubs, but not very many.
We’ve had a “no new stubs” policy for years.
The API comparison score is reasonably, though
not completely, accurate.
Hopefully this means we are several steps closer to having Java installed with the operating system that just works … for all the BSDs and all the Linuxes and just about anything else ….
It is all very well having byte code that can run anywhwere but if the JVM is not to hand then it just will not get the level of use.
Thats great.
Sun has publically committed itself to releasing its entire software library in time.
So enivitably this means Java, which also a Good Thing(tm).
While Classpath is 98% of 1.4, its run-time performance needs serious profiling work, sadly. In my own tests, the only run-time environment slower than Classpath was the Python VM. I love Python though.
I’m interested to see what happens when Sun open-sources 100% Java 5.
Still congrats to GNU for this work.
I can’t help feeling something nicer would now be available had Ximian/Novell concentrated on a Java VM rather than a .NET Mono VM. Oh well, thats fun and politics, I guess.
>> In my own tests, the only run-time environment slower than Classpath was the Python VM.
Classpath is a class library project and doesn’t actually
run standalone — you have to pair it with a JVM.
The performance you still depends critically on your
JVM choice; some of the Classpath-using JVMs are simple
bytecode interpreters and are thus quite slow. Others
are sophisticated JITs and are much faster.
Unfortunately, Sun has currently no plans to release any version of their virtual machine or core class libraries under an open source license, to my best knowledge. While it is indeed correct (and great, in my opinion) that Sun Microsystem is committed to making all of their software available gratis or under open source licenses, all public comments by Sun’s management have made clear that Sun’s implementation of the J2SE specifications falls into the gratis part of that, and not at all into the open source one.
As for Sun relicensing their implementation on Java 1.5, that’s very unlikely for a few reasons:
a) Marketing. In 2006, Sun Microsystems will be interested in migrating their customers to the next release of their implementation. Opening up an older version would take away momentum from that.
b) Support. Sun could not just open up their former crown jewels and let them bitrot in public without earning some bad press. I’ve watched people struggle majorly on Mustang forums to build Sun’s 1.6 betas at all, and I doubt Sun could just push out the source they have for 1.5 with anyone outside Sun being able to build it without massively cleaning it up. But otoh, supporting people building and hacking on an old release would take away momentum from the new release, and simply cost money for the support engineers that Sun would probably rather invest into supporting their 1.6 release.
c) Nowhere to go with patches. It’s unlikely that Sun would want or be able to accept community patches for an old release, due to the way the Java trademark is tied with compatiblity requirements. Making any release based on community patches would either require extensive compatibility testing, or, if Sun deliberately released untested, possibly incompatible implementations, dillute the Java brand’s positive connotations. The real, licensing-cash-worthy value for Sun is in the brand, not in a particular implementation they give away gratis.
d) Legal. Sun’s implementation contains more than three million lines of source code, according to Slava Pestov’s blog. Just like with Open Solaris, Sun would have to undergo a lengthy, costly process of securing relicensing rights/copyrights to each line of code it does not hold copyrights or relicensing rights to. That takes time, as one can see with OpenSolaris: work on opening all of Solaris up started a few years ago, and is not finished yet, afaik. It would be pointless for Sun to say they’d open up anything but their Java implementation, and then spend their resources doing it the other way round, wasting the positive PR effect.
e) Community. Sun would first try to build up a community around the code base, before they push it out in the open. Since there is no pilot program for Sun’s implementation, there is nothing in the works of that sort. Note that the Mustang ‘JRL community’ is explicitely designed to not be an ‘open source’ community, but to encourage collaboration with VM researchers and small bug fixes on Sun’s proprietary code base. There is nothing on the Mustang forums from Sun’s employees that indicates that Sun Microsystems would have an interest in transforming the Mustang code base into an open source offering in the near future, and there have been no such remarks from anyone who’d know in public, for all I know. They would contradict the official statements from Schwartz, McNealy, Gosling, Hamilton and others, anyway, and last time someone said something like that in public, his superiors were quick to rectify the mistake. On the other hand, I know that a lot of great people inside Sun would welcome being able to work with an open source community on J2SE as well, just like developers outside Sun, but I assume that Sun’s management would prefer to proceed gradually and see how the JINI, OpenSolaris, GlassFish and JES transitions work out before they tackle the big one.
f) No real need for Sun. Sun’s implementation gets 20 million downloads per month, according to a statement from Schwartz at the Sun/Google press conference last October. It’s hard to see for Sun how relicensing their implementation would buy them more ‘volume’, as the maker of the dominant desktop software platform, Microsoft, is not going to ship Sun’s implementation, no matter what the license is. They’ve got their own offering in the managed runtime space to promote with their upcoming operating system release, Vista.
For other popular software platforms, Sun either provide a compatible implementation themselves, or have a contract with someone with a financial interest in a seing compatible Java implementation on their platform, like Apple or IBM. If Sun opened up their implementation, and started to include ports to platforms where their licensees have financial interests of their own, they could cut into that licensing income.
Sun’s a business, and they usually act like one. Currently, all the indicators unfortunately speak against Sun having a business interest in opening up their J2SE code base.
cheers,
dalibor topic
This opens up a lot of opportunities. First it will be possible to have a JVM on any platform. This will make Java’s use more popular. It really will have the capability of “write once, run anywhere”. Secondly it will give Linux distros (and any other system for that matter) a complete java package to include in their distribution. Once this happens the pace of development and bug fixing will increase rapidly. If 1.5 is really completed this year it is possilbe that in 2007 GNU Classpath will be the best option for Java.
Compile apps into native code?, I mean not using bytecode.
This is been one of my dreams for long, being able to compile Java apps into some sort of executable + runtime easily redistributable.
Compile apps into native code?, I mean not using bytecode.
This is been one of my dreams for long, being able to compile Java apps into some sort of executable + runtime easily redistributable.
Yes
One of the problem areas for the Sun JVM is that the license is not transferable, which keeps it out of most BSD and Linux packaging systems. No inclusion in the standard distribution, no automatic updates. You have to get it directly from Sun, and manually check for updates.
In spite of the extra work, I use the Sun JRE. But I see that I am once more a revision behind, because I don’t get automatic updates like I do for *everything else* on my systems.
Sun always claims that the license is needed to ensure portability and standards compliance. I’ve never understood how making it harder to install and keep up to date aids portability and compliance.
As others have mentioned, Sun supports a fairly limited number of platforms. They target popular platforms that can cover the cost of support, which is understandable as a business decision. But it would be nice to have Java on every platform supported by Linux and NetBSD. I congratulate the Classpath and gjc projects in bringing us closer to that goal.
as 1.5 compliance is brought into line, the classpath guys should be able to take a breather – parameterized types should mean fewer apis to chase. in any case, great work, this project has been a great success.
Where is the mention of what it does ?
Where is the simple explanation ?
How come I can find answers only on messageboards on what its use is ?
In a C++ conversation, Classpath would be the standard library.
Classpath.Is.All.Those.Dotted.Classes.That.Do.Swell.Stuff
98% sounds pretty good, but it means that if your program uses even one function call from an unsupported API, then it won’t work with classpath.
I’m assuming that the unsupported stuff is not commonly used. So lets say for example that 2% is used in 0.02% of lines. (that means it’s 100X less common than you would guess based on the proportion of the API)
1/0.0002 = 5000
So a program of 5000 lines is likely to have 1 of these missing API calls.
My numbers are made up and there are a lot of details missing, but my point is that anything less than 100% compatibility is pretty useless unless the software was written with classpath in mind.
> I’m assuming that the unsupported stuff is not
> commonly used. So lets say for example that 2% is used
> in 0.02% of lines.
Actually, the numbers wouldn’t work out that way. A typical english dictionary has 65000 of the most common words. There are far more words in the english dictionary, so that chances are, a typical 1,000,000 word novel will not use a single word that is not in the dictionary, and ever if it does, the chances of that word being crucial to the story are realively small.
Yeah, that is a funny analysis but not borne out
in experience. For instance, we run Eclipse fairly
well, and it is more than 1 million LOC. We also
run Jonas, which is similarly large.
But, yes, missing APIs does translate to some programs
not working. That is why we’re working to complete
Classpath instead of stopping here :-).
My numbers are made up and there are a lot of details missing, but my point is that anything less than 100% compatibility is pretty useless unless the software was written with classpath in mind.
Bingo, that is the point of Classpath. Use Classpath to develop your apps and you can run your programs on both Classpath and Sun Java. Use Sun Java to develop your apps and chances are you can’t run on Classpath.
It is what the Classpath project recommends, to use Classpath so you don’t tie your apps exclusively to Sun’s Java and the limited platforms they support.
Compared with Sun JVM, OpenSource VM: Gij, Kaffe, SableVM, are painfully slowly.
Important OSS projects prefer Sun JVM instead of open source variants: Apache Tomcat, JBoss, Jedit, Eclipse.
Depends on what you benchmark, where you do it, etc.
In general, gcj compiled, optimized code (i.e. as native binaries) is almost always faster than Sun’s client 1.5.0 JVM, according to independant benchmarks on shudo.net.
Sun’s server 1.5.0 VM does some pretty neat, expensive optimisations, that will take a little longer to beat. gcj 4.x has some nice potential in that area though.
cheers,
dalibor topic