Here's the latest installment in what's up with Aaron. For those doing
active development, I encourage you to post a message to the list every
couple weeks or so to keep everyone up to date with what is going on. This
is my attempt to comply with my own advice.
I have been plodding away at java.io and am nearing completion. I just made
a massive checkin of virtually all of the 1.1 classes. The package is not
hard, it is just big. Very big. A wc report (which of course includes
copyright notices, comments, documentation, blank lines and even actual
code) shows that my portion of java.io alone (including all internal
classes, test scripts, and native code) is over 23,500 lines, consuming
nearly 700,000 bytes. That's enough to give a man cobol fingers. And that
doesn't even count Geoff's serialization implementation, which ain't
trivial.
Stuff left to do:
-- StreamTokenizer
-- Misc unimplemented methods
-- Additional character encodings. In particular, UTF-8 is required by
the spec. I may add a number of 8-bit encodings because they are trivial
under my setup.
-- There are a couple of 1.2 permissions classes I might implement if I am
bored.
Everything comes with complete javadoc comments and a test program. For
those of you who need raw access to the character encoding classes (Paul,
your name comes to mind immediately for String.getBytes()), they are in
gnu.java.io. I have an EncodingManager class that has convenience methods
for retrieving information. Right now I have only implemented 8859_1
(Latin-1) encoding. I set things up so that anything which uses an 8-bit
encoding scheme with 255 characters is trivial to implement. All you do is
set up a lookup table in your subclass and I take care of the rest. Better
than javadoc comment documentation should be written at some point, once my
approach is proven beyond a single encoding. (Heck, I might prove myself
bogus just doing the UTF-8 stuff).
If anyone is interested in trying out java.io, that won't be possible
currently. This is for a number of reasons. First, it requires that
java.lang.reflect.Constructor.newInstance() be implemented, which it is not
in Japhar. Keiser's implementation (which I checked out recently) contained
a comment that it had never been tested. So I just hacked up Japhar instead
to work for the 2 cases I needed it to. Second, compiling is a difficulty.
guavac builds things no problem. Things get ugly with javac. For some
reason I have not yet figured out, the JDK doesn't like my java.io
implementation. My current suspicion is that the JDK relies on the
internals of java.io.FileDescriptor and mine is not compatible with the
JDK's expectations. Everything worked fine under the JDK until I wrote that
class (and other associated File* classes).
Since I need my own classes in the classpath for compilation purposes, and
javac is written in java and thus relies on java.io - my non-working under
the JDK java.io - javac bombs bigger than life trying to compile the java.io
code. I've yet to develop a good fix for this yet. I'm reasonably
confident that a combination of parameters and an appropriate classpath
setting will make this work. That might be a weekend project.
Speaking of guavac, it is a great, super-fast Java compiler available under
the GPL. No need for Sun's proprietary and slow crap. You can download it
from http://www.cs.berkeley.edu/~engberg/guavac/
Speaking of fast compilers, there were several postings on slashdot.org over
the last couple weeks about the Jikes compiler from IBM. This compiler is
as proprietary as can be and I encourage everyone to avoid it.
The third reason for my build woes is that libtool refuses to link my
library against any other objects. Thus, using libtool to build the shared
library causes undefined symbols. I've been linking with raw ld to get
around this. If anyone has a good solution to inter-library dependency, let
me know please.
Speaking of Japhar, I highly advise that people working on JCL test their
code with Japhar, being as that is our first target platform. A couple of
pointers. First, if you have any native code, it must be in a library
called libjaphar_whatever.so, not libwhatever.so. Put it in
/usr/local/japhar/lib and all should be well. Plus, Japhar needs stub
functions for all native methods linked into the library. You can generate
these with japharh --stubs.
I was going to work on finishing up java.util when I got done with io. But
I seem to recall someone recently said they were working on that. Please
say something if you are. Otherwise, I'll pick something else like
java.util.zip.
That's all for now.
--
*****************************************************
* Aaron M. Renn *
* Email: [EMAIL PROTECTED] *
* Homepage: <URL:http://www.urbanophile.com/arenn/> *
*****************************************************
