> From: Aaron M. Renn
> Subject: Excellent News About java.io
>
> I have started the coding spree I said I was going to go on. I think
> java.io is ready for our first release. I have made the
> following changes:
>
> -- Fixed broken HTML in javadocs
> -- Updated for complete Java 1.2RC2 spec conformance (excepting
> serialization (Geoff Berry's baby) and a couple items I felt
> absolutely had to be included despite non-conformance)
As I think we told Stuart, those items you're talking about (overriding a
method when the spec doesn't override) are entirely OK to do. Spec
compatibility means conforming to the APIs, period.
> -- Fixed a couple of bugs
> -- Re-ran all tests with the latest Japhar from CVS. Everything ok.
>
> Some things remain untested. Nevertheless, all modules compile and the
> basics seem to be working alright. Building things remains the big
> problem. I am still compiling the Java by hand and the native
> code must be
> hand linked.
>
You shouldn't need to compile the Java code by hand ... the build process,
while not complete and wonderful, seems to be working pretty well. I got
401 classes out of it at last count, and that included (as far as I know)
all of java.io as of a week ago.
What do you mean, hand link the native code? Hand link to what? Japhar?
> John, you said you were using my java.io for your testing, but I highly
> doubt that is the case. The native library build succeeds fine,
> but due to
> a lack of interlibrary dependencies in libtool (possibly
> corrected now), it
> crashes on an undefined symbol at runtime.
This mystifies me given what you say. I definitely loaded the "javaio" lib
in the patch. I never had problems linking or compiling. "Hello World"
worked fine.
I can assure you, though, that I was using your java.io, because at one
point I was having problems with Japhar and then I put a little hack into
one of those files (PrintWriter.java, I think) and it worked fine. The fact
that it worked different after I hacked it was a sign it was definitely
using your java.io (at least in part). Any native code it used *had* to be
yours, since it was only loading your native library and not Japhar's.
> Additionally,
> FileDescriptor had
> a bug that was exposed by the latest Japhar which caused JVM symbol lookup
> errors.
>
It is possible that the symbol lookup errors you're talking about have to do
with (a) stubs or (b) a conflict with the native io lib Japhar loads, which
my patch commented out.
> Another issue is that the native routines still use functions in
> John's JCL
> common library that I don't know if we still are officially using. I'm
> talking the method/field id caching and JCL_jstring_to_cstring.
>
I think we need to evaluate the usefulness of the caching procs. I no
longer regard it as giving extra functionality, *ever*, but as a macro it
may be useful. It's been so long since I've messed with it that I don't
really know--you would actually be a better judge than any of us, I think,
Aaron, having used it more than most.
Other things, like jstring_to_cstring, we should probably still use. Common
libraries are generally good things.
VMI is entirely deprecated, as far as I know. None of us are using it,
right? I don't think I even loaded it into Japhar.
> If anybody wants to test with java.io, let me know and I'll put
> up a tarball
> with compiled Java classes and instructions on how to build the native
> code. (You need to link and install the native shared library by hand).
>
> Next up, I need to get java.net in shape, then I'm going to focus
> on either
> the build process or Japhar integration or whatever else needs help.
>
I'm impressed. Nice going.
--John
