On Tue, 10 Nov 1998, John Keiser wrote:

> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Brian Jones
> >
> > "John Keiser" <[EMAIL PROTECTED]> writes:
> >
> > > Some sort of scheme that checks which classes are
> > package-private will help
> > > even more.
> > > We really should create a "compliance file" or set of files by
> > running some
> > > variant of javap on Java's public and protected classes, and
> > their public
> > > and protected members.  Then we run that same program on our
> > stuff and we
> > > discover any methods and fields we're missing, too.
> >
> > I'm mainly interested in having something to easily let us know that
> > we've done the following:
> >
> > a) implemented the public classes
> > b) implemented all their public functions and constructors
> > c) implemented all their public data
> >
> > Package and private data, classes, and functions are probably
> > irrelevant since those are inaccessible outside of the package or
> > class anyway.
> >

Native does not matter but synchronized sure does. If people are using
things like java.io.PrintStream (for System.out or something) and the
JDK versions are synchronized but the classpath versions are not, that
would be a big problem. Is that what you meant?

> Change "public" to "public and protected," and we're agreed.  That would be
> really good to have.  Do you know if javap will generate the correct stuff?
> We need "native" and "synchronized" keywords removed, among others, since
> they don't matter for compatibility.
> 
> > > I'm curious: does everything that we have compile now (except
> > security of
> > > course)?
> > > --John Keiser
> >
> > There are problems with java/util as mentioned on the list which
> > someone needs to work on since I think those previously working on it
> > are tied up with other things at the moment.
> >
> > I think there are also problems with java.text and java.security, but
> > those are incomplete and we know it.
> >
> 
> Is there a way to take security out of the dependencies build for now?  Or
> would that be a serious pain in the arse?  All java/security files would be
> removed, as well as a few security classes in java.net (NetPermission and
> some kind of AccessController or something), and java.io.FilePermission.
> 
> > We really should get java.lang finished.  I don't think Paul is
> > working on this now.
> >
> 
> I was under the impression he was working on Double and Float, at least,
> which, since they are missing, are the source of many of our runtime
> problems.
> 
> > I finished all those 1.2 exceptions and error classes for java.lang
> > and also made them serializable (I think) including serialVersionUID
> > for every single one of them.
> >
> > If you want a list of errors I'm getting while compiling right this
> > very moment...
> > <snip>
> 
> Thanks.  Now that my work on Japhar integration is winding down, I'll make
> some time to fix the errors you were talking about.
> 
> We still need the remaining java.util, java.lang, java.util.zip and
> java.util.jar classes, though.  Hint hint, for those of you reading this. :)
> I think someone was working on java.util.zip, is that project still going
> on?
> 
> --John Keiser
> 

Reply via email to