There were some fixes in later releases. Does move to 6.0/6.1 helps you?

sorry, the version should be 6.5

Can you explain in more detail what the description of this bug means?  I do not understand it.

When you edit code with Java ME platform SDK 3.0, EA set as platform, the usage of objects of classes from
javax.microedition.media package might be incorrectly marked as "with errors", but the project can be builded. The
problem is that the editor takes classes from MIDP before the classes from MMAPI. As there are some classes, which are
in both JSRs and they are extended in MMAPI, so the ones in MMAPI should be used.

E.g. PlayerListener.STOPPED_AT_TIME;
will be underlined as the static fields exists only in PlayerListener in MMAPI class.

The cause of this is probably different order of JSRs during the build time and when the editor checks for errors.

Can you explain a bit about what the platform classpath looks like?  Is there a reason the SDK 3.0 needs multiple copies
of the same classes on the classpath?  That sounds like a bad idea.  A user is likely to code against features that may
not really exist in the deployment target.

Can't this be solved simply by multiple platform definitions depending on what is needed?  I think I'm missing something
here.

I don't know how the Netbeans takes the classpath for editor and (probably a different one) during the build time.
There are the same classes on classpath, because the MIDP/MMAPI API is defined so, it's nothing SDK 3.0 specific.
Look here: http://java.sun.com/javame/reference/apis/jsr118/ and here http://java.sun.com/javame/reference/apis/jsr135/
(package javax.microedition.media ). When the user chooses MMAPI for his project, the classes from MMAPI should be used,
as they are more "advanced". The building process does so, the editor doesn't.

We solved this for JavaCard by having project "flavors", and the platform's getClasspath() methods were overloaded to
pass an additional argument - but this required the supporting platform to identify which classes belonged to which
flavor (in a properties file).  

It would be a fairly brittle hack if the IDE is supposed to guess which JARs to include/not include, since there is no
requirement that all vendors package things the same way.

This issue cannot be fixed on the Jar level as the mentioned class is already a part of MIDP Jar and could not be cut out. Mobility already manages the classpath Jars individually.

The only workaround is to change classpath ordering internally and this was already fixed. Please re-open if the issue still occurs.