[jdom-interest] How will JDOM be updated for Java Generics (JDK 1.5)?
Duffey, Kevin
KDuffey at BUYMEDIA.com
Sat Jul 20 11:18:44 PDT 2002
I have to agree with Michael. One thing I really love about Java is its
clean code and separation. C++ is dam ugly, period. I have seen some
"ok" C++ code, but when you work with templates, oh man does it get
ugly. I really think adding generics is going to un-beautify the java
code out there, and lend coding styles more towards C++ instead of how
Java is. The only thing I see Java missing is direct hardware access,
and I say that because I would love to write real-time java for audio
and video processing apps, work with web-cams, specific soundcard
drivers (asio), etc. But because there seems to be no way other than
through JNI to do this, Java sucks in this area. Of course, unbloating
Swing would be nice too, making it much faster. But all in all, I think
Java is a cross between C/C++ and Delphi. Very clean looking, easy to
code with, easy to work in multi-team setups, fast to code with, etc.
Adding confusing looking code like generics is only going to make it
harder to learn and use Java. Why spoil a good thing? I hope this is not
a fight against C#!
-----Original Message-----
From: Michael Salmon [mailto:ms at formulae.org]
Sent: Saturday, July 20, 2002 9:51 AM
To: Geoff Rimmer
Cc: jdom-interest at jdom.org
Subject: Re: [jdom-interest] How will JDOM be updated for Java Generics
(JDK 1.5)?
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-
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com
More information about the jdom-interest
mailing list