I use Eclipse Save actions, and generally find them very useful. However, I've hit a scenario when using Lombok that is enfuriating.
In the following class, I want to set a default value for a field to prevent nulls, whilst still allowing a setter.
#Data
public class Foo {
#NonNull
private String value = "myDefaultValue";
}
This is great, until I hit save, when Eclipse makes the field final! I generally don't want' to disable save actions, as I like what they are doing most of the time. Just not in this instance!
This question suggests that I can't save without running save actions, and it's a pain to keep enabling/disabling save actions whilst editing the file.
This was a bug, and has been fixed in Issue 263. Originally, this fix was delivered in Lombok 0.10.4, but as a side effect a new problem was introduced that has been addressed in the 0.10.8 release.
Disclosure: I am one of the Project Lombok developers.
This is not a Lombok answer, I’m afraid. But in my experience final does more harm than good. It does not stop you from changing the object the reference points to (except, of course, for the immutable String). Optimization only helps little. I avoid final in Java, but like const in C++.
You can edit your Save actions and exlude adding the final keywords while still performing the other actions.
Related
Eclipse (any version AFAIK) has some weird behavior related to folding in Java code. Suppose I’m editing this class:
class A {
String field;
#Nonnull
Object method(){
// whatever
}
}
If folding is enabled and I tell it to collapse everything (it’s Control-NumSlash in mine, but that might be customized), the method is correctly folded, i.e. it shows only Object method()... for the method. All good ’till now.
The part that bothers me is that if I move the cursor right after field;, press Enter, and type something like “public”, and then stop for a second, Eclipse automatically folds that word into the method below.
That might seem reasonable (presumably it assumes I wanted to add that qualifier to the method); but in practice what I’m actually doing is trying to add a new method, and paused for a moment to think about its return type or maybe its name. (If I wanted to modify the method I’d unfold it first, since it might already have that qualifier, folded.)
I hate this “feature” with passion, but I can’t for the life of me find out how to disable it, nor even which of the damned mess of plugins (that Eclipse keeps insisting I should not be allowed to remove) is responsible for it so I can file a bug report.
So, does anyone know (1) where does that behavior come from, and hopefully (2) how can I get rid of it but keep manual folding? Thanks!
(For the record, I’m using Kepler SR1, but this behavior goes back a really long time, at least five years or so.)
I don't believe there's any way to prevent it from doing that unless you just make a habit of putting a semicolon ; or closing curly brace } after public which prevents the Object method(){.. from 'folding' it up. I believe it's written to fold everything up until the closest semicolon which is why #Nonnull is also included.
The only options for folding I can find are located in Window > Preferences > Java > Editor > folding
I would consider this to be a bug, or just a feature that had unintended side effects.
Funny enough, if you put almost any symbol or misspell public it wont fold it.
Lets say for example I write many times priavte instead private.
Is there a way to let Eclipse automatically fix my common typo?
Something like construct a map of my common typo to its desire fix,
and then just let Eclipse fix it without asking me about that.
Are there any other IDE\editors that have such support?
There is no builtin support for automatically changing strings. The closest to your request are the templates of the Java editor, but even those must explicitly be activated using CtrlSpace.
To get around your problem, I suggest simply not to write that much yourself. If you want to declare a private field, type just "pr" and hit CtrlSpace to invoke code completion. Eclipse can do code completion quite well, often even without any trigger characters (try it with an empty class file).
I am working on an Eclipse JDT plugin that requires parsing large numbers of source files,
so I am hoping to use the batch method ASTParser.createASTs(). The parsing executes without errors, but within the CompilationUnit instances it produces, many of the org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding instances have had their scope field set to null. This setting to null is occurring in the CompilationUnitDeclaration.cleanUp() methods, which are invoked on a worker thread that is unrelated to my plugin's code (i.e., my plugin's classes do not appear on the cleanUp() method call stack).
My parsing code looks like this (all rawSources are within the same project):
ASTParser parser = ASTParser.newParser(AST.JLS3);
parser.setResolveBindings(true);
parser.setStatementsRecovery(true);
parser.setBindingsRecovery(true);
parser.setIgnoreMethodBodies(false);
parser.setProject(project);
parser.createASTs(rawSources.values().toArray(new ICompilationUnit[0]), new String[0], this, deltaAnalyzer.progressMonitor);
Alternatively, I can execute the parsing this way, and no such problems occur:
for (ICompilationUnit source : rawSources.values())
{
parser.setResolveBindings(true);
parser.setStatementsRecovery(true);
parser.setBindingsRecovery(true);
parser.setIgnoreMethodBodies(false);
parser.setProject(project);
parser.setSource(source);
CompilationUnit ast = (CompilationUnit)parser.createAST(deltaAnalyzer.progressMonitor);
parsedSources.add(deltaAnalyzer.createParsedSource(source, ast));
}
This issue occurs in both Helios and Indigo (the very latest release build). I filed a bug in Eclipse Bugzilla, but if anyone knows of a way to work around this--or if I am using the API wrong--I would greatly appreciate your help.
Byron
Without knowing exactly what your exception is, I can still offer 2 suggestions:
Have a look at org.eclipse.jdt.ui.SharedASTProvider. If you are not making any changes to ASTs, this class may provide a more robust way of getting the ASTs.
Play around with some of the settings that you are using. Do you really need bindingsRecovery set to true? What about statementRecovery? Setting these to false may help you.
Im currently doing a lot of testing with JPA entities, where i have to keep calling the setter methods on the entity that looks something like this :
myEntity.setXXX(value);
myEntity.setYYY(value);
myEntity.setZZZ(value);
Is there any magic shortcut or menu in eclipse IDE to generate all the setter-method-calls that starts with "set", like those displayed in the ctrl-space (auto completion) popup (i think the inherited methods from Object are not being shown at popup) ?
So im imagining something like :
i type myEntity.set
and myEntity.set* are generated right away
Im a lazy programmer and currently using Eclipse Helios IDE.
Thank you !
Edit
Im not looking for source -> generate getter and setter, because that would helps me in generating the methods itself. Generating the method calls is what i want to achieve.
I have found the answer (I was always searching for this thing)...
The easiest way is to expand the class members in the "Package Explorer", sort them by name, multi-select all the setters, and then you have in the clipboard all the method names...
;-)
I like #Oscar's answer. It does lead to some cleanup though.
When I paste from the clipboard, I get something that looks like this:
setOne(int)
setTwo(String)
In order to clean this up, I first add semicolons with this search/replace regexp:
search = (.)$
replace = \1;
Then I add the getter calls (assuming incoming data object is named "data"):
search = s(et.*)\(.*
replace = s\1(data.g\1());
This doesn't handle multiple arguments in a method call...
you can use the outline at right side. There you can sort alphabetically or by declaration order using the toolbar button of the view.
and then you can filter out non required this.
From here also you can copy..all setter functions or getters functions names...
There is eclipse plugin to do that. The name of the plugin is **
FastCode
**. There are so many templates. Among those there is template to generate code for create object of the class and all setters method.
Source --> Generate Getters and Setters...
You can also get at it via the Quick Fix command (Ctrl+1) when the cursor is on a property.
EDIT
If you are simply looking for a faster way to copy properties from one object to another I suggest that you look at using reflection. I think this path would be much easier long term then generating the same-looking code over-and-over.
Commons BeanUtils can take away some of the pain in writing pure reflection code. For example, copyProperties takes a destination bean and either another bean or a Map as the source.
I'm not much of an Eclipse guru, so please forgive my clumsiness.
In Eclipse, when I call Assert.assertEquals(obj1,obj2) and that fails, how do I get the IDE to show me obj1 and obj2?
I'm using JExample, but I guess that shouldn't make a difference.
Edit: Here's what I see:
(source: yfrog.com)
.
Comparison with failure trace is not a easy task when your object is a little bit complex.
Comparison with debugger is useful if you have not redefined toString(). It remains still very tedious as solution because you should inspect with your eyes each objects from both sides.
Junit Eclipse plugin offers a option when there is a failure : "Compare actual With Expected TestResult". The view is close enough to classic content comparison tools :
Problem is that it is avaiable only when you writeassertEquals() with String objects (in the screenshot, we can see that the option in the corner is not proposed with no String class) :
You may use toString() on your object in assertion but it's not a good solution :
firstly, you correlate toString() with equals(Object)... modification of one must entail modification of the other.
secondly, the semantic is not any longer respected. toString() should return a useful method to debug the state of one object, not to identify an object in the Java semantic (equals(Object)).
According to me, I think that the JUnit Eclipse plugin misses a feature.
When comparison fails, even when we compare not String objects, it should offer a comparison of the two objects which rely on their toString() method.
It could offer a minimal visual way of comparing two unequals objects.
Of course, as equals(Object) is not necessarily correlated to toString(), highlighted differences should be studied with our eyes but it would be already a very good basis and anyway, it is much better than no comparison tool.
If the information in the JUnit view is not enough for you, you can always set a exception breakpoint on, for example, java.lang.AssertionError. When running the test, the debugger will stop immediately before the exception is actually being thrown.
Assert.assertEquals() will put the toString() representation of the expected and actual object in the message of the AssertionFailedError it throws, and eclipse will display that in the "failure trace" part of the JUnit view:
(source: ibm.com)
If you have complex objects you want to inspect, you'll have to use the debugger and put a breakpoint inside Assert.assertEquals()
What are you seeing?
When you do assertTrue() and it fails, you see a null.
But when you do assertEquals, it is supposed to show you what it expected and what it actually got.
If you are using JUnit, mke sure you are looking at the JUnit view and moving the mouse to the failed test.
FEST Assert will display comparison dialog in case of assertion failure even when objects you compare are not strings. I explained it in more detail on my blog.
If what you are comparing is a String then you can double click stack element and it will popup a dialog showing the diff in eclipse.
This only works with Strings though. For the general case the only way to see the real reason is to install a breakpoint and step into it.