[rc5] Security, Java, and Source

Eric Gindrup 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 mailing list