[ BUILD # : 200906241340 ]
[ JDK VERSION : 1.6.* ]
1. Create an field as 'private Boolean value;' for any class;
2. Call Alt + Insert > Getter;
3. Select 'value' field and click 'Generate'.
The method generated is 'isValue' instead 'getValue'. For boolean
fields it works fine.
The workaround is to use 'Encapsulate fields' refactoring.
We would like to fix it by NetFIX program. That is ok for you?
Reassigning to correct team.
Created attachment 84320 [details]
Attached is a proposed patch that fixes the problem.
See issue #160531. IMO, would be better to simply revert that fix. The bug will need to be re-opened and closed as won't
fix with an explanation.
I added some comments there...
I've reverted changes made in #160531, marking this one as FIXED.
This must be fixed to patch 1
Regression is an P1.
Regression in P4 functionality is not P1 IMHO. And removing the whole Alt + Insert > Getter would not be P1 from the
overall product perspective. If we used your methods every bug would be P1 and we could safely remove the whole priority
field from issuezilla. I am sorry I have jumped in here but the priority field should be set by the developer. Max it is
all yours now ;-) And finally I am not able to resist: "This must be fixed to patch 1" --> we all must die that is the
only sure thing on the earth.
So, if the feature doesn't work as expected why keep it available? I can't agree with with you since is unacceptable to
get this kind of feature working in this way. If I need to review the code generated by the tool I will not use the
feature or the tool at all. I am shame about get this issue just now after FCS and not when in NetCAT time since it is
an show stopper. I already instruct our team do DOESN'T use the feature since we can't trust in it. Probably we will
make this patch available in our internal UC to avoid problems when using Hibernate for example. I think you have no
idea how embarrassing is when an object is not persisted at DB because read method for some property can't be found by
framework because tool generated the wrong code... and of course this is the last thing you think about because you
trust in the code generated by IDE. Now, you saying to me that I need to review the Matisse code or any wizard generated
code too, since if an simple getter generation can be wrong, why not more complex features? When you are face to face
with users is not simple to explain this kind of things, the users just want tools that do your work correctly.
How do you define an feature priorities? By your uses or our uses? Code generation (code-generation) is an feature
really used  by users (I don't know how to filter by generator, probably not possible). How could you say this is an
P4 feature? Please, let us know how it works.
Finally, "we all must die that is the
only sure thing on the earth." and sometimes is what the manager want when you lost time with features that doesn't work
in ours day by day tool... and, the patch was make available some time after issue was filed by my coworker Michael so
there is no reason to not integrate it. Sorry for some strong words, but sometimes is really hard to accept some things.
I apologize if my words were rude or something but:
1. I was just saying that it is the people who develop (or pay for development) who set the (relative) priorities of
issues (myself here)
2. I have never said we will not fix this
3. I have never said we will not include it in the patch 1 release
4. The action is next to last in the list of actions on the page you cited
"How do you define the feature priorities": good question with rather complex answer that for sure does not belong to
this bug report.
"there is no reason to not integrate it" - how do you know there is no reason?
I need to apologize if my words were rude or something too, but I can't agree with some approaches you did...
v. at main repository and just let me know if you need any help from my side.
Thanks in advance
Integrated into 'main-golden', will be available in build *200907040200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Max Sauer <firstname.lastname@example.org>
Log: #168061: [67cat] Getter generation working wrong for Boolean fields
The fix has been ported into the release67_fixes repository.
Product Version: NetBeans IDE 6.7.1 RC (Build 200907150227)
Java: 1.6.0_14; Java HotSpot(TM) Client VM 14.0-b16
System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
Verified in 6.7.1 RC