I'm using IntelliJ with a mixed Java/Kotlin project. In one of my Kotlin files, I have this property:
override val value: String
get() {
return webElement.getAttribute("value")
}
IntelliJ's light bulb offers to "Convert property getter to initializer", which changes the code to this:
override val value: String = webElement.getAttribute("value")
To me, it seems like this isn't a simple refactoring, but a significant code change. What I think is happening is:
In the first version, the value property is retrieved when I call value.
In the changed version, the value property is set immediately when the class instance is constructed, and then never changes for that class instance.
But maybe this is more like C# expression-bodied members, which use a lambda arrow => instead of braces and return but otherwise work exactly the same way.
So...which is it? When will the second version of the code initialize?
You are correct regarding these statements:
In the first version, the value property is retrieved when I call value.
In the changed version, the value property is set immediately when the class instance is constructed, and then never changes for that class instance.
IntelliJ's light bulb offers to "Convert property getter to initializer" because it is just an option available. Light bulb only highlights the actions you can do with a selected piece of code.
IntelliJ does not try to tell you that "property initializer" and "property getter" are equal. What it tells you is that you can convert one to the other if you wish to.
I agree that it is confusing, especially considering this quote from IntelliJ Idea documentation:
As soon as the IDE finds a way to alter your code, it displays a yellow bulb icon in the editor next to the current line. By clicking this icon, you can view intention actions available for this unit of code. Intention actions cover a wide range of situations from warnings to optimization suggestions. You can view the full list of intentions and customize them in the Settings/Preferences dialog ⌘,.
Having this in mind it could appear that your code is either can be optimized or has a warning.
The answer
When will the second version of the code initialize?
... immediately when the class instance is constructed.
You are correct.
Related
On windows, I know that we can search for all the methods in the current class by using Ctrl+F12.
Suppose, that I am in the class Car.java
and there we have a method called accelerate();
The method is really long and now I did some modifications at the end of this method. How can I jump back to the place where the method accelerate() starts?
I used Ctrl+U but that just does not do anything at all.
Refer to this page from IntelliJ's manual: Method navigation
It's Alt+Up or Alt+Down
I have tried annotating a field with
org.checkerframework.checker.nullness.qual.NonNull
org.jetbrains.annotations.NotNull
javax.annotation.Nonnull
And in all cases, assigning a null to it generates no complaints from IntelliJ 2016.2.
public class GreetingController {
#NotNull Integer x = 3;
public void foo() { x = null; }
}
That all compiles fine according to IntelliJ.
This page from IntelliJ specifically states that "IntelliJ IDEA highlights the problems “on-the-fly”, so you can see the inspection results right in the editor." I have even copied the example code (public class TestNullable) into my editor and it produces no errors.
This other page from IntelliJ states you can change the annotations it responds to. So I chose javax.annotation.Nonnull and made sure that was the one I was using in my code, still no luck.
To be clear, what I'm hoping for, and what I understand should be provided, is that the editor window / compiler alerts me to the problem (I am not looking for a runtime check, NullPointerException already works fine at runtime.)
In case it didn't work in real time, I tried "Rebuild Project".
I'm sure this must work, what am I doing wrong?
I have uploaded an example of this not working here: ZIP download.
As I can see from your screenshots and the sample project, IntelliJ IDEA does show you the warnings. Note that these warnings are shown by the code inspections which are running on the fly and will be displayed in the editor or in the Analyze | Inspect Code results. These warnings will not be displayed by the compiler.
Note that you can configure the warnings highlighting if needed (for example add the underwave effect):
You can also change the severity of the inspection (like to Error):
You may also want to vote for this feature request:
IDEA-78625 Provide inspection severity level that will work like validation and abort compilation
As a bonus, pay attention to the javax.annotation.Nullable annotation, it may be not what you think it's for, see this comment and the documentation. For some years IntelliJ IDEA has incorrectly suggested to use this annotation, while the correct one for such cases would be javax.annotation.CheckForNull:
This annotation is useful mostly for overriding a Nonnull annotation.
Static analysis tools should generally treat the annotated items as
though they had no annotation, unless they are configured to minimize
false negatives. Use CheckForNull to indicate that the element value
should always be checked for a null value.
"Settings" > "Inspections" > "Probable Bugs" > "Constant conditions & exceptions"
Tick the first option: "Suggest #NotNull annotation for methods that possibly return null and report nullable values passed to non-annotated parameters.
Click "Configure Annotations". By default, Intellij will use their own annotations from org.jetbrains.annotation. I was using the more general (my own opinion) annotations from javax.annotation.
I set Nullable to: javax.annotation.Nullable
I set NotNUll to : javax.annotation.NotNull
In order to set these new options, you must click them, then click the tiny checkmark button to the right to set it. Selecting the javax.annotation annotations then hitting "OK" will NOT lock in the new settings, you must use the checkbox button.
After successfully specifying javax.annotation.Nullable and javax.annotation.NotNull, the code correctly highlighted null problems.
The best that this can do is offer up warnings. It will not stop compilation from happening, since the annotations do not prohibit or preclude code compilation from taking place.
Be sure that you have the appropriate inspections enabled in your IDE, and be sure that you remain aware of what parameters you're passing into your method. The IDE can at best warn you, but it can't really stop you.
Alternatively, introduce a unit test to fail if that method receives a null parameter, and rely on that to ensure that you're not breaking code or expectations.
In a Dolphin smalltalk treeview I'd like to use a custom icon, depending on the state of the item displayed, (differente state, different icon)
How can I do that ?
I cannot really understand how to use a "my" icon.
I've create a class "connection", with an instance variable "connected"
and two class methods "connectedIcon and unconnectedIcon that returns icon images.
Then an instance function "icon" that returns one or the other image based on the connection state.
I can add instances of this class to a tree view and see the name of the connections.
But how to show my Icons ?
I tried to sustitute the getImageBlock of my presenter view with the following expression [:obj | obj icon] but it doesn't work.
(nothing seems to happen).
this is made in my presenter initialize :
initialize
super initialize.
treePresenter view getImageBlock: [:obj | obj icon]
what's wrong with it ?
best regards
Maurizio
When you are editing a TreeView, one of the properties is getImageBlock. By default it is not really a block but another object that understands the message #'value:' (the class IconicListAbstract). You can replace this property with a code block (or other object that understands #'value:') and answer the image you want displayed.
In Microsoft Windows, icons are typically stored in a DLL. You should be able to use an icon explorer or editing tool to see the icons in a dll. For example, get IconExplorer from http://www.mitec.cz/iconex.html and try opening DolphinDR7.dll. Do the icons and numbers match what you see when you return a number in your application?
To determine (or override) the resource library used, see SessionManager>>#'defaultResLibPath'.
Typically, the getImageBlock is set using the property editor in the GUI editor, but setting it through code can work as well.
Wonderful Dolphin Smalltalk!
I had two problems
1) how and where to modify the getImageBlock method of my Treepresenter.
2) where to put the icons ad how to get the imageindex of each icon.
This is the solution :
1) it's not needed.
The treeview sends an #iconImageIndex" message to my model
this is handled by the default method (in the Object class) that send to my object the message #icon
and to the result of this message (an icon) the message #iconIndex.
This message is understood from the icon that answers with its own iconIndex.
So the only method I need to impement is #icon in my class Connection
that I implemented as follows:
icon
opened ifTrue: [^Connection connectedIcon] ifFalse: [^Connection unconnectedIcon]
In the class itself the two icons are imported in the image by evaluating the createIconMethod,
as explained in the blog article 'Beauty with less Beast'.
So my problems are solved.
Thanks to all.
Maurizio.
While executing my script in RFT, my script got failed due to the slight position change of a button. (This button's position slightly changes according to the option selected for previous combo box due to the label appearing near the button)
As there are 2 positions for this button in window, one of my script fails while other passes.
Please suggest how to identify this same object in 2 different places in RFT?
If you're alright with not using pre-mapped values and instead work with objects directly in code (which I've personally found to be extremely useful... it's allowed me to do great and wondrous things with RFT :), the following ought to work fine:
private void clickObject(String uniqueIdentifier) {
// Find object
RootTestObject root = RootTestObject.getRootTestObject();
TestObject[] matchingObjs = root.find(atProperty(".id", uniqueIdentifier));
if (matchingObjs.length > 0) {
// Click the object
((GuiTestObject) matchingObjs[0]).click();
}
// Clean-up
unregister(matchingObjs);
}
Feel free to replace ".id" with whatever property is best suited for the situation... since I work primarily with a web application, the ".id" property has worked splendidly for me.
Because the method finds the object anew each time, it'll grab the object's position wherever it's at at the time the method's called. The clean-up will also prevent any weird, horrible, and otherwise unfortunate UnregisteredObjectExceptions from cropping up.
Without looking at your pages I cannot be sure, but I think the buttons are actually two different buttons. Maybe they are generated by javascript, or they are just un-hidden after the option you select in the combobox.
If they are two different buttons (record them both and look at the recognition properties) you can either replace some properties with a regular expression or check wich button is visible/exists and then click it:
if (btn_button1.exists()) {
btn_button1.click();
} else if (btn_button2.exists()) {
btn_button1.click();
}
Here's a more complete tutorial on Object Recognition.
You can increase the tolerance of Rational Performance Tester AssureScript in the properties tab or you could set the description but hide the value. You can also make a custom code that updates the object map to prepare for this change in a java IF structure
I'm developing a plugin that takes all enums in workspace that implements certain interface (IDomain) parses the code (Using AST) does some modification over the enum and marks it as processed with an annotation (#IDomainInfo).
For example, it takes someting like this:
public
enum SomeEnum implements IDomain {
// ...
}
And generates something like this:
public #IDomainInfo(domainId = 1)
enum SomeEnum implements IDomain {
// Some changes here...
}
The idea behind of the #IDomainInfo is that annotated enums have not to be processed anymore by the plugin.
Basically what I do to accomplish the task is to make a search with JavaSearch API to find all the enums implementing IDomain (easy task), and as result I get a list of IJavaElements (which are in fact instances of IType). Then I call a method that iterates through the resulting list and creates a new list of all the IType instances that are not annotated with #IDomainInfo and then process the resulting list: For each non annotated IType do some work, annotate the IType with the #IDomainInfo annotation (Using AST) and then save back the results to file (using IFile, so I can see the changes without refresh, and in fact, if I have the enum open in the editor I see it refreshed instantly :-)
All that works fine, but if I open an #IDomainInfo annotated enum (just for testing) then remove the #IDomainInfo, save the file (I'm sure) and then call the action that does all the job I've described before, when I get to the part that filters annotated IType from non annotated ones, code is something like this:
for (IType type : typeList) {
IAnnotation annotation = type.getAnnotation(“IDomainInfo”);
if (!annotation.exists()) {
// The annotation does not exist, so add the type to the
// list of elements to update and go on...
ret.add(type);
continue;
}
// Something else here...
}
Well, it results that for the file I've just saved the IType detects the annotation I've just removed as if it's still there. If I close and reopen eclipse all works normally.
Now, I've just checked and triple checked my code, so I'm sure that I'm not keeping a stale copy of the old IType unedited still with the annotation version (all my IType come from a fresh java search call every time I run the action).
So the question is, what might I be doing wrong? I mean, I've just read the JavaCore API many times to check If I might be using it wrong or if I have some conceptual flaw there but really I have no clue, it's like if eclipse would be caching the IType ignoring the changes I've just made in the editor :-/
If any one have an idea I would appreciate it a lot :-)
When or how is your plugin called ? Did you register a resource listener or is it a project builder or something else ? If it is called by a resource listener, your plugin may be reading the 'primary copy' for your IType, which has not been saved yet. Hence your changes are still in the Working Copy.