Re: [cp-patches] Merge from generics -> HEAD

[Andrew John Hughes]

On Mon, 2005-02-21 at 18:56 +0100, Mark Wielaard wrote:
> Hi,
> 
> On Mon, 2005-02-21 at 00:04 +0000, Andrew John Hughes wrote:
> > I'm committing the attached patch to merge some simple
> > classes that currently reside only in the generics branch.
> > These are mainly just marker interfaces and exceptions.
> > They compile fine in the HEAD branch (no 1.5 features -- they
> > compile fine with jikes and gcj 3.3.5) and are functionally
> > simplistic.
> 
> How much sense does it make to add these classes when they are normally
> only used together with features we don't support yet? If there are real
> programs out there that use these and are usable with the addition of
> these classes I am all for adding them. But if not I am not sure we
> should add extra classes/interfaces that people will not currently use
> to the trunk.
> 
> Cheers,
> 
> Mark

Couple of points:

* My view of the generics branch (correct me if I'm wrong) is as a
branch for classes which use language features (one of the main ones
being generics) new to 1.5.  These classes can't be added to HEAD,
because the majority of compilers still won't compile it (including gcj,
jikes and kjc).  This is a more limited category than 1.5 API support,
which also appears to have started turning up on this branch.  As far as
I'm aware, 1.4 and previous versions didn't have separate trees, and the
only reason for one here is that the code on the generics branch is
uncompilable with a lot of current Free compilers.  If that is what is
wanted, then that's fine, but can this be made explicit (doing so could
also be really messy, as some changes are simply new sets of methods for
existing classes, and some of these are already on HEAD).
* From an administrative standpoint, merging the stuff that can be
merged simplifies things and brings the branches closer together.  At
some point in the future, these classes will be on HEAD anyway when the
branches are fully merged.  If they may prove useful on HEAD (see
below), and be more widely tested, in the meantime, this seems to make
sense to me.
* The usefulness of some of the files is dubious, I'll give you that,
but not all, and I can see a use without the remaining changes, for all
of them.  It's also a case of what we will start to see in the coming
months -- I don't see the generics branch being fully ready for trunk as
early as there will be more extended use of this code.

- java.io.Closeable, java.io.Flushable
These are simply used to mark our existing I/O classes as containing the
methods.  Doing the marking (still pending) doesn't even require any
real implementation work (as the methods already exist).  In code, these
gives you another level of generic support around the I/O classes, and
there's no reason that external code wouldn't use these classes for its
own I/O.
- java.lang.Readable
The inverse of Appendable, which was already added to HEAD for
StringBuilder.  Same reasoning as the last; external applications may
want to define Readable classes.
- java.lang.TypeNotPresentException
- java.annotation.AnnotationFormatError
- java.annotation.AnnotationTypeMismatchException
- java/lang/reflect/GenericArrayType.java: Likewise.
- java/lang/reflect/GenericSignatureFormatError.java: Likewise.
- java/lang/reflect/ParameterizedType.java: Likewise.
- java/lang/reflect/Type.java: Likewise.
- java/lang/reflect/WildcardType.java: Likewise.
These handles run-time bytecode level use of the new constructs.  The
first thing that comes to mind is the building of applications that
parse Java bytecode (JAPI, javap presumably, etc.) which may throw some
of these errors in parsing.  They also allom JVM developers to start
looking at adding support.  Again, the interfaces can also be used by
the user for other purposes.  Type, for example, is simply a marker,
which we would already be able to apply to java.lang.Class.

A lot of this depends on what kind of stuff we will see in the future,
and having them in trunk at least shows clearly that we are working
towards supporting this stuff, even if it is not yet complete.

On the topic of the generics branch, I'd be interested to know if anyone
has managed to use the compiled branch with any existing VM.  I've tried
to use it with JamVM, but I get failures in java.lang.Runtime (which
further debugging shows to be a problem with SystemProperties -- any
guesses from someone who knows more about the bootstrap process would be
greatly welcomed).

Anyway, that's my reasoning, and this patch makes the generics branch
just a representation of our implementation of the new constructs (enums
and generics, mainly for now).

-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

No software patents in Europe -- http://nosoftwarepatents.com

"Value your freedom, or you will lose it, teaches history. 
`Don't bother us with politics' respond those who don't want to learn." 
-- Richard Stallman

"We've all been part of the biggest beta test the world has ever known
--
Windows" 
-- Victor Wheatman, Gartner

signature.asc
Description: This is a digitally signed message part