Given the following source code with 1.5b3:
import java.io.InputStream;
class JalopyTest
{
/**
* Parse the given stream and create an instance of
the desired type using
* default parsing options.
*
* @param <T> the type parameter
* @param cls the class derived from Object
* @param src the data source
*
* @return the new object
*/
public static <T extends Object> T parse(
final Class<T> cls, final InputStream src
)
{
return null;
}
}
and:
jalopy.sh -c jalopy.xml -d _new JalopyTest.java
I get:
[INFO] c:\java\WORK\_\JalopyTest.java:0:0: Parse
[ERROR] c:\java\WORK\_\JalopyTest.java:5:13:
unexpected char: '<'
c:\java\WORK\_\JalopyTest.java:5:13: unexpected
char: '<'
at
de.hunsicker.jalopy.language.antlr.InternalJavadocLexer.
nextToken(InternalJavadocLexer.java:539)
at antlr.TokenBuffer.fill(TokenBuffer.java:69)
at antlr.TokenBuffer.LA(TokenBuffer.java:80)
at antlr.LLkParser.LA(LLkParser.java:52)
at
de.hunsicker.jalopy.language.antlr.InternalJavadocParser
.standard_tag(InternalJavadocParser.java:281)
at
de.hunsicker.jalopy.language.antlr.InternalJavadocParser
.internalParse(InternalJavadocParser.java:153)
at
de.hunsicker.jalopy.language.JavadocParser.parse
(JavadocParser.java:558)
at
de.hunsicker.jalopy.language.Recognizer.parse
(Recognizer.java:227)
at
de.hunsicker.jalopy.language.Recognizer.parse
(Recognizer.java:306)
at
de.hunsicker.jalopy.language.JavaLexer.makeJavaDoc
(JavaLexer.java:613)
at
de.hunsicker.jalopy.language.antlr.InternalJavaLexer.mM
L_COMMENT(InternalJavaLexer.java:1278)
at
de.hunsicker.jalopy.language.antlr.InternalJavaLexer.nex
tToken(InternalJavaLexer.java:341)
at
antlr.TokenStreamHiddenTokenFilter.consume
(TokenStreamHiddenTokenFilter.java:38)
at
de.hunsicker.jalopy.language.JavaRecognizer$1.nextTok
en(JavaRecognizer.java:482)
at antlr.TokenBuffer.fill(TokenBuffer.java:69)
at antlr.TokenBuffer.LA(TokenBuffer.java:80)
at antlr.LLkParser.LA(LLkParser.java:52)
at
de.hunsicker.jalopy.language.antlr.InternalJavaParser.cla
ssDefinition(InternalJavaParser.java:687)
at
de.hunsicker.jalopy.language.antlr.InternalJavaParser.typ
eDefinitionInternal(InternalJavaParser.java:632)
at
de.hunsicker.jalopy.language.antlr.InternalJavaParser.typ
eDefinition(InternalJavaParser.java:464)
at
de.hunsicker.jalopy.language.antlr.InternalJavaParser.par
se(InternalJavaParser.java:296)
at
de.hunsicker.jalopy.language.JavaRecognizer.parse
(JavaRecognizer.java:525)
at de.hunsicker.jalopy.Jalopy.parse
(Jalopy.java:1207)
at de.hunsicker.jalopy.Jalopy.format
(Jalopy.java:1027)
at
de.hunsicker.jalopy.plugin.console.ConsolePlugin.format
(ConsolePlugin.java:728)
at
de.hunsicker.jalopy.plugin.console.ConsolePlugin.main
(ConsolePlugin.java:246)
I am assuming that the parser does not like the "<T>" in
the Javadoc @param tag.
Note: As of J2SE 1.5 "@param <T>" is now accepted
by Javadoc to document the type parameter T to a type
or method.
Conventions file with Javadoc parsing enabled
Logged In: YES
user_id=723231
Is the following the correct javadoc format for this generic
parameter ?
/**
* A test
* @param <? extends K, ? extends V> amazing Passed in value
*/
public static void ack(Map<? extends K, ? extends V> amazing) {
}
Logged In: YES
user_id=152749
Hello,
I don't believe you would use the generics in the @param for
your example. It would look like the usual:
@param amazing Passed in value
You *would* need the generics when using something like:
<T, V extends T> V convert(String string);
@param <T> blah
@param <V> blah
@param string blah
HTH.
Logged In: YES
user_id=723231
Generic Paramaters are now formattable and wont "blow up"
the format. In CVS only.