Slashdot Mirror
OpenOffice 2.0 Criticized on Use of Java
karvind writes "Yahoo is running a story on how OpenOffice 2.0 Faces Opposition over Its Use of Java. According the article: "The problem, according to some free software voices, is that OO.o relies too much on Sun Microsystems Inc.'s proprietary Java programming language in an open-source project. In particular, free software advocates are objecting to the use of Sun specific Java code for such OO.o 2.0 features as the new, Microsoft Access-like database management program, Base and Writer's (OO.o's word processor) document wizards." Linus Torvalds also moved to an open-source solution for software configuration management system."
It doesn't do any good to have open source software if it requires a closed source VM to run. You're still at the mercy of whoever controls the VM. If they decide to pull your license (as Sun did to FreeBSD) then you're no longer allowed to use your own software. You can't build Free Software on a non-Free foundation.
There's no point in questioning authority if you aren't going to listen to the answers.
It seems that people are getting upset at looking at the imports in the code without realizing that THEY ARE NEVER USED!!! Again, I refer you to the blog entry, but for those of you too lazy:
This gcj request asks for the addition of java.awt.Frame.createBufferStrategy which is all that is missing from gcj to build the java canvas stuff. (Though the canvas module contains a pile of spurious imports of sun.awt which are unnecessary and can be removed, not that there's much point right now, if a createBufferStrategy becomes available then removing the sun.awt from the canvas/java .javas is all that's outstanding)
Nothing to see here, just move along. More jumping the gun rather than investigating things to completion.
Who is John Galt?
1. The license only restricts your ability to take java, change the name and call it your product, then start charging for it, without paying license and royalty fees to Sun.
2. Seeing how the source code is available, I don't see how you can say they are using undocumented features and keep a straight face.
I don't see anywhere in the article that indicates they're using undocumented internal com.sun.* classes. The problem seems to be that some key functionality in OpenOffice is implemented with Java, and that Java itself is not free.
;)
;)
Whether they say it in the article or not, it happens to be the case. Here is a post by the main Kaffe developer about it. I quote:
>import sun.security.provider.*;
>import sun.security.provider.SystemIdentity;
>import sun.security.provider.SystemSigner;
Not implemented and most probably won't be. These are
the JDK 1.1 undocumented (actually sun mentions them
in an example in the java security architecture paper,
but explicitely recommends staying away from it) key
management apis. Sun has deprecated the corresponding
classes in java.security with java 1.2, and uses
different key management facilities. Open office
developers should know better, as they are supposed to
be using java 1.3, right?
[lots of other imports of sun.* and sunw.* classes]
Anyone using sun.* classes doesn't _want_ to be
portable accross VM releases/implementations. Someone
(either the open office developers, or the debian
developers wanting to build open office using free
software) should clean up the sun.* mess. I wouldn't
want to implement sun.* classes just to suit someone
else's bad programming style, and I don't know anyone
who does
Indeed, the problem is big. Some BSDs don't have java, linux ppc users either. Right now Java's "portability" is a joke with Sun's VM, even if it was free as in speech.
That's why GNU classpath & GCJ is important. It will provide us with a free (as in speech & beer) java VM for those who doesn't want to use Sun's VM (linux users, basically). Redhat is putting lots programmers & money behind of GCJ and collaborating with tons of community-based projects - they really want a free java. In fact, Redhat has some people hacking on GCJ to support openoffice's java features.
Actually, GCJ 4 is one of the GCC 4.0 greatest features, here is an article about why it's so great. They've achieved almost all Java 1.4 important features and there's work ongoing to support 1.5.
And GCJ does support, in fact, MORE architectures and operative systems than Sun's propietary offerings - yes, more. It's what will make java truly palataform-independent. GCJ is part of GCC, so it supports the platforms that gcc supports - much more than Sun's VM or other propietary VMs
no app in it's right mind should be directly calling sun.*, for obvious reasons. If you find code in OO which does, then maybe there will be cause for complaint.
./hsqldb/makefile.mk is breaking due to sun.security.action.GetPropertyAction being missing.
There is code in OOo which uses com.sun classes. Quite a lot of it.
Caolan McNamara is working on building OOo on GCJ. Right on his blog there you can see several examples listed, e.g:
Ok? Noone is saying it's all Sun's fault here. But part of it is.
GCJ can compile java code for the platforms supported by GCC - way more than Sun's offerings or other propietary VMs.
Red Hat is paying people to support OOo 2.0 with GCJ. And GCJ 4.0 is already quite good...
From TFA:
So, no. It will never be zero, and it's currently 100% usable without a JVM.
Doug
Well, let's see... OK, so what you're asking for is that Sun should write a standard for a slimmed-down version of Java, just for PDAs? Say, we could call it Java 2 Micro Edition? And maybe you'd want that standard to be implemented on PocketPC machines?
Wait, it gets better. You can also find a full java implementation (Java 1.3) for iPAQ.
If you want something in between, there's also PersonalJava. It has more features than J2ME, but fewer than a full java. It's nearing end of life though, I'm not sure what will come out to replace it.
There are JVMs for PDAs and cell phones and yes, PocketPC too. They are a very good way of getting your software to run on many portable devices. The only downside is that your code will run slower than something hand-crafted for a particular type of device.