Java code import still fails in the following cases:
String literals with unicode escape sequences like in unsuitedFiles += "\n\u2022 " + filename; - the parser rejects the entire string literal (by complaining about the first quote);
an identifier str (or one of binary, hex. unbinary, or unhex) is declared or used in the Java code, like in String str = "Too bad!";.
Problem 1 is simply due to a forgotten escape sequence specification in the used grammar.
Problem 2 is caused by an overdone grammar extension to make Processing (cf. #932) code pass, where some specific conversion functions are named after Java base types (cf. #959) - instead of introducing specific rules only for these conversion functions, even those were added that hadn't caused conflicts (but therefore did now).
Java code import still fails in the following cases:
unsuitedFiles += "\n\u2022 " + filename;
- the parser rejects the entire string literal (by complaining about the first quote);str
(or one ofbinary
,hex
.unbinary
, orunhex
) is declared or used in the Java code, like inString str = "Too bad!";
.Problem 1 is simply due to a forgotten escape sequence specification in the used grammar. Problem 2 is caused by an overdone grammar extension to make Processing (cf. #932) code pass, where some specific conversion functions are named after Java base types (cf. #959) - instead of introducing specific rules only for these conversion functions, even those were added that hadn't caused conflicts (but therefore did now).