This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 178597 - Uncompilable code should not be deployed on save
Summary: Uncompilable code should not be deployed on save
Status: NEW
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Infrastructure (show other bugs)
Version: 6.x
Hardware: All All
: P2 normal with 2 votes (vote)
Assignee: Petr Jiricka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-14 08:08 UTC by Petr Jiricka
Modified: 2012-03-25 07:18 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2009-12-14 08:08:16 UTC
1. Create a Java web application
2. Create a Java class p.Worker with the following method:
    public static String doit() { return "xy"; }
3. In index.jsp, add the following line:
    <%= p.Worker.doit() %>
4. Run the application - it will be correctly displayed in the browser
5. In the doit() method in the Worker class, write some uncompilable garbage and save it.
6. Refresh the web browser

=> Browser will display an error message saying something like "org.apache.jasper.JasperException: java.lang.RuntimeException: Uncompilable source code ..."

I would expect that if the code is not compilable, the application will not be redeployed and the older working version of the app will continue to be available on the server.
Comment 1 Petr Hejl 2009-12-15 08:32:08 UTC
This is imo by design.
1) Developer can be much more productive if he can test certain area. So he is for example not forced to implement bunch of interface methods etc.
2) We would complicated the logic of deploy on save and artificially limit its usefulness.

The developer will have hard times to understand what is actually deployed:

1) He will made by source code uncompilable by mistake.
2) He will switch to the browser test something and everything works.
3) Wait, there is some old behavior in the app!
4) He will switch to the IDE - there is a bug.
5) What is deployed? Some old version or some magically fixed version? He will feel scared about the magic and perhaps he will disable DoS.

Compared to:
1) He will made by source code uncompilable by mistake.
2) He will switch to the browser test something and will see Uncompilable.
3) He will switch to the IDE - there is a bug.
4) Bug fixed, app works.
Comment 2 Petr Jiricka 2009-12-16 05:07:57 UTC
It could be that this is really the matter of personal preference; this issue came up in discussion with Marek Fukala, Jindra Sedek and Martin Schovanek - the consensus is that the current behavior is bad and we should not deploy uncompilable apps. 

Note that the same opinion was voiced at NetCAT before:

"...CoS also generates class files for code with compilation errors,
then causing exceptions at runtime if and when the code is executed.
This happens to be the other thing I dislike about CoS. I do not want to
deploy and run code that still has compilation errors in it. I want
fail-fast. This is one of the main reasons to use a statically typed
language after all."

See: http://old.nabble.com/forum/Permalink.jtp?root=22987537&post=24612988&page=y

With respect to magic - other people could consider the current behavior "magical". Would it help if we had some global indicator that would say whether the main/current project is fully compilable, so the user would immediately see that something is wrong in the application that needs to be corrected?
Comment 3 bht 2010-01-01 18:05:04 UTC
In my case, the current implementation of Deploy on Save breaks my EJB project full stop.

I am guessing that Deploy on Save maintains a cache of OLD uncompilable source files that have long been fixed otherwise I cannot explain this situation.

In the server (GlassFish 2.1.1) log file, I get errors like:

Caused by: java.lang.RuntimeException: Uncompilable source code - SomeClass is not abstract and does not override abstract method someMethod() in SomeInterface
at SomeBaseClass.<clinit>(SomeBaseClass.java:26)

where in fact the current source code of SomeClass does no longer extend SomeBaseClass as it used to a few days ago.

I was totally confused, and I blamed GlassFish 2.1 for it. Then I upgraded to GlassFish 2.1.1 - still the same problem.

Cleaning and building the project does not help. I have no idea how to get rid of this old junk. Only disabling Deploy on Save fixes the problem instantly. Switching Deploy on Save back on reproduces the error. I lost a whole day due to this, and Deploy on Save is broken until I don't know when. What kind of developer productivity is THAT?

I am inclined to open a separate bug for this, because my scenario is not really as debatable as the comments above suggest.

