Hello Group/Tim,

>________________________________________________________________________
>
>Message: 2
> Date: 21 Jan 2002 11:26:09 +0000
> From: Tim Foster <tim.foster@...>
>Subject: Re: Localization Directives - Working Example
>
>Hi All,
>
>On Sun, 2002-01-20 at 05:24, John Wm. Wicks wrote:
>
>>Yes but Java has it's own limitations, performance is still it's weakest
>>link. I've used a Java based IDE called Eclipse and it's unacceptably
>>slow on my Pentium 450. Since the primary role of this interface is
>>filtering and parsing I'd hate to see it bogged down by the overhead of
>>a completely Java implementation.
>>
>
>Swing is still the slowest part of java I believe, so comparing a
>heavyweight gui app to a file parsing library isn't fair. Along with
>that, j2se 1.4 brings noticable performance improvements.
>
Heavyweight ?? It's the minimal functional IDE.

>
>See also :
>http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf.html
>(this is quite old - things have improved since then)
>
>We're using java for our internal parsing needs, and it's very fast
>indeed. (our localisation filters are implemented using javacc) and
>there's all the gains of using java and a decent compiler compiler : see
>attached BNF generated for us by javacc.
>
But it's always going to be slower than a C++ solution correct or no.
I'm not all that familiar with the javacc or Java for that matter, is
this a native compilation ?? Do you still need JVM ?? If it is native
compilation, i.e. a standalone Win32 executable then what's the
difference between this an a C++ solution. So say Okapi is implemented
as a pure Java solution if I write a native Win32 application in C++ how
do I use the Java filters ?? JNI, RMI, Java IDL. On a Windows platform
we'd use the COM based interface by passing Java altogether since it's
not needed. If say another individual develops a Java UI client they'd
use the Java Okapi API interface, COM would probably drop out of the
picture for a shared library solution.

>
>I would maintain that using components across architectures is easier
>without the overhead of JNI (it is a bit of a pain to program) - and to
>simply implement in plain java. This way, the creator of the component
>doesn't have to worry about which architecture they need to target their
>code to - it just works.
>
Maybe I'm alittle rusty and things may have changed somewhat but you
still have to debug on all platforms correct. My experience with Java in
the past involved writing/rewriting classes because the functionality
across JVM's wasn't consistent. No I wasn't using any MS specific
extensions.

>
>What happens if I want to run the code on an SGI system ? Or MacOS X, or
>(etc. etc.) will the c++ source code for the filters always be available
>and guaranteed to port from system to system ? How many translators have
>compilers installed ? :-)
>
Well C++ can be compiled on all these platforms very nicely. I believe
the porting will be part of the Okapi tasks and the source is freely
available via SourceForge so unless they die out it should be there for
some time. Yves would know more about the "future" of Okapi than I though.

>
>Of couse, you may still want to use COM, in which case, a single JNI
>wrapper for the java classes would be the right approach, but in
>general, JNI accesses should be as few as possible.
>
And mind you I'm not saying that COM itself hasn't been ported to other
platforms, Sun, I think, purchased Chilisoft's ASP implementation of it
and its available for the Linux platform, Groove uses COM and it
supports Linux/Mac/Windows. COM just happens to be how Okapi exposes the
API interface to C++/Windows developers currently, it could just as
easily been exposed as a CORBA interface. You see what we're getting at,
Okapi could expose the API in pure C if need be. If you use a pure Java
implementation somewhere along the line every application that uses the
API has to have Java installed whether they needed Java for the rest of
the application or not.

>
>You may have gathered, this is a somewhat pro-Java stance, but I make no
>apologies for where my loyalties lie - I truely believe this is the way
>things should be.
>
Believe me I really wanted to use the Eclipse platform for an
application suite I'm developing so I don't mind the pro-Java stance I
'm just being realistic about all aspects and from my experience the
"write once, run everywhere" mantra just didn't work out that way. As I
said things may have changed somewhat but I make no apologies for my
past experience(s).

This is an interesting thread, I look forward to your replies...

John