[armedbear-devel] Several ABCL/Java questions

[Alessio Stalla]

On Tue, Jan 4, 2011 at 10:28 AM, Didier Verna <didier at lrde.epita.fr> wrote:
>
>  Hello,
>
> I'm trying to port Clon[1] to ABCL, or at least figure out whether it
> makes sense at all. My Java programming experience boils down to a Hello
> World program 10 years ago or so, so some questions belong to the Java
> side of ABCL for sure :-). I would be grateful if somebody can help me
> answer these.
>
> 1/ Is it possible to create standalone ABCL executables and how ?

I'd say no, but it really depends on what you mean. You can't create
standalone executables in Java, the equivalent is a bunch of Jar files
(for console or GUI applications). It is possible to package ABCL +
your software as a bunch of Jar files, but ABCL doesn't provide
facilities of its own for that, though it's not hard to do (you can
look at ABCL's own build script to get an idea). ABCL has no
facilities for dumping a memory image, either (memory being controlled
by the JVM makes this hard).

> 2/ ABCL doesn't seem to provide a [set|put]env function. From what I can
>   gather from the internet, that would be because there's no such thing
>   in Java. I've seen some nasty tricks around consisting in modifying
>   the (application-local) initial memory mapping of the environment,
>   but that's all. Is this correct ?

I'd say yes, it's correct. But what are you trying to achieve? If you
want to provide an environment for a subprocess, the ProcessBuilder
class supports it. If you want to modify your own environment, you
can't (without resorting to FFI, as far as I know), but why do you
want to do that?

> 3/ It seems that ABCL does not have a complete MOP. In particular, I
>   couldn't find a validate-superclass function. Is this correct ? Does
>   this mean that classes/superclasses are implicitely "validated" ?

It doesn't have a complete MOP. I think that validation is performed
on an ad-hoc basis (e.g. you can't extend structure classes), so every
other case is implicitly validated.

> 4/ There is a place where I need to access low-level information about a
>   stream in order to figure out whether it's connected to a tty, and in
>   that case, what's the tty line-width. In other implementations, I
>   have native support (or cffi support in the case of CLISP) for
>   calling ioctl with the TIOCGWINSZ argument. It either gets me the tty
>   line width or throws me an ENOTTY error in the face which is fine.
>
>   How can I do something similar in ABCL ?

I don't know. ABCL streams wrap java.io streams and readers/writers
and I don't think there's a mean of accessing their low-level
implementation. Perhaps with a dedicated library that uses JNI/JNA and
provides custom streams, but I don't know any. Terminal handling is
not common in Java (as most OS-specific stuff).

hth,
Alessio