Community
Participate
Working Groups
I20040330 I have set some of the style and ununsed code options to error. The disadvantage of doing so is that the compiler doesn't generate complete class files anymore. For example if I have a unused local the compiler generates a method body throwing an UnresolvedCompilerError although from a JDK standpoint the code is correct. This is especially annoying with hot code replace.
Workaround is to set this as warnings and not errors.
Sure, we know this. In order to release clean code many of us have set unused private members and imports to 'error'. However, when you then quickly comment out some code and run (or debug) it no longer works. This is quite a pain.
If you decide these are errors, then we should not allow it to run with unresolved errors. This is the whole purpose of raising errors. Leave them as warning, and start fixing them, so that your set of warnings become manageable again.
Philippe, I don't agree here. The problem is that these problems are neither warning nor errors (we discussed this a while ago). Since we can't change this we switch them to errors to get their attention. But if I am under developement with hot code replace it really hurts not being able to execute the code. Can you please reconsider this request.
+1 Not fixing this bug renders the "error" state for all our additional checks useless (at least for me): why would anybody set the state to error for e.g. imports or unused code because you cannot run/debug? On the other side, not all checks have the same importance but since I now have to flag them as warning and since we have lots of them, they don't get any attendance anymore and bad code gets released to the repository.
Reopening, but recategorizing as LATER. I am still not convinced this would be a good idea. What you'd like instead is to have several levels of warnings. Errors have to be fatal and prevent running the code. I don't think people would understand being able to run code with errors as if there was none... I strongly believe you should address warning categories one at a time to bring them down to a manageable set. If you waited so long without addressing them, then I can understand your being overhelmed now, but then you should focus on a few critical ones, then reveal more of them as you fixed the first ones.
Not for 3.0
Re: comment#5. This is not a bug, but working as per design. Thinking more about it, if we did allow generating errors and still issuing functional classfiles, then users would get confused by errors which prevent from running (JLS errors). There is no way you could tell the difference, and this would make the tools useless. How can you determine if you can export and deploy code any longer ? Just guess... We have another PR for providing refinements on warning severities. I consider this one closed.
Working as expected.
The other PR is bug 47340.
