OpenOffice 2.0 Criticized on Use of Java 805
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."
Code is still open, though, right? (Score:2, Informative)
Re:If you'll pardon my French (Score:2, Informative)
2. RTFA, the major problem is that they're using undocumented sun-only features, almost as if they're deliberately breaking it on Kaffe etc.
I do leave it alone and use KOffice, and I try and encourage others to do the same. One way to do so is tell people about the problems with OpenOffice. Because make no mistake, these are problems.
Re:If you'll pardon my French (Score:1, Informative)
It doesn't matter that java is free beer or that Sun had to pay for OO.org. You are missing the point. The complaints are because it will be detrimental to the OO.org progress to use a dependency on a non-free (as in speech) application. Its use in OO.org makes it impossible to redistribute a fully functional officesuite since java cannot be freely distributed. And kaffe and gcj cannot (yet) handle all the new java stuff in OO.org, although projects are underway to address this. In addition, it's possible that OO.org will only partly work on platforms for which no complient java exists (Currently Sun as no 1.4.x jre for my ibook running linux, although perhaps OO.org will run using IBM's jre).
I think the people who are complaining are doing a good thing. It is not productive at all to have such dependencies on a closed language, its much worse as what linus did. You at least didn't need to install bitkeeper to use all the features of your kernel.
Re:Use of Java (Score:5, Informative)
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 [slashdot.org]) then you're no longer allowed to use your own software. You can't build Free Software on a non-Free foundation.
How OO.o and BK connect (Score:4, Informative)
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
Re:It's not GPL'ed either! (Score:3, Informative)
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.
Re:Use of Java (Score:3, Informative)
The problem Sun had with Microsoft's Java was that Microsoft was giving access to Win32-only API's, so that the source that used them would run only on a platform that supported Win32. Sun accused them of attempting to take a language they had worked hard to make platform independent, and tie it directly to Win32.
If Microsoft was making extensions that were useful and didn't need Win32 to implement, my guess is that Sun wouldn't have been so upset about it.
The analogous problem would be if Sun implemented stuff that would only work under Solaris. The JRE works on all of the platforms it's released on (at least it's supposed to).
Nothing I've read about the Sun Only extenions are inheriently unimplementable by anyone else on a standard Java platform. When they refer to them as Sun only. I'm guessing it's an API that Sun is working on standardizing, but wants to make it available for use to shake out defects in the API. That, and/or its so new that no one else has had time to implement it.
Kirby
Re:It's not GPL'ed either! (Score:3, Informative)
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...
Umm, it's been fixed to compile under GCJ... (Score:5, Informative)
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 [gnu.org] 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.
Re:If you'll pardon my French (Score:5, Informative)
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.
Re:Point of order... (Score:5, Informative)
Whether they say it in the article or not, it happens to be the case. Here [debian.org] 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 Anyone? (Score:4, Informative)
Non-Free = Less Portable (Score:2, Informative)
If you think that the Java license is not a problem, try running Java apps on a non-Intel Linux platform such as linux/ppc. Sun does not make a JRE for linux/ppc so the choices come down to IBM Java (which is also non-free, crashes frequently and does not support the 1.5 spec), Blackdown (which is non-free and seems to be stalled at 1.3), and the free JREs such as Jikes which will always be behind the curve as RMS points out.
These problems are not incidental. They're a necessary consequence of the non-free license. Fewer developers are allowed to work with the code. This lack of resources directly translates to less portability. It also lengthens the bug fix cycle, slows the adoption of new features, and places supreme power in the hands of the copyright holder. If you require big changes to a free software product, you have the power to make those changes or hire someone else to make them for you. If you require big changes to a non-free product, you're at the mercy of the copyright holder.
In the case of Java, the source is not as open as Sun would like you to believe. Parts of it are open. Other parts are locked away in binary files. You need an existing Sun bytecode compiler (on a platform supported by Sun) to build Java from source. This necessarily precludes porting it to other platforms without assistance from Sun. This is why the folks at blackdown needed to sign special agreements with Sun before they were granted access.
I love Java. It's quickly becoming my favorite programming language, but I also have to agree with RMS that the license is problematic. Great language. Dangerous platform.
Militant Bullshit (Score:3, Informative)
I got into Linux because I wanted Unix at home. Not to rape and pillage the unbelievers. If we're getting to a point where I have to live by the Purer Faith, so to speak, just to use software, I'll head to BSD land. Because while I think the open source method is very, very cool, and will revolutionize software (in truth, it already has), I'm getting tired of the militants lecturing me about what I choose to put on my computer. I didn't sign up for that.
Re:And what would be better? (Score:1, Informative)
First, Perl gives the programmer many different constructs for doing simple tasks instead of just one. If there is only one way to do it, that way will be used in all code that gets written, not just all code you write. This makes it easier to read.
The second reason is how tightly Perl has integrated regular expressions. Without detailed comments, anything beyond a basic regular expression is write-only.
The last reason just has to do with the context in which Perl is an appropriate language to use. Perl tends to be used for relatively simple text processing applications which tend to be developed quickly without much concern for code maintainability.
Re:Runs fine, right? (Score:1, Informative)
Re:It's not GPL'ed either! (Score:3, Informative)
Re:It's not GPL'ed either! (Score:4, Informative)
Re:Java = write once, run everywhere = good for OO (Score:4, Informative)
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
There is no controversy (Score:2, Informative)
OO.o helped out getting rid of non-portable java constructs in their code.
Red Hat hackers and other fixed some gcj and classpath bugs revealed by OO.o.
Now it all works.
Redhat had OO.org 2.0 RUNNING using gcj... (Score:2, Informative)
Article is not well researched, and sounds like scaremongering.
classpath (Score:5, Informative)
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 [gnu.org].
Actually, GCJ 4 is one of the GCC 4.0 greatest features, here is an article [lwn.net] 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
Re:If you'll pardon my French (Score:5, Informative)
There is code in OOo which uses com.sun classes. Quite a lot of it.
Caolan McNamara [linux.ie] 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!! (Score:5, Informative)
Red Hat is paying people to support OOo 2.0 with GCJ. And GCJ 4.0 is already quite good... [lwn.net]
Re:It's not GPL'ed either! (Score:5, Informative)
From TFA:
So, no. It will never be zero, and it's currently 100% usable without a JVM.
Doug
Stallman - what a nut job (Score:4, Informative)
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.
Java is fastest language of its kind (Score:3, Informative)
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 [debian.org], C# [debian.org], and Java [debian.org]. 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.
Re:If you'll pardon my French (Score:4, Informative)
Re:Stallman - what a nut job (Score:1, Informative)
If you don't want to do that, make a contribution to the FSF so that they can hire more programmers to address this issue.
There are a lot of ways you can make a positive difference.
Re:It's not GPL'ed either! (Score:5, Informative)
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 [sun.com]? And maybe you'd want that standard to be implemented [lancs.ac.uk] on PocketPC machines?
Wait, it gets better. You can also find a full java implementation [blackdown.org] (Java 1.3) for iPAQ.
If you want something in between, there's also PersonalJava [sun.com]. 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.
Re:Maybe, they would prefer to wait (Score:3, Informative)
Looking at your website, you offer a script for "automating FTP opertions [sic]". I rest my case.
Re:It's not GPL'ed either! (Score:4, Informative)
This is an utterly uninformed statement. The JRE is indeed freely redistributable. [sun.com]
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.
Re:It's not GPL'ed either! (Score:4, Informative)
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
Re:It's not GPL'ed either! (Score:2, Informative)
in suns java theese are in the package sun. and if you use such classes then you can end up with jvm specific java code.
Re:GCJ Anyone? (Score:3, Informative)