However there's a fair bit of impedence between core Parrot PMC's (strings, arrays, hashes, etc) and Java datatypes (4 types of integer!).

This should (in theory) not make any difference. The compiler will determine which Parrot PMC is most appropriate to each Java datatype and assign them accordingly. It is also possible (and very likely) to write new Parrot PMCs which will map more directly to the Java datatypes.

It is important to think of Parrot as a toolbox for compilers, and not so much for programmers.

Being more optimistic, will it be possible to subclass a Java class in Perl6 and then use it as a method argument to another Java class?

My sticking point is subclassing back to Java. A somewhat contrived example:

In Perl 6:

class MyPerlClass
    method foo {...};
    method bar {...};
[download]

...then to extend the class in Java

class MyJavaClass extends MyPerlClass {
    public void output() {System.out.println(foo() + bar());}
}
[download]

Add or concatonate?

The programmer still needs additional interfacing definitions, or castings or something. It doesn't look seamless.

Well the Perl would compile into something like this (I wrote this in PIR instead of PASM because I am not that much of a masocist :)

.namespace [ "MyPerlClass" ]

.sub "__onload" :load
    .local pmc klass
    newclass klass, "MyPerlClass"
    .return ()
.end

.sub foo 
    $S0 = "MyPerlClass::foo"
    .return($S0)
.end

.sub bar 
    $S0 = "MyPerlClass::bar"
    .return($S0)
.end
[download]

And the Java would compile into something like this:

.namespace [ "MyJavaClass" ]

.sub "__onload" :load
    .local pmc klass
    $P0 = getclass "MyPerlClass"  # load the Perl class 
    subclass klass, $P0, "MyJavaClass"
    .return ()
.end

.sub output 
    .local pmc System
    .local pmc String
    $S0 = self.foo()
    $S1 = self.bar()
    concat $S2, $S0, $S1    
    # assume that the Java 
    # standard libraries exist 
    System = getclass "java.lang.System"
    String = getclass "java.lang.String"
    # assume that a String object can be
    # constructed from a native Parrot string 
    $P0 = String.new($S2)  
    $P1 = System.out()
    $P1.println($P0)
    .return ()
.end
[download]

Of course I am simpliying here, Java classes would need to inherit from java.lang.Object somehow, so maybe the Java compiler writer would have a special PMC specifically for Java classes (although compatible with normal PMC classes too). As for how we know that the return values of self.foo() and self.bar() are Parrot strings and not java.lang.String. It is not outside the range of the compiler's abilities to determine this, especially since it would be known that foo and bar are not defined in MyJavaClass, and could (maybe) be assumed to be coming from MyPerlClass. Of course it does get trickier if either of those methods actually came from MyPythonClass which maybe MyPerlClass would inherit from (not shown in the example).

But what I am trying to get at really is that once everything is compiled to PIR/PASM, it really doesn't make much difference. Most of the problems you are bringing up are problems that the compiler writers will have, and should not be problems that users are made to deal with. If users have to deal with these issues, then the compiler is not doing it's job correctly.

UPDATE:
I forgot to address your last question :)

Add or concatonate? The programmer still needs additional interfacing definitions, or castings or something. It doesn't look seamless.

Does the programmer need to deal with this in regular (non Parrot) Java? Of course not javac handles it. Why would a Java to Parrot compiler be any different? Given enough static anaylsis, this is a likely a fairly trivial case.

-stvn