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.
>If someone could explain how this relates to OO.o's use of Java, I'd appreciate it.
2 .0-development/ch19lev1sec2.html
s p
As I say in the story--in a one sentence remark--it's because in both cases, some people are objecting to the use of proprietary software in an open source project.
It's not like this is a new battle between free software advocates and open-source supporters. The one most people probably know best is the use of TrollTech's QT in KDE. For more on that, see:
http://developer.kde.org/documentation/books/kde-
For the original version of the OO.o story see:
http://www.eweek.com/article2/0,1759,1813986,00.a
Steven
Nope. C# runs at least as places Java 1.5 does, thanks to Mono/ASP.NET.
With Java, Sun's proprietary moving target policy means you're stuck between the "old standards" that Gnu's java and other non-licensees have, or the small handful of supported platforms from Sun and a couple licensees.
Thanks to Mono, with C# you're good anywhere you feel like cross-compiling to.
The ironic thing here is that Gnu has a Java compiler, gcj, *and* gcj is intended to ultimately become the Java solution for Open Office.
You'd think nobody knew there were open source Java implementations... Java is a great language, and there is significant effort going into Open Source versions. It's all good...
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
GCJ can already compile and run Eclipse, which is one of the most complex Java apps out there. I doubt compiling OPenOffice 2.0's Java code into .so format would be a huge hurdle.
What cygwin-esque environment is needed to run python apps? Links and resources, please...
Normally, I just install python's win32 installer, and run my apps. If I need some third-party extension, I just install it, and go. No need for any cygwin-esque environment.
-gus
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
See: The Java Trap, by Richard Stallman
Sun's implementation of Java is non-free. Blackdown is also non-free; it is an adaptation of Sun's proprietary code. The standard Java libraries are non-free also. We do have free implementations of Java, such as the GNU Java Compiler and GNU Classpath, but they don't support all the features yet. We are still catching up.
So the "free" version of Java is incomplete.
The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system. Then if you use a Java feature or library that free software does not yet support, you will find out straightaway, and you can rewrite that code immediately.
And he wants developers to write Java targetting this crippled "free" version instead of the official Sun compiler.
Here's an idea FIX THE DAMN "FREE" COMPILER. There's nothing wrong with the Java code people are writing - it's the incomplete "free" compiler that's the problem.
I am the maverick of Slashdot
What's scary is that you are freakin' serious. First off, there's nothing similar to Java that runs faster at raw performance numbers (method calls/second, numerical speed, GC). Python is much slower in that respect. Even the leading Smalltalk implementations are 1/4 the performance of Java at object-oriented benchmarks like method call overhead. Smalltalks are similar to Python in being dynamic object-oriented languages, but have had a LOT more optimization work done. Microsoft does everything they can to prevent non-funded C# benchmarks from being released, but even their C# is significantly slower performance-wise in running "managed code" (mono is a non-contender).
You're right that Python can be faster, mostly at scripting, because of using native code in more direct ways, but for something like OO.o where there is a LOT of code and quite a bit of math (laying out all that data, updating spreadsheets) realistically a pure-python implementation would probably be around 1/20th the speed of a Java one. FYI, Python runs significantly faster than Jython/JPython because the Java virtual machine is not designed for dynamic ("message passing") form of OO... but running the quivalent code in Java and Python, and Java will be the clear winner.
And oh yeah you think Mono is faster because the Language shootout says so? Or Java is slow? Take for example the word-counting benchmark for C, C#, and Java. Notice that the Java version uses the system locale's definition of whitespace where as the C# version hard-codes checks against space, \n, and \t? Or that the C version uses freaking table of sums to avoid branching? Under the hood Java is doing three method calls, an &, and a compare is almost as fast as Mono doing just 3 simple integer comparisons. Not that the language shootout is even fair... for instance it should compare throughput by increasing the number of iterations until it takes more than a certain time (so if C is 5x faster on a benchmark it does 5x more iterations). When even this minor scripting is too difficult to do it doesn't inspire much confidence in the results. Without this change they have lots of granularity errors and measuring of startup time on the fast end.
So yeah mod me down because this is a rant... but I'm just tired of the ignorant repeating over and over that Java is slow, when it's really the fastest of its kind.
Notice the sun.* packages in that API doc you link to? No, me neither. Oh wait, that's because THEY'RE NOT THERE
I am trolling
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.
1) The JRE is NOT freely redistributable. Therefore I can't legally add it to my OOo CD's that I pass on to customers and I have to make them download it first.
This is an utterly uninformed statement. The JRE is indeed freely redistributable.
The whole point of the JRE is to allow developers to ship a runtime environment with their products, should a customer require it. If it were not freely distributable, few would develop for Java because there would be no guarantee that a customer would wish to download the JRE separately.
Regarding adding the JRE to OOo CD's that you pass on to customers, some people have done just that; google for this and you will find examples of people adding a JRE folder to the OOo iso.
Why would Sun restrict the distribution of JRE along with OpenOffice.org? It would be shooting themselves in the foot.
it's = "it is"; its = possessive. E.g., it's flapping its wings.
1) The JRE is NOT freely redistributable. Therefore I can't legally add it to my OOo CD's that I pass on to customers and I have to make them download it first.
1) this is bullshit.
2) this is wrong.
3) this is FUD.
4) Sorry to say that
Why? Why do you think, there is a JDK and a JRE? Hm? Wow
Every software based on Java, to be bought on CD or DVD has an JRE bundled
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.