The code and source jars have line number mismatches, and no warning for a template name/filename mismatch

[rwperrott]

When I try and debug a NullPointerException (!) in ST4-4.0.8.jar, for a 'missing' .st file, the byte-code line number and source jar line numbers don't match, so I have to hunt for the method and guess where inside inside it the exception occurred, which is stupid and annoying, this frustration appears to cover the whole of my stack trace inside the Jar, hmm!

The NullPointerException was caused by the template name being different from the .st filename, but all I got was a very unhelpful NullPointerException because it couldn't find the template name in the templates map in the STGroup class.

[Clashsoft]

Did you try the latest version 4.3.1?

[rwperrott]

Yes, that's what I'm actually got set in my pom.xml, it looks like IDEA displayed stale dependency data, for my Maven import, and a re-import fixed that; I may retry debugging later, to verify the 1st issue. My builds were Maven based, so the 2nd issue probably still exists.

[rwperrott]

Adding to this, using 4.3.1:

• A .stg file load finds a syntax error in a template, the STGroup emits a message with the correct line number to its Error Listener, but no exception is thrown. This is annoying, but my code can workaround that by using a custom ErrorListener to set a load failure flag.
• When a ErrorType.NO_SUCH_PROPERTY event occurs in a template, an STGroupFile, for a file, emits a message with an unhelpful template, relative, line number to its Error Listener, not the absolute line number; this may also affect STGroupDir and STGroupString. I can't patch this annoyance, because ST object doesn't appear to provide an absolute source start line number, in the source, to adjust the line number with.

[parrt]

Thanks for the report, @rwperrott !!

[rwperrott]

I don't expect the 2nd issue above to be addressed soon, so investigated more and made a workaround, which I expect to drop later.

• My render phase ErrorListener tests if msg is a STRuntimeMessage and that it's scope field is not null.
• Gets the relevant template name with scope.st.getName().substring(1);
• Has a static source (String or URL) keyed, lazy-created, map of Template name keyed maps of their start line numbers, for the source containing the template. A regex is used to find the start line of each template and to extract its name
• Looks up the template map for the source then the start line number for the template name.
• Uses data-copying sub-class of STRuntimeMessage (in same package, because the interp field was package private), with a modified version of Misc::getLineCharPosition which starts at the absolute line number, not bogus 1.

This hack successfully converts relative line numbers to absolute ones for STGroupFile, including imports, via STGroup::getImportedGroups(), and should work with STGroupString too. I suspect that supporting STGroupDir will be a pain.

[rwperrott]

I suggest that CompiledST objects should carry an absolute start line number and Misc.getLineCharPosition sets line from a start line parameter, not unreliable 1, and that callers, like STRuntimeMessage, are updated to pass in the absolute start line number.