Some pointers to things useful for Free Java.
- gcj, of course
Crypto provides javax.crypto support
- Jessie provides
JSSE support, aka javax.net, javax.net.ssl, and
Fitzsimmons' JHBuild for gcj and friends.
- Jipsi (site
in German) provides a CUPS back end for javax.print
- Jacorb or OpenORB for CORBA
- Java-Gnome is
nice java bindings for Gnome APIs
for running applets in Mozilla and elsewhere
- rhug has a
little bit of everything, all nicely pre-packaged for use with
- Java LDAP
bindings. There's also some from
Mozilla, and an
abandoned Java LDAP server on sourceforge.
This is one piece of the webstart puzzle -- a way to run java
applications directly off the web. Anthony has an implementation
javax.jnlp to go along with this. It turns out
there are a couple more of these: Java URL (no URL handy) and netx. netx might be
the best one at the moment; it has a comparison page. The
OpenJNLP page has pointers to some webstart programs, which would
be useful for testing.
Some Mozilla stuff I haven't really investigated:
an XPCOM/Java bridge.
- JRex, a way to embed
Mozilla in a Java program.
Some cool projects I'd like to see:
- Fix up gjdoc not to be so slow. Make it work with Ashkelon.
- Enhance java-gnome to let you write panel applets in Java.
Ideally, go one step farther and let them run in a secure
context, and let the user drag-and-drop jar files from Mozilla
onto the panel
- Write a GConf
back end for java.util.prefs. Better yet, use UniConf.
- Update Classpath to use the URL providers in inetlib by
- A Swing plaf that can read
Gtk theme files.
- A nice Java wrapper for gstreamer. The
existing bindings don't appear to be complete yet.
- An implementation of
works with gstreamer
- A Java wrapper for DBus (AIUI java-gnome has this now)
- A plugin for eclipse that teaches it how to use libgcj as a
target VM. Ideally we would be able to develop some parts of
libgcj directly in eclipse.
- We could make it simpler for folks to write native methods
which just map some C library API. We would do this by having a
"linker" class that would know how to use libffi to make stubs
which wrap the functions in question. Then this could all be done
dynamically. For libgcj we could have a special flag and
implement a different sort of call, so that we wouldn't even need
the stub in some cases and could just put a pointer to the C
function into the vtable. Take a look at GDirect
if you're interested in this.
- Would it make sense to write a javax.naming back end for
GConf? For Java LDAP it would certainly make sense.
- A JDWP implementation for libgcj. One way this could work is
by wrapping gdb and using it to do the difficult parts of the
org.eclipse.cdt.debug.mi.core plugin from
Eclipse would be useful here -- it is relatively independent of
the rest of Eclipse, and can be used to drive gdb
programmatically via MI.
- Have Classpath javadoc link directly to JExamples.com.