Final answer
Combining the code cleanups explained in the Your answer cleaned up section below with Pepe Schwarz's improvements mentioned in the Expectation alert section below we get:
use java::util::zip::CRC32:from<Java>;
my $crc = CRC32.new();
for 'Hello, Java'.encode('utf-8').list {
$crc.update($_);
}
say $crc.getValue();
Your answer cleaned up
use v6;
use java::util::zip::CRC32:from<Java>;
my $crc = CRC32.new();
for 'Hello, Java'.encode('utf-8').list { # Appended `.list`
$crc.'method/update/(I)V'($_);
}
say $crc.getValue();
One important changed bit is the appended .list
.
The 'Hello, Java'.encode('utf-8')
fragment returns an object, a utf8
. That object returns just one value (itself) to the for
statement. So the for
iterates just once, passing the object to the code block with the update
line in it.
Iterating just once could make sense if the update
line was .'method/update/([B)V'
, which maps to a Java method that expects a buffer of 8 bit ints, which is essentially what a Perl 6 utf8
is. However, that would require some support Perl 6 code (presumably in the core compiler) to marshal (automagically convert) the Perl 6 utf8
into a Java buf[]
and if that code ever existed/worked it sure isn't working when I test with the latest Rakudo.
But if one appends a judicious .list
as shown above and changes the code block to match, things work out.
First, the .list
results in the for
statement iterating over a series of integers.
Second, like you, I called the Integer arg version of the Java method (.'method/update/(I)V'
) instead of the original buffer arg version and the code then worked correctly. (This means that the binary representation of the unsigned 8 bit integers returned from the Perl 6 utf8
object is either already exactly what the Java method expects or is automagically marshaled for you.)
Another required change is that the from<java>
needs to be from<Java>
per your comment below -- thanks.
Expectation alert
As of Jan 2015:
Merely using the JVM backend for Rakudo/NQP (i.e. running pure P6 code on a JVM) still needs more hardening before it can be officially declared ready for production use. (This is in addition to the all round hardening that the entire P6 ecosystem is expected to undergo this year.) The JVM backend will hopefully get there in 2015 -- it will hopefully be part of the initial official launch of Perl 6 being ready for production use this year -- but that's going to largely depend on demand and on there being more devs using it and contributing patches.
P6 code calling Java code is an additional project. Pepe Schwarz has made great progress in the last couple months in getting up to speed, learning the codebase and landing commits. He has already implemented the obviously nicer shortname calling shown at the start of this answer and completed a lot more of the marshaling logic for converting between P6 and Java types and is actively soliciting feedback and requests for specific improvements.