RE: [Cxtable-devel] RE: Can you help me guage how long this'd tak e?

[Williams, D. <DAV...@ca...>]

I don't think they'd listen to me..


David Scott Williams
Computer Associates

--->Marketing Representative-Sales Call Center<---
One Computer Associates Plaza 
Islandia, New York  11749
tel: +1 800-243-9462 ext. 73431
tel: +1 631-342-3431 (Direct)
fax: +1 631-342-5734
wi...@ca...






-----Original Message-----
From: Borne Goodman-Mace [mailto:bm...@eg...]
Sent: Thursday, January 03, 2002 4:28 PM
To: Williams, David
Subject: RE: [Cxtable-devel] RE: Can you help me guage how long this'd
tak e?


Other than having to download the JRE, because of it's interpreted
nature, I believe you would find a Java program (it's .class files), are
generally much smaller than C code which does the same thing.  It also
(usually) takes a lot less Java code (and time) to write the same thing
as you would in C.

I will attempt to address them as well as I can.

Network IO, in Java, can be similar in performance, though I don't know
the exact percentage difference.  One of the huge wastes in Java
networking IO, previous to version 1.4, was that you had to spawn a
thread (or jump through other horrible hoops), to efficiently handle
client IO.  The 1.4 NIO libraries do a great deal to bring Java up to C
/ C++ speeds in this regards.  It is also VERY painful to port complex
network code between Windoze and Unix, as the Grapevine folks will find
out, if they don't know already.

I haven't seen a good (and fast) implementation of crypto in Java that
didn't use JNI for the hard core stuff.  I think this is more a lacking
in the implementations than in Java's abilities, but the big problem
caused by the bad implementation is the use of a TON of CPU cycles. 
When running a 2ghz processor (and faster in the future), even a bad
crypto implementation with 4096 keys will run pretty well in Java.

Because of this issue, when dealing with web traffic, or SSL streams in
general, if performance is important, it is best to tunnel this through
some kind of native SSL stream (ssh, https, etc).

If you want to work for your company, and that is all they write in,
then true, the bullet must be bitten, unless you can convince them to
work on a conversion of some components to Java.  I know it sounds far
fetched, but in my early years, I convinced 2 separate companies that I
worked for to start developing in Java, before it was "hot", and they
never went back.

--bjgm

On Thu, 2002-01-03 at 15:14, Williams, David wrote:
> Well..one of the reasons (and I wasn't entirely certain that this was correct, at the time) that Grapevine is working in C++, is a smaller, quicker, executable....
> 
> I, of course, wondered how much sense this made...
> 
> I do have some questions/issues with Java that perhaps you can address for me?
> 
> Sockets and Secure Sockets... and all that..  They run at 90% of a well-written C socks program?
> 
> More importantly, would there be any advantage as far as tunneling through FWs and Proxies in C versus Java?  Or are these distinctions that I've drawn up in my head?
> 
> Also..my company writes in C/C++...  They, of course, create closed-source, high-priced 'eBusiness' software...
> 
> I might want to work for them programming, but at this point, since I don't write C and Assembler, I haven't a chance..