[jdom-interest] How will JDOM be updated for Java Generics (JDK 1.5)?

[Michael Salmon]

On Sat, Jul 20, 2002 at 01:43:26PM +0000, Geoff Rimmer wrote:
> Michael Salmon <ms at formulae.org> writes:
> >
> > I do not agree with adding Generics to Java. Let me list many of my
> > reasons.
> >
> > Java is stable, changes to the syntax and use of the language
> > assumes that something is wrong with the existing language. Don't
> > fix what aint broke.
> >
> > Generics dont accomplish anything that you couldnt do with Java
> > already.
> 
> The main benefit of generics for me is the compile-time type safety;
> not only for simple types like:
> 
>     List<String>
> 
> but also for complex types like:
> 
>     Map<String,List<Map<String,String>>> map;
> 
> which you would *traditionally* iterate as follows:
> 
>     for ( Iterator iter1 = map.entrySet().iterator(); iter1.hasNext(); )
>     {
>         Map.Entry entry1 = (Map.Entry)iter1.next();
>         String key1 = (String)entry1.getKey();
>         List list = (List)entry1.getValue();
>         
>         for ( Iterator iter2 = list.iterator(); iter2.hasNext(); )
>         {
>             Map map2 = (Map)iter2.next();
>             for ( Iterator iter3 = map2.entrySet().iterator();
>                   iter3.hasNext(); )
>             {
>                 Map.Entry entry3 = (Map.Entry)iter3.next();
>                 String key3 = (String)entry3.getKey();
>                 String value3 = (String)entry3.getValue();
>             }
>         }
>     }
> 
> Now, the above code contains 7 casts which will only be checked at
> runtime.  If there are any mistakes in the casting, you might not
> found out about it for weeks.
> 
> The generics version looks like this:
>             
>     for ( Iterator<Map.Entry<String,List<Map<String,String>>>> iter1
>           = map.entrySet().iterator(); iter1.hasNext(); )
>     {
>         Map.Entry<String,List<Map<String,String>>> entry1 = iter1.next();
>         String key1 = entry1.getKey();
>         List<Map<String,String>> list = entry1.getValue();
>         
>         for ( Iterator<Map<String,String> iter2 = list.iterator();
>               iter2.hasNext(); )
>         {
>             Map<String,String> map2 = iter2.next();
>             for ( Iterator<Map.Entry<String,String>> iter3
>                   = map2.entrySet().iterator(); iter3.hasNext(); )
>             {
>                 Map.Entry<String,String> entry3 = iter3.next();
>                 String key3 = entry3.getKey();
>                 String value3 = entry3.getValue();
>             }
>         }
>     }
> 
> and if any of the parameterised types was incorrect, the compiler
> would refuse to even generate the .class file.  This is without doubt
> a major benefit for code maintenance.

There is more code when you use generics and parts like
Map.Entry<String,List<Map<String,String>>> entry1 = iter1.next();
make me gag. I don't particularly *like* C++ and I dont want Java to
start adding parts of it because people after so many years have been pushing
for it. What next, operator-overloading? (lets not even go there)

> I understand there are also proposals to introduce a 'foreach'
> construct, which would make the code look something like this:
> 
>     for ( entry1 : map.entrySet() )
>     {
>         String key1 = entry1.getKey();
>         for ( map2 : entry1.getValue() )
>         {
>             for ( entry3 : map2.entrySet() )
>             {
>                 String key3 = entry3.getKey();
>                 String value3 = entry3.getValue();
>             }
>         }
>     }

great, even more unlike traditional java and more to Perl and C++.
You know something I really like in other languages is the ability to
access and alter main memory. I strongly think we should add it to Java. 
Since we're not using the * character in the language it should fit nicely. 
What do you think?

> > It is very easy to subclass the list type you want to allow only
> > particular types of values for.
> 
> Erm, which is easier out of these two?
> 
> 1. List<Fish> fishList = new ArrayList<Fish>();
> 
> 2. public class FishList extends ArrayList
>    {
>        public FishList() {}
>        public FishList( Collection c ) { super( c ); }
>        public FishList( int initialCapacity ) { super( initialCapacity ); }
>        public Fish[] toArray( Fish[] a ) { return (Fish[])super.toArray( a ); }
>        public boolean add( Fish f ) { return super.add( f ); }
>        public void add( int i, Fish f ) { return super.add( i, f ); }
>        public Fish getFish( int i ) { return (Fish)super.getFish( i ); }
>        public Fish remove( int i ) { return (Fish)super.remove( i ); }
>        public Fish set( int i, Fish f ) { return (Fish)super.set( i, f ); }
>    }
> 
>    FishList fishList = new FishList();
> 
> You would have to write one of these classes for every new type that
> comes along.  A maintenance nightmare.  Note also that creating a
> "type-safe" List by extending ArrayList is not safe, as you can still
> bypass the "type-safe" methods you have introduced, and to call the
> base class methods instead (with the wrong types).

Firstly for a project like JDOM, how many of these classes do you suppose 
would be needed? I only can think of 2, Elements and Attributes. 
If your project requires 100 strictly typed list types, maybe there's some
other problem you should be addressing. Like a different object model.

Also you would stop the user from being able to use the non-strictly typed
methods by overriding them. Notice how add returns false.
public boolean add (Object o) { return false; }


> > Is changing the language really going to make it any easier for
> > everyone?
> 
> It certainly is if they use generics sensibly (and not just do
> List<Object>, Map<Object,Object> etc, which would defeat the point).

well using them to strongly type object would be of course retarded, but
i couldnt imagine anyone ever doing that. so you are saying that any use
but a 100% braindead use of generics is sensible. I disagree.

> > I strongly disagree to adding generics code to jdom until; its
> > released in the jdk, has full backwards compatibility and most
> > people seem to understand how they would use it properly and also
> > how they can accomplish the same thing without it.
> 
> I would say that JDOM should probably not contain any Generics code
> (parameterised types) until the first beta of 1.5 is released; but
> that does not stop the JDOM developers from doing some preparatory
> changes *now* in readiness for when 1.5 is released.  For example the
> two I mentioned in my earlier post: creating a Node interface, and
> changing the way filters work.

Bah, if JDOM wanted storngly-typed iterators for xml data there could
easily be added an Elements and Attributes classes. Look at EXML, it
already has such a beast.

> > I dont want to support Java changing things like PERL does whenever
> > someone comes up with some "bright idea".
> 
> Generics are not just some new trendy idea that happens to be in
> favour at the moment; their equivalent in C++ (Templates) has been
> around for years, with proven success.

Java != C++
I know how templates work, they're fine and dandy.
Java does not *need* templates. If they did *need* them, then no one 
would be programming Java so many years after it has been released.

This is not a generics mailing list, but since there are lot of
smart people here, it may be as good as any other place to discuss it.

> -- 
> Geoff Rimmer <> geoff.rimmer at sillyfish.com <> www.sillyfish.com

ms-