gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] java port


From: Tom Lord
Subject: Re: [Gnu-arch-users] java port
Date: Tue, 22 Jun 2004 17:05:32 -0700 (PDT)

    > From: Peter Conrad <address@hidden>

    > I've thought about Java integration of arch for a while, and
    > I've come to the conclusion that the best way to do it would be
    > to write Java wrapper classes that execute 'tla' and parse its
    > output.

I'm not sure about that but it might be right.

    > For one thing, using 'tla' is necessary for some operations
    > (e. g. Java has no portable support for modifying unix file
    > permissions).

Another good one is regexps.  I think it is hard to make a good
re-implementation of tla unless you use Rx or perhaps Spencer's latest
Posix matcher.  A native java port would need some foreign function
bindings no matter what.

That wasn't originally the case, of course.  Originally, Rx was happy
just to use the regexp engine (GNU regex, I believe) in GNU find.  But
experience quickly showed (and occaisionally reminds) that (a) the
regexp evaluation part of inventory traversals is quite
performance-critical and (b) often the regexps in question are large
disjunctions:

        A|B|C|D ...

which is exactly the sort of thing that Rx does very well and nearly
all other (dynamic) regexp engines handle poorly.


    > More important, though, is the fact that IMO the internal
    > operations of tla currently change much faster than tla's
    > external interface. Following these changes would probably much
    > more difficult and error-prone than simply relying on tla to do
    > things properly.

The flip side of that is that if there ever is another arch
implementation that stands as a peer with tla (and I hope there will
be), then having to keep the multiple implementations in-sync will
be a check on wild archive format (and similar) changes:  it'll
eventually help to stabilize arch.  (Not that it isn't stable in its
external and exchange formats already .... just that with two
implementations that stability is more formal and more practically
necessary rather than just being a nice thing the tla maintainer
happens to do.)

-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]