William, Thank you for offering your thoughts and your experiences.
I feel about better about using Inline::Java. My application is large enough that porting it to another language would be nontrivial. Inline::Java seem like a better choice than the alternatives such as calling Java with system, reimplementing algorithms. -- David On Wed, May 29, 2013 at 3:15 PM, William Cox <[email protected]> wrote: > My suspicion is that it's 2-fold: > 1. Java doesn't fit the "Perl mold" > 2. Inline::Java can be tricky to get setup (despite the docs > appearing to make it easy) > > On (1), the development philosophies between perl and java tend to be > so different that each side almost writes the other off. > > In my experience on (2), for example by BEGIN block does the following > things (for the maven wrapper): > 1. find the installation of the mvn command line utility, then add > all the jars to $ENV{CLASSPATH} > 2. map java classnames to constant subs in the current package > representing the perl package standing in for that java class > > Then I execute the 'use Inline (args);' line. Here is a brief example > of what I'm doing: > > BEGIN { > chomp(my $mvn = `which mvn`); > $mvn or die "Unable to locate maven installation - is it installed?"; > > $maven_home = Cwd::realpath($mvn); > $maven_home =~ s{/bin/mvn$}{}; > > $ENV{CLASSPATH} = join ':', <$maven_home/lib/*.jar>, > <$maven_home/boot/*.jar>; > > @class = ( > 'java.io.File', > 'java.io.FileInputStream', > ... > 'org.apache.maven.Maven', > ... > ); > > %class = map { (/\.(\w+)$/ => Inline::Java::java2perl(__PACKAGE__, > $_)) } @class; > > # this will create &subs that simply return the full class of the java > # package > my $stash = Package::Stash->new(__PACKAGE__); > while (my ($C, $P) = each %class) { > my $symbol = "\&$C"; > next if $stash->has_symbol($symbol); > $stash->add_symbol($symbol, sub () { $P }); > } > } > > use Inline ( > Java => 'STUDY', > EXTRA_JAVA_ARGS => > "-Dmaven.home=$maven_home > -Dclassworlds.conf=$maven_home/bin/m2.conf -Xms2048m -Xmx2048m", > STUDY => \@class, > AUTOSTUDY => 1, > JNI => 1, > CLASSPATH => $ENV{CLASSPATH}, > NAME => __PACKAGE__, > DIRECTORY => ((__FILE__ =~ m{^(.*)\.pm$})[0] . '/_Inline'), > ); > > All of this makes for a rather non-trivial use-case for Java inside > perl. I spent a lot of time finding the right setup for my needs. And > that tends to be common for Java in general (why engineer it once when > you can over engineer it twice). > > On Wed, May 29, 2013 at 1:41 PM, David Larochelle <[email protected]> > wrote: > > Thanks William, > > > > My biggest concern with Inline::Java is why it isn't more widely known > and > > used. For data analysis, there are two main choices: Python and the JVM > > stack. CPAN is nice but it just doesn't have the data libraries these > > platforms do. It would seem like Inline::Java would be frequently touted > as > > a savor of Perl letting you write code that uses both powerful Java > > libraries and CPAN while still having the benefits of Perl. > > > > Are the reasons why Inline::Java isn't more widely known and used > cultural? > > E.g. Perl developers have an aversion to Java, most Perl developers don't > > need data analysis, Inline::Java is badly marketed, etc. Or are there > > technical reasons why Inline::Java is less attractive than it first > appears? > > > > Would it make sense to use Inline::Java and Perl for a green field > project > > or would it be better to just use Java or other JVM languages such as > Scala > > or Jython when Java libraries are a major component? > > > > -- > > > > > > David > > > > On Tue, May 28, 2013 at 10:42 PM, William Cox <[email protected]> > wrote: > >> > >> I've used Inline::Java for 2 main projects in my $work: one is a > >> wrapper around the Maven libraries to introspect POMs, the other is a > >> long run daemon using an internal java library. I've found it to be > >> extremely reliable. To help maintain performance, keep in mind the > >> following: > >> > >> 1. use the JNI interface so that all Perl<->Java communication happens > >> in the same process. the other mode runs a separate process and > >> communicates over a unix socket. > >> 2. more importantly, plan very carefully your calls (method calls, > >> property lookups, object construction, etc.) from Perl to Java. I've > >> found that the time to communicate even simple data can take much > >> longer that the time taken to process that data (to much context > >> switching). > >> > >> (2) for me was exemplified for me on wrapping our internal Java > >> library. I was doing lots of back-and-forth. After implementing a > >> Java-side layer that did the same calls I was doing from Perl, I saw a > >> significant speed boost. > >> > >> Hope this helps. > >> > >> On Tue, May 28, 2013 at 8:59 PM, David Larochelle < > [email protected]> > >> wrote: > >> > Does anyone have experience with Inline::Java? > >> > > >> > I did some basic tests with it and it seems to work but I'm concerned > >> > about > >> > its reliability in production use. > >> > > >> > The use case is a large data processing system implemented in Perl. > I'd > >> > like to add an algorithm (Conditional Random Fields) that's not > >> > implemented > >> > on CPAN but is available as a Java library. > >> > I'm hoping to use Inline::Java to allow this algorithm to be called > from > >> > the existing Perl code. > >> > An alternative is to execute the Java code as a separate process and > >> > pass > >> > data to the Perl process with pipes and files. > >> > > >> > In my case the Java code will be run around 50,000 times a day to > >> > process > >> > incoming data. So I want to make sure that whatever solution I use is > >> > stable and low overhead. > >> > > >> > Thanks, > >> > > >> > David > >> > > >> > _______________________________________________ > >> > Boston-pm mailing list > >> > [email protected] > >> > http://mail.pm.org/mailman/listinfo/boston-pm > >> > >> > >> > >> -- > >> William Cox > >> > >> email: [email protected] > >> sgp.cm/mydimension > >> > >> -----BEGIN GEEK CODE BLOCK----- > >> Version: 3.1 > >> GCS d- s+:+() a C++(++++)$ UBLC(++)$ > >> P+++(++++)$ L++(+++)$ !E--- W++(+++)$ > >> !N !o? K--? !w--- !O M++ !V- PS-(--)@ PE+() > >> Y+ !PGP t++ !5 X+++ !R tv(+) b+>++ > >> DI+(++) D+() G e h--- r+++ y+++>++++ > >> ------END GEEK CODE BLOCK------ > > > > > > > > -- > William Cox > > email: [email protected] > sgp.cm/mydimension > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.1 > GCS d- s+:+() a C++(++++)$ UBLC(++)$ > P+++(++++)$ L++(+++)$ !E--- W++(+++)$ > !N !o? K--? !w--- !O M++ !V- PS-(--)@ PE+() > Y+ !PGP t++ !5 X+++ !R tv(+) b+>++ > DI+(++) D+() G e h--- r+++ y+++>++++ > ------END GEEK CODE BLOCK------ > _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
