You made the assertion that Sun Specific APIs do not exist, saying 'all I can say is, "They're in the fine manual."', I've shown that you are wrong: unspecified (com.)sun.* packages exist and they were unfortunately used in `1.0.x sources. Instead of raising a stink, people talked about it on the mailing list, filed bug reports, and things got fixed for 2.0.x. That's a good thing, and shows that developers are able to work together quite well.
In my opinion, to go with the comic theme from your handle, you're painting Sun as some rather loaded, Hulk like character, that's every moment about to explode and go on a rampage in too tight shorts in an outburst of barely controlled rage.
My experience is quite to the contrary. In this age of participation, as Schwartz calls it, Sun appears to be interested in positioning itself in the center of a social hub for creation of larger works, rather then posing as a potentially threatening bully outside the playfield.
There is, simply put, no money to be made in squashing and threatening open source projects. It'd be an irrational act, and Sun is made up of pretty rational people, afaik. They seem to know what they are doing.
Transvirtual went straight into bankruptcy a few years ago. Afaict, the Kaffe.org project is independant, as there is no corporate backer throwing money at it. It's driven by energetic, fun people.
I believe most of the stirring up regarding the Java Trap article was done by people who either did not read, or did not understand the article properly, and went off on wild tangents. Afair, RMS has not taken part in the ensuing flame wars.
You misunderstood the OOo issue, but that's understandable. As I explained in other places, Sun, Free Runtime developers and OpenOffice.org developers have sat together to figure out a good way to plug different VMs into OpenOffice.org. Various people tried their luck making Free Runtimes work with OOo (I, for example, failed making sense out of the build system, and the com.sun.secret.and.unspecified.Something classes referenced in the sandbox module, and eventually gave up trying to figure the largely undocumented code out.). Caolan, otoh, didn't give up, and made gcj work well as a runtime within OpenOffice.org. That was cool, and he managed to get his patches gradually integrated into OOo's main tree. Then he went for holidays, someone published an article about Sun sneaking in Java in the next version of OOo and all hell broke lose without anyone having a real clue what was happening for the first day or two. Then it got fixed, but Caolan was still on holiday away from his mail, so noone was able to tell how far along things really are. It turned out that they are very far along, and as you can see for yourself in Fedora Core 4, most things just work.
If you want to see Sun Specific APIs in action, please grep over the 1.0.x source code for imports of com.sun.* or sun.* namespaces. Those APIs are not specified, so they can not be implemented. See http://java.sun.com/products/jdk/faq/faq-sun-packa ges.html for details on why using Sun-specific APIs makes Java programs unportable and unreliable.
If you take some time to research OOo on gcj, you'll notice that the development has been beneficial for both OOo and gcj. Good thngs can positively encourage each other, and OOo is a very cool project to help along with.
I've got the idea that you are thinking that Sun is desparate from your continous stream of (mildly amusing) scenarious where Sun would be constrcuted to be threatening to me. They'd only run amok with funky IP claims if they were really, really desperate, though, as funky IP amok runs tend to leave the business in shambles as customers turn somewhere else. Sun is, these days, quite a few billions of dollars away from being desperate, though.
I believe you're boxing with your own shadow, here. On one hand you're the one saying 'Sun could have crushed OSS! They could find many reasons to sue you, personally, even now!' on the other hand you're nevertheless saying 'Sun will never sue OSS projects. They never did.'. I think you are simultaneously arguing both sides of a heated 'Sun is evil! No it's not!' debate taking place somewhere else.
You seem to take the pain, suffering, and (my goodness!) bad press that Sun gets pretty personally. Do you happen to work for Sun's PR team? Or are you by chance one of their Evangelists?
I kindly refer you to sunsource.net FAQ for Sun's own statements regarding them being a part of the open source community. I'm sure they know best whether they are or are not a part of it. Or someone hacked the site.:)
The OOo issue was largely a case a of miscommunication between FSF, Sun, various online publications, and bad PR firefighting. I don;t think anyone saw it coming until it surfaced in the Newforge article. And then wham! All hell was lose.
See Fedora Core 4 for a nice OOo 1.9.x that runs well with gcj. See the tools-jdk list for the current discussions about OpenOffice.org support for Free Runtimes, and how to avoid such things in the future (build deamons with gcj, for example),
I guess IBM gets a lot of sympathy for dealing with SCO. Heard anything crazy about GPL being an unamerican tool of terrorists from Darl lately?:) IBM's taking out the trash, and that's very kind of them, as it's not such a fun task.
My analysis of the JRL is very critical for a simple reason: noone wants to have to go to court, in particular over something that could have been avoided easily by analysing the license and trying to figure out the worst case, and make sure that it does not occur. The legal opinions I quoted give a pretty good reasoning why one should avoid getting bound by simplistic Residual Rights clauses, I think, and why it is so hard to prove in court that no copyright infringement occured if it comes to a lawsuit. Why create potential copyright problems in the future, when we are doing fine without that source code? If one looks at the last three years, Free Runtimes have prospered nicely without having or demanding access to Sun's source code. I don't think that whatever information is buried in the source code if worth putting an aura of doubt around our efforts and potentially putting Sun into an uncomfortable position oh having to pick their alegiances. Instead, such information should find its way into the official specs.
I think the SCSL is quite clear in that respect: when the Lutris developers accepted the SCSL, they were bound by it, and could not release their product os open source without violating the SCSL. There was no need for anyone to threaten anything as the issue is pretty clear cut, and if you read the enhydra archives from back then, it's pretty apparent that Enhydra App Server devs, after trying to negotiate with Sun about having a certified J2EE server under an open source license, gave up in frustration and chose to accept the SCSL and not to release their code as open source, rather then violating Sun's license. That's a very sane decision.
The JBoss agreement is the most puzzling part of the SCSL puzzle, as most news sources from back then indicate that JBoss and Sun had to clean up some licensing problems, and that cleaning up was monetary. JBoss was shipping Sun's code licensed under the BCL, according to Marc Fleury http://www.theserverside.com/news/thread.tss?threa d_id=9177 . Afaict, BCL has some pretty heavy obligations as well regarding javax namespaces, and by developing Jboss for javax.* APIs and distributing BCLd code prohibiting subclassing of those APIs, they might have violated the BCL. Nevertheless, most news reports back then talked about the SCSL, so I need to say that I am just speculating here, as no official statements on the background of the whole deal were released by either side.
If you've got a chance to get the javax.swing.text.html.HTMLEditorKit specification improved, please go for it, this was just meant as an example of the specs being somehwat incomplete. For a rather bad example, see RTFEditorKit.
What one usually does with such incompletely specified classes is to see what other literature exists describing the missing details (books on SWING, for example), and how the code is used in real life by Free Software applications.
I am afraid you've got Transvirtual, the company, and Kaffe.org, a free software project mixed up. It was Transvirtual that accepted funding from Microsoft, not the Kaffe.org project.
Please take some time to read the Java Trap article, and you may find that it's a reasonable, informed opinion about the importance of using Free Software as building bricks for Free Software, rather than introducing hidden dependencies on non-free software. RMS encourages people writing Free Software to evaluate their choices. If they chose the Java programming language they are encouraged to test their code with Free Runtimes, and to help along to make them preferable choices for development and execution of programs written in that language to the non-free implementations. My experience from a few exchanges with RMS is that he's too polite (and busy) to engage himself in flamewars.
A more restrictive licensing arrangement of Sun's source code would hurt Sun Microsystems more than anyone else, as no Free Runtime licenses source code from Sun Microsystems, so they can not be affected by whatever license Sun, if they were as childish as you seem to believe, came up with.
Withholding key information from the public is not possible for Sun any more, now that the JCP takes care about the specifications. Making specifications deliberately worse than they are would again be a move that would only hurt Sun and their customers.
There is nothing evil about Sun Microsystems. They are a huge corporation worth billions of dollars and certainly not shaking in their boots and contemplating desperate measures just because a bunch of hackers managed to pull off what was thought to be impossible and create a thriving ecosystem for Free Runtimes around GNU Classpath or because a few years ago some company made a deal with Sun's current most valued business partner.
I'd be interested to know what makes you think that Sun's so desperate.
Given that Sun Microsystems is a large part of the "OSS community" (see the "share" marketing campaign going on atm), that you accuse of pissing off Sun, you make it sound as if that they have done a lot of bad things to themselves. Have they, really? I'd find that odd.
"effectively declared themselves an enemy", oh my goodness, that's a really odd phrase. Where did you get that sort of weird, martial language from? What makes you think it fits software development, or what Sun thinks of Free Runtimes?
There had been almost no contact between Sun and the Free Runtimes for the first 9 years, until a few folks (including me) started building bridges last year, and working together with progressive people inside Sun Microsystems on finding ways for Sun to learn to know the amazing stuff happening out there. There were no bridges to burn since Sun has never, afaik, tried talking to Free Runtime developers in the past. Sun has been largely non-existant in Free Runtime community, other then as a potential legal boogeyman, and that's certainly not because Sun didn't know where we're hiding. They probably simply didn't think much about it all.:)
See, no Classpath devs care about begging Sun for favours, like asking for opening up their implementation. It's never going to happen, so why bother?
What we're interested in is creating an ecosystem of great, mutually compatible runtimes for programs written in the Java programming language. In oder to fulfill the promise of the platform independance, and truely make programs written in the Java programming languiage run everywhere, we need to be fully compatible with the non-free implementations. It is in the interest of the non-free implementation vendors to be compatible with GNU Classpath.
So mutual compatiblity is definitely an area that we can work on together. Where we differ is that at GNU Classpath, people are interested in verifiable compatiblity claims, rather than cute coffee cup logos, so Mauve, the GNU Classpath compatibility test suite is Free Software, that anyone, including Sun, can freely use to verify the compatiblity of their implementation with GNU Classpath. Sun has so far not returned the favour, they have instead chosen to release their test suites under non-free software licenses. It's their code, it's their choice, it's their loss.
I keep saying that Sun is cordially invited to participate in GNU Classpath, whenever they are ready for it. I sincerely hope that Apache Harmony will be a good venue for them to become a part of the Free Runtime family, and collaborate with Free Runtime developers on shaping the future of the platform.
Yes, I've looked at the new JRL, and unfortunately it's not as simple as the FAQs say. See http://www.mail-archive.com/classpath@gnu.org/msg0 9825.html for details. In particular, let me quote from Larry Rosen's book on open source licensing, regarding an almost word for word equivalent provision in Microsoft's Shared Source license:
""If you are a software developer who intends to write software that might potentially compete with Microsoft's copyrights or patents, there is great risk in looking at Microsoft's source code. Under the copyright law in the United States, if Microsoft proves that there is "substantial similarity" between your commercial software and theirs, you may be an infringer. You may have to prove that you saw and read Microsoft's source code but that you relied only on intangibles and only
on your memory when you wrote your own software.
That's a difficult evidentiary burden. I'm not sure how even
an experienced programmer can walk that fine line. Perhaps the best way is simply not to look at Microsoft's source code at all."
For another lawyer's optinion why you should stay away from Shared Source licenses like the JRL even if they may have been written with best intentions regarding tainting, see
I am not aware of Kaffe, or gcj, or GNU Classpath biting Sun hands, at least noone at Sun told me that, and I've talked with Schwartz, Gosling, and a lot of other folks there...
The Kaffe.org project is not affiliated with Sun Microsystems, so there are no hands involved which could be bitten, afaict. It is also not a 'J'VM, as the term 'JVM' is trademarked by Sun Microsystems for their proprietary software offerings, so I don't use that and wouldn't recommend using it. Kaffe is a VM, no sugar for me, thanks.
cheers,
dalibor topic
Fixing the license incompatibilities between the GPL and Apache License are on the agenda as well, as obviously everyone would like the GPLd runtimes to be able to reuse code written within Apache Harmony.
cheers,
dalibor topic
This is logical nonsense. Questioning Sun's JVM compatibility, (for whatever political reasons you have) does not make Kaffe any less incompatible!
That must have been a misunderstanding. I questioned the soundness and usefulness of a definition of compatibility that is based on belief, rather than on verifiable proofs.
Without being able to prove whether an implementation is compatible or not, one can not (scientifically:) decide assertions of compatibility.
I am prepared to take interest in a product despite the attitude of its supporters.
Cool! See you around. And I hope you don't mind me being zealous about compatibility.
I disagree strongly with you about many things, but I have to say you have made me inclined to keep an eye on Kaffe. I wish the project well.
Thanks! And I hope you don't mind me questioning what you know and what you believe strongly as I did.
I am currently doing the compatiblity dance with Sun, and I am very disappointed by Sun's approach to compatibility so far. I think we can do better together, towards mutually verifiable compatibility, that you, as a Java user, can verify for yourself as well, instead of having to blindly trust a logo on an officially unsupported platform (Debian).
That's where I want to get, as that's the only way to fill the empty phrase 'compatibility' with real, verifiable value.
On other matters I remain resolutely unconvinced. I see little evidence that Kaffe is either fast or compatible enough for general use.
If you read my posts carefully, you'll notice that I did not make those claims. You're bashing a straw man of your own making. I hope it feels good, it's surely amusing to watch from over here.
I said that for some specific uses, Kaffe is faster than Sun's implementation, and showed you how to check it for yourself, and explained why that is the case.
I also questioned your claim that Kaffe is incompatible by showing that you do not have any knowledge about compatibility. You have a lot of beliefs about compatibility, but no way to prove them, and that sort of disqualifies your qualifying assertions because you don't really seem to understand what you're talking about.:)
I explicitely did not say that Kaffe is compatible. It will pass the TCK one day, but till then, I can not verifyably tell how much, or if it is compatible at all, so any such assertion is pointless.
If you have problems with Kaffe in Debian, you're kindly invited to use Debian's bug reporting mechanisms. I'd recommend bug-buddy.
Also, on a side note, since you pride yourself on using a 'Java' branded release of Sun's non-free software and assume that means something, I'd like to kindly point out that what you're using has never been certified as passing the TCK on any Debian release. So what you're running is not 'Java'-compatible in any meaningful, verified way.
You're apparently blindly trusting a logo to shield you away from libc & kernel issues and you sound as if you like it that way. Good luck, anyway, you sound like you may need it.:)
Obviously. But I wasn't the one claiming that the logo implies compatiblity, that was you. And the logo looks just the same on all implementations, afaik.:)
So what is it now, does the logo or doesn't it mean that implementations are compatible?
Why are you assuming I am not checking them for myself?
Because you believe that Sun's implementation is compatible, but you don't know it and refuse to check. Instead you voluntarily chose to rely on hearsay. You defend relying on hearsay, saying that it doesn't matter for you because you don't implement VMs, which I find pretty amusing, as in another breath you say:
However, something without the 'Java' label, indicating a TCK pass, is not going anywhere near my commercial servers.
That's pretty funny, as you don't seem to really know what the Java label indicates, have not seen the test suites, and apparently have an idea of compatibility that James Gosling makes jokes about in interviews[1].
What I find really fascinating is that Sun released 1.4.2 with a known compatibility test suite failure according to the page I quoted above. So much for the logo guaranteeing passing the test suite, I guess.
I think calling arrangements like this 'bogus' is rather petty and mean-spirited.
I have had the pleasure to read the SCSL a few times, to enjoy its full literary value. Some of the provisions in the SCSL are very interesting attempts to extend copyright without regard for copyrightability, others are pretty bold attempts to grab patent-like protection without going through the patent process. That may have been just funny back in 1999. These days, after SCO has shown how much expensive mess a rogue 'copyright holder' can do without even owning copyrights, and having such privileges written down in their licenses, I think it's justifiable to call licenses explicitely grabbing such wide privileges dangerous, or more mildly, 'bogus'.
I really don't get this attitude to Sun. Stuff that they have released like OOo have been vital for the acceptance of Linux on the desktop. They have done so much good for the IT industry over the years.
Sun is a respected member of free software community, and does a lot of things that are just plain great. They also do a few things that are not that great. That's understandable, it's a company after all, it's not a charity.
Sun's choice of licensing their Java technology implementations is their own business. A critique of some of Sun's licensing choices does not imply critique of Sun's other actions.
For example, JCP is a great idea. The execution is not that great though, the specifications coming out of it in the J2SE area have over the years decreased in quality, in my opinion. The JLS3 has stil not been released as a final specification, *years* after the assert keyword was added to the language.
As a Sun Java user, you may chose to interpret that as an attack on Sun, without undertaking the effort to validate my assertion against facts, instead validating them against your beliefs. That's fine. It's a human, emotional response. But as you may have noticed during the course of our discussion, I have made several assertions that you believed to be untrue, that have in fact turned out to be somewhat contrary to your initial beliefs.
There is a difference between what you believe to be true, and what is true. I call SCSL cooperation unfriendly not because I have a bad attitude towards Sun, but because Sun themselves are changing away from the SCSL for JINI, another 'crown jewel' technology in Sun's crown, in order to encourage further adoption, remove restrictions on user code licensing, and to fix issues with commercial multi-tiered distribution. See http://community.jini.org/servlets/ReadMsg?list=di scuss&msgNo=1182
They are switching to ASL2.0, btw. See http://community.jini.org/servlets/ReadMsg?list=di scuss&msgNo=1404 for details.
It is to do with the practical ability to move code between VMs and JREs. The 'Java' brand indicates that you can do this.
Yeah, right:) Try compiling a HalloWorld app on 1.5 and running it on 1.4. Both have the cute logo. But the same program compiled on one, won't necessarily run on the other, unless you somehow manage to convince the compiler to generate code with the other VM's class file format version information and to avoid stuffing in references to the 1.5-specific classes into the class file.
As far as I can see from the logo image, it contains no 'versioning' information, so it's useless for that scenario.
I don't know how to prove that Sun's VM passes the test, but I know that it does.
As a scientist, you surely know that's belief, not knowledge. I told you it's a cargo cult:)
If it did not work, this would be a major news story and Java's reputation would crumble.
Hardly. Sun has regularly been making changes to each release so far breaking backwards compatibility at the source level(the assert keyword, JDBC 3.0 breaking interfaces, etc.) and even at binary level (the System.getenv() melodrama, see http://www.tigress.co.uk/rmy/java/getenv/case.html for an overview). And guess what? Most of Sun's users just kept swallowing the breakage and loved it, because they never noticed it happen. Others vented their anger on BugParade without much result. Where was the big news story?:)
Sun has pretty much forked Java since 1.2 in interesting, slightly incompatible ways, and never documented properly what changes they made to the VM and Language specification, so that a lot of people implementing free runtimes are forced to scratch together information from various crumbles on mailing lists. Noticed any of that in the news? Of course not, because for most users it doesn't matter at all. Most users couldn't care less if their perception of Sun's stewardship of Java and reality matched. They are locked in into non-free software, so why bother getting disillusioned:)
I can't risk putting major enterprise apps on Kaffe and just hope; no matter the quality of the coding.
I fully agree. That's what the test suites of those major enterprise apps are for. I think Jonas on gcj is getting really good, afair from aph's posts on the gcj lists.
Don't trust claims blindly, check them for yourself. Be an informed customer.
Fair enough, but that is a very specialised use. Almost all scientific apps use the equivalent of C or Java doubles for calculation. Almost no serious high-performance scientific calculation would use arbitrary precision mathematics. The only use I can think of is numerical research.
And geometrical computing. Anywhere you can't afford the results to be subject to limits of floating point represetations. See http://www.mpi-sb.mpg.de/%7Emehlhorn/ftp/ClassRoom Example.ps for an interesting paper on the subject of robustness of floating point caclulations.
I don't think it is useful to pick one very specialised case where Kaffe has improved speed and ignore the general case where it seriously lags.
Each benchmark shows some specialized case. If you look at shudo's results, Kaffe beats the client 1.5 VM from Sun on the Sieve benchmark. Does that mean Kaffe's faster than 1.5's client VM in general? To me it only means it's faster on that specific benchmark. Whether that result maps onto what you want to do, depends on what you do. Benchmark your own code, if you need to know.
Generally claiming that Kaffe is slower than Sun is wrong, as those results show. On some tasks Kaffe is faster, on others it's still slower. When Kaffe's gcj-bindings are updated to gcj4, and jit4 is merged in, it will be quite interesting to see the performance of that combined runtime solution.
That's just a link to a description of the testing tools. It's not the tools, nor is it the J2SE test suite. Everyone can put up a cute web page saying they are compatible with something, but hardly anyone can actually prove it. And without proof, such claims are worthless.
Why should I care?
Because it's pointless to argue about compatibility without knowing what it is, and having means to verify it. You made the assertion that Kaffe is incompatible, but you can't even prove that Sun is compatible. So what's your point about invoking that marketing nosense? The branding program is just a way for Sun and their business partners to market themselves together, as far as I can see. It has nothing to do with real, verifiable compatibility.
It's like a cargo cult: just because it has a coffee cup logo on it, it must automatically be compatible. Yeah, right:) Microsoft's VM had red coffee cups slapped on it, too, and that didn't seem to work that well for guaranteeing compatibility.
OK, you are right about the SCSL - it is not truly open source.
But, I am afraid my honest reaction is 'so what?'
Nothing really. I'm pretty amused by desperate attempts by Sun's marketing division to rub off a bit of 'Open Source' street-credibility onto their proprietary product by calling it 'as good as open source', 'closed open source' and what not. It's an amusing running gag in the 'Java melodrama'. I think 'closed open source' is so far the funniest description I've ever heard of Sun's licensing policy, and it comes right from Gosling.
That being said, just because Sun's implementation is not available under a suitable license, doesn't mean that Java is bad or useless or something. It's a cute platform, as C-based platforms go.
Like RMS said, let's build up implementations that help make software written in the Java programming language accessible to more people without getting them entangled in bogus non-free licensing agreements. The restrictive choice of licensing means that people who care will write implementations like gcj, Kaffe, IKVM etc. that are (becoming) better in most respects, not just freedom, than the non-free offers. It may take a few more years, still, but it's been happening already at an amazing pace. This whole article shows how misinformed people are about the massive amount of progress being made on free software implementations: OOo is now buildable with gcj thanks to Caolan, and most of the things work.
What license Sun choses for their J2SE code is completely irrelevant these days. Sun had the chance to open up their software while their implementation still mattered, people were begging them to, now the begging phase is over, and for an increasing number of people the future of the platform is beggining to lie in GNU Classpath. And they are taking an active part in shaping that future by contributing to it.
Sun is now, belatedly, trying hard to emulate GNU Classpath and Kaffe and build up communities around their code base. Looking at Sun's history of 'proprietary-to-open' transitions in OOo and NetBeans, I doubt they will succeed before Kaffe passes the TCK, in particular as long as they stick to their cooperation-unfriendly licensing regime.:)
I don't believe a word of this. Hot-spot is so good it can use parallel architectures like MMX to optimise math, and even optimise machine code instruction order.
You don't have to believe it. You can go ahead and check it out yourself by getting the simple BigInteger benchmark from i2p at http://dev.i2p.net/javadoc/net/i2p/util/NativeBigI nteger.html
They also use GNU MP and have a factor of 10 improvement over Sun's code on their data. Running the benchmark on Kaffe from CVS head with -Xnative-big-math makes kaffe run about 4 times faster than 1.4.2 on the modPow tests. Which is why, in scientific and crypto intensive applications, you may want to use Kaffe rather then Sun's implementation.
Thank you for quoting irrelevant mails around, but not every misinformed source you may find in some search engine can support your assertion that SCSL is open source.:)
May I kindly instruct you to educate yourself using the http://www.opensource.org/licenses/ site that lists all the OSI certified open source licenses? I especially kindly would like to point your attention to the fact that there is no SCSL listed there. And that's not an omission.:)
Furthermore, may I kindly instruct you to enlighten yourself reading the fascinating insight into the reasons why Sun made the SCSL the way they did it on http://www.sun.com/981208/scsl/principles.html , which clearly spells out that SCSL is supposed to combine aspects of 'Open Source' and 'Proprietary' licensing models into one. That's should be a very huge clue bait that it's not open source. The document also gives some explanation why Sun explicitely didn't want an Open Source license.
If you feel the need to educate yourself on the specifics of what makes the SCSL such a funny read, I kindly refer you to http://advogato.org/person/robilad/diary.html?star t=46
which compares the SCSL versus the Open Source definition, and finds it violating 8 out of 10 principles. The SCSL is about as open source as Microsoft Windows 98 SE EULA, I guess.
The parent claimed that Sun's JRE licenses are 'free, indefinitely', I showed him wrong by pointing out how the license allows for revocation in specific cases, that's all there is to it.:)
Ah, the ones approved by the Open Source Initiative? Hence your description of them as 'funny non-free' is factually incorrect.
Nonsense. Neither SCSL nor BCL have ever been approved by OSI. They are clearly not open source. Read them, read the open source definition, and it should be obvious that OSI would never approve them as open source.
That would be neat, as I have benchmarked Sun's VM as equal to the speed of GCC for many scientific/math uses. So, you are claiming that Kaffe is 20x faster than GCC? That would be quite an achievement. In fact, I would call it impossible.
Kaffe can use the excellent state-of-the-art GNU MP bignum library for javax.math. Hot-spot is no match for it. By far. By a factor of 1000 and larger on really big numbers, afair from mailing list reports. That's simply because the GPLd code is so much better in that area than anything Sun has come up with so far. Be happy and enjoy it.
Nonsense. (1) there is the compatibility testing
Is there? Really? Have you ever seen the results of a compatiblity test published anywhere so that they can be independently verified? Have you ever been able to verify those claims? Have you ever seen the tests?
The compatibility has to be proven, or else it is not Java.
Sure. I'd like to see proof that Sun's VM passes all the tests. Show it to me, please.:)
Those of the SCSL, the BCL, and similarly funny non-free software licenses used for Java technology, for example.
There is a difference here: there are people who prefer to beg, and there are people who don't care about Sun any more and hack on a better platform. I'm part of the latter group.
Have you used these? Kaffe has always been slow and problematic. The GNU VM is slow and incompatible. GNU Classpath is incomplete, and Mono doesn't have a compatible modern Java.
That certainly depends on what you do. On some applications (scientific, crypto, nestedvm,...) Kaffe outperforms Sun's hotspot by a factor of 20 or more. On some applications it performs worse than Sun. That will be fixed eventually, when it starts to matter enough.
Compatibility is a huge marketing bogosity in the Java space, without anything to back up the claims. There are no publicly available means to verify compatibility claims of runtime makers so it's all hot air talk by proprietary vendors. In the words of James Gosling: 'Well, I tested it myself and it seems to work OK for me,' or 'Hi, a bunch of my friends tested it and it worked OK.'[1]
cheers, dalibor topic
[1] Though he was referring to open source projects, the same reasoning applies equally to the non-transparent compatibility claims without proof from non-free runtimes.
It seems to me that the problem here is that the Free Java implementations are unready and need to be completed.
Hardly. I've looked at the code, and the problem was largely due to OOo using undocumented Sun-specific classes, which can't be implemented freely, because no specifications exist. That's not much different from Microsoft Word using some hidden MS APIs to do stuff and creating trouble for Wine.
It seems that they have cleaned up their act in the udk, though, which was the worst component in OOo.
There is actually a certain amount of ridiculously bad, standard-disregarding, undocumented Java code in OpenOffice.org that doesn't and won't ever build on Kaffe or gcj because it uses some undocumented sun-specific classes. Fortunately, Caolan has done a great job on kicking that cruft out of his build.
Sun is a bit more reserved on those things. For example, some of that hopelessly bad code is in the Applet Sandbox. OpenOffice.org includes its own Applet execution environment, because obviously you need to have the ability to embed applets in your documents. Ahem.:)
We had a brief conversation on kicking out that code, which seems to have been written for Java 1.0 or 1.1 and uses some really, really insane stuff, but Sun didn't feel like ripping out those unmaintainable (because they undocumented, prone to change classes) features. I guess someone at Sun uses them and desperately needs to have applets in their Writer files.
The major trouble with OpenOffice.org's code is that the code base is insanely hard to build. Last time I tried to do it, it took a few days of searching the docs, hanging out on IRC with handholding and all that, and I still ended up beig frustrated with the dumb, undocumented Sandbox code. Sigh.
That being said, Sun has been nice, and expressed a lot of interest in getting things to run on a free platfrom. Unfortunately, refactoring OpenOffice.org to use 'Sane Java' instead of 'Sun Java' could take a lot of time, and would need some dedicated volunteers to fix Sun's bugs first. And some of them are regarded as features by Sun, apparently:(
All this pressure for Sun to open source Java is in reality pressure for Sun to open source their source for their Java implementation.
Yeah. And one would think that after 10 years of trying to put up pressure on Sun to do something they repeatedly said that they don't want to do, people would finally learn to stop wasting their breath and just go ahead and try to create something better instead of begging to be released of their shackles.
Fortunately, in increasing numbers, they do now. See Mono, see GNU Classpath, see gcj, and see Kaffe.
If I did, it would be gcj that I would consider. (Sorry Kaffe.)
gcj is pretty excellent, and the Kaffe devs are incorporating components from gcj into Kaffe in order to make it easier to have a Kaffe-on-Gcj mixed runtime (and to create interfaces for them in GNU Classpath). It will be an interesting year ahead once we have a mixed-mode engine with fast natively compiled class libraries and quick jitters.
Slashdot Mirror
In my opinion, to go with the comic theme from your handle, you're painting Sun as some rather loaded, Hulk like character, that's every moment about to explode and go on a rampage in too tight shorts in an outburst of barely controlled rage.
My experience is quite to the contrary. In this age of participation, as Schwartz calls it, Sun appears to be interested in positioning itself in the center of a social hub for creation of larger works, rather then posing as a potentially threatening bully outside the playfield.
There is, simply put, no money to be made in squashing and threatening open source projects. It'd be an irrational act, and Sun is made up of pretty rational people, afaik. They seem to know what they are doing.
cheers, dalibor topic
I believe most of the stirring up regarding the Java Trap article was done by people who either did not read, or did not understand the article properly, and went off on wild tangents. Afair, RMS has not taken part in the ensuing flame wars.
You misunderstood the OOo issue, but that's understandable. As I explained in other places, Sun, Free Runtime developers and OpenOffice.org developers have sat together to figure out a good way to plug different VMs into OpenOffice.org. Various people tried their luck making Free Runtimes work with OOo (I, for example, failed making sense out of the build system, and the com.sun.secret.and.unspecified.Something classes referenced in the sandbox module, and eventually gave up trying to figure the largely undocumented code out.). Caolan, otoh, didn't give up, and made gcj work well as a runtime within OpenOffice.org. That was cool, and he managed to get his patches gradually integrated into OOo's main tree. Then he went for holidays, someone published an article about Sun sneaking in Java in the next version of OOo and all hell broke lose without anyone having a real clue what was happening for the first day or two. Then it got fixed, but Caolan was still on holiday away from his mail, so noone was able to tell how far along things really are. It turned out that they are very far along, and as you can see for yourself in Fedora Core 4, most things just work.
If you want to see Sun Specific APIs in action, please grep over the 1.0.x source code for imports of com.sun.* or sun.* namespaces. Those APIs are not specified, so they can not be implemented. See http://java.sun.com/products/jdk/faq/faq-sun-packa ges.html for details on why using Sun-specific APIs makes Java programs unportable and unreliable.
If you take some time to research OOo on gcj, you'll notice that the development has been beneficial for both OOo and gcj. Good thngs can positively encourage each other, and OOo is a very cool project to help along with.
I've got the idea that you are thinking that Sun is desparate from your continous stream of (mildly amusing) scenarious where Sun would be constrcuted to be threatening to me. They'd only run amok with funky IP claims if they were really, really desperate, though, as funky IP amok runs tend to leave the business in shambles as customers turn somewhere else. Sun is, these days, quite a few billions of dollars away from being desperate, though.
I believe you're boxing with your own shadow, here. On one hand you're the one saying 'Sun could have crushed OSS! They could find many reasons to sue you, personally, even now!' on the other hand you're nevertheless saying 'Sun will never sue OSS projects. They never did.'. I think you are simultaneously arguing both sides of a heated 'Sun is evil! No it's not!' debate taking place somewhere else.
You seem to take the pain, suffering, and (my goodness!) bad press that Sun gets pretty personally. Do you happen to work for Sun's PR team? Or are you by chance one of their Evangelists?
The OOo issue was largely a case a of miscommunication between FSF, Sun, various online publications, and bad PR firefighting. I don;t think anyone saw it coming until it surfaced in the Newforge article. And then wham! All hell was lose.
See Fedora Core 4 for a nice OOo 1.9.x that runs well with gcj. See the tools-jdk list for the current discussions about OpenOffice.org support for Free Runtimes, and how to avoid such things in the future (build deamons with gcj, for example),
I guess IBM gets a lot of sympathy for dealing with SCO. Heard anything crazy about GPL being an unamerican tool of terrorists from Darl lately? :) IBM's taking out the trash, and that's very kind of them, as it's not such a fun task.
My analysis of the JRL is very critical for a simple reason: noone wants to have to go to court, in particular over something that could have been avoided easily by analysing the license and trying to figure out the worst case, and make sure that it does not occur. The legal opinions I quoted give a pretty good reasoning why one should avoid getting bound by simplistic Residual Rights clauses, I think, and why it is so hard to prove in court that no copyright infringement occured if it comes to a lawsuit. Why create potential copyright problems in the future, when we are doing fine without that source code? If one looks at the last three years, Free Runtimes have prospered nicely without having or demanding access to Sun's source code. I don't think that whatever information is buried in the source code if worth putting an aura of doubt around our efforts and potentially putting Sun into an uncomfortable position oh having to pick their alegiances. Instead, such information should find its way into the official specs.
I think the SCSL is quite clear in that respect: when the Lutris developers accepted the SCSL, they were bound by it, and could not release their product os open source without violating the SCSL. There was no need for anyone to threaten anything as the issue is pretty clear cut, and if you read the enhydra archives from back then, it's pretty apparent that Enhydra App Server devs, after trying to negotiate with Sun about having a certified J2EE server under an open source license, gave up in frustration and chose to accept the SCSL and not to release their code as open source, rather then violating Sun's license. That's a very sane decision.
The JBoss agreement is the most puzzling part of the SCSL puzzle, as most news sources from back then indicate that JBoss and Sun had to clean up some licensing problems, and that cleaning up was monetary. JBoss was shipping Sun's code licensed under the BCL, according to Marc Fleury http://www.theserverside.com/news/thread.tss?threa d_id=9177 . Afaict, BCL has some pretty heavy obligations as well regarding javax namespaces, and by developing Jboss for javax.* APIs and distributing BCLd code prohibiting subclassing of those APIs, they might have violated the BCL. Nevertheless, most news reports back then talked about the SCSL, so I need to say that I am just speculating here, as no official statements on the background of the whole deal were released by either side.
If you've got a chance to get the javax.swing.text.html.HTMLEditorKit specification improved, please go for it, this was just meant as an example of the specs being somehwat incomplete. For a rather bad example, see RTFEditorKit.
What one usually does with such incompletely specified classes is to see what other literature exists describing the missing details (books on SWING, for example), and how the code is used in real life by Free Software applications.
cheers, dalibor topic
Please take some time to read the Java Trap article, and you may find that it's a reasonable, informed opinion about the importance of using Free Software as building bricks for Free Software, rather than introducing hidden dependencies on non-free software. RMS encourages people writing Free Software to evaluate their choices. If they chose the Java programming language they are encouraged to test their code with Free Runtimes, and to help along to make them preferable choices for development and execution of programs written in that language to the non-free implementations. My experience from a few exchanges with RMS is that he's too polite (and busy) to engage himself in flamewars.
A more restrictive licensing arrangement of Sun's source code would hurt Sun Microsystems more than anyone else, as no Free Runtime licenses source code from Sun Microsystems, so they can not be affected by whatever license Sun, if they were as childish as you seem to believe, came up with.
Withholding key information from the public is not possible for Sun any more, now that the JCP takes care about the specifications. Making specifications deliberately worse than they are would again be a move that would only hurt Sun and their customers.
There is nothing evil about Sun Microsystems. They are a huge corporation worth billions of dollars and certainly not shaking in their boots and contemplating desperate measures just because a bunch of hackers managed to pull off what was thought to be impossible and create a thriving ecosystem for Free Runtimes around GNU Classpath or because a few years ago some company made a deal with Sun's current most valued business partner.
I'd be interested to know what makes you think that Sun's so desperate.
cheers, dalibor topic
"effectively declared themselves an enemy", oh my goodness, that's a really odd phrase. Where did you get that sort of weird, martial language from? What makes you think it fits software development, or what Sun thinks of Free Runtimes?
There had been almost no contact between Sun and the Free Runtimes for the first 9 years, until a few folks (including me) started building bridges last year, and working together with progressive people inside Sun Microsystems on finding ways for Sun to learn to know the amazing stuff happening out there. There were no bridges to burn since Sun has never, afaik, tried talking to Free Runtime developers in the past. Sun has been largely non-existant in Free Runtime community, other then as a potential legal boogeyman, and that's certainly not because Sun didn't know where we're hiding. They probably simply didn't think much about it all. :)
See, no Classpath devs care about begging Sun for favours, like asking for opening up their implementation. It's never going to happen, so why bother?
What we're interested in is creating an ecosystem of great, mutually compatible runtimes for programs written in the Java programming language. In oder to fulfill the promise of the platform independance, and truely make programs written in the Java programming languiage run everywhere, we need to be fully compatible with the non-free implementations. It is in the interest of the non-free implementation vendors to be compatible with GNU Classpath.
So mutual compatiblity is definitely an area that we can work on together. Where we differ is that at GNU Classpath, people are interested in verifiable compatiblity claims, rather than cute coffee cup logos, so Mauve, the GNU Classpath compatibility test suite is Free Software, that anyone, including Sun, can freely use to verify the compatiblity of their implementation with GNU Classpath. Sun has so far not returned the favour, they have instead chosen to release their test suites under non-free software licenses. It's their code, it's their choice, it's their loss.
I keep saying that Sun is cordially invited to participate in GNU Classpath, whenever they are ready for it. I sincerely hope that Apache Harmony will be a good venue for them to become a part of the Free Runtime family, and collaborate with Free Runtime developers on shaping the future of the platform.
Yes, I've looked at the new JRL, and unfortunately it's not as simple as the FAQs say. See http://www.mail-archive.com/classpath@gnu.org/msg0 9825.html for details. In particular, let me quote from Larry Rosen's book on open source licensing, regarding an almost word for word equivalent provision in Microsoft's Shared Source license:
""If you are a software developer who intends to write software that might potentially compete with Microsoft's copyrights or patents, there is great risk in looking at Microsoft's source code. Under the copyright law in the United States, if Microsoft proves that there is "substantial similarity" between your commercial software and theirs, you may be an infringer. You may have to prove that you saw and read Microsoft's source code but that you relied only on intangibles and only on your memory when you wrote your own software.
That's a difficult evidentiary burden. I'm not sure how even an experienced programmer can walk that fine line. Perhaps the best way is simply not to look at Microsoft's source code at all."
For another lawyer's optinion why you should stay away from Shared Source licenses like the JRL even if they may have been written with best intentions regarding tainting, see
I am not aware of Kaffe, or gcj, or GNU Classpath biting Sun hands, at least noone at Sun told me that, and I've talked with Schwartz, Gosling, and a lot of other folks there ...
The Kaffe.org project is not affiliated with Sun Microsystems, so there are no hands involved which could be bitten, afaict. It is also not a 'J'VM, as the term 'JVM' is trademarked by Sun Microsystems for their proprietary software offerings, so I don't use that and wouldn't recommend using it. Kaffe is a VM, no sugar for me, thanks.
cheers,
dalibor topic
Fixing the license incompatibilities between the GPL and Apache License are on the agenda as well, as obviously everyone would like the GPLd runtimes to be able to reuse code written within Apache Harmony. cheers, dalibor topic
That must have been a misunderstanding. I questioned the soundness and usefulness of a definition of compatibility that is based on belief, rather than on verifiable proofs.
Without being able to prove whether an implementation is compatible or not, one can not (scientifically :) decide assertions of compatibility.
I am prepared to take interest in a product despite the attitude of its supporters. Cool! See you around. And I hope you don't mind me being zealous about compatibility.
cheers, dalibor topic
Thanks! And I hope you don't mind me questioning what you know and what you believe strongly as I did.
I am currently doing the compatiblity dance with Sun, and I am very disappointed by Sun's approach to compatibility so far. I think we can do better together, towards mutually verifiable compatibility, that you, as a Java user, can verify for yourself as well, instead of having to blindly trust a logo on an officially unsupported platform (Debian).
That's where I want to get, as that's the only way to fill the empty phrase 'compatibility' with real, verifiable value.
Wish me luck, it's been fun talking to you :)
cheers, dalibor topic
If you read my posts carefully, you'll notice that I did not make those claims. You're bashing a straw man of your own making. I hope it feels good, it's surely amusing to watch from over here.
I said that for some specific uses, Kaffe is faster than Sun's implementation, and showed you how to check it for yourself, and explained why that is the case.
I also questioned your claim that Kaffe is incompatible by showing that you do not have any knowledge about compatibility. You have a lot of beliefs about compatibility, but no way to prove them, and that sort of disqualifies your qualifying assertions because you don't really seem to understand what you're talking about.:)
I explicitely did not say that Kaffe is compatible. It will pass the TCK one day, but till then, I can not verifyably tell how much, or if it is compatible at all, so any such assertion is pointless.
If you have problems with Kaffe in Debian, you're kindly invited to use Debian's bug reporting mechanisms. I'd recommend bug-buddy.
Also, on a side note, since you pride yourself on using a 'Java' branded release of Sun's non-free software and assume that means something, I'd like to kindly point out that what you're using has never been certified as passing the TCK on any Debian release. So what you're running is not 'Java'-compatible in any meaningful, verified way.
You're apparently blindly trusting a logo to shield you away from libc & kernel issues and you sound as if you like it that way. Good luck, anyway, you sound like you may need it. :)
cheers, dalibor topic
Obviously. But I wasn't the one claiming that the logo implies compatiblity, that was you. And the logo looks just the same on all implementations, afaik.:)
So what is it now, does the logo or doesn't it mean that implementations are compatible?
For another intersting bit of information that you seem to be missing, there is no backwards compatibility between 'point-releases' of a Sun implementation either. See http://java.sun.com/j2se/1.4.2/compatibility.html# incompatibilities .
Why are you assuming I am not checking them for myself?
Because you believe that Sun's implementation is compatible, but you don't know it and refuse to check. Instead you voluntarily chose to rely on hearsay. You defend relying on hearsay, saying that it doesn't matter for you because you don't implement VMs, which I find pretty amusing, as in another breath you say:
However, something without the 'Java' label, indicating a TCK pass, is not going anywhere near my commercial servers.
That's pretty funny, as you don't seem to really know what the Java label indicates, have not seen the test suites, and apparently have an idea of compatibility that James Gosling makes jokes about in interviews[1].
What I find really fascinating is that Sun released 1.4.2 with a known compatibility test suite failure according to the page I quoted above. So much for the logo guaranteeing passing the test suite, I guess.
cheers, dalibor topic
[1] 'Well, I tested it myself and it seems to work OK for me,' or 'Hi, a bunch of my friends tested it and it worked OK.' See http://programming.itmanagersjournal.com/programmi ng/05/03/17/0131245.shtml?tid=56
I have had the pleasure to read the SCSL a few times, to enjoy its full literary value. Some of the provisions in the SCSL are very interesting attempts to extend copyright without regard for copyrightability, others are pretty bold attempts to grab patent-like protection without going through the patent process. That may have been just funny back in 1999. These days, after SCO has shown how much expensive mess a rogue 'copyright holder' can do without even owning copyrights, and having such privileges written down in their licenses, I think it's justifiable to call licenses explicitely grabbing such wide privileges dangerous, or more mildly, 'bogus'.
I really don't get this attitude to Sun. Stuff that they have released like OOo have been vital for the acceptance of Linux on the desktop. They have done so much good for the IT industry over the years.
Sun is a respected member of free software community, and does a lot of things that are just plain great. They also do a few things that are not that great. That's understandable, it's a company after all, it's not a charity.
Sun's choice of licensing their Java technology implementations is their own business. A critique of some of Sun's licensing choices does not imply critique of Sun's other actions.
For example, JCP is a great idea. The execution is not that great though, the specifications coming out of it in the J2SE area have over the years decreased in quality, in my opinion. The JLS3 has stil not been released as a final specification, *years* after the assert keyword was added to the language.
As a Sun Java user, you may chose to interpret that as an attack on Sun, without undertaking the effort to validate my assertion against facts, instead validating them against your beliefs. That's fine. It's a human, emotional response. But as you may have noticed during the course of our discussion, I have made several assertions that you believed to be untrue, that have in fact turned out to be somewhat contrary to your initial beliefs.
There is a difference between what you believe to be true, and what is true. I call SCSL cooperation unfriendly not because I have a bad attitude towards Sun, but because Sun themselves are changing away from the SCSL for JINI, another 'crown jewel' technology in Sun's crown, in order to encourage further adoption, remove restrictions on user code licensing, and to fix issues with commercial multi-tiered distribution. See http://community.jini.org/servlets/ReadMsg?list=di scuss&msgNo=1182
They are switching to ASL2.0, btw. See http://community.jini.org/servlets/ReadMsg?list=di scuss&msgNo=1404 for details.
cheers, dalibor topic
Yeah, right :) Try compiling a HalloWorld app on 1.5 and running it on 1.4. Both have the cute logo. But the same program compiled on one, won't necessarily run on the other, unless you somehow manage to convince the compiler to generate code with the other VM's class file format version information and to avoid stuffing in references to the 1.5-specific classes into the class file.
As far as I can see from the logo image, it contains no 'versioning' information, so it's useless for that scenario.
I don't know how to prove that Sun's VM passes the test, but I know that it does.
As a scientist, you surely know that's belief, not knowledge. I told you it's a cargo cult :)
If it did not work, this would be a major news story and Java's reputation would crumble.
Hardly. Sun has regularly been making changes to each release so far breaking backwards compatibility at the source level(the assert keyword, JDBC 3.0 breaking interfaces, etc.) and even at binary level (the System.getenv() melodrama, see http://www.tigress.co.uk/rmy/java/getenv/case.html for an overview). And guess what? Most of Sun's users just kept swallowing the breakage and loved it, because they never noticed it happen. Others vented their anger on BugParade without much result. Where was the big news story? :)
Sun has pretty much forked Java since 1.2 in interesting, slightly incompatible ways, and never documented properly what changes they made to the VM and Language specification, so that a lot of people implementing free runtimes are forced to scratch together information from various crumbles on mailing lists. Noticed any of that in the news? Of course not, because for most users it doesn't matter at all. Most users couldn't care less if their perception of Sun's stewardship of Java and reality matched. They are locked in into non-free software, so why bother getting disillusioned :)
I can't risk putting major enterprise apps on Kaffe and just hope; no matter the quality of the coding.
I fully agree. That's what the test suites of those major enterprise apps are for. I think Jonas on gcj is getting really good, afair from aph's posts on the gcj lists.
Don't trust claims blindly, check them for yourself. Be an informed customer.
cheers, dalibor topic
And geometrical computing. Anywhere you can't afford the results to be subject to limits of floating point represetations. See http://www.mpi-sb.mpg.de/%7Emehlhorn/ftp/ClassRoom Example.ps for an interesting paper on the subject of robustness of floating point caclulations.
I don't think it is useful to pick one very specialised case where Kaffe has improved speed and ignore the general case where it seriously lags.
Each benchmark shows some specialized case. If you look at shudo's results, Kaffe beats the client 1.5 VM from Sun on the Sieve benchmark. Does that mean Kaffe's faster than 1.5's client VM in general? To me it only means it's faster on that specific benchmark. Whether that result maps onto what you want to do, depends on what you do. Benchmark your own code, if you need to know.
Generally claiming that Kaffe is slower than Sun is wrong, as those results show. On some tasks Kaffe is faster, on others it's still slower. When Kaffe's gcj-bindings are updated to gcj4, and jit4 is merged in, it will be quite interesting to see the performance of that combined runtime solution.
cheers, dalibor topic
That's J2EE. I asked for proof that Sun's VM passes all the tests. That's J2SE. They are very, very different things.
If you want to prove it to yourself. Here is the website for some test suites: http://java.sun.com/developer/technicalArticles/JC Ptools/
That's just a link to a description of the testing tools. It's not the tools, nor is it the J2SE test suite. Everyone can put up a cute web page saying they are compatible with something, but hardly anyone can actually prove it. And without proof, such claims are worthless.
Why should I care?
Because it's pointless to argue about compatibility without knowing what it is, and having means to verify it. You made the assertion that Kaffe is incompatible, but you can't even prove that Sun is compatible. So what's your point about invoking that marketing nosense? The branding program is just a way for Sun and their business partners to market themselves together, as far as I can see. It has nothing to do with real, verifiable compatibility.
It's like a cargo cult: just because it has a coffee cup logo on it, it must automatically be compatible. Yeah, right :) Microsoft's VM had red coffee cups slapped on it, too, and that didn't seem to work that well for guaranteeing compatibility.
cheers, dalibor topic
Nothing really. I'm pretty amused by desperate attempts by Sun's marketing division to rub off a bit of 'Open Source' street-credibility onto their proprietary product by calling it 'as good as open source', 'closed open source' and what not. It's an amusing running gag in the 'Java melodrama'. I think 'closed open source' is so far the funniest description I've ever heard of Sun's licensing policy, and it comes right from Gosling.
That being said, just because Sun's implementation is not available under a suitable license, doesn't mean that Java is bad or useless or something. It's a cute platform, as C-based platforms go.
Like RMS said, let's build up implementations that help make software written in the Java programming language accessible to more people without getting them entangled in bogus non-free licensing agreements. The restrictive choice of licensing means that people who care will write implementations like gcj, Kaffe, IKVM etc. that are (becoming) better in most respects, not just freedom, than the non-free offers. It may take a few more years, still, but it's been happening already at an amazing pace. This whole article shows how misinformed people are about the massive amount of progress being made on free software implementations: OOo is now buildable with gcj thanks to Caolan, and most of the things work.
What license Sun choses for their J2SE code is completely irrelevant these days. Sun had the chance to open up their software while their implementation still mattered, people were begging them to, now the begging phase is over, and for an increasing number of people the future of the platform is beggining to lie in GNU Classpath. And they are taking an active part in shaping that future by contributing to it.
Sun is now, belatedly, trying hard to emulate GNU Classpath and Kaffe and build up communities around their code base. Looking at Sun's history of 'proprietary-to-open' transitions in OOo and NetBeans, I doubt they will succeed before Kaffe passes the TCK, in particular as long as they stick to their cooperation-unfriendly licensing regime.:)
cheers, dalibor topic
You don't have to believe it. You can go ahead and check it out yourself by getting the simple BigInteger benchmark from i2p at http://dev.i2p.net/javadoc/net/i2p/util/NativeBigI nteger.html
They also use GNU MP and have a factor of 10 improvement over Sun's code on their data. Running the benchmark on Kaffe from CVS head with -Xnative-big-math makes kaffe run about 4 times faster than 1.4.2 on the modPow tests. Which is why, in scientific and crypto intensive applications, you may want to use Kaffe rather then Sun's implementation.
cheers, dalibor topic
May I kindly instruct you to educate yourself using the http://www.opensource.org/licenses/ site that lists all the OSI certified open source licenses? I especially kindly would like to point your attention to the fact that there is no SCSL listed there. And that's not an omission. :)
Furthermore, may I kindly instruct you to enlighten yourself reading the fascinating insight into the reasons why Sun made the SCSL the way they did it on http://www.sun.com/981208/scsl/principles.html , which clearly spells out that SCSL is supposed to combine aspects of 'Open Source' and 'Proprietary' licensing models into one. That's should be a very huge clue bait that it's not open source. The document also gives some explanation why Sun explicitely didn't want an Open Source license.
If you feel the need to educate yourself on the specifics of what makes the SCSL such a funny read, I kindly refer you to http://advogato.org/person/robilad/diary.html?star t=46
which compares the SCSL versus the Open Source definition, and finds it violating 8 out of 10 principles. The SCSL is about as open source as Microsoft Windows 98 SE EULA, I guess.
cheers, dalibor topic
Sure. So? I didn't make that claim.
The parent claimed that Sun's JRE licenses are 'free, indefinitely', I showed him wrong by pointing out how the license allows for revocation in specific cases, that's all there is to it. :)
cheers, dalibor topic
Nonsense. Neither SCSL nor BCL have ever been approved by OSI. They are clearly not open source. Read them, read the open source definition, and it should be obvious that OSI would never approve them as open source.
That would be neat, as I have benchmarked Sun's VM as equal to the speed of GCC for many scientific/math uses. So, you are claiming that Kaffe is 20x faster than GCC? That would be quite an achievement. In fact, I would call it impossible.
Kaffe can use the excellent state-of-the-art GNU MP bignum library for javax.math. Hot-spot is no match for it. By far. By a factor of 1000 and larger on really big numbers, afair from mailing list reports. That's simply because the GPLd code is so much better in that area than anything Sun has come up with so far. Be happy and enjoy it.
Nonsense. (1) there is the compatibility testing
Is there? Really? Have you ever seen the results of a compatiblity test published anywhere so that they can be independently verified? Have you ever been able to verify those claims? Have you ever seen the tests?
The compatibility has to be proven, or else it is not Java.
Sure. I'd like to see proof that Sun's VM passes all the tests. Show it to me, please. :)
cheers, dalibor topic
Those of the SCSL, the BCL, and similarly funny non-free software licenses used for Java technology, for example.
There is a difference here: there are people who prefer to beg, and there are people who don't care about Sun any more and hack on a better platform. I'm part of the latter group.
Have you used these? Kaffe has always been slow and problematic. The GNU VM is slow and incompatible. GNU Classpath is incomplete, and Mono doesn't have a compatible modern Java.
That certainly depends on what you do. On some applications (scientific, crypto, nestedvm, ...) Kaffe outperforms Sun's hotspot by a factor of 20 or more. On some applications it performs worse than Sun. That will be fixed eventually, when it starts to matter enough.
Compatibility is a huge marketing bogosity in the Java space, without anything to back up the claims. There are no publicly available means to verify compatibility claims of runtime makers so it's all hot air talk by proprietary vendors. In the words of James Gosling: 'Well, I tested it myself and it seems to work OK for me,' or 'Hi, a bunch of my friends tested it and it worked OK.'[1]
cheers, dalibor topic
[1] Though he was referring to open source projects, the same reasoning applies equally to the non-transparent compatibility claims without proof from non-free runtimes.
Hardly. I've looked at the code, and the problem was largely due to OOo using undocumented Sun-specific classes, which can't be implemented freely, because no specifications exist. That's not much different from Microsoft Word using some hidden MS APIs to do stuff and creating trouble for Wine.
It seems that they have cleaned up their act in the udk, though, which was the worst component in OOo.
cheers, dalibor topic
Sun is a bit more reserved on those things. For example, some of that hopelessly bad code is in the Applet Sandbox. OpenOffice.org includes its own Applet execution environment, because obviously you need to have the ability to embed applets in your documents. Ahem. :)
We had a brief conversation on kicking out that code, which seems to have been written for Java 1.0 or 1.1 and uses some really, really insane stuff, but Sun didn't feel like ripping out those unmaintainable (because they undocumented, prone to change classes) features. I guess someone at Sun uses them and desperately needs to have applets in their Writer files.
The major trouble with OpenOffice.org's code is that the code base is insanely hard to build. Last time I tried to do it, it took a few days of searching the docs, hanging out on IRC with handholding and all that, and I still ended up beig frustrated with the dumb, undocumented Sandbox code. Sigh.
That being said, Sun has been nice, and expressed a lot of interest in getting things to run on a free platfrom. Unfortunately, refactoring OpenOffice.org to use 'Sane Java' instead of 'Sun Java' could take a lot of time, and would need some dedicated volunteers to fix Sun's bugs first. And some of them are regarded as features by Sun, apparently :(
cheers, dalibor topic
Yeah. And one would think that after 10 years of trying to put up pressure on Sun to do something they repeatedly said that they don't want to do, people would finally learn to stop wasting their breath and just go ahead and try to create something better instead of begging to be released of their shackles.
Fortunately, in increasing numbers, they do now. See Mono, see GNU Classpath, see gcj, and see Kaffe.
cheers, dalibor topic
gcj is pretty excellent, and the Kaffe devs are incorporating components from gcj into Kaffe in order to make it easier to have a Kaffe-on-Gcj mixed runtime (and to create interfaces for them in GNU Classpath). It will be an interesting year ahead once we have a mixed-mode engine with fast natively compiled class libraries and quick jitters.
cheers, dalibor topic