At 21:50 4/29/96, Timothy C. May wrote:
By the way, I had a discussion at a party with several Sun folks and other Java programmers, and they agreed that external code (C, for example) could be called, even by an _applet_, if arranged. For example, various underlying graphics routines in the AWT (Alternative Window Toolkit) package are of course using underlying code written in various other languages, code that has been reasonably optimized for speed.
I understand that calling C libs from Java is possible, but the details how to go about that are still hazy to me. It is also unclear if Sun will support this dual coding as a general capability that can be used by all Java apps (don't think of Java just as downloadable applets) or require that all modules, to give an example, for a certain soon to be very relevant Java application to be written in 100% Java. [...]
The interesting thing here is that a crypto package, perhaps with speed-optimized underlying routines in C or even hand-coded machine language, could be released. It might be that patent holders (not that I am endorsing this) could license such packages to users.
Thus,
import java.bignum.* import.java.entropy.* import java.rsa.* import java.digicash.* ...
(Such packages may need approval by Sun, etc., and formal integration, a la AWT. But certainly there is talk of replacing AWT with something else, so changes and additions are clearly possible.)
Presumably, such packages would have to be signed by Sun. Needless to say, these certificates would cost money. A potentially lucrative source of revenue for Sun. Nothing wrong with that. Disclaimer: My opinions are my own, not those of my employer. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.