Sam,

sorry but your suggestion is no different from mine, and would change the nature of the contract between the Tool and a target.
So yes theoretically it is possible to fix the bug without altering the Java generation, but that is both unnecessary (there is no requirement)
and a major change in the Tool design, which relies primarily on the STG, and only uses the Target as a helper class.

I don't understand your point re NetBeans. Does the AntLR plugin not point to a Tool the same way the Eclipse and VS plugins do?
If not, that's wrong plugin design, and should not be supported.

Eric


Le 23 mai 2014 à 02:33, Sam Harwell <notifications@github.com> a écrit :

> In tool/resources/org/antlr/v4/tool/templates/codegen/Java/Java.stg:
> 
> > @@ -214,6 +222,8 @@ Parser(parser, funcs, atn, sempredFuncs, superClass) ::= <<
> >  Parser_(parser, funcs, atn, sempredFuncs, ctor, superClass) ::= <<
> >  @SuppressWarnings({"all", "warnings", "unchecked", "unused", "cast"})
> >  public class <parser.name> extends <superClass> {
> > +    static { RuntimeMetaData.checkVersion("<file.ANTLRVersion>"); }
> My statement was not incorrect. The handling of declarations could be performed by allowing the Target class to override the generation of the declarations but keeping the default implementation generating them in the current form, and then passing them to the code generation templates as strings like they were previously. This is likely not ideal, but supports the statement that Python declarations can be supported without altering the Java templates. This was also not a bug, but rather a limitation in the extensibility mechanisms.
> 
> Preserving backward compatibility across multiple versions of the runtime is not a required feature, but it is a feature I manually evaluate and test for the Java target prior to release. No other language target would be required to implement or even suggest the same behavior, but a requirement when adding support for new targets is to not let those changes impact the guarantees I am currently providing for the Java target unless truly required (though I have yet to see an example of such a requirement).
> 
> ANTLR 4 is a monumental improvement over prior versions of ANTLR, especially in regards to support for applications like IDEs. I anticipate situations where an IDE, e.g. NetBeans, offers multiple plugins supporting different languages (e.g. ANTLR and Go, which are implemented in separate extensions). I don't want an update to ANTLRWorks to ship a new version of the ANTLR runtime and break the functionality of the Go plugin. Since these plugins may be developed by independent teams or even separate companies, compatibility across versions is an effort to provide additional stability to companies that may have a commercial investment in their project seeking long-term reliability of their product offerings.
> 
> You are correct that RuntimeMetaData.checkVersion does not prevent code from running. However, at the current time the method is not required for the Java target. The breaking changes which have been introduced to date in the Java target result in code that will throw an exception before ever running if a version mismatch covers a use case described in the breaking changes. The error reported to the console by this method would be misleading for Java users. However, if you wish to keep the template in the Python target for any reason, that is fine.
> 
> —
> Reply to this email directly or view it on GitHub.
>