Hey,
On Fri, Jan 28, 2011 at 3:00 PM, Stephen Williams <scient...@gmail.com> 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.
> 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.
> A method I use for returning more than one value would be useful here also:
> Integer[] arg = new Integer[](1);
> arg[0] = new Integer(5);
> // or with autoboxing:
> arg[0] = 5;
>
> void funkyChanger(Integer[] arg) {
> synchronized (arg) { ... arg[0]++; ... }
> }
>
> Is there a problem with this as a general idiom? You could use naming to
> signal the nature as indirect vs. logically an array. And, a future version
> of Java could use syntactic sugar for 'ref' to do this by autoboxing the 1
> deep array also.
>
> 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.
> Stephen
Regards,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
