Linked by Thom Holwerda on Thu 10th Aug 2006 16:28 UTC, submitted by Mark Wielaard
Java This is the first release that has a full graphics 2D implemenation based on Cairo enabled by default. This enables the use of applications like JEdit, FlickrBackup and JFreeChart out of the box. See Screenshots of CairoGraphics2D in action. Also new in this release is the inclusion of an applet viewer and plugin that can be embedded in webbrowsers or other applications. It works on any platform supported by the various runtimes based on GNU Classpath, including 64 bit architectures. Lots more improvements, like better gnome integration, are mentioned in the release announcement.
Order by: Score:
sweet
by spikeb on Thu 10th Aug 2006 17:12 UTC
spikeb
Member since:
2006-01-18

they're making nice progress to enable most of us to run free software runtimes, even for our browser applets

Reply Score: 3

Lots of information, little details
by fretinator on Thu 10th Aug 2006 17:16 UTC
fretinator
Member since:
2005-07-06

I read all the pages, but I still can't tell the only question most of us end users want to know - is there a plugin for Firefox?

Reply Score: 1

Eugenia Member since:
2005-06-28

Yes, it was included in the new FC6 test version. It is brand new though (possibly extremely buggy/incompatible as of yet).

Edited 2006-08-10 17:23

Reply Score: 1

fretinator Member since:
2005-07-06

Buggy is OK, I'm just hoping for the ability to deploy a completely free Java on some machines I'm starting a small business (besides my day job as a programmer) selling used Linux and BSD laptops. Also, every step closer to usabilty puts more pressure on Sun, who will have to either actually open-source java or risk insignificance. I know they have verbally committed to doing so, but talk is not action. A little more pressure helps.

Reply Score: 1

evangs Member since:
2005-07-07

Also, every step closer to usabilty puts more pressure on Sun, who will have to either actually open-source java or risk insignificance.

The logic of that sentence escapes me. How will this spur Sun to open source Java? It's like saying Mono will put pressure on MS into open sourcing the .NET framework.

Reply Score: 1

fretinator Member since:
2005-07-06

And I'll exlain. If VERY good free implementations of Java arise from the OSS world, eventually they could become the standard. For instance, if all the apps I currently am developing could be built and run using GCJ/CLasspath, then I wouldn't need Java. If all the major software ran on a free alternative, why would anyone use the closed-source java. If we ever get to that point, then I agree that opening Java would do not good for Sun or anyone, because it would have become _insignificant_. Thus, Sun should open Java _now_, when it is the best game in town. If that were to happen, I do not see why anyone would use very imperfect imitations like GCJ/Classpath. Only research projects who wanted to implement some personl extenstion to Java perhaps. Rememver, if Sun opens Java, they still have the exclusive right to call it Java. Other would be creating forks, which I for one would not be interested in using.

Reply Score: 5

evangs Member since:
2005-07-07

The problem is that Classpath and the free alternatives will always be playing the catch up game. Sun's Java is a moving target, take for example how long it has taken classpath to achieve 100% JDK 1.4 compatibility? Even after JDK 1.4 has been released for 3 years, we still do not have 100% compatibility. Let's not even start with JDK 1.5, and 1.6 that will be released soon.

In theory, Classpath provides a threat to Sun Java. However, it suffers from the same problem projects like Wine and Mono: they are always playing catch up. That's not to say they won't be good pieces of software, just that they will not threaten to make the originals insignificant.

Reply Score: 1

JeffS Member since:
2005-07-12

"In theory, Classpath provides a threat to Sun Java. However, it suffers from the same problem projects like Wine and Mono: they are always playing catch up. That's not to say they won't be good pieces of software, just that they will not threaten to make the originals insignificant."

Hit nail on head, with that comment.

I'm very interested in a successful gcj. It's nice that you can compile it to machine code. It's also nice that it integrates with the rest of gcc and GNU make.

However, for general Java usage, I won't use gcj/classpath. Why would I use a 95% implementation of Java 1.4 when I can just as easily use a 100% implementation of Java 5, right now? And with Sun putting out a new OSS friendly license (for Linux distors and BSD to distribute Sun Java JRE/JDK more easily), it's now a plain no brainer to just use the full featured, up to date, standard Java, rather than a crippled, obsolete implementation.

But as for Mono, there is a value add proposition, that makes using it over standard MS .Net worthwhile - it's actually cross platform, and it wraps around GTK.

Reply Score: 1

robilad Member since:
2006-01-02

Like Linux, gcj/gnu classpath provides certain benefits to those that have a need for them. It is a better implementation of many of the standard Java APIs in the sense that it's often more efficient, integrates more closely with the GNOME desktop, is cross-platform/cross-vm, and in general breaks Java code out of the JVM box by providing efficient ways to reuse such code in pther environments like dynamic languages via gcj/swig, or .NET via IKVM.

