GWT refactoring: classes, modules, rename the whole project - java

I am writing here because of desperation caused by refactoring a GWT project.
My first try:
After I read all the praises of the refactoring tool from Eclipse ( I am using it as IDE) I simply right clicked on a module ( what a fool i was ) and use the refactoring option. My project became unusable.
First Conclusion:
Found out that I need to start with the classes and then go up and refactor a module at a time.
Second try:
Refactored some classes, worked fine until I messed something related to a ui.xml file. Project unusable!
Second Conclusion:
Be careful at the ui.xml files!
Third try:
Went pretty well, but I got ahead of myself and tried to remove some comments or replace class names in comments. Predictable result : project unusable!
Third Conclusion:
Try again!
Forth try:
Fail!
Fifth try:
Fail!
You get the picture.
Can someone experienced with GWT please offer some guidelines about the mystical realm of refactoring?

GWT has some rules based on naming conventions (e.g. the two interfaces for GWT-RPC, the *.ui.xml files and the class that uses them through UiBinder, the files related to ClientBundle or ImageBundle methods, the *.properties files for I18N), so failing to respect them when renaming/moving one class/file will break it.
GWT also sometimes references classes by name in non-Java files (#eval in the *.css of a CssResource, or in *.ui.xml files), non-Java portions of classes (JSNI) or string literals (e.g. in #ProxyForName and #ServiceName). Failing to update them all will break the build.
Because a tool makes it easy to refactor does not mean you should let it do it blindly: it's just a tool, you have to understand what it does and double-check it (hint: check the box in Eclipse that forces a preview before applying the refactoring) so it doesn't do too much or too few.

Related

Use of modules within Java programming

Hopefully this is a question that only needs a fairly quick answer, but I haven't had much luck finding something online that is in terms I understand!
Quite simply, I'm working on my first real project in Java, a text adventure, (using IntelliJ IDEA) and I was just wondering if I need to be splitting my code into modules? So, for my monsters, should I keep all of my monster classes within a module called Monsters, or can I just keep it in the same module?
I only ask because; a) I wasn't sure whether it was a done thing in order to keep the project tidy and b) When I tried to create a Monster module, I received a warning telling me that the files in this module wouldn't be accessible from the rest of the program, which seems to defeat the object to me...
Many thanks in advance for any advice!
I believe you are referring to IntelliJ's concept of a module. As stated on their page:
A module is a discrete unit of functionality which you can compile, run, test and debug
independently.
Modules contain everything that is required for their specific tasks:
source code, build scripts, unit tests, deployment descriptors, and
documentation. However, modules exist and are functional only in the
context of a project.
So, modules should not be referencing the source code from other modules. They should essentially be completely different units.
As in thecbuilder's answer, you should look into using Java's packaging system instead.
By modules if you mean packages, then its a good habit to keep related classes in one package and distributing unrelated classes in different packages.
And to the thing, that the classes wouldn't be accessible, you'll have to make them public to access them from different packages.
More on package structuring :
http://www.javapractices.com/topic/TopicAction.do?Id=205
http://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html
https://stackoverflow.com/a/3226371/3603806
For access specifiers :
Taken from : http://www.go4expert.com/articles/java-access-specifiers-t28019/

How I can find all unused import programmatically?

