use java::util::zip::CRC32:from<java>;
my $crc = CRC32.new();
for 'Hello, Java'.encode('utf-8') {
$crc.'method/update/(B)V'($_);
}
say $crc.getValue();
sadly, this does not work
Method 'method/update/(B)V' not found for invocant of class 'java.util.zip.CRC32'
This code is available at the following links. It is the only example I've been able to find
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:
Your answer cleaned up
One important changed bit is the appended
.list
.The
'Hello, Java'.encode('utf-8')
fragment returns an object, autf8
. That object returns just one value (itself) to thefor
statement. So thefor
iterates just once, passing the object to the code block with theupdate
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 6utf8
is. However, that would require some support Perl 6 code (presumably in the core compiler) to marshal (automagically convert) the Perl 6utf8
into a Javabuf[]
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 thefor
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 6utf8
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 befrom<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.