Hello... long time no hear, hope you're all well!

I was just about to release the latest addition to my toxiclibs libraries - somewhat of a Java port of NodeBox' Colors library - when I just tried to test my examples in the PDE... and miserably failed. Epic fail!

Since am mainly working in Eclipse I haven't used Processing in the PDE for ages & so haven't noticed any of the pre-processor issues now biting me last minute. I'm just after some advice, what would be the best option to take apart from renaming my package and classes to avoid these.

I'm currently struck by 2 interlinked issues related to the preproc:

1) One of the core classes of the new library is called "Color" and does conflict with the Color class in the automatically imported java.awt package.

2) My library package is called "toxi.color", so when trying to resolve the ambiguous "Color" class by using its full name "toxi.color.Color" the pre-processor complains about the "." after "color" in the package name (since it interprets it as the Processing color type/method call).

So a classic Catch-22...

No. 1 could be avoided by a less wildcard-style automatic import of the entire java.awt package and instead only refer to the classes actually needed.

No. 2 should be in theory possible to turn off via the "preproc.color_datatype" preference, but somehow doesn't seem to make any difference...

I'm tempted to revert my class names to the british spelling of "colour", which would circumvent both issues nicely (and which I'd prefer personally). At the same time I've received mild complaints by others about the lack of the far more common american spelling version instead...

Opinions Other solutions

Thanks Florian!

Hmm... As said above, I'm with you about using the american spelling. However, I'm really against using any unnecessary prefixes to classes since they distract and don't add anything in terms of semantics & especially not if they're only a workaround for something more fundamental which should be addressed instead. My point was more about the shortcomings of the preprocessor and I've filed a bug to address them properly.

The main cause for such issues (this is not the first time I encounter this) are the wildcard imports automatically added by the preprocessor, which then clutter the class name space for the sketch and can cause naming conflicts. I also guess this could occur increasingly often now that there's a growing number of 3rd party libraries and more people are regularly venturing outside the normal Processing syntax and constructs.

For example, I know that both of these import statements are added automatically:

Code:

import java.awt.*;
import java.util.*; 

That means even a simple standard thing like this is ambigous, because there's a List type in the AWT package and another one (the one we really want in 90% of the case) in java.util:

Code:

List list=new ArrayList(); 

In most programming literature it's considered bad practice to import entire packages, but even Sun does so at times. However, apart from convenience there doesn't seem to be any plausible reason Processing has to do it this way. IMHO it's just one of those legacy things in the app code which haven't been touched in years, but are actually quite simple to resolve (without sacrificing convenience for the vast majority of users).

As mentioned, I've filed a bug & possible solution for this over here:

http://dev.processing.org/bugs/show_bug.cgi?id=1103

Would be great to hear others' thoughts on this...

I'm all for the current automatic imports and the convenience of not having to manually include Hashtable, ArrayList etc. I'm only taking issues with the way this is currently handled and have already proposed a possible solution in the above bug report. If the automatic imports would be refactored to be able to import specific classes rather than entire packages this current system would be much more flexible and the change invisible in behaviour. Also the change is trivial to implement and all what's needed is to compile a reduced list of commonly used classes to import and communicate this change to users.

The specific problem with my library conflict is the automatic full import of the whole java.awt package. If this instead would only include the few classes really likely to be used of the package, this wouldn't be any problem. But at current this means also java.awt.Color will be imported automatically and I'm fairly convinced that hardly anyone is ever using this class. Same goes for most other AWT classes...

Hope that makes sense!