Grant Proposal: JERL (Alien::Jerl) Perl5 running in the JVM

10 Comments

We have received the following grant application. Please leave feedback in the comments field by March 22nd, 2014.

JERL (Alien::Jerl) Perl5 running in the JVM

  • Name

    Michael Shomsky

  • Email:

    undisclosed

  • Amount Requested:

    How much is your project worth? $ ~3000 (US)

  • Note:

    The project is in maintenance mode and it's 2nd year. It's gotten this far on 4hrs/month from one developer who would like to see it in a state where the build-toolchain is documented further, additional tests in Java products to insure future integration, and complete work on the rest of the build.

Synopsis

JERL: Run perl in the JVM

Benefits to the Perl Community

Why should the Perl Community grant this project? 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.

Deliverables

Current Deliverables may be found at https://code.google.com/p/jerl/

Expected Deliverables:

  • Java based testing to ensure VM still works with new builds
  • Stable Eclipse project as a build artifact
  • Updates to the VM wrapper
  • Documentation for the build environment
  • Documentation for the test environment
  • A more complete build of perl living within the JVM

Project Details

https://code.google.com/p/jerl/wiki/JERL_FAQ

JERL's aim has been clear: include Perl in Java. The project at 4 person hours / month has been stable enough to maintain the existing product. However, it is not enough time to address build and test related issues without further funding. A few issues and enhancements have been outstanding for a while that cannot progress without further person hours or funding.

Milestones Overview

  • Enhanced Testing: 40-person hours
  • Commandline: 0-person hours (already done in Alien::Jerl)
  • Products: [eclipse project and java test integration]: 40-person hours (needed)
  • Formalize build environment and toolchain: 10-person hours
  • Finalize transition of build from microperl to full perl 2 weeks

Inch-stones

  • Enhanced Testing: 40-person hours
    • Java Artifacts 40-person hours
      • Inchstone: Create build artifact for a sample java product
      • Inchstone: Create build artifact for an eclipse product
      • Inchstone: Create tests for VM integration as part of build
      • Inchstone: Create tests for Perl to detect and set Java
      • Inchstone: Modify tests to correct for windows environment
      • Inchstone: Modify tests to be language independent
  • Formalize build environment and toolchain: 10-person hours
    • Inchstone: Build and debug in clean/new ubuntu environment
      • Inchstone: Document environment setup during creation
    • Inchstone: Document build process in the form of text and wiki entries
    • Inchstone: If failures or complexities are encountered then document differences from PERL5
  • Full Perl5 Functionality:
    • Research meta-build 160-person hours
    • Inchstone: Re-research the perl5 build and how the build builds the build
    • Inchstone: Review how to run the built products from the VM to allow for the Perl5 build to continue even though some of the build will have to proceed in the VM
    • Inchstone: Document build process, identify pieces that migrate to VM

Project Schedule

  • How long will the project take?

    1 month for 1 developer effort

  • When can you begin work?

    Late March, Early April 2014

Completeness Criteria

  • Completeness Criteria:
    • Inchstone identified have measurable artifacts which include projects
    • Whitepaper / Howto Build

Bio

  • Who are you?

    My name is Michael Shomsky http://www.linkedin.com/in/michaeltshomsky

  • What makes you the best person to work on this project?

    I want to see this work and have been nursing this project, from inception, since 2012. I'm delighted that there are people out there who use it.

10 Comments

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?

Leave a comment

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

Recent Comments

  • Kirk Kimmel: Let me add a clarification. When I mean business cases read more
  • rjbs.manxome.org: I'm not sure I understand just what is meant by read more
  • Nicholas Clark: This is a very nicely structured grant proposal. It clearly read more
  • Kirk Kimmel: I agree with the other comments, this is a very read more
  • michael shomsky: Thank you for commenting Leon. It is my first proposal. read more
  • michael shomsky: Dear Alberto, thank you for asking that question. The benefit read more
  • mtshomsky: To David's point, it is worth following up with the read more
  • Leon Timmermans: This proposal is too vague for my taste. It may read more
  • David Golden: I share Alberto's question. While it's interesting that this is read more
  • Alberto Simões: Dear Michael, although this is not directly related with your read more

About this Entry

This page contains a single entry by Makoto Nozaki published on March 15, 2014 9:00 AM.

Maintaining Perl 5: Grant Report for Month 7 was the previous entry in this blog.

Grant Proposal: RPerl Test Suite Upgrade & Module::Compile Integration is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

OpenID accepted here Learn more about OpenID
Powered by Movable Type 4.38