commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Williams <>
Subject Re: Pointers
Date Fri, 28 Jan 2011 23:47:27 GMT
On 1/28/11 3:14 PM, James Ring wrote:
> Hey,
> On Fri, Jan 28, 2011 at 3:00 PM, Stephen Williams<>  wrote:
>> True, you shouldn't synchronize on any object that A) you want to change and
>> B) can only be changed by being replaced by a newly constructed object.  If
>> Integer, for instance, had a setter method, then it could still have been
>> used in this way.  However, it seems to be immutable.  I generally just
>> create something like the following to synchronize:
> Just because an object is immutable doesn't mean that you shouldn't
> necessarily synchronize on it.
The point of the suggested link, which is valid, is to make sure you aren't synchronizing
on a variable when you are going to 
replace the value of that variable by assignment.  Since you are really synchronizing on what
the object variable is referencing, 
assigning to it later means that the objects involved before and after assignment are different
objects.  Therefore, the 
synchronization is completely broken.
>> Object lockArg;
> For example, Object lockArg = new Object() is immutable but is fine
> for synchronization.
> FYI java.util.concurrent has a much better suite of synchronization
> utilities than the language primitives provide.

Absolutely, very cool features.  But not always needed.
>> ...
>> About returning tuples:
>> Returning more than one value from a method has two reasonable solutions
>> that seem minimal for their use cases: returning a tuple as a single value
>> or making one or more calls to a callback method.  The simplest case is when
>> multiple values need to be returned.  While callbacks have their place when
>> you need to trigger more operations incrementally, they are cumbersome as
>> you need to define a class and provide an implementation, although the
>> latter can be an anonymous implementation.  Many have complained about the
>> lack in Java of pair<>, however with the object reference system, it is easy
>> to do this with arrays.  If the types are all the same, like String[], this
>> is completely typesafe.  Otherwise, you can use Object[].  You can also
>> define a return type class to fill, however that is cumbersome.  In addition
>> to Object[], a TreeMap can be a good solution, especially when more than a
>> few parameters are needed and they might change over time.
> Returning tuples indicates that you are missing some sort of
> abstraction that should be introduced to represent the thing you are
> returning. Defining a class and providing an implementation is way
> less cumbersome than dealing with the bugs that crop up when you fail
> to properly encapsulate your state. Returning a TreeMap is probably
> bad for the same reason.

Certainly, that is the common analysis.  And it can be true in many cases.  However, you could
argue your point in the extreme: The 
return value for any method should be a defined type.  Rather than returning an int, why not
"ScreenWidthType"?  There is a 
balancing need, which most ignore or do not see until it is too late, to be concise and not
promote "class diarrhea".  That is a 
term I coined after working on a project where the primary development was by an offshore
team who never met an idea for creating 
new classes that they couldn't apply several times a day.  A single transaction through the
system involved substantially all of the 
600 classes that they had created in a few months.

If you must create a return type, do it as an inner class right at the definition of the method.
 Having many tiny classes with 10 
lines of real code each can become a huge complexity burden: complex simplicity does not result
in anything like the lowest total 
complexity.  If the types are common and key objects in your system, then a separate abstraction
is appropriate.  That is seldom 
true of everything in a system.

As for the TreeMap method, both Qt/C++ and Objective-C includes a properties system where
arbitrary values can be ferried by 
objects.  For certain things, like returning sets that are potentially variable such as the
results of an XML parse, this is ideal.

>> Stephen
> Regards,
> James

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message