Thread: Fwd: Re: [SrcML] Java 1.5 update
Status: Beta
Brought to you by:
crashchaos
From: Frank R. <fra...@in...> - 2005-05-28 09:54:14
|
I forward this to the list, as I suspect it was accidentally sent to me only: ----- Forwarded message from Dennis Waldherr <den...@in...> ----- Frank Raiser wrote: >All compiles are now done with -Xlint:unchecked. There are a few >places where the generics aren't as nice as I'd like them to be. >Everywhere where we interact with other libraries not using generics >we obviously get into trouble. There's still a compiler warning in >the srcml module for the line elements().add(i, e) which involves >a dom4j method. Maybe Dennis can take a look at that, as I haven't >found a way to silence the compiler there. I've not added this >compiler option to the parser-java's build.xml as the generated >antlr sourcecode is giving a myriad of errors then. We will still >have to wait for a 1.5 version of antlr for that. > > > No idea on the elements().add(i,e) thing yet. >Vector<SrcMLElement> v = new Vector<SrcMLElement> >for (Method m : getMethods()) v.add(m); > >This basically means 'casting' a Vector<Method> to a >Vector<SrcMLElement>. If someone knows a more elegant way to solve >the above problem please let me know. > > > v.addAll(getMethods()) should work. My getMethods implementation still returns a normal List (and I'd prefer it to return a List<Method> lateron and not a Vector<Method>) - Dennis ----- End forwarded message ----- As I said we're compiling with -Xlint:unchecked now _and_ I've rewritten big parts of the code to minimize the amount of warnings by adding proper generics. This means there are no more occurences of List or Vector without a generic type specification added to it. As for my example method it was an invention only and I don't know if it exists as such in the source code (so it could very well be List<Method> by now). However that is not the point I'm trying to get across. The main problem is that it is no longer List.addAll(Collection c), but now we are implicitly calling List<E>.addAll(Collection<E> c) and we're running into the above 'problem' whenever the first and second E differ. -- Raiser, Frank Student @ University of Ulm (www.uni-ulm.de) Software suppliers are trying to make their software packages more user-friendly. Their best approach, so far, has been to take all the old brochures, and stamp the words, user-friendly on the cover. (Bill Gates) |
From: Dennis W. <den...@in...> - 2005-05-28 10:03:26
|
Frank Raiser wrote: >As I said we're compiling with -Xlint:unchecked now _and_ I've >rewritten big parts of the code to minimize the amount of warnings >by adding proper generics. This means there are no more occurences >of List or Vector without a generic type specification added to it. >As for my example method it was an invention only and I don't know >if it exists as such in the source code (so it could very well be >List<Method> by now). >However that is not the point I'm trying to get across. >The main problem is that it is no longer List.addAll(Collection c), >but now we are implicitly calling List<E>.addAll(Collection<E> c) and >we're running into the above 'problem' whenever the first and second E >differ. > > > Well the List interface specifies addAll to be "|*addAll <http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html#addAll%28java.util.Collection%29>*(Collection <http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html><? extends E <http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html>> c)|" in which the "second" E (being '?') may differ as long as it's subtype of the first E. - Dennis |
From: Dennis W. <den...@in...> - 2005-05-28 10:08:12
|
Dennis Waldherr wrote: > Frank Raiser wrote: > >> As I said we're compiling with -Xlint:unchecked now _and_ I've >> rewritten big parts of the code to minimize the amount of warnings >> by adding proper generics. This means there are no more occurences >> of List or Vector without a generic type specification added to it. >> As for my example method it was an invention only and I don't know >> if it exists as such in the source code (so it could very well be >> List<Method> by now). However that is not the point I'm trying to get >> across. >> The main problem is that it is no longer List.addAll(Collection c), >> but now we are implicitly calling List<E>.addAll(Collection<E> c) and >> we're running into the above 'problem' whenever the first and second E >> differ. >> >> >> > Well the List interface specifies addAll to be "|*addAll > <http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html#addAll%28java.util.Collection%29>*(Collection > <http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html><? > extends E > <http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html>> c)|" in > which the "second" E (being '?') may differ as long as it's subtype of > the first E. O o Ok this link garbage wasn't meant to be sent... actually I wanted to write addAll(<? extends Collection>) (good work Thunderbird :/ ) - Dennis |
From: Frank R. <fra...@in...> - 2005-05-28 11:02:04
|
On Sat, May 28, 2005 at 12:08:35PM +0200, Dennis Waldherr wrote: > >Well the List interface specifies addAll to be "|*addAll > ><http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html#addAll%28java.util.Collection%29>*(Collection > ><http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html><? > >extends E <http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html>> > >c)|" in which the "second" E (being '?') may differ as long as it's > >subtype of the first E. > > O o > > Ok this link garbage wasn't meant to be sent... actually I wanted to write > addAll(<? extends Collection>) > > (good work Thunderbird :/ ) > - > Dennis That's why we have you on the project :).. I found the main problem of this kind to occur in the PrintSelectionJava plugin with a return type of Vector<Vector<SrcMLElement>> which I have now changed to use Vector<Vector<? extends SrcMLElement>>. This needed a few more changes, but works out great when adding List<Method> or similar objects. Thanks for the pointer. We'll still have to make some more modifications to the existing source (f.ex. changing those Vectors to Lists), but so far the addition of generics seems to be rather unproblematic and the new for loops alone justify the switch. -- Raiser, Frank Student @ University of Ulm (www.uni-ulm.de) If you want truly to understand something, try to change it. (Kurt Lewin) |