[rc5] Security, Java, and Source
gindrup at okway.okstate.edu
Fri Oct 10 11:04:12 EDT 1997
Although the networking code has been implemented once in C, there are
several problems with your points.
First, select() is not universal across all platforms/compilers. It's
not Standard C. It's a POSIX invention. Socket and thread libs tend
to have the same platform specific problems. So, one has to port to
all of the idiosyncracies on each target compiler/platform. Java
would make all of this code *exactly* the same on every platform.
Second, GUI code is even more platform specific than the first
collection of items. Although there are two GUI programming targets
in Java now, that number is much smaller than the number of platforms
with non-compatible GUI interfaces. Finally, there have been several
complaints about the reliability of the connection process used by the
clients. Java networking appears considerably more robust.
The comment isn't that it hasn't been done, it's that porting that
stuff to each new platform is time-intensive. This time would be
better spent addressing the requested client improvements, not on
fixing another micro-difference between this and that thread library.
-- Eric Gindrup ! gindrup at okway.okstate.edu
______________________________ Reply Separator _________________________________
Subject: Re: [rc5] Security, Java, and Source
Author: <rc5 at llamas.net > at SMTP
Date: 1997/10/09 20:04
On Thu, 9 Oct 1997, David M. Putzolu wrote:
> I'll reiterate my original Java points, because there most
> definitely appears to be a misunderstanding of them given
> what you write:
> * A certain number of people, X, will run native code. These
> people are participating.
> * A certain number of people, Z, will not run native code due
> to security risks. Some of these people might be willing to
> run Java code.
> * As long as Z is non-zero and a Java implementation is able
> to crack any keys at all, then X + Z > X. So, there is *some*
> benefit to having a Java client.
> * Beyond this, a Java client would provide a good, clean codebase
> (given a good programmer, which the Bovine team has several of)
> for reference when building native clients. Java is a very
> readable language - much more than straight C.
> * By using Java's native methods capability, it would be possible
> to get ALL the performance benefits of "native, targeted,
> hand-tuned assembly code." Furthermore, it would NOT be necessary
> to re-write all the supporting infrastructure code (network,
> GUI, etc.) for every platform.
So you're saying: core in assembler, networking in java.
But: the networking part is already here in C.
And this _should_ compile on almost every platform. Every platform
has it's C-compiler, including sockets, select, accept, etc.
(even dos has DJGPP/libsocket)
> So, why not use Java?
It has been done? (in C).
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5