Obviously, that won't matter for the majority of users, in the same way how the one specific year of Linux on the desktop never comes. Otoh, we're now covering 99,35% of 1.4, and 94.62% of 1.5 APIs, and that, along with the ubiquity of free runtimes based on GNU Classpath, has positively influenced the thinking at Sun about licensing, cooperation opportunities, and future of Java, in ways that would not have happened without the community putting their energy behind developping GNU Classpath, rather than demanding that Sun does their bidding using open letters.

People (not associated with gcj/gnu classpath) have been in various forms demanding of Sun to make their Java implementation distributable under an OSS friendly license for more than five(5) years, but only after OpenOffice.org and Eclipse were in most distributions running on top of/with gcj/gnu classpath did Sun realize that indeed there was a legitimate demand for Java to be redistributable under more liberal terms, and then they made the licensing changes that allowed them to meet that demand.

So, really, everybody wins by having GNU Classpath as a strong, vital project: those of us who need its benefits, and those of us who don't, and prefer to use something else.

FWIW, GNU Classpath is even used in Mono's deveopment tools collection via IKVM. ;)

Reply Score: 2

sigzero Member since:
2006-01-03

Also, every step closer to usabilty puts more pressure on Sun, who will have to either actually open-source java or risk insignificance.

What?! That is crazy. Nobody I know is going to risk enterprise class system on Classpath. They are going to stick with Sun's Java because that is the standard.

That being said, I don't think there will be "fork" as Sun fears.

Edited 2006-08-10 18:51

Reply Score: 1

fretinator Member since:
2005-07-06

Nobody I know is going to risk enterprise class system on Classpath

Perhaps, but it is worth noting that projects such as Eclipse, Open-Office (for the Base component), JEdit and others do quite well using GCJ. What if project Harmony, which backing from industry heavyweights such as IBM did even better? Also, you're assuming that the OSS philosophy won't gain traction in the Enterprise world. I'm not sure you're correct.

Or maybe it's just my version of FUD so I can get a OSS plugin to work in Firefox!

Reply Score: 1

hashnet Member since:
2005-11-15

It's one thing to run Classpath on your own desktop where you can switch back to Sun's JDK or even fix things yourself, and is perfectly fine.

Now if you are running a business that need java apps *online*, you may want to lower your risk. That's what shareholders expect from you. A strategy is to get your platform from a vendor with support contracts. You could also hire people whose job are to certify a platform for use with your applications.
The first option is often less costly.

Classpath will get adoption only when there are companies that offer support for it.
Red Hat did just that for Linux (RHEL).

On the other hand, Classpath is a boon on the platforms where Sun does not offer a JRE, like some embedded systems. That's where Classpath is invaluable.

Edited 2006-08-11 04:57

Reply Score: 1

mark2 Member since:
2006-08-10

(possibly extremely buggy/incompatible as of yet).

The version in Fedora Core 6 Test 2 is still a bit preliminary. But it shouldn't be extremely buggy/incompatible. It has been tested against a lot of applets out there:
http://developer.classpath.org/mediation/Applets

The biggest missing feature is LiveConnect between the applets and javascript on the html page. Please do report any bugs/issues you find so they can be fixed quickly:
http://www.gnu.org/software/classpath/bugs.html

Reply Score: 2

Hmm, jEdit not working here...
by DrCurl on Thu 10th Aug 2006 19:01 UTC
DrCurl
Member since:
2006-01-17

I build this release of Classpath on ubuntu with gcj. Then I installed jEdit with the java installer (which worked great).

JEdit don't work though, here is what I get:
(.:27743): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()
[error] AWT-EventQueue-4: java.lang.InternalError: Pango: Invalid UTF-8 string passed to pango_layout_set_text()
[error] AWT-EventQueue-4: at java.la
[error] AWT-EventQueue-4: ng.reflect.Constructor.newInstance(libgcj.so.7)
*** glibc detected *** double free or corruption (!prev): 0x081f1768 ***
Aborted

Too bad, was loving the antialiasing in the installer ;)

Reply Score: 1

RE: Hmm, jEdit not working here...
by mark2 on Thu 10th Aug 2006 19:42 UTC in reply to "Hmm, jEdit not working here..."
mark2 Member since:
2006-08-10

I build this release of Classpath on ubuntu with gcj. Then I installed jEdit with the java installer (which worked great).

Too bad, was loving the antialiasing in the installer ;)


The integration with cairo and pango does indeed look very nice.

gcj itself needs to be updated, which is now work in progress:
https://www.redhat.com/archives/fedora-devel-java-list/2006-August/m...

But either jamvm
http://jamvm.sf.net/
or cacao
http://www.cacaojvm.org/
should work out of the box when installed in the default locations.

If you want mono.net integration check out ikvm (which might not support the gui parts yet): http://weblog.ikvm.net/

Reply Score: 2