Hi All,

I'll keep it short - I promise. I'm not going to get into a
comp.lang.misc my impl. language is bigger/ better/ faster/ smaller/
slower/ more efficient/ more elegant/ easier to type /etc. than yours.
There are other places on the internet for that !


On Mon, 2002-01-21 at 20:29, yves_savourel wrote:
> Although I'm a Windows developer, I can see some advantages in
> developing filters in Java. First, they would offer a better cross-
> platform support, but I think one of the main interests also reside
> in the good i18n functionality Java provides.

Yep. Strings are in unicode by default, - they're read from the native
filesystem under the default encoding (or a programmer supplied one) and
converted for you. There's further nice support in jdk1.4 for other
character conversion (should you need it - see the java.nio.charset
package) There is java locales too, which would also help the cross
platform nature of Okapi.

> This said, I think the callers of filters are often developed for a
> single platform (often Windows), and when it comes to GUI
> applications Java -from my modest experience- seems to be 'a little
> behind'.

I agree (for the moment). John Wicks was claiming that in his
experience, Eclipse was slow - I claimed it wasn't fair comparing a
"heavyweigh gui" to a file parsing library. By that I mean, that IDEs
are quite a test of system resources. (we don't all have our windowing
systems built into our kernels) Just because the gui is slow, it doesn't
mean that the rest of the platform is slow.

Also, fwiw, SGI appear to have a jdk at
http://www.sgi.com/developers/devtools/languages/java2_131.html

Java is not always going to be slower than native code.

Javacc is similar to a combination of lex/yacc - it's a compiler
compiler which produces .java classes (not native code) Using such tools
is usually more efficient (and bug-free) than hand-coding a parser. It
was originally developed in SunLabs, and has since moved to Metamata
(now Webgain) http://www.webgain.com/products/java_cc/ Antlr is also
worth checking out, so I'm told http://www.antlr.org/ - I haven't had
time to play with it


Re. cross platform java - you *can* write truely cross-platform java if
you do it properly. (yes you can write non portable java also). That
said, you can write cross-platform c/c++ too - the only thing
outstanding is that you need to provide the source for the c/c++ in
order to get it to run on a different platform and the user needs to
recompile that source.

> Overall we should have a way to access Java filters from Windows
> applications and it could be done as follow:

<...>

> All this obviously doesn't prevent to write filters in C++ if it is
> your preference: the important part is to have a common interface so
> layers for interoperability can be also constructed and re-used.

This sounds excellent to me. If I could write filters to an interface in
Java, that would be good enough for me. I will maintain that Java is the
right way to go, but that said, by all means continue to use other
languages if they suit particular applications more.

cheers,

tim