Compile behaviour

At some point in the eap cycle (around late 9xx) compile file stopped working for me.

Or rather, its behaviour was modified from the previously useful state to a rather non-useful state.

Previously, when choosing compile class, the class as well as any modified dependencies it had was compiled. This no longer seems to be the case, and I'd like to know if this change is intentional (and what logic there is behind it), or not. Here's an example to clarify:

Compile class A (which calls B.doSomething)

Rename method B.doSomething to B.doFoo

Modify class A to call doFoo

Compile class A

Previously the last step would have resulted in a successful compilation. Currently it does not, instead you get an error saying that doFoo does not exist.

This behaviour IMHO makes compile class completely useless.

0
25 comments

I noticed the same.

I started to use make project instead of compile.

0

Yes, the behaviour is intentional. The inention was to make compiler compile exactly those classes that were selected and not
compile those files that were not explicitly chosen.
If you want to compile all modified files as well as those that depend on them, use "make".

--

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



0

The problem with using make is that it compiles all dirty files in the project (in all modules), this is definitely not what I want, especially with very large projects. I still think that the old method of 'compile this class and all its deps ONLY' is desperately needed, instead of it being either this one class or all dirty classes in this project....or am I missing an option here?

0

Well, previous behaviour also was not working as you described. It compiled only those classes that were directly used from the
class on which the compilation was started (this is how javac works).
Consider the situation:

public class A {
public static void main(String[] args) {
B.bar();
}
}

public class B {
public static void bar() {
C.foo();
}
}

public class C {
public static void foo() {}
}

If you modify C, leave B untouched and then invoke compilation on A, C won't be recompiled, while it should.

We just made the ctrl-shift-F9 behaviour consistent: it tries to compile the exact set of files that was specified.
Why not compile the whole project once and then use make? It works faster than explicit recompilation of modified files and it
tracks "back" depandancies between classes - the thing that javac does not do.
In latest Aurora builds it is also possible to compile concrete module and if you have "Make before run/debug" checkbox checked,
then only modules needed to run particular class will be maked.

--

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

"Hani Suleiman" <hani@formicary.net> wrote in message news:10285855.1072544995511.JavaMail.itn@is.intellij.net...

The problem with using make is that it compiles all dirty files in the project (in all modules), this is definitely not what I

want, especially with very large projects. I still think that the old method of 'compile this class and all its deps ONLY' is
desperately needed, instead of it being either this one class or all dirty classes in this project....or am I missing an option
here?


0

Yeah, I realise that, but at least it was consistent with what javac did!

Anyway, compile module could fix it for me, with the following two provisions:

1) It remembers failures (eg, if I previously compiled class X, and it didn't compile, it doesn't try again unless I change it or do a rebuild module)
2) It's available via a shortcut, not just the run/debug dialog.

0

Regarding compile all, there's also an EXTREMELY annoying bug where if using jikes and a bunch of libraries are missing, the compile toolwindow cannot be stopped, and all further compilation attempts do nothing, and only an IDEA restart will fix it.

0

Could you please submit an SCR for this?

"Hani Suleiman" <hani@formicary.net> wrote in message news:14206114.1072547866814.JavaMail.itn@is.intellij.net...

Regarding compile all, there's also an EXTREMELY annoying bug where if using jikes and a bunch of libraries are missing, the

compile toolwindow cannot be stopped, and all further compilation attempts do nothing, and only an IDEA restart will fix it.


0

Yes, we'll provide a separate "Make Module" action which will work as you described.

BTW, could you suggest a good shortcut for it?
--

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


"Hani Suleiman" <hani@formicary.net> wrote in message news:33238878.1072547759765.JavaMail.itn@is.intellij.net...

Yeah, I realise that, but at least it was consistent with what javac did!

>

Anyway, compile module could fix it for me, with the following two provisions:

>

1) It remembers failures (eg, if I previously compiled class X, and it didn't compile, it doesn't try again unless I change it or

do a rebuild module)

2) It's available via a shortcut, not just the run/debug dialog.



0

