As a matter of fact, yes. But only briefly, because it was much more expedient to simply write the whole thing in the native language. Here’s the relevant quote – and the problem – taken directly from the Perl web-page:
Then Perl asks the Java classes what public methods have been defined. These classes and methods are available to the Perl program as if they had been written in Perl.
. . . but the phrase, “as if they had been written in Perl,” is somewhat misleading. Perl has transparent access to Java’s foreign-function interfaces, but is no more privileged in that regard as would be any other client using a similar interface.
The two interpreter environments are running in tandem, using (in this case) Java’s public interfaces. Those interfaces do not expose whatever is private, and they (of course, necessarily) do not have Perl-VM “doing” anything to, or directly with, the Java-VM’s environment, because languages never expose interfaces that would de-stabilize or compromise their own integrity, even in the name of testing. As I read the OP, the latter is along those lines: “you, Java, having created this var, let me, Perl, do with it.” Your capacity to do this is, as I read it, too limited to support the requested scenario.
Java has testing frameworks comparable to, and in some ways superior to, those offered by Perl. Therefore, if it were me, I would cleanly divide this testing scenario into three non-intersecting parts: (1) a test of Perl by Perl; (2) a test of Java by Java; and (3) a test of the interface between them, specifically where those interfaces are meant to be “public interfaces offered by this Java app for the consumption by others.”
Although it may not seem so, and although I do not always explain myself too well, I don’t make comments here merely to see my handle showing up on a web page. If I am mistaken, simply correct me.
| [reply] |
| [reply] |
