> 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);
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 - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT