I don't this we will be able to automate this, as this requires opening
smaller projects under glassfish, attach the rule file to Query and
Refactor for Jackpot Transformation and accept the valid transformations
(as there are few formatting changes we may not need to take), verify
those manually and then apply transformations. So there is some manual
check, setup required in this process, but if you know any better pls
let us know.
thanks
Dinesh
kedar wrote:
> We should definitely do this. Is automating this like
> FindBugs a possibility?
>
> Kedar
>
> Dinesh Patil wrote:
>
>> Dear Module owners and Developers,
>>
>> For removing the excessive use of these objects using "new Boolean(),
>> new Integer(), new Byte() .. " we are experimenting the NetBeans
>> Jackpot Transformation tool : http://jackpot.netbeans.org/ to replace
>> code as below to use the objects from Cache.
>>
>> // Effective Java, Item 4: Avoid creating duplicate objects
>> new java.lang.Boolean($b) => java.lang.Boolean.valueOf($b);
>> new java.lang.Byte($b) => java.lang.Byte.valueOf($b);
>> new java.lang.Character($c) => java.lang.Character.valueOf($c);
>> new java.lang.Integer($i) => java.lang.Integer.valueOf($i);
>> new java.lang.Long($l) => java.lang.Long.valueOf($l);
>> new java.lang.Short($s) => java.lang.Short.valueOf($s);
>> new java.lang.String($s) => $s :: $s instanceof java.lang.String;
>>
>> You can refer to the email thread for more details. Jan and myself
>> tried this on appserv-jstl and appserv-commons modules, and I could
>> find following diffs where this transformation matches and replaces
>> in appserv-commons module.
>>
>> http://glassfishbuildtools.sun.com:8000/jackpot_acommons.log
>>
>> We will be running this transformation on all the modules, so if you
>> have any comments, suggestions or if you prefer to do it yourself on
>> your own modules please let me know.
>> thanks
>> Dinesh
>>
>>> Hi Tom,
>>> Tom Ball wrote On 10/17/06 14:04,:
>>>
>>>> Charlie is right: these sorts of transformations are trivial and
>>>> safe for Jackpot to do. Here are the relevant rules:
>>>>
>>>> // Effective Java, Item 4: Avoid creating duplicate objects
>>>> new java.lang.Boolean($b) => java.lang.Boolean.valueOf($b);
>>>> new java.lang.Byte($b) => java.lang.Byte.valueOf($b);
>>>> new java.lang.Character($c) => java.lang.Character.valueOf($c);
>>>> new java.lang.Integer($i) => java.lang.Integer.valueOf($i);
>>>> new java.lang.Long($l) => java.lang.Long.valueOf($l);
>>>> new java.lang.Short($s) => java.lang.Short.valueOf($s);
>>>> new java.lang.String($s) => $s :: $s instanceof java.lang.String;
>>>>
>>>> Float and Double constructors aren't changed because their valueOf
>>>> implementations don't currently have caches, but they can be both
>>>> for source consistency and to potentially take advantage of future
>>>> runtime performance enhancements. I'd be happy to run this over
>>>> your source base if you like, or you can install Jackpot in your
>>>> NetBeans IDE (http://jackpot.netbeans.org), open the Refactoring
>>>> Manager, create a new rule file, and paste in the above.
>>>
>>>
>>> works like a charm!
>>> Jan
>>>
>>>> Speaking of performance enhancements, I don't recommend spending
>>>> time trying to micro-optimize the new code. Regardless of whether
>>>> one can write a more efficient valueOf implementation than the core
>>>> team, HotSpot is going to optimize it for you if it becomes a
>>>> problem. The best way to ensure that HotSpot can optimize it is to
>>>> write clear, standard code which it can easily recognize.
>>>> Tom
>>>> Charlie.Hunt_at_Sun.COM wrote:
>>>>
>>>>> Why not write a Jackpot transformation to do all this code
>>>>> re-engineering for you?
>>>>> Jackpot could scan the entire GlassFish source in a matter of
>>>>> seconds and do the entire transformation in one click. You just
>>>>> need to write a line or two of transformation code to recognize
>>>>> the pattern and what you want to replace it with.
>>>>> If you talk with Tom Ball, cc'd here, I'm he would likely help get
>>>>> someone started.
>>>>> This Boolean and Integer transformation would be great candidates
>>>>> to add the Jackpot transformation repository for NetBeans.
>>>>> See http://jackpot.netbeans.org for more information on Jackpot.
>>>>> charlie ...
>>>>> Kin-man Chung wrote:
>>>>>
>>>>>> I have seen codes like new String("blah")! :-)
>>>>>> Wonder why javac not just silently turn "new Boolean(true)" into
>>>>>> Boolean.TRUE and "new Boolean(x)" into "x? Boolean.TRUE:
>>>>>> Boolean.FALSE"?
>>>>>> Also wonder if "x? Boolean.TRUE: Boolean.FALSE" may not be more
>>>>>> efficient than Boolean.valueOf(x)?
>>>>>> -Kin-man
>>>>>> On Fri, 2006-10-13 at 17:13, Craig L Russell wrote:
>>>>>>
>>>>>>> Note that valueOf(boolean) was introduced in JDK 1.4, and many
>>>>>>> of these are left over from previous releases.
>>>>>>> +1 to replacing the new Boolean with valueOf.
>>>>>>> Craig
>>>>>>> On Oct 13, 2006, at 5:03 PM, Jan Luehe wrote:
>>>>>>>
>>>>>>>> I've monitored the number of java.lang.Boolean instances on the
>>>>>>>> heap
>>>>>>>> after different types of operations using 9.1 b21.
>>>>>>>>
>>>>>>>> After starting, I see approx. 1,300 instances, occupying
>>>>>>>> approx. 21,000 bytes. Each deploy of a very simple webapp adds
>>>>>>>> another 1,200 instances, and each undeploy adds 500.
>>>>>>>>
>>>>>>>> All of these instances will be gc'ed eventually, but at any time
>>>>>>>> during the appserver lifecycle, there should be no more than
>>>>>>>> 2 instances of java.lang.Boolean (Boolean.TRUE and Boolean.FALSE)
>>>>>>>> on the heap.
>>>>>>>>
>>>>>>>> If you search the GlassFish code base, you'll find tons of places
>>>>>>>> where "new Boolean(x)" instead of the recommended
>>>>>>>> "Boolean.valueOf(x)"
>>>>>>>> is used. I've also seen places where "new Boolean(true)" or
>>>>>>>> "new Boolean("true")" is used instead of Boolean.TRUE.
>>>>>>>>
>>>>>>>> All of this is flagged by FindBugs (along with "new Integer(x)" vs
>>>>>>>> "Integer.valueOf(x)", etc.).
>>>>>>>>
>>>>>>>> Fixing this is a very low-hanging fruit. We've already cleaned up
>>>>>>>> most of the web code.
>>>>>>>>
>>>>>>>> Jan
>>>>>>>
>>>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>