Our automatic update fetched the new Inline-Java version from CPAN some
time ago!
http://search.cpan.org/src/PATL/Inline-Java-0.51/CHANGES
Congratulations!
There were some awaited features here, including the option to bind on
another host (127.0.0.1) and CharSequence support. Super cool!
There is, also, another proposal for improvement:
To start the Java::Inline inside our JVM we instantiate the
InlineJavaServer manually. We automatically search for the
CPAN-installed "InlineJavaServer.jar", load it via URLClassLoader and
instantiate the InlineJavaServer using reflection. Thus we have some
independence from the Inline::Java version we use: we can
install/upgrade Inline::Java on different architectures and things
continue to work, and we don't have to modify or copy anything (like
copying "InlineJavaServer.jar" into our libs and linking against it).
Thus we preserve Inline::Java unity and encapsulation as much as
possible, i think. The problem is, since we have to call two methods on
the InlineJavaServer: the public constructor and RunMainLoop, we run
into possibility of portability problems, because InlineJavaServer
public constructor contains pretty match the whole configuration of the
Inline::Java JVM part. We can't guarantee that next update won't add
more parameters to the constructor (it is even possible that some
parameter would be removed and another added into its place, leading to
consequences unknown), as it happened with the update from 0.50 to 0.51.
I think, the best solution to preserve feature portability here would be
to have an empty public constructor for InlineJavaServer, with
configuration moved to system properties; thus the InlineJavaServer can
be configured both from the code and from outside the JVM using it's
command-line arguments. Another solution would be (again, having an
empty constructor with some defaults) to configure the InlineJavaServer
using set* methods. Or there might be a Properties instance to be passed
as a single argument to the InlineJavaServer. Overall, i think the
InlineJavaServer is an important API for anyone using Inline::Java from
inside their application, and portability of its interface should be
considered.
Again, thanks for the great work continued even up to 0.51,
and good luck.
