harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: svn commit: r960424 - /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java
Date Wed, 07 Jul 2010 19:12:19 GMT

In message <AANLkTinsT2AfVDLXXn8767i9NNj5JhqazxmsBmNJTOp8@mail.gmail.com>,
Jesse Wilson writes:
> On Sun, Jul 4, 2010 at 8:05 PM, <regisxu@apache.org> wrote:
> On Tue, Jul 6, 2010 at 6:56 AM, Mark Hindess <mark.hindess@googlemail.com>
> wrote:
> > This breaks the build for the IBM VME (from developerWorks).  Since
> > they don't have a sun.misc.Unsafe, so the AtomicInteger can't be
> > resolved.
> If VME is to stay modern, they're going to need to support
> java.util.concurrent. I don't think Harmony should provide a
> lowest-common-denominator class library; supporting systems that don't
> have j.u.c is an unnecessary handicap.

For what it is worth, I agree.  I was not necessarily anticipating the
change being reverted.  I would not be unhappy with our breaking the
obsolete VME.  My main purpose in sending my mail was to make sure we
did it knowingly with good reason rather than inadvertently because we
weren't paying attention.

> Particularly since they can implement AtomicInteger using
> less efficient concurrency primitives. There's even a full
> backport<http://backport-jsr166.sourceforge.net/>that could close some
> gaps if the standard java.util.concurrent isn't feasible for their VM.

Useful reference.  Thanks.


View raw message