Community
Participate
Working Groups
The template for "for" in 3.1 is now for (Iterator iter = collection.iterator(); iter.hasNext();) { type element = (type) iter.next(); }; This should be for (Iterator<type> iter = collection.iterator(); iter.hasNext();) { type element = iter.next(); }; at least when switched to 5.0 compatibility
*** This bug has been marked as a duplicate of 95787 ***
I don't see why this would be a duplicate of bug 95787; it is exactly the opposite suggestion! I could imagine there to be duplicate templates, with a mention as to to which JDK level they apply, but merely as a temporary solution.
The point is that we need to enhance the template infrastructure with the additional info like the Java SDK level. Once this is in place both requests can be resolved.
We do know the source level once a template is being applied. Only the content assistant / template engine collecting the proposals does not know about it. When resolving a template (happens when it gets applied or the additional info computed), we know the CU. However, the current for-template would have to be changed to be something like this: for (Iterator${typespec} ${iterator} = ${collection}.iterator(); ${iterator}.hasNext(); ) { ${type} ${element} = ${typecast}${iterator}.next(); ${cursor} } Note the new variable types 'typespec' and 'typecast'. ${typespec} would resolve to the empty string when in a 1.4 project, while ${typecast} would resolve to the empty string in a 1.5 project. Additionally, the ${type} variable would have to be resolved in a 1.5 project. No action for 3.1 as it is far more common to use the new for loop template here. The old template would only make sense where one wants to call the Iterator.remove() method.
bug 102747 is really a dup of this one but is targeted for 3.2 - marking this bug as a dup. *** This bug has been marked as a duplicate of 102747 ***
