There are a whole lot of things here I think we need to think about whether we want to support:
We definitely want
newArray[T] T is a java class, such as existing APIs (i.e. excluding java-compiled x10 classes)
newArray[T] T one of the java primitives
We are therefore forced into having
newArray[Any] because java.lang.Object is a java class and is exposed as Any
We may want this, and it's easy to support. I don't think it is useful.
I don't think we do want this, even though it's easy to support. It's even less useful.
newArray[T] T is a user-defined struct
And we definitely don't want this, because it would need more boxing than we currently do
newArray[T] T is an unsigned integer type
Note that if newArray[T] for a given T is not allowed, it is still possible to store the same data using newArray[Any]
Supporting everything that is easy to implement at this time is probably a bad idea as it could make it harder to change design later. We should only support things for which there is an apparent use.
Controlling whatever restrictions we go with using the type system seems like making hard work for ourselves. The above-mentioned feature isn't implemented yet and there are no concrete plans for it that I know of. We can however throw an exception at runtime if T is inappropriate, and use whatever logic we want to check the dynamic type of T, and change this logic whenever we feel like it without having to rely on the type system.
This is only sensible if we are not worried about performance of creating tiny java arrays from X10. There is only one case I can think of where this could be a problem, and that's the byref idiom in java:
int byref_arg = new int;
int r = f(byref_arg); // f assigns to byref_arg
I don't think this will come up enough at the interface between x10 and java to justify doing the T check statically.