Re: KPathSea bindings for Java

Hi Karl,

On Mon, 2024-07-08 at 16:40 -0600, Karl Berry wrote:
> Maybe "jpathsea" would be a more fun name :)?
> (Not that I have anything against jkpathsea which is, admittedly, more
> logical.)
Well, I've just consulted the manual, but it's still a mystery to me what the
'k' stands for in kpathsea. Is it like kernel-based as in Kernel-based Virtual
Machine (KVM)?


> Maybe it would of interest in the "Island of TeX" project, since their
> main program arara is written in Java. It seems like it would fit in:
> https://islandoftex.gitlab.io/
I think so too. Maybe there are some other steps required to have it suitable
for development environments, like packaging with Maven.

> There are other Java packages in TeX Live, like the aforementioned
> arara, bib2gls as you mentioned, texosquery, tlcockpit, etc., so I see
> nothing against it, in principle.
I've scanned those and it seems some would benefit from it.
Like texosquery uses kpsewhich on the shell, which could be replaced with a
future release (still have to implement in_name_ok et cetera).

tlcockpit, however, seems to use mostly other utilities, like mktexlsr or
fmtutil. It only uses kpathsea once with var_value in TlmgrProcess.

arara I'm unsure of though.

> There are no other Java libraries distributed as part of TL, and I don't
> want to create a whole new subtree. But I guess your jar file could be
> put into texmf-dist/scripts, like all the others, and found ... somehow.
> Not sure of the most convenient way to set that up, but we could figure
> it out if the project comes to fruition. --happy java hacking, karl.
It also would ship a .so or .dll file which has to be configured for Java with:
  -Djava.library.path=/path/to/libs

So, if both jars and libs can be found, then the only requirement for users is
to have their JAVA_HOME setup properly, since that isn't shipped by TeX Live as
far as I can remember. That would make it somewhat Java-friendly I suppose.

Regards, Erik