In any case, I fully agree with http://old.nabble.com/-67cat---java--Rethinking-CoS-again-td22987537.html#a24612988
.

I expect an IDE to protect me from errors not to provide me with convenience to ignore them.
Comment 4 Petr Jiricka 2010-01-04 01:43:35 UTC
>  Then I upgraded to GlassFish 2.1.1 - still the same problem.

Hi, can you please try whether this is still a problem with GlassFish v3? That way we can find out whether this is a problem on the IDE side or the server side.


BTW, one other piece of data - reportedly Eclipse works the same way NetBeans works now, it redeploys code even if it is not compilable.
Comment 5 bht 2010-01-04 11:22:40 UTC
Petr, Thanks for your comments.

I could eventially sove the problem, only by single-recompiling various classes.

While I still have a copy of the misbehaving project, I consider it unproductive and silly to even try to produce a testcase for this (I usually don't submit bugs without testcase). NetBeans obviously got confused with this not the server because NetBeans decides what gets deployed to the server. Without THIS issue, I would not have had this problem.

We already know what the problem is - that is NetBeans deploys rubbish to the server (I wonder where this idea comes from), which is the subject of this bug . 

Knowing that Eclipse does it this way is one more reason not to use Eclipse :). Could it be that someone just copied the idea from Eclipse ?
Comment 6 Jan Lahoda 2010-01-19 02:38:09 UTC
Well, I think I can (relatively) easily prevent (re-)deployment of classes from source roots that contain compilation error (in java.source), but I always though this was one of the main reasons to introduce compile on save (it certainly was one of the main reasons in J2SE Project). Actually I think that not support from java.source would be necessary to implement DoS without deploying classes with error.

Please tell me exactly how do you what DoS to work for Web projects, and I will implement what I can in java.source.

bht: your problem is caused by a broken cache. Unfortunately, your description does not contain enough data to fix this problem. A report that would help us fix that problem (e.g. with a reproducible test case) would be very welcome. Note that if (re-)deployment of source roots with compilation errors would be disabled, you would not be able to (re-)deploy at all with DoS enabled.
Comment 7 bht 2010-01-19 15:19:06 UTC
Jan, Thanks for your comments.
I don't think I understand well enough how DoS works. I just see the effects of it. If I save a file that fails to compile then I don't understand how this can be deployed because I don't know how a valid class file can be generated for it.

Later the failed source file might become valid WITHOUT saving, without doing anything because the error might be resolved via a change in another referenced java file that does compile successfully.

I guess I am thinking about "Deploy on Compile" not "Deploy on Save", and I could imagine that a scheme like this is more complicated, but on the other hand I think the current system must be capable to deal with the above case anyway.

My problem with the "broken cache" is still reproducible. I just open the old project. Again I don't understand well enough but if a global cache is broken then how can I fix and break the cache by switching the project folders between the old broken project and the fixed new project with the same name and sources, after closing and re-opening the IDE? The IDE cannot distinguish the projects because they are in the same directory, just different versions copied into it.

But creating a testcase from it is a different matter. I have written so many testcases for NetBeans and I know the feeling when there is only a very slim chance of reducing a large project to a manageable testcase. This feels like it, like the problem is going to slip away, and the work involved would be huge. I just commented about it to show what kind of effects one can get with DoS. I am not going to delete the project yet, may be I will get an idea some time.
Comment 8 Petr Jiricka 2010-02-01 06:50:06 UTC
Changing to TASK - first need to agree on the desired behavior.
Comment 9 bht 2012-03-25 07:18:31 UTC
Where is the benefit of deploying a project that contains errors? Who would want to do that? Meanwhile, more than two years later:

1) no decision what the current behavior should be
2) no way for the user to fix the persistent problem using the IDE interface, in Eclipse, at least, the user can clean the project (Menu|Project|Clean)
3) acknowledgment that this is not limited to Deploy on Save - it happens with Compile on Save - see bug 210053