Hi,
my reply to your question in 41cat probably somewhere disappeard.

There is no sense for main classes in J2ME project. If you mean MIDlet as a
"main class" the answer is no - we do not support single MIDlet execution so
there is no "Run file" action available.

If you mean J2SE project - I think any main class should have enabled "Run file"
action no matter if compiled.

And you are talking about the only solution by deletion of some file. I am not
sure I understand which file what does it solve.

to clarify more this issue - current behavior is correct and it has been designed
in this way intentionally:
1. we always create a jar file for execution. The reason is that some files are
excluded during the packaging process and the requirement here is to prevent a
situation when execution in the IDE works but when deployed on a device it
doesn't work.
2. execution doesn't start if build fails. Our requirement is to prevent a
situation when user would get an impression the application works (it's running)
but in fact the compilation failed.

In J2ME project, you can use project customizer to exclude a class or package
from build process, so if I understand your use case correctly it will solve
your problem.

I'm closing this issue as Invalid because it works according to initial
requirement. If there is a new requirement on automatic excluding of
uncompilable classes from the build process we have re-define current build
system flow first, not only for J2ME project.

You are right. In case of J2ME project I meant MIDlet.

In both cases I tend to have some "experimental" classes in my project for
future use, or I exclude uncompilable classes by commenting theirs use temporarily.

I don't like to exert project customizer to exclude a class or package
from build process (not possible for J2SE projects by the way), because then I
often have to switch these settings for testing purposes.
At least a class should be excludeable by context menu and should be indicated
by a badge to remember me.

> ... to prevent a situation when execution in the IDE works but
> when deployed on a device it doesn't work.
We have the same situation, when a class is excluded by project customizer.

> Our requirement is to prevent a situation when user would get an impression
> the application works (it's running) but in fact the compilation failed.
What's the problem, if compiling of an "experimental" class fails and the
application works?

It's a regression, because in NetBeans 3.6 it was easy to handle uncompilable
"experimental" classes.

Now you have following options:
 - create separate experimental projects
 - use project properties to filter experimental packages/classes
 - comment-out uncompilable parts of your code

Single MIDlet execution feature was intentionally dropped for J2ME.

I am changing this defect to a new feature request.

Thanks for reopening this issue.

I like to comment your options:

 - create separate experimental projects
You mean: Duplicating the project, accept wasting discspace, perhaps installing
a new CVS working dir or copying back the changed sources and be aware to don't
forget any detail, rename classes (You know, overwriting in IDE ends up in a
OldName_1 class, deleting results in irritating cvs).
I don't accept all that work just for outlocking a class for a period of some
minutes to some hours.

 - use project properties to filter experimental packages/classes
Not available for J2SE;
You have the same problem as if the noncompiling class isn't included in the
jar, if you forget this property after a time, and you are in bona fide (good
faith) all is complete in your project.

 - comment-out uncompilable parts of your code
Sometimes bad experience with this: comment-out one line, compile and have to
comment out another line, third compile needs to comment-out some other lines ...
Later you have to track back theese comments and be aware to don't forget one.


The best, I think, is to have a badge indicating the outlocking, an invoke it by
right-mouse-button menu (for J2SE and J2ME). By the way, the not-compiled badge
indirectly indicates also, that this class cann't be a part of the JAR, if you
would allow this.


I propose to delete the J2ME-part in the summary, and move this issue to
standard NetBeans components.

Moved to ide core, because it concerns both J2SE and J2ME.

reassigne to projects, in my opinion this is as designed, if you have one
uncmpilable file in your project, you can't compile the wholke project...

...which works fine for me in a dev build. Make a j2seproject with

package xxx;
public class Broken {
    public Broken() {
        xxx
    }
}

package xxx;
public class Fine {
    public static void main(String[] args) {
        System.out.println("OK");
    }
}


"Run" fails with a compile error on Broken.java. "Run File" on Fine.java works.

You are wright, this works in J2SE.

But what's about J2ME ?

I can use project properties to filter experimental packages/classes, ...
but problem: There is a good chance to overlook this some times later, and it's
not comfortable to use.

The best, I think, is to have a badge indicating the outlocking, an invoke it by
right-mouse-button menu. By the way, the not-compiled/excluded badge indirectly
indicates also, that this class cann't be a part of the JAR, if you would allow
this.

Such a featue would be helpful for J2SE and J2ME.

Adame can you evaluate it, why it does not work in the J2ME project when it
works fine in the J2SE project. Javac creates closure of files to compile in the
class reader. Is it because of the configurations?

Compilation of single file (when there are some uncompilable files present)
works even in J2ME Project.
The only unsupported operation by J2ME Project is single file execution. There
was already mentioned we need to build whole jar to run the application.
But I suggest to let the enhancement of single file execution for J2ME open for
next releases.

Hi,
in my opinion, this issue abandons it's original intention.

The intention was, to have a comfortable, feasible and secure way to exclude
classes from the build-process to avoid deleting or out-commenting them, and not
primarily the "Run file"-option.

Using the project customizer to exclude a class or package from build process is
neither comfortable nor secure(It's easy to forget the exclusion after a time).
For this I like to have a badge indicating the excluding/outlocking, an invoking
it by right-mouse-button menu. 

moving to mobility component

BTW: Can't vote for this, because of Issue 79189.

There is another way how to exclude classes from compilation if you don't like
our Filtering panel in Project Properties.
You can start your experimental sources with preprocessor command //#condition
and setup an ability or project configuration that will disable/enable
particular sources for compilation.
Currently all broken files are badged and the badging takes in account the
proprocessor so it solves your problem.
I am closing this issue as it works for me and there are already several ways
how to solve your use case.