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
_______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
