See bug #196452 comment #1. If you have a module which has jlfgr-1_0.jar in its classpath and then you try to use
@ActionRegistration(displayName="New", iconBase="toolbarButtonGraphics/general/New16.gif")
you will get an error when building with JDK 6:
"Cannot find iconBase file at toolbarButtonGraphics/general/New16.gif"
even though the icon really exists.
The error is not produced using JDK 7's javac.

Issue was introduced with
changeset: 189257:b466219620fe
parent: 189245:d8a6a684084f
user: Jaroslav Tulach <jtulach@netbeans.org>
date: Sun Feb 20 15:16:24 2011 +0100
files: openide.awt/src/org/netbeans/modules/openide/awt/ActionProcessor.java openide.awt/test/unit/src/org/netbeans/modules/openide/awt/ActionProcessorTest.java
description:
Detect missing iconBase to easily diagnose typos in the name of the resource
The only workaround I can find is to relax the check a bit so that it still fails in JDK 7 when given an invalid path, but always passes in JDK 6: core-main #5adfdac10656

Created attachment 107206[details]
Warn on JDK6, fail on JDK7
First of all I think we should write a test.
Second I'd prefer to leave the behavior on for JDK7 and turn it into a warning for JDK6.
I patch that does the above is attached.

(In reply to comment #4)
> turn it into a warning for JDK6
I do not think this is a good idea, because it will produce an incorrect warning which you cannot suppress when the icon really exists in your classpath (as in the original motivating use case). It is better to miss some opportunities to warn about incorrect code than to falsely warn about correct code.
Anyway checking for AutoCloseable is wrong because what you want to check has nothing to do with whether the JRE is 6 or 7; you only care about the version of langtools (javac), which can run on JRE 5+. For example, the processor when run inside the NB editor on JDK 6 should be using the fixed version of javac (assuming nb-javac is synching regularly).
(In reply to comment #5)
> for (Location l : new Location[] {StandardLocation.SOURCE_PATH,
> StandardLocation.CLASS_OUTPUT}) {
...and CLASS_PATH.

> > turn it into a warning for JDK6
>
> I do not think this is a good idea, because it will produce an incorrect
> warning which you cannot suppress when the icon really exists in your classpath
I've seen a comment from you, Jesse, somewhere saying that having icons outside of module JAR is a poor practice anyway.
OK, so we should disable the check on JDK6 completely, right? We want to keep it on JDK7, right? If so, we can add the tests and run them only on JDK7.
> Anyway checking for AutoCloseable is wrong; you only care about the version
> of langtools (javac),
I believe that it is safe to assume that when AutoCloseable is present, the compiler is comming from JDK7 as well. I don't think there is any explicit versioning in the compiler itself. We could use
static boolean isJDK7() {
try {
SourceVersion v = SourceVersion.valueOf("RELEASE_7"); // NOI18N
return true;
} catch (IllegalArgumentException ex) {
return false;
}
}
but I am not sure if that is reliable (does not work in the test).
Passing to you, as I will not be able to integrate to release70 branch anytime soon.

(In reply to comment #7)
> I've seen a comment from you, Jesse, somewhere saying that having icons outside
> of module JAR is a poor practice anyway.
I was referring to icons in _another_ module. Did not even consider the use case of keeping icons in a separate Class-Path extension, which is perhaps unusual but I think valid - such a JAR is bundled in the same NBM and put in the same ClassLoader, so there is no possibility that the icon will not be there at runtime.
> OK, so we should disable the check on JDK6 completely, right? We want to keep
> it on JDK7, right?
That is what my current patch does.
> If so, we can add the tests and run them only on JDK7.
OK. Don't know of any builder which would do so, but useful for the future.
> I believe that it is safe to assume that when AutoCloseable is present, the
> compiler is coming from JDK7 as well.
No, because you may be running the JDK 6 compiler with an explicit boot CP.
I will see if there is some other check that can be used.

(In reply to comment #13)
> i created simple jar with icon, created nb platform app, created module with
> action inside that app, in action changed iconbase to point at icon from jar,
> put that jar with icon inside nbplatform app (added it using library wrapper),
> ran
Good.
> cannot reproduce in old build (beta2)?
See comment #1; beta 2 performed no iconBase validation.