Dear Michael, although this is not directly related with your grant proposal, what are the benefit of having Perl running on JVM? Thank you.
I share Alberto's question. While it's interesting that this is even possible, I don't see a great demand for this and don't think it's a good use of limited TPF resources.
This proposal is too vague for my taste. It may be useful and worth the money, but I can't quite decipher that.
To David's point, it is worth following up with the current users to see how they're using the current library and what the demand is.
Dear Alberto, thank you for asking that question. The benefit should be no different from any other ported build running perl; additionally, having perl available from jar makes it is independent of the current installed perl and available for its inclusion in a java-based project.
Thank you for commenting Leon. It is my first proposal. Feel free to post a more detailed critique to the proposal @ https://groups.google.com/forum/#!forum/jerl-software-project
I agree with the other comments, this is a very vague idea. Is the goal of Perl 5 on the JVM the ability to interact with Java libraries and provide another way to build upon existing java code bases?
What are the business cases for the this project? As it is I see this as a waste of TPF's limited funds.
This is a very nicely structured grant proposal. It clearly sets out the proposed work at a useful level of detail, and the amount requested is quite reasonable given the work described. However, I'm not convinced that the benefits of the project make it worth funding.
The benefits to the community are stated as The community is using this product and it adds to Perl5's capabilities. A more complete product is more helpful for the QA and dev community.
I find this far from compelling. The linked-to FAQ stresses that Jerl is not fast, suggesting alternatives which are, meaning that Jerl isn't appropriate for production use. I've tried benchmarking jerl.jar, and on the same hardware it's about 50 times slower than native perl 5.
Right now it's based on microperl, which means that it can't even use Config, let alone more interesting modules. Whilst the grant intends to change the build to using full perl which would provide at least Config and pure-perl modules, it's not clear from the grant whether core XS modules would be built, let alone whether it would be possible to build and install modules from CPAN.
Something which is 50 times slower than native Perl 5, which can't build CPAN modules, is really not of any practical use to the dev or QA community.
Which makes me wonder what it is useful for.
If the goal is Perl on the JVM, then Rakudo Perl 6 already builds on the JVM. On the same hardware it's already faster than Jerl, even for string handling, which is currently a weakness of Rakudo. Unlike Perl 5, Rakudo provides decent concurrency support, including useful high-level composable concurrency features. It also interfaces to native Java code already, which isn't even on the Jerl roadmap. It's likely that this months "Star" release will support the JVM too, meaning that there will soon be a Rakudo .jar analogous to the jerl.jar.
So within a few weeks (ie before this grant will have started, let alone finished) there will be far more interesting Perl available for the JVM.
The other stated goal is fun. I have no trouble whatsoever with fun (even if it looks like I'm spoiling the fun). Fun is a good reason for a personal project. But I don't think that TPF should be spending its limited resources on projects which don't benefit the community, and the fun of implementation is neither a lasting benefit nor a community benefit. :-(
I'm not sure I understand just what is meant by "include Perl in Java." My understanding is that what is being done right now is that perl is running on a "PC" VM running inside the JVM. That is: perl's running on a traditional machine running on the JVM. If this is the case, my assumption is that you can't call Perl routines from Java code with this system, nor call Java code from Perl code.
My assumption would be that you could, given a Perl program as a file or a string, have the program run on this emulated hardware and communicate with it using traditional RPC/IPC techniques. So, the main benefit *seems* to be deploying Perl code in jars to run on emulated hardware.
Have I grossly misunderstood?
Let me add a clarification. When I mean business cases for this project I mean what would make me use Perl 5 on the JVM over the existing Perl 5 implementation?