I thought I'll give JDeveloper a try and indeed there are a couple of handy features, but discovering this problem in the first couple of minutes of playing around with it did not really help me to develop a trust in its code-generating/refactoring abilities.
If I want to use this feature on a simple "int x;" line it nicely generates the getters/setters but despite this being the default option it does not set the field to private. Am I doing something wrong? It's hard to beieve that there is a bug in such a widely used option.
Is there a place where I could report bugs, feature requests? (Are they listening to users suggesting features anyway?)
Edited by: 1002924 on 27-Apr-2013 18:20
Yes we do listen.
Why should it set the field to private? If you don't define the field's modifier it defaults to protected. It's legit to have accessors for protected fields, as such JDev doesn't then automatically modify your attributes modifier to private, because maybe the developer actually wanted he default protected modifier.
Hi Chris and thanks for your answer.
As far as I know, if you don't define a field's modifier it does not default to protected, the difference being whether subclasses outside the package can access that field.
To answer your question, it should set the field to private because I want it to, meaning this is what I would choose even if it would not be the default choice anyway which it is. Basically the dialog informs me that it's going to do it and then it leaves the field with default accessibility.
I might be misunderstanding something but to me it really seems like a bug.
Edited by: 1002924 on 28-Apr-2013 10:05
Ok, I understand, we're talking about the encapsulate dialog, not the generate accessor dialog.
I'm travelling this morning. When I get back to my machine Ill verify the issue & log a bug on your behalf.
The default accessor for a field is neither private nor protected. The default is no accessor, which is equivalent to package level accessor. It would be an error to add private by default. No field accessor is the default, not a bug.
Selecting Field Accessibility as private in Encapsulated Fields and setting the accessibility to default (no access modifier) is a bug, but the default not being private is not a bug. The bug is in the Encapsulated Fields not the code generated.
Well you've managed to confuse me as the bug we are discussing is in the Encapsulate Fields dialog.
The bug as lodged, for field "int x", on opening the dialog the default field modifier is private. If selecting ok, while the accessors are generated, the field & it's modifier is not changed when it is expected to be as per original poster's expectations, changed to "private int x".
Firstly, the example cited is int x, but the screen image shows the field s. Is s a different field?
Secondly, encapsulation is often interpreted to imply make the fields private and methods public to restrict direct access to the fields. For encapsulation at class level the definition is fine. But, encapulation could be at the class level, package level or sub class level. For package level encapsualtion the access modifier for fields would be the package modifier, which is no modifier. For sub class level encapsulation the access modifier would be protected. Field Accessibility default setting of private is arbitrary as private for encapsulated fields is the most common setting. The ambiguity is because encapsulation has two definitions; the first is bundling data with the methods, the second is restricting access to components, which could imply setting fields to private, protected or package and making the get/set methods of wider scope.
Field not getting set with private access modifier if private is selected in Encapsulated Fields is a bug. The Field Accessibility selected should be applied to the field generated.