In my case there are two reason for doing that:
Sometimes people by mistake import classes which present in macbooks JDKs but absent in Linux. That causes build to fail on ci servers which are Linux based boxes. I doesn’t happen frequently, but when it does happened I'm thinking that there should be some smarter way to find out that earlier.
Unused imports trigger warning in IDE/code analysis. From time to time somebody need to spend time on cleaning up this stuff. Even if its just single right click in IDE you still need to commit your changes and make sure everything alright on build.
I'm curious if there is any way to find unused imports programmatically (lets say from unit test) and fail locally if there are any.
Maybe failing a build because of unused import sounds harsh, but if it saves time for team overall it makes sens to do so (would love to hear opinion on that as well).
UPDATE:
I followed yegor256 suggestion and incorporated Checkstyle task with initially small subset of Sun Code Conventions (unused imports is one of them) and made it break a build if violations found.
After one week of trial we've got zero unused imports in our codebase and surprisingly zero complaints about this rule (by the way, Checkstyle is really fast: analyzing ~100KLoc taking less than one second).
As for using IDE for such analysis: yes, it good choice, but having this kind of checks run as part of automated build is better.
What you're trying to do is called static code analysis. Checkstyle can help you. If you're using Maven, this plugin will do the automation for you: http://maven.apache.org/plugins/maven-checkstyle-plugin/
You can also take a look at qulice.com (I'm one of its developers), which integrates a few static analysis tools and pre-configures them (incl. Checkstyle, PMD, FindBugs).
If you are using eclipse IDE or IntelliJ IDEA, you can configure them to
1a. organize imports / remove unused imports on save or before commit (see cleanup preferences)
1b. switch the "unused imports" warning to an error (see error settings)
2a. configure a jre which does not include com.* stuff
2b. configure the warning of proprietary api usage from the jre to be an error
You might still want to check that on the build server, though. In this case the more complicated stuff like configuring CheckStyle would still be necessary.
I'm curious if there is any way to find unused imports programmatically (lets say from unit test) and fail build locally if there are any.
I use IntelliJ to organise imports, this removes all the unused imports. You can do this with one hot key from the top of you code base to correct all the imports. (It also has over 700 other types of static checks and fixes)
Maybe failing a build because of unused import sounds harsh, but if it saves time for team overall it makes sens to do so (would love to hear opinion on that as well).
I have IntelliJ check in code which formatted and with imports organised so the issue never arises in the first place. ;)
In Computer Science the name given to such a process of analyzing the code without executing is known as static code analysis.
Try using an IDE, I am using Eclipse, which marks all the Unused imports and Unused Variables or methods in with a Yellow color underline....
Aren't these unrelated questions? If you import classes only present in the local JDK, these imports are used (just unsatisfied). For either problem, I recommend solving it in the IDE so the problem will be detected when code is written, rather than prior to checkin (the earlier the detection, the easier the fix ...).
In eclipse, you could prevent unsatisfied imports with access rules, and automatically fix imports whenever a source file is saved by enabling the appropriate save action. If you check these settings into version control, you can easily share them with the team.
I see lot of comments in same way that use this IDE or that IDE. But all my friends try to understand the difference. Doing something programmatically is different and using IDE is different.
If I want a process to be programmatic then suggestion of IDE is not useful. It might be possible some one is asking this question because he is building complete process and this step is part of it. How opening IDE would help him on different machines and OS where CI is working?
I too building one tool on similar lines. I achieved it up to some level but it programmatically open IDE and close it automatically and fixes source code too. But opening same in Linux might be a question for me.
Understanding some one's view before answering is really very important.

Why use link option when import file into eclipse project?

I know that there is the option to have links to source code under your src directory instead of having the source code files directly in your Eclipse project.
When is this case i.e. links for source code is best used?
I always found it more convenient to have the source code inside the Eclipse project
I can think of two possible use cases for this.
The first would be if you want to keep your source and IDE meta-data separate. For example it may be that some developers use Eclipse and some IntelliJ. In this case you would probably only want the source of the project to be stored in SCM, as otherwise, one set of developers are going to have to remove meta-data before importing the project. If they just link to the source, they can maintain there own meta-data for there IDE. Obviously this isn't an issue if everyone uses the same IDE.
The second use case would be dependencies. Say for example your working on two different projects A and B where A depends on B. If your not using a dependency management tool or willing to build and import the Jar from B to A each time you modify it, you could link to the source in B instead.
I'm sure there are plenty of other use cases floating around.
In addition to what Kingamajick mentions, you could have a structure that causes overly long path names.
Windows can only handle so much (256 characters? in older versions), and a deep package structure easily breaks that limit.
So, having your classes in a shallow directory near the top allows you to have your workspaces deeper down, and still leaves some room to wiggle.
Other scenarios; You have source code which is common for several OS:es, but the Eclipse projects are specific for each OS.
You can also create a form of linked resources that are relative to an environment variable. I've used that for situations where the version control system (ClearCase) adds user-specific catalognames.

