java.util: I thought another group from outside had a stable
implementation of that stuff, didn't they contact us a while back?
Maybe there was a licensing issue or something. I was going to move on
to java.util, but if you want to work on it, go ahead (I'm just doing
whatever isn't done); I think I will move on to RMI when I finish Beans.
--John Keiser
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
> M. Renn
> Sent: Friday, July 31, 1998 11:01 PM
> To: [EMAIL PROTECTED]
> Subject: What's Up with Me
>
>
> 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/> *
> *****************************************************
>
>
