I have completed appserv-commons and admin module using this
transformation. Here is the checkin log.
http://fisheye5.cenqua.com/changelog/glassfish/?cs=MAIN:dpatil:20061104013924
thanks
Dinesh
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
>