There are legitimate reasons to do that as long as you maintain
thread-safety such as the case Ralph mentioned. Though that would probably
require full control of the API from top to bottom-ish.
On 30 April 2014 10:22, Ralph Goers wrote:
> Actually, I believe there was a case where I did that b
Actually, I believe there was a case where I did that because the method in the
subclass used java.util.concurrent instead of requiring method synchronization.
Ralph
On Apr 30, 2014, at 7:19 AM, Remko Popma wrote:
> Yes, overriding a synchronized method with an unsynchronized method sounds
>
Yes, overriding a synchronized method with an unsynchronized method sounds
dangerous... Warnings would probably be helpful.
On Wed, Apr 30, 2014 at 11:13 PM, Gary Gregory wrote:
> I'm pretty sure Eclipse does that.
>
> Gary
>
>
> On Wed, Apr 30, 2014 at 9:50 AM, Matt Sicker wrote:
>
>> So it's
I'm pretty sure Eclipse does that.
Gary
On Wed, Apr 30, 2014 at 9:50 AM, Matt Sicker wrote:
> So it's a good idea to set up your IDE to warn if you override a
> synchronized method with an unsynchronized method? I remember seeing that
> one somewhere.
>
>
> On 30 April 2014 00:35, Remko Popma
So it's a good idea to set up your IDE to warn if you override a
synchronized method with an unsynchronized method? I remember seeing that
one somewhere.
On 30 April 2014 00:35, Remko Popma wrote:
> Agreed that unless the synchronization is part of the public API it is
> better to lock on an in
Agreed that unless the synchronization is part of the public API it is
better to lock on an internal object (e.g. private Object lock = new
Object(); ).
On the other hand, OutputStreamManager and subclasses have some
synchronized public/protected methods and in this case the synchronization
on "th
If you want more than one condition monitor, it's also better to use Lock.
I'll definitely agree on the simplicity of synchronizing on an internal
Object instance, though. Locking on this, however, is generally a bad idea
because any other code can synchronize on the object as well by accident
and
I like the KISS approach for now as well.
Gary
On Tue, Apr 29, 2014 at 9:45 PM, Remko Popma wrote:
> This should be a separate thread, but anyway...
>
> I would oppose using fair locks. Not only will throughput be much less,
> the benefits are debatable, since fairness of locks does not guaran
This should be a separate thread, but anyway...
I would oppose using fair locks. Not only will throughput be much less, the
benefits are debatable, since fairness of locks does not guarantee fairness
of thread scheduling. So we would always pay a price in throughput
without any guarantee of upside
Should we be using a fair lock? That's usually a lot slower than a typical
one, but if it's more proper behavior, then it would make sense to go that
route.
On 29 April 2014 14:49, Jörn Huxhorn wrote:
> Please keep in mind that synchronized is not fair.
>
> http://sourceforge.net/apps/trac/lili
Please keep in mind that synchronized is not fair.
http://sourceforge.net/apps/trac/lilith/wiki/SynchronizedVsFairLock
Yes, a fair ReentrantLock is way slower than an unfair one… but if starvation
is caused by a logging framework then this is a serious issue in my opinion.
Joern
On 29. April 2
I'll delegate my arguments to the SO post about it:
http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java
In short, it's defensive programming. It's safer to synchronize on an
internal object than on this. Plus, it aids in concurrency throughput
instead of just using a synchroni
Why are they not appropriate lock objects? Start a discussion before just
changing them.
Ralph
On Apr 28, 2014, at 10:40 AM, Matt Sicker wrote:
> In that case, Item 69: prefer concurrency utilities to wait and notify.
> Sounds like we can just use a plain Object instance to lock (which is p
In that case, Item 69: prefer concurrency utilities to wait and notify.
Sounds like we can just use a plain Object instance to lock (which is
pretty much equivalent to using ReentrantLock) when doing normal locks, but
instead of using .notifyAll() and .wait(), we should use the Condition
interface
Yes, guidelines called out by Effective Java are appropriate when they apply.
As for concurrency, “New” isn’t always better than old. In a few places you
changed synchronized(object) to use a Lock instead. There is little to no value
in doing that and makes the code look a little more cluttered
What about style things covered by Effective Java? These are pretty much
all good ideas.
Also, how about some guidelines on concurrency? I'd recommend not using the
old concurrency stuff and instead using java.util.concurrent.* for more
effective concurrency. This doesn't include the Thread vs Run
Perhaps if one breaks the build, it should be polite to revert that last
commit...
Gary
On Mon, Apr 28, 2014 at 3:07 AM, Ralph Goers wrote:
> I think we need to develop and post some development “guidelines”, “best
> practices” or whatever you want to call it for Log4j 2. Here are some of
> th
I recommend this gets reposted to the wiki or the site docs.
On Mon, Apr 28, 2014 at 2:07 AM, Ralph Goers wrote:
> I think we need to develop and post some development “guidelines”, “best
> practices” or whatever you want to call it for Log4j 2. Here are some of
> the things I would definitely
18 matches
Mail list logo
