[rc5] Security, Java, and Source

Roland Nilsson rynilss at ibm.net
Fri Oct 10 20:39:32 EDT 1997


Addressed to: rc5 at llamas.net
              "David M. Putzolu" <dputzolu at teleport.com>

David, I think I understood the first 14 times.
But then, I'm not a programmer ;-) 

Java is portable, by definition.
It can use platform-specific routines for optimum speed.
It is also safe.
All of the above brings more clients into the effort 
and helps contribute to the effort.

BUT, I confess I get confused when you start shouting in short sentences.
Without the verbs, one tends to get rather LESS verbal.

Still, Mishari has a point too, doesn't he? Show what you can do.
Let's calm down a bit and save bandwidth for us dial-ups.

(Hope MY mailer doesn't add a lot of extra garbage!!!)

> Date: Fri, 10 Oct 1997 07:49:20 -0700 (PDT) 
> From: "David M. Putzolu" <dputzolu at teleport.com> 
> Subject: Re: [rc5] Security, Java, and Source 
>  
> Mishari Muqbil (mishari at thepentagon.com) wrote: 
> >Look, i have absolutely no idea what you guys are all Bitching on about: 
>  
> Try paying attention then. 
---<snip>--------------------
> >JAVA? Java is 50-60 times slower than the average v1 client. 
>  
> Pay attention Mishari:  Java has within it the concept of 
> NATIVE METHODS.  This concept allows a Java program to 
> call methods WHICH ARE WRITTEN IN THE NATIVE MACHINE LANGUAGE 
> OF THE PLATFORM IT IS RUNNING ON.  Sorry about the shouting, 
> but some people seem to not be reading things closely. 
> So: Write the GUI and networking code in Java.  Write a 
> very small NATIVE METHOD in the assembly language for 
> your particular machine of choice.  So, you get all 
> the wonderful hand-tuned performance that people are so 
> orgasmic about, yet you significantly increase the overall 
> portability of your client.  You also greatly improve the 
> safety of the client, in that it is easy to verify the 
> safety of a small native method, but quite difficult to 
> verify it for an entire client, and the Java code is 
> safe by definition. 
>  
> Do you have an idea (clue) what we are bitching about now Mishari? 
>  
>  
> Ivo Janssen (ivo at ricardis.tudelft.nl) wrote: 
> > David Putzolu wrote: 
> > > * 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) 
>  
> Are you being disingenous?  Did you miss the word "GUI" in 
> my point above?  I'll reiterate using short sentences to 
> ensure comprehension: 
>  
> Core in assembler. Use native methods to do this. Good performance. 
> Networking in Java. GRAPHICAL USER INTERFACE (GUI) in Java. 
> GUI code in C not portable. GUI code in Java portable. 
> Repeat: GUI C code not portable. GUI Java code portable. 
> Portable good! Not portable bad!  C GUI bad! Java GUI good! 
>  
> Also: 
> C not safe. Java safe. Easy to verify security of 
> small core module. Hard to verify security of large 
> C networking/GUI module.  So do Java GUI/networking. 
> Java safe. Make very small core key test module. Small core 
> module easy to verify for security.  I can verify core 
> module and sign with PGP.  So can lots of people. Don't 
> have time to verify entire C source. Can't anyway, Bovine 
> team knows best and won't release. 
>  
> Is this clear enough?  

---<snip>  --------------

> Date: Fri, 10 Oct 97 10:04:12 -0600 
> From: "Eric Gindrup"<gindrup at okway.okstate.edu> 
> Subject: Re[2]: [rc5] Security, Java, and Source  
>  
---<snip>  --------------
>      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



  
  
-----------------------------------------------------------
Roland Y Nilsson                WARPING on
JARFALLA            ... with PostRoad Mailer 2.6!
SWEDEN                         from InnoVal
----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list