[
https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804029#comment-13804029
]
Knut Anders Hatlen commented on DERBY-6391:
-------------------------------------------
+1 to making these changes. We've had a similar rototill in client and server
code (DERBY-5873), since those code bases have required Java 5 for a few
releases already.
I don't see any downside of using auto-boxing here. javac will insert calls to
{{Long.valueOf(long)}}, so I don't think the byte code size will be much
different. {{valueOf()}} is slightly more efficient than the constructor,
though, since it retrieves the {{Long}} instances from a cache if they're
within the range \[-128, 127\]. (Not that efficiency matters much in this
case.) {{StandardException.newException()}} will still receive a Long
instance, so the formatting of the message should not change because of it. The
main benefit, in my opinion, is that it simplifies the argument list and makes
the code (slightly) easier to read.
I've only come across one problem so far when using auto-boxing: If you have a
{{List<Integer>}} instance and want to remove an element from it, you should
convert the argument to {{Integer}} explicitly before you call
{{List.add(Object)}}, otherwise you may end up calling {{List.add(int)}}, which
interprets the argument as a position rather than the actual element to remove.
> remove unneeded object creation in newException() calls in releases > 10.10
> ---------------------------------------------------------------------------
>
> Key: DERBY-6391
> URL: https://issues.apache.org/jira/browse/DERBY-6391
> Project: Derby
> Issue Type: Improvement
> Affects Versions: 10.11.0.0
> Reporter: Mike Matrigali
> Labels: derby_backport_reject_10_10
>
> In releases after 10.10 the code has been converted to use new
> java language features. One of the benefits I just noticed is that
> arguments to StandardException.newException() no longer have
> to be Objects. I believe this is due to reimplementation using varargs.
> As an example old code use to have to be written as:
> throw StandardException.newException(
> SQLState.FILE_BAD_CHECKSUM,
> id,
> new Long(checksum.getValue()),
> new Long(onDiskChecksum),
> pagedataToHexDump(pageData));
> The only reason for the new Long() calls was to make them Objects so
> that the call would match up to a hard coded N Object arg version of
> the newException call. I believe these conversions to Objects are no
> longer needed (but formatting of the args might change).
> There may be code size savings to be had by doing this code
> rototil.
> Anyone see a downside to changing the code in this way?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
