Why does Type inference not work in the Processing editor?

With Type inference I mean

List<Type> list = new ArrayList<>();

unexpected token: >
Why is that?

To provide “further research” (I can feel the toxicity of excessive StackOverflow usage flowing in my veins)

I suspected that maybe Type inference wasn’t supported in all Java versions that have generics.
So I checked my version with this post.

Or maybe perhaps this isn’t a feature that the Java compiler provides, but is just the overzealous doing of the Java IDEs I used?

Well, that’s my wit’s end.

1 Like

Hi LoliProcessor,
I don’t know if the processing implement the inference like go, python or other languages…
For resolve you question you have to declare list inside the symbols

import java.util.ArrayList;  
import java.util.List;  

List list = new ArrayList<List>();

I hope I was helpful…

Processing 3.5.3
Win10 64bit

The reason we can’t use an empty diamond <> generic inference is b/c it’s incompatible w/ PDE’s (Processing’s IDE) pre-processor current features! :frowning_face:

But I believe we can use the empty diamond in “.java” files, not in “.pde” 1s. :coffee:

I recall the empty diamond operator is a Java 7 feature AFAIK. :large_orange_diamond:


I use

ArrayList list = new ArrayList();

Now that you have an answer (it is the partial Java 7/8 preprocessor’s fault)…

Just to confirm – is it that you like the syntactic sugar of not having to repeat the type, or is there something specific you are trying to do that you cannot do with one of the compilable options?

import java.util.List;
List<PVector> list = new ArrayList<PVector>();

// ...or
List list = new ArrayList<PVector>();
// or
List<PVector> list = new ArrayList();
// or
List list = new ArrayList();

2nd & 4th options should be avoided! The others 1st and 3rd are OK. :nerd_face:

1 Like

Well, that’s fair and good to point out – I’m not saying you should do them – I’m just saying they compile.

I think the first is what OP wants – but I can’t be sure not knowing anything about the code context.

1st 1 is more complete. 3rd 1 just declares generics on the variable only; but it’s enough. :flushed:

Well, is there a documentation about the preprocessor of Processing (ha!) ?
Or is the source code available somewhere?

To answer your question, yes, I do like my sugar syntactical.
I asked the question solely to resolve why Type inference doesn’t seem to work in the Processing editor.

Actually, does the Processing preprocessor also fuck up explicit Type arguments?

Syntax error on token "<", TypeArgumentList1 expected after this token
1 Like

As a workaround, you can type in the PDE “incompatible” syntax inside some “.java” file: :coffee:


import java.util.Collections;
import java.util.Set;
import processing.core.PVector;

interface EmptySet {
  Set<PVector> emptyVecSet = Collections.<PVector>emptySet();

Then use it inside your “.pde” files: :grinning:


import java.util.Set;
import java.util.HashSet;

final Set<PVector> empty = EmptySet.emptyVecSet;
final Set<PVector> mySet = new HashSet(empty);

void setup() {
  println(empty, mySet);
1 Like

What the preprocessor reads and writes is (largely) documented in the reference – if not, there is some documentation of the compiling process and then it is straight to the preprocessor source, which is in Antlr. So, if the syntax from Java that you are using appears in the Processing reference or examples, then that is Processing. If it doesn’t, then you can always try and see! Processing is mostly documented declaratively, for learners, like a language – “I can do this” – not differentially, “this is an enumeration of the ways I’m different from Java 7 / 8.” For that, there is mainly experience and forum lore (and the source).

If you don’t WANT to write in Processing – an intentionally simplified syntax that primarily targets beginners and artists – then you can still write Java in .java files that are part of a .pde sketch folder. Or, even better, use an Eclipse project instead of PDE and work with the full Processing API, but not the PDE format or compiler – just write it all in 100% Java, with no pde. It seems like that might be what you want…?

1 Like

Then I guess the Folder of your processing sketch (where the data folder is inside as well) acts as the default package of your module.
But good to know that you can mix .java and .pde files.

For more on how that works in PDE (vs eclipse) also read the two “Advanced” note boxes in the documentation I linked above. You can also subclass PApplet within PDE and do all-java there, but your classes are no longer automatically inner classes, so some of the PDE “just works” magic is gone – passing around PApplet is required. At that point it starts making sense to set up the Processing Eclipse Template instead.


The PDE concatenates all “.pde” files and transpiles them as 1 valid “.java” file wrapped up as 1 PApplet subclass.

But the PDE doesn’t add the keyword package to this unified “.java” file. So it’s kinda “packageless”.

However, we can use the keyword package in our own “.java” files, if we really feel like it:

But even if we do use package in our “.java” files, using import inside our “.pde” files, in order to access those “.java” sketch files, is still optional.

That is, even though I’ve included package gotoloop.countdown; inside “Countdown.java”, that import gotoloop.countdown.Countdown; statement inside “CountdownClass.pde” isn’t really needed at all.

Are you sure about your statement about the import statement not being required.
Using a packaged class without import gives error:
Cannot find a class or type named “class_name”

The decision to change language syntax, as opposed to just structural syntax, is probably the worst decision Processing made. It’s what makes adopting Java 7/8 features like this more difficult, and ends up with Java syntax actually being the simpler one. Maybe with Java 11 (and additional type inference like var) it would be good to either remove the bulk of the preprocessor, or provide an alternative mode?

For comparison, PraxisLIVE uses Java basic syntax, but the same basic structural wrapping (import, class body, etc.) as Processing using preprocessing code from Janino that has most of the same benefits with less code, and handles Java language updates without problem.

Oh, you’re right! Perhaps that was true in some very old PDE version. :woozy_face:

Indeed, if we use package in a “.java” file, we’ve gotta use import for it. :roll_eyes:

Otherwise, if they don’t have package, we can straight use them! :star_struck:

I am really not trying to pick on Processing here. In fact, I think Processing is pretty cool.

But is it possible that wildcard extensions don’t work in the Processing editor either?

Wildcard Extension:

ParameterizableClass<? extends TYPE> a;

TYPE objectOfTYPE = new TYPE();

a.parameterizedMethod(objectOfTYPE); // prePROCESSES to an error that the capture of a type doesn’t equal the type itself

Ru sure that’s valid Java syntax? I’ve made the attempt code below in order to check that out: :writing_hand:

import java.util.List;
import java.util.ArrayList;

public class Test {
  public final List<? extends Double> list = new ArrayList<>();
  public final Double d = Math.random();

  public Test() {
    //list.add(d); // uncomment this for "capture" bug!

  @Override public String toString() {
    return "" + d;

  @SafeVarargs public static final void main(final String... args) {
    System.out.println(new Test());

Pasted that code at this Java online IDE site (javac 1.8.0_201): :spiral_notepad:

And here’s the error log if we uncomment list.add(d); inside Test’s constructor: :skull_and_crossbones:

/tmp/java_3Bq5e5/Test.java:9: error: no suitable method found for add(Double)
    list.add(d); // uncomment this for bug!
    method Collection.add(CAP#1) is not applicable
      (argument mismatch; Double cannot be converted to CAP#1)
    method List.add(CAP#1) is not applicable
      (argument mismatch; Double cannot be converted to CAP#1)
  where CAP#1 is a fresh type-variable:
1 Like