Hm, I'd say that it'd make sense to modify the existing make shortcut to be make module. This would be backward compatible as all old projects will have just one module, and it makes more sense (to me at least) to have it be one key since you're a lot more likely to be working/testing in one module rather than the whole project. No idea though on what a good new shortcut would be, since I don't even use the defaults ;). I map compile/make to F5 and F6 respectively, much faster to have it one key away!

Working on a testcase project for the other compile issue, I'll file an SCR once I've reproduced it in the test project.

0

I reported this few times. If you are on windoze, open task manager and kill Jike proces, that way you don't have to restart Idea.

0


"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message news:bske2q$crq$1@is.intellij.net...

Yes, the behaviour is intentional. The inention was to make compiler compile exactly those classes that were selected and not
compile those files that were not explicitly chosen.
If you want to compile all modified files as well as those that depend on them, use "make".


I agree with Hani, it's not always convenient to use "make". Code is getting more
and more reused between projects so in most cases I have a lot of
pieces of other projects in my workspace with the single purpose to apply
refactorings to them also along the way. They can't be compiled properly in some/most
cases and must be excluded manually which is quite annoying and errorprone
(especially if you need to flip this setting from time to time and/or they are
spreaded through multiple packages).
Explicit compilation is a somewhat easier workaround for the problem since it
is an all visual and one-time action. It's still just a workaround though...
So would you consider the following improvements:

1. Make "make" to work with selected files/packages, i.e.
perform "make" operation for
a) selected files only or
b) for the whole project with selected files excluded

2. Add file/package "temporarily included/excluded" state controllable
via right-click menu plus a "temporary status enable/disable" button
in the toolbar. So I can assign included/excluded state to my source files
and ignore all these settings altogether when I need to rebuild everything.

3. Add "non-project source file[s]" state and/or folder[s] with an option
(enable/disable button?) to include/exclude such files into autocompletion
drop-downs (or, at least, just permanently exclude). It would also be very
convenient to have project/non-project views so I can separate foregn files
into a different subtree in the project view.

So the idea is to allow some foregn files to be present and refactored without.
getting on the way too much. 2. and 3. are essentually the same thing. 3. is somewhat
more elaborate though. The same approach can be applied to modules.

--Oleg


0

There's pretty simple solution to get previous behavior back!
Just add "-sourcepath ]]>" as additional compiler arguments and voila! :)

P.S. I still beleive it should be available without such tricks.

--Dima

0

I agree that it should be changed back! This is VERY annoying! I get compile errors all the time now! I have to track down which OTHER classes need to be compiled to make it work. I don't always want to use "make." I want to use IDEA like I used to which was VERY PRODUCTIVELY! I paid for the new version only to be blind-sided by this "feature" which now makes my development life a pain. I am NOT happy! Please change it back QUICKLY!

0

I don't always want to use "make."


Are there any serious reasons for not using make?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


"James Carman" <no_mail@jetbrains.com> wrote in message news:10078605.1079615006985.JavaMail.itn@is.intellij.net...

I agree that it should be changed back! This is VERY annoying! I get compile errors all the time now! I have to track down

which OTHER classes need to be compiled to make it work. I don't always want to use "make." I want to use IDEA like I used to
which was VERY PRODUCTIVELY! I paid for the new version only to be blind-sided by this "feature" which now makes my development
life a pain. I am NOT happy! Please change it back QUICKLY!


0

Eugene Zhuravlev wrote:

Are there any serious reasons for not using make?


I went over to using make long ago and prefer it, but the issue is
imposing the make metaphor on people who aren't accustomed to it or
comfortable with it yet and who want the conventional compilation of a
java file instead of the explicit compilation in IDEA. I'm with you that
make is generally a preferable approach once you get used to it, but it
confuses people at first and many feel imposed upon once they do see how
things works. Forcing use of the make metaphor due to explicit
compilation limitations comes across as heavy-handed. I've tried to come
up with a way to help the new user with SCR 30120 that I hope gets
implemented as soon as possible. Another approach is to also allow
people to "make" a file that would compile the conventional way - to
have this in addition to explicit compilation. I'm sure there is an SCR
or two for this, but they seem to always get closed. So, I'm with you on
the superiority of make but I want users to be weened into using it
without the bewilderment and frustration that can turn them off, a turn
off that none of us want to happen to new IDEA folks most especially
during evaluations of IDEA.