A tool to detect broken JAR dependencies on class and method signature level

The problem scienario is as follows (Note: this is not a cross-jar dependency issue, so tools like JarAnalyzer, ClassDep or Tattletale would not help. Thanks).
I have a big project which is compiled into 10 or more jar artifacts. All jars depend on each other and form a dependency hierarchy.
Whenever I need to modify one of the jars, I would check out the relevant source code and the source code for projects that depend on it. Modify the code, compile, repackage the jars. So far so good.
The problem is: I may forget to check one of the dependent projects, because inter-jar dependencies can be quite long, and may change with time. If this happens some jars may go "out-of-sync" and I will eventually get a NoSuchMethodException or a some other class incompatibility issue at run-time, which is what I want to avoid.
The only solution I can think of, the most straighforward one, is to check out all projects, and recompile the bunch. But this takes time, especially if I re-build it every small change. I do have a continuous integration server, that could do this for me, but it's shared with other developers, so seeing if the build breaks is not an option for me.
However, I do have all the jars so hypothetically it should be possible to verify jars which depend on the code that I modified have an inconsistency in method signature, class names, etc. But how could I perform such check?
Has anyone faced a similar problem before? If so, how did you solve it? Any tools or methodologies would be appreciated.
Let me know if you need clarification. Thanks.
EDIT:
I would like to clarify my question a little bit.
The ultimate goal of this task is to check that the changes that I have made will compile against the whole project. I am looking for a tool/technique that would aid me perform such check.
Consider this example:
You have 2 projects: A and B which are deployed as A.jar and B.jar respectively. A depends on B.
You wish to modify B, so you check it out and modify a method signature that A happens to depend on. You can compile B and run all tests by itself without any problems because B itself does not depend on anything. So you happily commit your changes.
In a few hours the complete project integration fails because A could not be compiled!
How do I avoid this?
The kind of tool I am looking for would retrieve A.jar and check that all dependencies in A on the new modified B are still fine. Like a potential compilation error that would happen if I were to recompile A and B sources together.
Another solution, as was suggested by many of you, is to set up a local continuous integration system that would recompile the whole project locally. I don't mind doing this, but I want to avoid doing it inside my workspace. On the other hand, if I check-out all sources to another temporary workspace, then I need to mirror my local changes to the temporary workspace.
This is quite a big issue in my team, as builds break very often because somebody forgot to check out (or open in Eclipse) the right set of projects. I tried persuading people to check-out source and recompile the bunch before commits, but not only it takes time, it needs running quite a few commands so most people just find it too troublesome to do. If the technique is not easy or automated, then it's unusable.
If you do not want to use your shared continuous integration server you should set up a local one on your developer machine where you perform the rebuild processes on change.
I know Jenkins - it is easy to setup (just start) on a local machine and I would advice to run it locally if no one is provided in the IT infrastructure that fits your needs.
Checking signatures is unfortunately not enough. Having the correct signatures does not mean it'll work. It's all about contracts and not just signatures. I mean what happens if the new version of a library has the same method signature, but accepts an ArrayList parameter now in reversed order? You will run into issues - sooner or later. I guess you maybe consider implementing tools like Ivy or Maven:
http://ant.apache.org/ivy/
http://maven.apache.org/
Yes it can be pain to implement it but once you have it it will "guard" your versions forever. You should never run into such an issue. But even those build tools are not 100% accurate. The only proper way of dealing with incompatible libraries, I know you won't like my answer, is extensive regression testing. For this you need bunch of testing tools. There are plenty of them out there: from very basic unit testing (JUnit) to database testing (JDBC Proxy) and UI testing frameworks like SWTBot (depends if your app is a web app or thick client).
Please note if your project gets really huge and you have large amount of dependencies you always not using all of the code there. Trying to check all interfaces and all signatures is way too much. Its not necessary to test it all when your code use lets say 30 % of the library code. What you need is to test what you really use. And this can be only done with extensive regression testing.
I have finally found a whole treasure box of answers at this post. Thanks for help, everyone!
The bounty goes to K. Claszen for the quickest and most input.
I'm also think that just setup local Jenkins is a best idea. What tool you use for build? Maybe you can improve you situation with switching to Maven as build tool? In more smart and don't recompile full project if you don't ask it directly. But switch to in can be HUGE paint in the neck - it hardly depends on how you project organized now...
And about VCS- exist Mercurial/SVN bridge - so you can use local Mercurial for you development ....
check this link: https://www.mercurial-scm.org/wiki/WorkingWithSubversion
There is a solution, jarjar, which allows to have different versions of the same library to be included multiple times in the dependency graph.
I use IntelliJ, not Eclipse, so maybe my answer is too IDE-specific. But in IntelliJ, I would simply include the modules from B into A, so that when I make changes to A, it breaks B immediately when compiling in the IDE. Modules can belong to multiple projects, so this is not anything like duplication, it's just adding references in the IDE to modules in other projects.

