RE: JavaMemoryModel: Final and Volatile array classes

From: Doug Lea (
Date: Thu Mar 23 2000 - 09:42:19 EST

> I think there are pragmatic arguments which favour a language
> change. First, modifying array-using code to instead use
> VolatileXXXArrays is very intrusive. It's not just declarations
> which have to be changed, it's all uses as well. Worse, ...

I'm sympathetic. But all of the syntactic approaches I know of are
almost equally intrusive, and introduce additional language
complexities of the kind that C++ programmers know and hate.

For example, suppose the syntax is

  (volatile int)[] varr = new (volatile int)[100];

I could not send varr to a method expecting an int[], at least not
without giving up volatile properties. So I'd need to reparameterize
(and in some cases therefore duplicate, so could apply to both
flavors) methods like:

  void reverse(int[] a);
  void reverse((volatile int)[] va);

Plus rules for casts in both directions. And so on.

The net effect on programmers is just not all that different than the
special-classes proposal. The net effect on the language is a new,
fairly large set of rules that would take a while to iron out and
would prbably meet a lot of resistence.

> Second, there are a several places in the standard APIs where
> arrays are used as lightweight factories. And unless things
> have changed recently, this mechanism is recommended for use in
> GJ to work around the it's lack of support for type-
> parametrized object creation. If GJ forms the basis of the
> design for parameterized types in a future Java (which seems
> likely) there might be scope for conflicts.

I can't see any such conflicts offhand, but agree that
generics JSR folks ought to sanity-check this.

> Third, many working programmers simply will not believe that
> their compilers will be able to do a good enough job of
> inlining these methods calls. And if they're that worried about
> performance it's quite likely that they're the ones coding
> data-races: ie. the very consituency the VolatileXXXArray
> proposal is aimed at is likely to be the most resistant it.

Yup. This, and the need to revise core classes, are the two
best arguments against it. Still, I think they are outweighed
by other advantages.

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT