There are four known shortcomings of the Java source import, related to type arguments:
[x] Type casting to a parameterized type causes parser failure, e.g.:
Vector<String> lines = (Vector<String>) getLinesFromFile("test.txt");;
[x] Array declarations over parameterized types cause parser failure, e.g.:
JComboBox<String>[] comboBoxes = null;;
[x] Nested parameterized types cause parser trouble if their closing angular brackets cling together (the lexer reads them as shift operator in this case, which can be prevented by inserting space, however), e.g.
HashMap<String, ArrayList<String>> myMap;;
[x] Type parameter ? (as e.g in Class<?>) causes parser failure.
All of these shortcomings can of course be overcome by deriving a manually modificied copy of the source file before importing it, where disturbing type parameters are effaced or enclosed by comments, but it is tedious and cumbersome.
Therefore Structorizer might mitigate at least the first and the third of them via automatic file preprocessing. The second one, however, is more tricky, but it should be possible to separate closing angular brackets in a heuristic approach with sufficient likelihood of appropriateness. It seems safer, though, to offer it only optionally (i.e., leaving it to a new Java-specific import option), because it may be easier to manually fill in the blanks where actually needed (before the import) than to find a way to prevent or circumvent a mistaken automatic splitting of mis-conceived real shift operators (if the file preprocessing mechanism overdoes).
There are four known shortcomings of the Java source import, related to type arguments:
Vector<String> lines = (Vector<String>) getLinesFromFile("test.txt");;JComboBox<String>[] comboBoxes = null;;HashMap<String, ArrayList<String>> myMap;;?(as e.g inClass<?>) causes parser failure.All of these shortcomings can of course be overcome by deriving a manually modificied copy of the source file before importing it, where disturbing type parameters are effaced or enclosed by comments, but it is tedious and cumbersome.
Therefore Structorizer might mitigate at least the first and the third of them via automatic file preprocessing. The second one, however, is more tricky, but it should be possible to separate closing angular brackets in a heuristic approach with sufficient likelihood of appropriateness. It seems safer, though, to offer it only optionally (i.e., leaving it to a new Java-specific import option), because it may be easier to manually fill in the blanks where actually needed (before the import) than to find a way to prevent or circumvent a mistaken automatic splitting of mis-conceived real shift operators (if the file preprocessing mechanism overdoes).