java-interop: x10.interop.Java.newArray[T] should reject unsigned types for element type (JavaArray2_MustFailCompile)

As Section 4.5 "Constrained Type" in X10 language spec says, if we can use type inequalities in constraint, we will be able to reject Java.newArray[UInt](10).

public static native def newArray[T](d0:Java.int){T!=UInt}:array[T]{self.length==d0};

x10/interop/Java.x10:36: Could not find field or local variable "T".
x10/interop/Java.x10:36: Could not find field or local variable "UInt".
x10/interop/Java.x10:36: Cannot build constraint from expression |T != UInt|.
3 errors.

Added a test case in r23767.

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.
newArray[T] T<:x10.lang.Object

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[1];
int r = f(byref_arg); // f assigns to byref_arg[0]
System.out.println(byref_arg[0]);

I don't think this will come up enough at the interface between x10 and java to justify doing the T check statically.

We need to agree on what to do for this (i.e. Java array of unsigned types) issue in a short term and in more longer term. Do you think it is OK to describe this as an implementation limitation and leave it as is for X10 2.3?

I think it would be ok to leave as an implementation limitation for 2.3.0.

Record the conversation for future reference.

----- Forwarded by Mikio Takeuchi/Japan/IBM on 2012/08/28 15:10 -----

Mikio Takeuchi/Japan/IBM wrote on 2012/08/28 15:10:12:

> From: Mikio Takeuchi/Japan/IBM
> To: David Cunningham/Watson/IBM@IBMUS
> Cc: Vijay Saraswat/Watson/IBM@IBMUS
> Date: 2012/08/28 15:10
> Subject: Re: Java array of unsigned types – how can we avoid it?
>
> I don't think explicit overloading is a good idea because we also
> want to prohibit (a instanceof Java.array[UInt]) as compile-time error.
> Currently Java.array[Int] and Java.array[UInt] are valid different
> types but both of them are compiled to int[], which causes a post-
> compilation error.
>
> Mikio Takeuchi
> IBM Research - Tokyo

>
> From: David Cunningham/Watson/IBM@IBMUS
> To: David Cunningham/Watson/IBM@IBMUS
> Cc: Mikio Takeuchi/Japan/IBM@IBMJP, Vijay Saraswat/Watson/IBM@IBMUS
> Date: 2012/08/28 06:43
> Subject: Re: Java array of unsigned types – how can we avoid it?
>
> Let's go with the isref solution for now as it's easy. We can
> always broaden the API later.
>
> David Cunningham/Watson/IBM wrote on 08/27/2012 11:39:11 AM:
>
> > From: David Cunningham/Watson/IBM
> > To: Mikio Takeuchi/Japan/IBM@IBMJP
> > Cc: Vijay Saraswat/Watson/IBM@IBMUS
> > Date: 08/27/2012 11:39 AM
> > Subject: Re: Java array of unsigned types – how can we avoid it?
> >
> > Now we have isref, we can guard the call with isref T and have
> > explicit overloads for the 11 java primitives.
> >
> > UNLESS we actually want to suppose arrays of structs, in which case
> > we need a single method with a statically unconstrained T, but a
> > dynamic check for T == the unsigned variants.
> >
> > Mikio Takeuchi/Japan/IBM wrote on 08/27/2012 10:15:45 AM:
> >
> > > From: Mikio Takeuchi/Japan/IBM@IBMJP
> > > To: David Cunningham/Watson/IBM@IBMUS
> > > Cc: Vijay Saraswat/Watson/IBM@IBMUS
> > > Date: 08/27/2012 10:15 AM
> > > Subject: Java array of unsigned types – how can we avoid it?
> > >
> > > We need a decision soon.
> > >
> > > http://jira.codehaus.org/browse/XTENLANG-3003
> > >
> > > Mikio Takeuchi
> > > IBM Research - Tokyo

This is an implementation limitation in X10 2.3. Will defer to 2.3.1.

bulk defer to 2.3.2