3 ms·

> You can't run code unless the whole project compiles (poor for quick sanity check, test driven development, and refactoring breaking changes). What do you me

by lma21 6y ago

> You can't run code unless the whole project compiles (poor for quick sanity check, test driven development, and refactoring breaking changes). What do you mean by _running_ specific parts of the code? Isn't this a language problem (compile all dependencies (classes) to byte code, package .class files in jar files, define the main class, define the classpath, and then run)?

thu2111 6y ago
Eclipse uses a special compiler that can compile code even if it's got errors. Parts of the code that don't compile get compiled to just a stub that throws an exception. Some devs really like this. I never really encounter it as a problem because for any refactoring, I prefer to use IntelliJ's refactoring tools that ensure all code (that's in your project at least) gets rewritten in the same moment the refactoring occurs.
- adrianmsmith 6y ago
  > IntelliJ's refactoring tools that ensure all code (that's in your project at least) gets rewritten in the same moment the refactoring occurs That's the same as Eclipse (e.g. rename method), right? What's the benefit of IntelliJ here?
  - dcminter 6y ago
    Pretty much. They both have refactoring operations, but they're a slightly different set. (Edit: Some of the IntelliJ operations are distinctly superior to the Eclipse ones. But not all. In my experience I'd say they're about even here.) For example, in Eclipse it's trivial to take an inner class and move it to its own file. In IntelliJ that doesn't seem to be an option. And that's a breaking change if I do it manually, which is where the Problems panel is so useful. Not forgetting TDD where in Eclipse I can write multiple tests for a feature before any code exists and run them before the unit I'm testing even fully compiles! For example, in this screenshot one of the methods the test class invokes doesn't exist: https://paperstack.com/img/ides/eclipse_run_broken_code.png https://paperstack.com/img/ides/eclipse_run_broken_code.png
    - pavlus 6y ago
      1. For static class: Refactor > Move Inner Class then choose from: a) move it to upper level (new java file), or b) move to another class 2. For non-static class: Refactor > Move Inner Class to Upper Level Then you can select class name and parameter name of formerly enclosing class.
      - dcminter 6y ago
        Ah yes, you're right. Maybe it's Groovy classes that this doesn't work for? Still, when a refactoring operation doesn't exist for a code change (even if it's due to operator ignorance) it's nice to have the Problems pane to tidy up with.

by lma21 6y ago

thu2111 6y ago

Eclipse uses a special compiler that can compile code even if it's got errors. Parts of the code that don't compile get compiled to just a stub that throws an exception. Some devs really like this. I never really encounter it as a problem because for any refactoring, I prefer to use IntelliJ's refactoring tools that ensure all code (that's in your project at least) gets rewritten in the same moment the refactoring occurs.

adrianmsmith 6y ago
> IntelliJ's refactoring tools that ensure all code (that's in your project at least) gets rewritten in the same moment the refactoring occurs That's the same as Eclipse (e.g. rename method), right? What's the benefit of IntelliJ here?
- dcminter 6y ago
  Pretty much. They both have refactoring operations, but they're a slightly different set. (Edit: Some of the IntelliJ operations are distinctly superior to the Eclipse ones. But not all. In my experience I'd say they're about even here.) For example, in Eclipse it's trivial to take an inner class and move it to its own file. In IntelliJ that doesn't seem to be an option. And that's a breaking change if I do it manually, which is where the Problems panel is so useful. Not forgetting TDD where in Eclipse I can write multiple tests for a feature before any code exists and run them before the unit I'm testing even fully compiles! For example, in this screenshot one of the methods the test class invokes doesn't exist: https://paperstack.com/img/ides/eclipse_run_broken_code.png https://paperstack.com/img/ides/eclipse_run_broken_code.png
  - pavlus 6y ago
    1. For static class: Refactor > Move Inner Class then choose from: a) move it to upper level (new java file), or b) move to another class 2. For non-static class: Refactor > Move Inner Class to Upper Level Then you can select class name and parameter name of formerly enclosing class.
    - dcminter 6y ago
      Ah yes, you're right. Maybe it's Groovy classes that this doesn't work for? Still, when a refactoring operation doesn't exist for a code change (even if it's due to operator ignorance) it's nice to have the Problems pane to tidy up with.