An interview with Flavio Glock that takes as its starting point his brand new project, PerlOnJava, a native compiler that turns Perl into Java bytecode and runs it. 

We've interviewed Flavio a couple of times before on his previous project, Perlito. Perlito is a compiler collection that implements a subset of Perl 5 and Perl 6 and compiles Perl 5 or Perl 6 programs into various backends, including JavaScript, Python, Ruby and Go. But it was also designed with extensibility from the ground up so it could be extended to other backends further along the line. That point came about 7 years ago with the new backend being that of Java.

So given Flavio's new PerlOnJava project, it begged the question - how does it differ from Perlito? So we asked him for a new interview to catch up with the latest developments.

But before finding out everything about PerlOnJava and to set the proper context of our latest conversation, here's an excerpt of the 2017 interview I did with Flavio on Perlito and, at the time, the new Java backend:

So Flavio, back in 2013 Perlito's definition was:

a compiler collection that implements a subset of Perl5 and Perl6

Are we still talking about a subset, and in any case what percentage of Perl can be now mapped to Java?

At this stage, Perlito5 sees itself more like a "Perl port" within which Perlito5-Java and Perlito5-JavaScript would be “platforms”. Many of the missing features are due to platform differences, rather than “not yet implemented”.

All of the Perl syntax can be mapped to Java. Specific functions are prioritized to be implemented first - either because they are more useful, or because it is low-hanging-fruit.

All Perl types are supported - scalar, array, hash, closure, regex, typeglobs, references and objects; as well as declarations - my, our, state, local. “require” was just implemented (after the release); “tie”, “overload” are work-in-progress.

Error messages are hard to replicate exactly. This is slowly improving.

What is left out? 

XS is left out. XS is Perl foreign function interface through which a program can call a C or C++ subroutine - this doesn’t work (not natively) in the JVM environment.

• many CPAN modules that use C libraries don't work
• some CPAN modules are already ported, see: Perlito5 - java - native types wip

The ported Digest::MD5, Digest::SHA1, and MIME::Base64 modules are neat, because there are Java APIs that could be used almost straight out of the box.

List::Util, Scalar::Util, and Encode.pm are not so clean - these involve some low-level (Java) stuff.

XS is very interesting, but it is also very complicated. Supporting pure Perl allows Perlito to have completely different calling convention and internal data structures, optimized for JVM.  

What cannot be done? 

DESTROY is not done. While we could track object lifetimes, this is just not the way the JVM works. Even if you don’t use DESTROY directly, you will notice other problems:

• files don't "auto-close" at the end of a block
• weaken() is a no-op
• Try::Tiny "finally" doesn't work
• Object::InsideOut will not cleanup unused objects 

Given Flavio's PerlOnJava project sounds very similar in purpose to that of Perlito, I set to uncover the differences. However the discussion did not constrain itself to those narrow boundaries, but expanded to examine topics such as the JVM, GraalVM, Truffle, Raku, and Virtual Threads, and so on as well as ending up asking Flavio's opinion on Perl's future. So without any further ado, let's jump in!

Are you still working at Booking and what are you working on currently?

I am currently employed at Booking.com as a Senior Developer in the Marketing Department. My role focuses on leading and contributing to projects aimed at enhancing our tools and strategies for optimizing campaign performance and overall marketing effectiveness. Additionally, I have been actively involved in building Perl 5 and Raku compilers since 2005, when I started contributing to the Pugs project.

Now to the hot question. What is the difference between Perlito and PerlOnJava?

Perlito, a bootstrapped Perl compiler written in Perl, is highly versatile and supports both Ahead-of-Time (AOT) and scripting modes. It's feature-rich due to its longer development history and can generate Java bytecode or JavaScript, but this comes at a cost: Perlito's compilation process can be slow, and the compiler itself is quite large.

In contrast, PerlOnJava is a native Perl compiler for the JVM, utilizing the ASM library to generate Java bytecode directly. This results in several key benefits:

• Faster startup times: PerlOnJava produces smaller JAR files, making it quicker to load and run.

• Efficiency in eval execution: PerlOnJava handles eval operations more efficiently than Perlito.

• Modular design: From an architectural standpoint, PerlOnJava is more structured, making it easier to maintain and extend.

While Perlito has the advantage of more features at this stage, PerlOnJava's direct bytecode generation offers significant performance benefits, particularly for JVM-based environments. Moreover, PerlOnJava's streamlined, modular design makes it a strong choice for future scalability and improvements, especially in environments where startup time and eval performance are critical.

Both compilers face similar JVM limitations, such as the lack of native support for Perl's reference counting, XS modules, and automatic closing file handles.