Hi Folks, James and I discussed about Generic support in DOM4J lately. Here is a critiqual opion posted at com.lang.java.programmer. Maybe we should consider that when we decide to work with Generics. Regards Toby "Jorn W Janneck" <[EMAIL PROTECTED]> schrieb im Newsbeitrag news:<YKjT6.66898$[EMAIL PROTECTED]>... > hi everybody. > > as you may or may not have noticed, the jsr (java specification request, > i.e. a proposed extension to the java language) concerning the addition of > generic classes is in public review. > > i think those of us who are going to use this language in the future may be > interested in exerting whatever little influence we have on the process, > because in my view that the current proposal is a very big mistake, and once > accepted will not only adversely affect the expressiveness of the java > language, but maybe even more importantly further distort the public view on > what generic types are and can be (pretty much like c++ templates did, whose > defects dominate the vast majority of discussions on the issue). > > so in a sense this can be an important juncture in the design of the java > language, and i would like to encourage you to take an active interest in > the issue. for starters, you will probably want to review the current > proposal itself: > > http://jcp.org/aboutJava/communityprocess/review/jsr014/ > > then you will want to check the orginal request: > > http://jcp.org/jsr/detail/14.jsp > > the current proposal has a lot in common with GJ (generic java), which can > be found here: > > http://www.cs.bell-labs.com/who/wadler/pizza/gj/index.html > > a critique of GJ, and a prototypical alternative (albeit in an outdated > version of java) can be found on the PolyJ site: > > http://www.pmg.lcs.mit.edu/polyj/ > > here are a few reasons why i think that the current proposal is a big > mistake: > > the original request quoted the following design goals: > > <quote> > b) Type parameters (e.g., T) should be first-class types. > (A consequence of this is that List<T> is a first class type). > By "first-class" we mean that these new sorts of type expressions can be > used in exactly the same ways as existing type expressions. In particular, > it should be possible to cast a value expression to one of these sorts of > types, and to test whether an object is an instance of such a type. > c) Reflection should recognize generic type definitions, and provide > accurate information about formal type parameters in classes, interfaces and > methods > </quote> > > it explicitly did *not* include the following: > > <quote> > It is explicitly not required that the system > > a) Provide downward binary compatibility: It is not necessary that class > files compiled under the generic compiler should run on previous releases, > whether they use generics or not. > </quote> > > the current proposal does not answer the request -- it violates the > requirements (b) and (c) above, in order to obtain (a) below. the reason is > that List<Integer> (say) is *not* a proper type, the way String is, or > Object, or Boolean [ ]. it is not represented at runtime as a class object, > and thus contrary to all other (object) types, there is no way that i can > distinguish, at runtime, an instance of class List<Integer> from an instance > of List<String> -- if i do getClass() on either object, i get the same > List.class class object. > > this has several deep consequences. > > (1) for the first time in java, an object does not carry its complete type > information around. this means that reflection is no longer complete -- the > get-method of the class of an instance of List<String> has return type > Object, rather than String (e.g.). > > (2) downcasting becomes a lot more complex. i cannot simply downcast any > Object to, say, Map<String, Integer>, because there is no way that i could > check this at runtime. the result is a set of complicated rules governing > when i can downcast to a parametric type (cf. 5.3 in the proposal). > > (3) because things compile to regular jvm code, including all its > typechecks, one of the potential benefits of generic types, viz. removing > casts, cannot be realized. the casts are removed from the source-code, but > they are automatically compiled into the bytecode. so even though the need > to type them goes away, the runtime issue remains. (even though this is not > a very big point, it *is* ugly, and small machines might very well benefit > from the removal of casts.) > > (3a) even worse though is this -- generic classes are normal java classes, > i.e. they can be used without parameterizing them. because typecasts are > implicit, we can now (for the almost first time, see 4) have a situation > where a class cast exception is thrown without a cast being present in the > source. > > (4) the decision not to make parameterized classes proper classes (i.e. > represent them with distinct class objects) is also inconsistent with the > way arrays are treated in java. arrays can be seen as a small specialized > form of generic classes, and A [] iand B [] are different classes: > A [] a = new A[1]; B[] b = new B [1]; > System.out.println(a.getClass() == b.getClass()) > > so please let us discuss this proposal here, and maybe come up with > something better. maybe we can even form a small group of people interested > in this matter, and submit our objections to sun. the closing date is august > 01, so we need to hurry somewhat. > > best regards, > > -- j > > > > > > > > _______________________________________________ dom4j-dev mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dom4j-dev
