Java dependency?

[Johnicholas]

Hello, Ke Jin.

I am looking forward to experimenting with Pococapsule, but I'm having
trouble with the Java and Jni components.
Eventually I will solve the configuration problems, but in the
meantime, could you explain what features or libraries from Java
pococapsule is using? I'm not a "everything must be the same language"
bigot, but none of the articles I read mentioned that Pococapsule was
using Java internally.

Also, I note that pococapsule is using Xerces. How difficult would it
be to substitute the Kranf parser ("Small, simple, cross-platform,
free and fast C++ XML Parser") instead? I know it is less standards-
compliant, but small and simple is very tempting.

Johnicholas

[Ke Jin]

Hi Johnicholas,

Thanks again for the two good questions! They happen to be related to
each other, and all relate to the same issue of description reader.
See my inline answers.

Ke

On Feb 28, 12:49 pm, Johnicholas <johnicholas.hi...@gmail.com> wrote:
> Hello, Ke Jin.
>
> I am looking forward to experimenting with Pococapsule, but I'm having
> trouble with the Java and Jni components.
> Eventually I will solve the configuration problems, but in the
> meantime, could you explain what features or libraries from Java
> pococapsule is using? I'm not a "everything must be the same language"
> bigot, but none of the articles I read mentioned that Pococapsule was
> using Java internally.
>

All PocoCapsule development tools/utilities, such as pxgenproxy,
pxtransform, pxencode, etc. are written in Java. In addition, one of
the three description readers of PocoCapsule uses, through JNI, the
same java based XML parsing and DOM transformation engine of these
tools (the other two description readers are purely C++ based) .
Although this Java based XML description reader could be used in
production runtime if feasible, it is most likely to be used in
learning, testing, and development time. See more discussion on this
issue below.

> Also, I note that pococapsule is using Xerces. How difficult would it
> be to substitute the Kranf parser ("Small, simple, cross-platform,
> free and fast C++ XML Parser") instead? I know it is less standards-
> compliant, but small and simple is very tempting.

It is straightforward. In PocoCapsule, application description readers
can easily be implemented, replaced, and added (registered) to the
core engine. To do this, one only need to implement a description
reader that extends the POCO_AppDescReader class (pocodom.h) and
register itself to PocoCapsule through static singleton constructor.
For detail, the Xerces based XML reader can be used as an example (in
xmlreader/xmlreader.C/h). Implementing a new XML description reader
from scratch should need less than two hours and 300 lines of code.

However, I do not see the need and advantage of having another XML
description reader in PocoCapsule. Even the Xercse based XML
application reader in PocoCapsule is only included in the source code
as an example (to show how to implement an description reader) rather
than for any practical advantage. What should be used is the Java
through JNI based XML description reader (in the xslreader directory).
This reader appears to be worse than other C++ native alternatives but
is actually a sufficient and better solution for XML handling and
model transformation in PocoCapsule (see discussions below). If any
additional description readers are to be added, I would look at, for
instance a Lisp S-Expression reader, a C++ or Java annotation reader,
etc.. rather than another XML reader.

The conclusion above is based on the following consideration namely,
IoC frameworks are not intended to be yet another scripting
environment. Rather, IoC frameworks are mainly for:

* Separating plumbing logic (component life cycle controls wirings,
initial property settings etc.) from business logic and supporting
framework agnostic business logic components.
* Allowing user to setup (configure/deployment/etc.) an application
declaratively (by expressing what it is alike, rather than the
procedure of how to build it step-by-step),
* Supporting the idea of software product lines (SPL) based on
reusable and quickly reconfigurable components and domain-specific
modeling.

Therefore, in real production environments (especially, considering
they are C++ applications), it is not that desirable that XML
descriptions would be directly used without first going through
testing/verification/packaging etc. manipulations. For instance, many
component frameworks (such as EJB, CCM, etc.) require XML descriptors
to be used after being packaged in .ear, war, or .zip files.
Therefore, in PocoCapsule, directly using XML descriptions is believed
to be mostly useful for learning, testing, and product development. In
PocoCapsule, XML descriptions can be pre-parsed, validated, model
transformed, and encoded off-line using the PocoCapsule development
tool pxencode. PocoCapsule runtime engine is able to read these pre-
encode descriptions directly without using any XML parser at all.

Therefore, for testing, validating, developmenting purposes, the size
(footprint) of the XML handling library is a much less significant
issue than its functions. A primitive XML library that does not
support schema validation and XSLT transformation is useless for these
purposes.

For production applicatins, if the XML library's runtime footprint is
an concern, then the best solution is simply eliminate the XML
handling instead of reduce it. By eliminating XML handling completely,
the PocoCapsule engine is able to have a runtime footprint of
~70Kbytes.

Therefore, the Java via JNI based XML description reader of
PocoCapsule is sufficient for its purposes and needs. And other native
C++ alternatives would neither meet the testing, validation, and
development purposes, nor meet the rogorous runtime footprint
requirements. For instance, the suggested Kranf XML parser is too
primitive (does not come with XSLT support) on one side, and too heavy
on the other side (100K, comparing to the 70Kbytes of the PocoCapsule).