1. I didn't write unit tests but it shouldn't be any different than writing tests against any other Perl object. It may take a bit more work to test output that is not a primitive value. All you'd be testing though is your interface to the Java layer, not the actual Java itself.
2. There was certainly no option that came up with better integration than Inline::Java. For my use cases, there was nothing that could be run via system(). An RPC interface wasn't handy either and my Java chops aren't up enough to write one. I was a lone wolf on those projects and had to make do with what I had. Perl is the more readily used language in my group so this also provided the most interoperability. It comes down to "what is the best solution for you?" An RPC makes sense if that allows quicker future integrations. system() makes sense if a CLI exists already. There may be other reasons to pick those options. Although, come to think of it, Inline::Java (in it's default mode, separate JVM) is pretty much and RPC-ish interface you don't have to write yourself. Granted, it's Perl only. Food for thought. On Sun, Jul 14, 2013 at 10:04 PM, Tom Metro <[email protected]> wrote: > William Cox wrote: >> Feel free to ask any questions you may have. > > Thanks to both of you for a nicely done presentation. > > A couple of follow-up questions: > > 1. Did either of you attempt to unit test your Java code? > > Presumably, if you structure things well, there should be minimal need > for this. Your inlined Java code gets reduced down to wrapper/glue code, > and that gets coverage through traditional Perl-driven unit tests or > system test. > > > 2. What alternatives to Inline did you explore for making the Perl-Java > connection? > > One of you made reference to preferring Inline over using system() to > call a command line Java tool, which makes sense, but I heard no mention > of RPC options. An obvious solution (as a non-Java developer) that comes > to mind is to use servlets. This gives you a nice clean separation > between the Perl and Java code, allowing each domain to be handled by > separate programmers and unit tests. (I've worked on the Perl side of > teams doing Perl-Java servlets interfacing.) > > The downside to an RPC mechanism is that you'll need multiple processes, > resulting in a heavier weight, slower solution. (Though you already > discussed optimizing to minimize Perl-Java transitions, and it sounded > like some of he Inline options used multiple processes.) > > Creating the Java side for an RPC solution may be more work, if you > don't know Java or don't have a Java programmer on your team to cover > that side. Both RPC and Inline require some work on the Perl side to > deal with the transition. > > I suspect the servlet approach outnumbers Inline for inter-language > interfacing these days. That's what SOA is all about. > > -Tom > > -- > Tom Metro > Venture Logic, Newton, MA, USA > "Enterprise solutions through open source." > Professional Profile: http://tmetro.venturelogic.com/ > > _______________________________________________ > Boston-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/boston-pm -- William Cox email: [email protected] gplus.to/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
