If I use
ANTLRFileStream antlrFileStream = new ANTLRFileStream(\"myfile.testlang\");
or
ANTLRInputStream input = new ANTLR
As for @Mike Lischke's comment about it being unfortunate that Unicode support was not simply folded into the existing ANTLRInputStream rather than creating the new CharStreams class (and breaking existing code, albeit in a (maybe? usually?) "easy-to-fix manner": Could it be that some code writte for ANTLRInputStream depending on it being a non-Unicode stream (e.g. 8 or 16 bit characters only)?
I'm new to ANTLR (and picking up rusty Java again after learning it 10 years ago in CS class.), so I don't know how much the incomplete Unicode support for ANTLRInputStream was.
The "don't change the old interface to fold in new behavior, just create a new one" thing reminds me of Apple Swift (and their Cocoa/iOS/etc APIs) that seems in a constant state of source-code-compatibilty flux.
You can use the CharStreams
class instead of the deprecated classes as below.
CharStream codePointCharStream = CharStreams.fromFileName("myfile.testlang");
TESTLANGLexer lexer = new TESTLANGLexer(codePointCharStream);
TESTLANGParser parser = new TESTLANGParser(new CommonTokenStream(lexer));
parser.addParseListener(new TESTLANGEventListener());
// Start parsing
parser.testlangFile();