Jon

0

How about consistency with every other compiler out there?

0

In terms of real life usage, I've found that when I'm heavy development, I often like to be able to compile certain pieces without building the whole project (because I know there are other areas that won't compile yet). The current approach forces me to either track down the dependency graph manually for the class I want to compile, or to ensure that the whole project is compilable.

0

That is EXACTLY what I'm running into. Sometimes, in the middle of my development, I like to write little "spike" solutions to test out ideas. And, maybe my other "real" or "half-baked" code doesn't necessarily compile yet (as I'm in the middle of an idea and need to test it out), but I want to compile and run my "spike." Having to track down the dependency graph in these situations is very annoying. In the mean-time, I HAVE switched to using make and it works wonderfully! But, please fix this issue.

0

What I really don't understand is why the original feature was removed.
I mean, by all means add an extra compile action to compile just the
selected file, but don't get rid of a perfectly good action that's
already there! You expect a newer version of your IDEA to add features,
not take them away! Sadly it seems version 4 has taken away features in
a number of other areas too.

I know what you're gonna say, you can't make an omelette without
breaking eggs, but don't start asking us why we eat our eggs a different
way some times?

(yeah I know that's a pretty tenuous metaphor, but hey ;) )

N.

Eugene Zhuravlev wrote:

>>I don't always want to use "make."


Are there any serious reasons for not using make?

0

Ok, understood.
Never had such problems myself because I try to keep the project always in compilable state. For small experiments the number of
files to be compiled is known and it is easy to select them all and compile (though I use make for this :-). And more "advanced"
experimental code lives in a separate test project.

Anyway, let me explain why the behaviour was changed. This is all about multiple output paths and modules with overlapping contents.
When you explicitly compile a file, that depends on another file, which is located in a different module, this second file will be
put in the output directory of the first module which is wrong. Unfortunately there are no ways to tell javac to ignore some files,
the only way is to run against explicitly specified list of files.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"James Carman" <no_mail@jetbrains.com> wrote in message news:24986799.1079629982215.JavaMail.itn@is.intellij.net...

That is EXACTLY what I'm running into. Sometimes, in the middle of my development, I like to write little "spike" solutions to

test out ideas. And, maybe my other "real" or "half-baked" code doesn't necessarily compile yet (as I'm in the middle of an idea
and need to test it out), but I want to compile and run my "spike." Having to track down the dependency graph in these situations
is very annoying. In the mean-time, I HAVE switched to using make and it works wonderfully! But, please fix this issue.


0

In a case like this, does IDEA have enough information on dependencies,
out-of-date & modules to do the appropriate number of module-only
javac's using explicit compilation so that the compilation outputs go to
the right destinations and all the dependent compilations are done?

Eugene Zhuravlev wrote:

This is all about multiple output paths and modules with overlapping contents.
When you explicitly compile a file, that depends on another file, which is located in a different module, this second file will be
put in the output directory of the first module which is wrong. Unfortunately there are no ways to tell javac to ignore some files,
the only way is to run against explicitly specified list of files.

0

jikes can be killed from the Windows TaskMgr, but it’s very annoying cannot argue about it.

0

Theoretically, yes, it has such information. But obtaining it would cause unacceptable overhead and slow down compilation.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


"Jon Steelman" <jon@cc.gatech.edu> wrote in message news:c3cqqj$ig8$1@is.intellij.net...

In a case like this, does IDEA have enough information on dependencies,
out-of-date & modules to do the appropriate number of module-only
javac's using explicit compilation so that the compilation outputs go to
the right destinations and all the dependent compilations are done?

>

Eugene Zhuravlev wrote:

This is all about multiple output paths and modules with overlapping contents.
When you explicitly compile a file, that depends on another file, which is located in a different module, this second file will

be

put in the output directory of the first module which is wrong. Unfortunately there are no ways to tell javac to ignore some

files,

the only way is to run against explicitly specified list of files.



0

One reason is the need to build webapp exploded directories. This seems
to take quite a bit of time.

Eugene Zhuravlev wrote:
>>I don't always want to use "make."


Are there any serious reasons for not using make?


--
Barry Kaplan
bkaplan@integratedtrading.com

0

Please sign in to leave a comment.