Things possible in IntelliJ that aren't possible in Eclipse?

Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I have heard from people who have switched either way and who swear by the one or the other.
Being a huge Eclipse fan but having not had the time to try out IntelliJ, I am interested in hearing from IntelliJ users who are "ex-Eclipsians" some specific things that you can do with IntelliJ that you can not do with Eclipse.
Note: This is not a subjective question nor at all meant to turn into an IDE holy war. Please downvote any flamebait answers.
CTRL-click works anywhere
CTRL-click that brings you to where clicked object is defined works everywhere - not only in Java classes and variables in Java code, but in Spring configuration (you can click on class name, or property, or bean name), in Hibernate (you can click on property name or class, or included resource), you can navigate within one click from Java class to where it is used as Spring or Hibernate bean; clicking on included JSP or JSTL tag also works, ctrl-click on JavaScript variable or function brings you to the place it is defined or shows a menu if there are more than one place, including other .js files and JS code in HTML or JSP files.
Autocomplete for many languagues
Hibernate
Autocomplete in HSQL expressions, in Hibernate configuration (including class, property and DB column names), in Spring configuration
<property name="propName" ref="<hit CTRL-SPACE>"
and it will show you list of those beans which you can inject into that property.
Java
Very smart autocomplete in Java code:
interface Person {
String getName();
String getAddress();
int getAge();
}
//---
Person p;
String name = p.<CTRL-SHIFT-SPACE>
and it shows you ONLY getName(), getAddress() and toString() (only they are compatible by type) and getName() is first in the list because it has more relevant name. Latest version 8 which is still in EAP has even more smart autocomplete.
interface Country{
}
interface Address {
String getStreetAddress();
String getZipCode();
Country getCountry();
}
interface Person {
String getName();
Address getAddress();
int getAge();
}
//---
Person p;
Country c = p.<CTRL-SHIFT-SPACE>
and it will silently autocomplete it to
Country c = p.getAddress().getCountry();
Javascript
Smart autocomplete in JavaScript.
function Person(name,address) {
this.getName = function() { return name };
this.getAddress = function() { return address };
}
Person.prototype.hello = function() {
return "I'm " + this.getName() + " from " + this.get<CTRL-SPACE>;
}
and it shows ONLY getName() and getAddress(), no matter how may get* methods you have in other JS objects in your project, and ctrl-click on this.getName() brings you to where this one is defined, even if there are some other getName() functions in your project.
HTML
Did I mention autocomplete and ctrl-clicking in paths to files, like <script src="", <img src="", etc?
Autocomplete in HTML tag attributes. Autocomplete in style attribute of HTML tags, both attribute names and values. Autocomplete in class attributes as well.
Type <div class="<CTRL-SPACE> and it will show you list of CSS classes defined in your project. Pick one, ctrl-click on it and you will be redirected to where it is defined.
Easy own language higlighting
Latest version has language injection, so you can declare that you custom JSTL tag usually contains JavaScript and it will highlight JavaScript inside it.
<ui:obfuscateJavaScript>function something(){...}</ui:obfuscateJavaScript>
Indexed search across all project.
You can use Find Usages of any Java class or method and it will find where it is used including not only Java classes but Hibernate, Spring, JSP and other places. Rename Method refactoring renames method not only in Java classes but anywhere including comments (it can not be sure if string in comments is really method name so it will ask). And it will find only your method even if there are methods of another class with same name.
Good source control integration (does SVN support changelists? IDEA support them for every source control), ability to create a patch with your changes so you can send your changes to other team member without committing them.
Improved debugger
When I look at HashMap in debugger's watch window, I see logical view - keys and values, last time I did it in Eclipse it was showing entries with hash and next fields - I'm not really debugging HashMap, I just want to look at it contents.
Spring & Hibernate configuration validation
It validates Spring and Hibernate configuration right when you edit it, so I do not need to restart server to know that I misspelled class name, or added constructor parameter so my Spring cfg is invalid.
Last time I tried, I could not run Eclipse on Windows XP x64.
and it will suggest you person.name or person.address.
Ctrl-click on person.name and it will navigate you to getName() method of Person class.
Type Pattern.compile(""); put \\ there, hit CTRL-SPACE and see helpful hint about what you can put into your regular expression. You can also use language injection here - define your own method that takes string parameter, declare in IntelliLang options dialog that your parameter is regular expression - and it will give you autocomplete there as well. Needless to say it highlights incorrect regular expressions.
Other features
There are few features which I'm not sure are present in Eclipse or not. But at least each member of our team who uses Eclipse, also uses some merging tool to merge local changes with changes from source control, usually WinMerge. I never need it - merging in IDEA is enough for me. By 3 clicks I can see list of file versions in source control, by 3 more clicks I can compare previous versions, or previous and current one and possibly merge.
It allows to to specify that I need all .jars inside WEB-INF\lib folder, without picking each file separately, so when someone commits new .jar into that folder it picks it up automatically.
Mentioned above is probably 10% of what it does. I do not use Maven, Flex, Swing, EJB and a lot of other stuff, so I can not tell how it helps with them. But it does.
There is only one reason I use intellij and not eclipse: Usability
Whether it is debugging, refactoring, auto-completion.. Intellij is much easier to use with consistent key bindings, options available where you look for them etc. Feature-wise, it will be tough for intellij to catch up with Eclipse, as the latter has much more plugins available that intellij, and is easily extensible.
Probably is not a matter of what can/can't be done, but how.
For instance both have editor surrounded with dock panels for project, classpath, output, structure etc. But in Idea when I start to type all these collapse automatically let me focus on the code it self; In eclipse all these panels keep open leaving my editor area very reduced, about 1/5 of the total viewable area. So I have to grab the mouse and click to minimize in those panels. Doing this all day long is a very frustrating experience in eclipse.
The exact opposite thing happens with the view output window. In Idea running a program brings the output window/panel to see the output of the program even if it was perviously minimized. In eclipse I have to grab my mouse again and look for the output tab and click it to view my program output, because the output window/panel is just another one, like all the rest of the windows, but in Idea it is treated in a special way: "If the user want to run his program, is very likely he wants to see the output of that program!" It seems so natural when I write it, but eclipse fails in this basic user interface concept.
Probably there's a shortcut for this in eclipse ( autohide output window while editing and autoshow it when running the program ) , but as some other tens of features the shortcut must be hunted in forums, online help etc while in Idea is a little bit more "natural".
This can be repeated for almost all the features both have, autocomplete, word wrap, quick documentation view, everything. I think the user experience is far more pleasant in Idea than in eclipse. Then the motto comes true "Develop with pleasure"
Eclipse handles faster larger projects ( +300 jars and +4000 classes ) and I think IntelliJ Idea 8 is working on this.
All this of course is subjective. How can we measure user experience?
Idea 8.0 has the lovely ctrl+shift+space x 2 that does the following autocomplete:
City city = customer.<ctrl-shift-space twice>
resolves to
City city = customer.getAddress().getCity();
through any number of levels of getters/setters.
Don't forget "compare with clipboard".
Something that I use all the time in IntelliJ and which has no equivalent in Eclipse.
My favorite shortcut in IntelliJ that has no equivalent in Eclipse (that I've found) is called 'Go to symbol'. CTRL-ALT-SHIFT-N lets you start typing and glob up classes, method names, variable names, etc, from the entire project.
I tried to switch to IntelliJ because of the new Android Studio. But I'm very disappointed now. I'm using Eclipse with the Code Recommanders Plugin. Here is a simple example why Eclipse is so awesome:
I want to create a new SimpleTimeZone. SimpleTimeZone has no Constructor with zero arguments.
Ctrl + Space in Eclipse
Ctrl + Space in IntelliJ
In IntelliJ I get no informations what kind of constructors SimpleTimeZone has.
After Enter in Eclipse
I get the previously selected constructor filled with predefined variable names. And I can see the type of every argument. With Code Recommanders Eclipse guesses the right constructor by the previously defined variable types in the current scope and fills the constructor with these vars.
After Enter in IntelliJ nothing happens. I get an empty constructor. I have to press Ctrl + P to see the expected arguments.
If you have the cursor on a method then CTRL+SHIFT+I will popup the method implementation. If the method is an interface method, then you can use up- and down- arrows to cycle through the implementations:
Map<String, Integer> m = ...
m.contains|Key("Wibble");
Where | is (for example) where your cursor is.
IntelliJ has some pretty advanced code inspections (comparable but different to FindBugs).
Although I seriously miss a FindBugs plugin when using IntelliJ (The Eclipse/FindBugs integration is pretty cool).
Here is an official list of CodeInspections supported by IntelliJ
EDIT: Finally, there is a findbugs-plugin for IntelliJ. It is still a bit beta but the combination of Code Inspections and FindBugs is just awesome!
Far, far, far more refactorings.
One thing I use regularly is setting a breakpoint, but then controlling what it does. (At my last job, most everyone else used Eclipse... I remember being surprised that no one could find how to do this in Eclipse.)
For example, can have the breakpoint not actually stop, but just log a message to the console. Which means, I don't have to litter my code with "System.out.println(...)" and then recompile.
There are many things that idea solves in a much simpler way, or there's no equivalent:
Autocomplete actions: Doing ctrl+shift+a you can call any idea action from the keyboard without remembering its key combination... Think about gnome-do or launchy in windows, and you've got the idea! Also, this feature supports CamelCasing abbreviations ;)
Shelf: Lets you keep easily some pieces of code apart, and then review them through the diff viewer.
Local history: It's far better managed, and simpler.
SVN annotations and history: simpler to inspect, and also you can easily see the history only for such a part of a whole source file.
Autocomplete everywhere, such as the evaluate expression and breakpoint condition windows.
Maven integration... much, much simpler, and well integrated.
Refactors much closer to the hand, such as loops insertion, wrapping/casting, renaming, and add variables.
Find much powerful and well organized. Even in big projects
Much stable to work with several branches of a big project at the same time (as a former bugfixer of 1.5Gb by branch sources, and the need to working in them simultaneously, idea shown its rock-solid capabilities)
Cleaner and simpler interface...
And, simpler to use only with the keyboard, letting apart the need of using the mouse for lots of simple taks, saving you time and giving you more focus on the code... where it matters!
And now, being opensource... the Idea user base will grow exponentially.
Structural search and replace.
For example, search for something like:
System.out.println($string$ + $expr$);
Where $string$ is a literal, and $expr$ is an expression of type my.package.and.Class, and then replace with:
$expr$.inspect($string$);
My timing may be a little off in terms of this thread, but I just had to respond.
I am a huge eclipse fan -- using it since it's first appearance. A friend told me then (10+ years ago) that it would be a player. He was right.
However! I have just started using IntelliJ and if you haven't seen or used changelists -- you are missing out on programming heaven.
The ability to track my changed files (on my development branch ala clearcase) was something I was looking for in a plugin for eclipse. Intellij tracks all of your changes for a single commit, extremely easy. You can isolate changed files with custom lists. I use that for configuration files that must be unique locally, but are constantly flagged when I sync or compare against the repository -- listing them under a changelist, I can monitor them, but neatly tuck them away so I can focus on the real additions I am making.
Also, there's a Commit Log plugin that outputs a text of all changes for those SCCS that aren't integrated with your bug tracking software. Pasting the log into a ticket's work history captures the files, their version, date/time, and the branch/tags. It's cool as hell.
All of this could be supported via plugins (or future enhancements) in eclipse, I wager; yet, Intellij makes this a breeze.
Finally, I am really excited about the mainstream love for this product -- the keystrokes, so it's painful, but fun.
The IntelliJ debugger has a very handy feature called "Evaluate Expression", that is by far better than eclipses pendant. It has full code-completion and i concider it to be generally "more useful".
Well, for me it's a thousand tiny things. Some of the macros, the GUI layout in general in Eclipse I find awful. I can't open multiple projects in different windows in Eclipse. I can open multiple projects, but then it's view based system swaps a bunch of things around on me when I switch files. IntelliJ's code inspections seem better. Its popup helpers to fix common issues is nice. Lots of simple usability things like the side bar where I can hover over a hot spot and it'll tell me every implementing subclass of a method or the method I'm implementing and from where.
Whenever I've had to use, or watch someone use, Eclipse it seems like they can do most of the things I can do in IntelliJ, but it takes them longer and it's clunkier.
Introduce variable. (Ctrl+Alt+V on Windows, Cmd+Alt+V on OSX)
Lets say you call a method, service.listAllPersons()
Hit Ctrl+Alt+V and Enter, and variable for return value from method call is inserted:
List<Person> list = service.listAllPersons();
Saves you typing, and you don't have to check the return type of the method you are calling. Especially useful when using generics, e.g.
new ArrayList<String>()
[introduce variable]
ArrayList<String> stringArrayList = new ArrayList<String>();
(of course you can easily change the name of the variable before hitting Enter)
IntelliJ has intellisense and refactoring support from code into jspx documents.
For me, it's IDEA's maven support, especially in version 9 is second to none. The on-the-fly synchronizing of the project to the maven model is just fantastic and makes development pleasant.
Intellij has a far superior SVN plug-in than either Subversive or Subclipse and it works! The amount of time we've wasted merging source files using Eclipse doesn't bear thinking about. This isn't an issue with IntelliJ because the plugin helps you much more.
Also the Subclipse plugin is unreliable - we regularly have instances where the plugin doesn't think there has been any code checked in to SVN by other developers, but there has - the CI server has processed them!
VIM Emulator. This plugin provides nearly complete vi/vim/gvim emulation while editing files in IDEA.
The following functionality is supported:
Motion keys
Deletion/Changing
Insert mode commands
Marks
Registers
VIM undo/redo
Visual mode commands
Some Ex commands
Some :set options
Full VIM regular expressions for search and search/replace
Macros
Diagraphs
Command line history
Search history
Jumplists
VIM help
some comments about this plugin from http://plugins.jetbrains.net/plugin/?id=164
I can't see ever going back to any other ide because of this plugin..
Best of both worlds... Awesome!.
that's what i was lacking in all IDEs.
One of the good points in my opinion is the Dependency Structure Matrix:
http://www.jetbrains.com/idea/features/dependency_analysis.html#link0
There's a good introduction to DSM usage and benefits in Lattix' website (a standalone product):
http://www.lattix.com/files/dl/slides/s.php?directory=4tour
A few other things:
propagate parameters/exceptions when
changing method signature, very
handy for updating methods deep
inside the call stack
SQL code validation in the strings passed as arguments to jdbc calls
(and the whole newly bundled
language injection stuff)
implemented in/overwritten in icons for interfaces & classes (and their methods) and
the smart implementation navigation
(Ctrl+Alt+Click or Ctrl+Alt+B)
linking between the EJB 2.1 interfaces and bean classes
(including refactoring support); old
one, but still immensely valuable
when working on older projects
Two things that IntelliJ does that Eclipse doesn't that are very valuable to me:
Method separators: those faint gray lines between methods make code much more readable
Text anti-aliasing: makes code look so nice in the IDE
One very useful feature is the ability to partially build a Maven reactor project so that only the parts you need are included.
To make this a little clearer, consider the case of a collection of WAR files with a lot of common resources (e.g. JavaScript, Spring config files etc) being shared between them using the overlay technique. If you are working on some web page (running in Jetty) and want to change some of the overlay code that is held in a separate module then you'd normally expect to have to stop Jetty, run the Maven build, start Jetty again and continue. This is the case with Eclipse and just about every other IDE I've worked with. Not so in IntelliJ. Using the project settings you can define which facet of which module you would like to be included in a background build. Consequently you end up with a process that appears seamless. You make a change to pretty much any code in the project and instantly it is available after you refresh the browser.
Very neat, and very fast.
I couldn't imagine coding a front end in something like YUI backing onto DWR/SpringMVC without it.
Preamble to my answer: My use of Eclipse is limited. We needed a Java IDE to work on both Windows and Mac and the Mac port slowed down day by day. This was years ago and I'm sure it's OK now. But that is what got us to switch to IntelliJ and we've been happy with it.
Now for my answer: One big difference I haven't seen mentioned yet is that tech support is better with IntelliJ/Jet Brains. We send an e-mail to JetBrains and get a definitive answer back in less than an hour. Looking for answers to Eclipse problems results in the usual, "You stupid idiot" answers (usually a small number of the replies) along with the much larger number of insightful, helpful replies. But it takes some sorting through to get the real answer.
Something which I use in IntelliJ all the time is refactoring as I type. I have re-written classes from a printout (originally written in eclipse) using both IDEs and I used about 40% less key strokes/mouse clicks to write the same classes in IntelliJ than eclipse.
I wouldn't want to use Eclipse until they support as much refactoring with incomplete pieces of code.
Here is a longer list of features in IntelliJ 8.0/8.1 [http://www.jetbrains.com/idea/features/index.html]
There is one thing that IntelliJ does much much better than Eclipse and that is empty your pockets!
I do however prefer using it and one big advantage it has over Eclipce is the way it synchronises with the file system, for big projects and slow computers (yes in work environments the PC's are a lot slower than our ones at home) Eclipse seems to struggle where IntelliJ seems to be quicker albeit with a slower initial indexing time.
IntelliJ Community edition obviously makes using it free but you soon want those extra refactoring and nice little goodies not included in the CC edition.
In my opinion, its generally a better user experience but whether its worth the cost is a question for each developer to answer themselves.
But lets be grateful we have up to three great IDEs for Java right now with NetBeans getting better all the time.
Data flow analysis : inter-procedural backward flow analysis and forward flow analysis, as described here. My experiences are based on Community Edition, which does data flow analysis fairly well. It has failed (refused to do anything) in few cases when code is very complex.
First of all I love intellij. There are at least a hundred features it has that eclipse lack. I'm talking magnitudes better in reliability and intelligence that no hyperbole can describe when it comes to refactoring, renaming, moving and others which have already been mentioned.
BUT, there is one thing that intellij does not allow which eclipse does. It does not allow running multiple projects at once under the same vm.
When you have separate projects for the front, middle, core, agents..etc, where they all have to interact with each other, you can not quickly modify and debug at the same time, afaik. The only way I current cope with this is to use ant scripts to deploy and update jars in dependent projects, or use maven.
Eclipse allows multiple projects to be debugged under one ide vm instance.

Categories

Resources