Java's One-way Reusability Problem -- it's too hard to use existi ng native code

[Haeh,George-2]

A discussion of MS J++ and execution speed led me to the following thoughts:

* What appeals to me most in Java is portability for the GUI.

* Scripting applications that are not compute-intensive comes a close
second.

* Native code has its advantages when it comes to the heavy lifting.

What hurts right now with Java is the lack of a simple means to build
interfaces to current APIs which often are available for a variety of
different platforms.

The difficulty of plugging Java into available APIs is the major obstacle to
taking advantage of the native software that is already out there.  We are
forced to wait either for Java interfaces to be added to these products or
for the whole thing to be totally redone in Java with a strong likelihood of
initial performance problems.

Even if Java performance becomes reasonable for compute-intensive
applications, the cost of enabling Java in existing applications and APIs is
a major obstacle.  While Java promises  reusability, the reality that it is
awkward to use existing APIs with Java stands in contradiction to that
promise.

Can the Java initiative afford to wait much longer?  

[hidden email]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[mcbrides]

>A discussion of MS J++ and execution speed led me to the following thoughts:
>
>*      What appeals to me most in Java is portability for the GUI.
>
>*      Scripting applications that are not compute-intensive comes a close
>second.
>
>*      Native code has its advantages when it comes to the heavy lifting.
>
>What hurts right now with Java is the lack of a simple means to build
>interfaces to current APIs which often are available for a variety of
>different platforms.
>

There is a choice. You write it in Java and be platform independent or you
write it in Java using JNI and loose the independence. Personally, if you have
difficulties accessing the desired non-java API, move your project to one that
is more specific to your needs.

>The difficulty of plugging Java into available APIs is the major obstacle to
>taking advantage of the native software that is already out there.  We are
>forced to wait either for Java interfaces to be added to these products or
>for the whole thing to be totally redone in Java with a strong likelihood of
>initial performance problems.
>

Performance is less and less of a problem. With the latest relase of the JDK
upgrade from IBM, Java on OS/2 is a killer. More than likely, the other platforms
will catch up. Aside from the mentioned API question, I'd worry less about
speed and more about staying 100%...

>Even if Java performance becomes reasonable for compute-intensive
>applications, the cost of enabling Java in existing applications and APIs is
>a major obstacle.  While Java promises  reusability, the reality that it is
>awkward to use existing APIs with Java stands in contradiction to that
>promise.
>

Look at it this way. If you implement a desired interface in 100% Java and do it
first, the world will beat a path to your door.

>Can the Java initiative afford to wait much longer?
>

Wait... and be that much more behind...

--

/-------------------------------------\
| Jerry McBride                       |
|                                     |
|                ([hidden email]  |
\-------------------------------------/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>