JNI vs. Runtime.exec()

I would consider using Runtime.exec if you can. This method
of 
interacting with other applications is nice because failures
from that 
application doesn't effect the JVM and both will run in
parallel. You 
don't have to manage any extra threads or handle any
fork/exec code at 
all as you might in JNI to achieve the same level of
separation. 
However, if the MTX has a library that provides more control
and 
additional features that you need, you'll have to code to
that via JNI.

Sounds like they already have a CLI interface that produces
somewhat 
parsable text, so I'd just stick with Runtime.exec for now.

-bp


leperjuice wrote:
>
> I've been digging around and I can't come up with a
confident answer, 
> and I was hoping could get some advice. I'm using mtx 
> <http://mtx.badtux.net/>
 to control a SCSI-attached CD-ROM library. 
> It's a simple (relatively) command line unix program.
>
> Task: Develop a Java method to encapsulate the
operations of mtx as 
> part of a MVC app that will represent and control the
library. This is 
> part of a larger project, but I think it will take a
while to complete 
> this portion, so I'm only concentrating on this
component.
>
> My question is:
>    Should I just go the simple route of parsing the
command line 
> output from mtx by using Runtime.exec() with the
appropriate commands?
>              or
>   Should I did deeper into the wonderful world of JNI
to achieve my 
> results?
>
>  



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://gr
oups.yahoo.com/group/chicago-java/

<*> To unsubscribe from this group, send an email to:
    chicago-java-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.c
om/info/terms/
 

Thank you for the advice! Now I just have to figure out how
to set up an
efficient parser that can handle the output from MTX.

I appreciate the help, as I'm working on a project that has
languished for
nearly 5 years, and now I have a better idea how to proceed.

--
"Live with cause and leave results to the great law of
the universe. Pass
each day in peaceful contemplation." -Zengetsu


On 8/16/06 9:35 AM, "Brian Pontarelli"
<brianpontarelli.com> wrote:

> I would consider using Runtime.exec if you can. This
method of
> interacting with other applications is nice because
failures from that
> application doesn't effect the JVM and both will run
in parallel. You
> don't have to manage any extra threads or handle any
fork/exec code at
> all as you might in JNI to achieve the same level of
separation.
> However, if the MTX has a library that provides more
control and
> additional features that you need, you'll have to code
to that via JNI.
> 
> Sounds like they already have a CLI interface that
produces somewhat
> parsable text, so I'd just stick with Runtime.exec for
now.
> 
> -bp
> 
> 
> leperjuice wrote:
>> 
>> I've been digging around and I can't come up with
a confident answer,
>> and I was hoping could get some advice. I'm using
mtx
>> <http://mtx.badtux.net/>
 to control a SCSI-attached CD-ROM library.
>> It's a simple (relatively) command line unix
program.
>> 
>> Task: Develop a Java method to encapsulate the
operations of mtx as
>> part of a MVC app that will represent and control
the library. This is
>> part of a larger project, but I think it will take
a while to complete
>> this portion, so I'm only concentrating on this
component.
>> 
>> My question is:
>>    Should I just go the simple route of parsing the
command line
>> output from mtx by using Runtime.exec() with the
appropriate commands?
>>              or
>>   Should I did deeper into the wonderful world of
JNI to achieve my
>> results?
>> 
>>  
> 







 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://gr
oups.yahoo.com/group/chicago-java/

<*> To unsubscribe from this group, send an email to:
    chicago-java-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.c
om/info/terms/