Compile Messages Window and warnings

I rebuild the whole project and get some warnings due deprecated
methods. Fine.

Now I modify a class and just Make the Project. Only the necessary
files are recompiled. Since those do not cause any warnings, the
message pane is hidden and the deprecation-warnings are not visible
any more.

I would appreciate it, if IDEA would be smart enough to keep the
warnings from files that aren't recompiled when doing a Make Project.

Tom

31 comments

Why not just suppress warnings. If you aren't going to look at them when they compile, then it doesn't seem like there is any value in having them displayed.

It even seem that you can disable just the deprecated methods, so if you don't want those, then you can disable that.

Mike

0

Hi Michael,

Maybe I wasn't clear enough: I want IDEA to show the warnings, so I
can get rid of it.

Currently I need to do a full recompile to see all warnings. On our
3500 classes project this takes its time...

Tom

0

No... You were clear. I didn't read properly.

How about something like when you recompile after making modifications, IDEA looks at the new sets of messages for the files compiled, and removes those messages from the list that are no longer relavant, but leaves others there. This way, you can incrementally go through warnings and remove them without having to recompile everything.

Mike

0

That's exactly what I want.

Tom

0

That does not make sense to me. I only want to see messages that are from the current compile. I do not want to see messages that are left over from a previous compile. If the depreciated warnings are an issue, why not fix them when you first see them or if you do not have time to fix them and want to get to them later put a note about fixing them on a todo list.

0

Consider the following scenario:

1) Make entire project - you get 47 warnings
2) Fix the first 7 warnings from the 1st file.
3) recompile that file.

Now all 47 warnings disappear. How do you get them back.

You must recompile the entire project. (thousands of files).

Instead, we want the behavior where only those warnings associated with the specific files that are recompiled are removed, leaving the list with 40 remaining warnings (I can now to and fix them).

Mike

0

Why not have an option that would let compiler output go to multiple
tabs, like what's done with the Find option? I think that would solve
both problems nicely. You'd have some additional compile/make setting
(or option) that would either default to multiple tabs, or allow
reporting of messages to another tab on a one-off basis.

Peter

Thomas Singer wrote:

Added an RFE: #11615.

Tom


0

You can "lock" the message tab (use context menu on it) and then compiler will output to a new tab.

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"



0

So the functionality is already there, would it be possible to add a new
compile dialog to allow one-shot output to a new tab,

or IDE setting which would globally allow "always output to new tab" or not?

Peter

Eugene Zhuravlev wrote:

You can "lock" the message tab (use context menu on it) and then compiler will output to a new tab.

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"



0

I know, but this is just a kind of "hack", because I cannot see, what
warnings are resolved -- they are still visible in the locked tab. To
see all remaining warnings, I need to do a full rebuild.

Tom

0

Hi Tom -

Just playing devil's advocate here, how would you be able to discern
whether messages were resolved or not on a recompile? What if you added
some lines of code? IDEA wouldn't be able to tell that the line numbers
had shifted, but the warning was the same (at least I wouldn't want it
to try).

What if you had the ability to delete or "mark fixed" messages from the
compiler output instead? Since I presume you're double-clicking on a
message to navigate to it and fix it, you could probably have some
additional option to remove the message from the "to do" list.

Peter

Thomas Singer wrote:

I know, but this is just a kind of "hack", because I cannot see, what
warnings are resolved -- they are still visible in the locked tab. To
see all remaining warnings, I need to do a full rebuild.

Tom


0

Well, on a full rebuild, the compiler generated a couple of messages
and IDEA knows, to what files they are related. On a Make Project only
a few files are recompiled and IDEA should only replace the messages
for these files with the newly created ones. Seems not very difficult,
isn't it?

Tom

0

Why not fix all 47 of them instead of just 7 of them? If time is the issue, then use the TODO functionality that is in idea to remind you that you still have 40 warnings to fix.

0

Ah I see, so you're just advocating that the messages for a particular
file be replaced completely. I agree with that then, and yes it should
be easy for IDEA to do that.

Thanks for the clarification, I may not have read your original message
correctly.

Peter

Thomas Singer wrote:

Well, on a full rebuild, the compiler generated a couple of messages
and IDEA knows, to what files they are related. On a Make Project only
a few files are recompiled and IDEA should only replace the messages
for these files with the newly created ones. Seems not very difficult,
isn't it?

Tom


0

Because sometimes it takes some time to fix them and I compile often
and feel uncomfortable when not doing a compile for 5 minutes.

Tom

0

What kind of warnings are you usually getting and are so eager to fix?


--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"

"Thomas Singer" <fake@fake.com> wrote in message news:selaav49fgd67v61h6v6f2a2ae2euea6bm@4ax.com...

Because sometimes it takes some time to fix them and I compile often
and feel uncomfortable when not doing a compile for 5 minutes.

>

Tom



0

Just read more carefully the original message: looks like most interesting for you are deprecation warnings. We've got a special
code inspection for it. Isn't it a solution? I think that the feature proposed looks much like a hack to javac-specific behaviour
and provided we already have relevant support, the feature is not worth-implementing.

--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"

"Eugene Zhuravlev" <jeka@intellij.com> wrote in message news:b84077$csh$1@is.intellij.net...

What kind of warnings are you usually getting and are so eager to fix?

>
>

--

>

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"

>

"Thomas Singer" <fake@fake.com> wrote in message news:selaav49fgd67v61h6v6f2a2ae2euea6bm@4ax.com...

Because sometimes it takes some time to fix them and I compile often
and feel uncomfortable when not doing a compile for 5 minutes.

>

Tom

>
>


0

Dear Eugen,

Did you tried it? I did and here are the results:

Full Rebuild (javac): 1:53min
Inspect Code (only Deprecation checked): 3:09min

So your suggestion takes more than double as much time as the Full
Rebuild!!!

And since removing deprecations isn't always a simple job (for
instance: setNextFocusableComponent()), you need to run the Inspect
Code again after solving one deprecation.

No, this is not a solution.

>... the feature is not worth-implementing.

I think, it is.

Tom

0

While I think I understand Thomas request,
I am happy enough with either

1) locking the full compile output window
(if I'm planning to go and fix most warnings in my current 'development
session')

2) adding a custom TODO tag (if removing the warnings is a low-prio,
ongoing task)

Edo



Thomas Singer wrote:

Dear Eugen,

Did you tried it? I did and here are the results:

Full Rebuild (javac): 1:53min
Inspect Code (only Deprecation checked): 3:09min

So your suggestion takes more than double as much time as the Full
Rebuild!!!

And since removing deprecations isn't always a simple job (for
instance: setNextFocusableComponent()), you need to run the Inspect
Code again after solving one deprecation.

No, this is not a solution.

>>... the feature is not worth-implementing.


I think, it is.

Tom


0

Thomas Singer wrote:

I know, but this is just a kind of "hack", because I cannot see, what
warnings are resolved -- they are still visible in the locked tab. To
see all remaining warnings, I need to do a full rebuild.


IDEA already keeps track of which files need to be recompiled when you
"make" your project. How about an option setting saying that files that
had warnings last time they were compiled should also be recompiled by
"make" (not only files that had errors or whose .class files are not up
to date)? Then you'd always get all your warnings, with up-to-date line
numbers and everything.

0

Sure, that your suggestion would work, but wouldn't that be another
hack? Not to mention, that it would increase the time, Make needs
(although I guess, it would be only a small amount of time).

Tom

0

just did an experiment for on one project here:
deprecated usages reported by javac (after rebuild-all) : 2
deprecated usages reported by inspection : 55

i think i'll stick with inspection. or maybe i should open an SCR...
of course, i would love to see incremental inspection.

"Thomas Singer" <fake@fake.com> wrote in message
news:heocav4ek9bp11ug8m1s6air7fp8c7argv@4ax.com...

Dear Eugen,

>

Did you tried it? I did and here are the results:

>

Full Rebuild (javac): 1:53min
Inspect Code (only Deprecation checked): 3:09min

>

So your suggestion takes more than double as much time as the Full
Rebuild!!!

>

And since removing deprecations isn't always a simple job (for
instance: setNextFocusableComponent()), you need to run the Inspect
Code again after solving one deprecation.

>

No, this is not a solution.

>

>... the feature is not worth-implementing.

>

I think, it is.

>

Tom



0

Strange, for me, javac reports more warnings than inspection did:
those where implementing an interface that has deprecated methods.

Tom

0

Thomas Singer wrote:

Strange, for me, javac reports more warnings than inspection did:
those where implementing an interface that has deprecated methods.

Tom


I find that warning to be a stupid one.
Usually you can do something to your code to avoid a warning - but not
that one : you have to fully implement an interface after all.

Having just one warning per @depre method declaration in an interface
would be enough for me.

Edo

0

>I find that warning to be a stupid one.
>Usually you can do something to your code to avoid a warning - but not
>that one : you have to fully implement an interface after all.

Completely agree with you.

Tom

0

mine are all use of deprecated methods... including the 2 that get reported
by rebuild

"Thomas Singer" <fake@fake.com> wrote in message
news:5cgdav0eqio4gfr32f7t4agvau9q626qlb@4ax.com...

Strange, for me, javac reports more warnings than inspection did:
those where implementing an interface that has deprecated methods.

>

Tom



0

Strange, for me, javac reports more warnings than inspection did:
those where implementing an interface that has deprecated methods.

>

Tom

>

I find that warning to be a stupid one.
Usually you can do something to your code to avoid a warning - but not
that one : you have to fully implement an interface after all.


In the release notes of the 1.4.1...+ versions, there was a reference to the
compiler ceasing to output warnings when a deprecated method
used/implemented/... deprecated methods/classes.

So, if you deprecate the methods in the implementation, the warnings should
disappear.

Carlos

PS: I have yet to test if this is true, and I'm feeling very lazy right now
to do tests :)


0

Sorry, the deprecation warnings still occur.

Tom


"Carlos Costa e Silva" <carlos@keysoft.pt> schrieb:

>> > Strange, for me, javac reports more warnings than inspection did:
>> > those where implementing an interface that has deprecated methods.
>> >
>> > Tom
>>
>> I find that warning to be a stupid one.
>> Usually you can do something to your code to avoid a warning - but not
>> that one : you have to fully implement an interface after all.
>
>In the release notes of the 1.4.1...+ versions, there was a reference to the
>compiler ceasing to output warnings when a deprecated method
>used/implemented/... deprecated methods/classes.
>
>So, if you deprecate the methods in the implementation, the warnings should
>disappear.
>
>Carlos
>
>PS: I have yet to test if this is true, and I'm feeling very lazy right now
>to do tests :)
>

0

>In the release notes of the 1.4.1...+ versions, there was a reference to

the

>compiler ceasing to output warnings when a deprecated method
>used/implemented/... deprecated methods/classes.

>

>

Sorry, the deprecation warnings still occur.

>

Tom


I was overeager, it's only 1.4.2 that has this resolved.

http://developer.java.sun.com/developer/bugParade/bugs/4346296.html

>PS: I have yet to test if this is true, and I'm feeling very lazy right

now

>to do tests :)


And this time I did test that the warning disappeared :)


0

Please sign in to leave a comment.