Date: 28 Mar 2002 07:42:22 -0800 From: Anthony Green <green@redhat.com> To: Bill Huey <billh@gnuppy.monkey.org> Cc: Brian Behlendorf <brian@hyperreal.org>, freebsd-java@FreeBSD.ORG Subject: Re: [press@apache.org: PRESS RELEASE: ASF Reaches Agreement with Sun to Allow Open Source Java Implementations] Message-ID: <1017330145.2206.84.camel@dhcppc2> In-Reply-To: <20020328064218.GA2973@gnuppy.monkey.org> References: <20020328002610.GA2023@gnuppy.monkey.org> <20020327221634.M1335-100000@yez.hyperreal.org> <20020328064218.GA2973@gnuppy.monkey.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2002-03-27 at 22:42, Bill Huey wrote: > IMO, from looking at all the HotSpot/JVM internals over this year and a > half time frame, that's impossible for an open source group to commit > the necessary resources to create a useable J2SE clone. You need too > many domain experts with too long term a focus to complete each > subsystem. I think the libraries are the real problem. Not only is the immense size of the libraries a problem (they grow with each release), but they aren't documented well enough to clone 100% reliably. That being said, and at the risk of beating a dead horse, I think the gcj project has been very successful. You can certainly build and run many useful applications with it today (or... at least with the coming 3.1 release, which will be real breakthrough release), and it works well on longish list of target systems. Leveraging off of the good work of the GCC project was smart, as was getting the FSF to cooperate on runtime libraries (they changed the GNU Classpath license to a more liberal GPL + an exception allowing static linking of the library with no further obligation from the user). The performance of the resulting binaries is good. It's competitive with state-of-the-art JIT systems. Meaning... sometimes faster, sometimes slower. When it's faster, it can be much faster. For instance, certain crypto operations used in SSL can run 10x faster than state-of-the-art commercial JITs. And start up times are always much faster. I've installed the Rhino javascript interpreter as /usr/bin/js. It really starts up incredibly quickly, making it a practical alternative unix scripting language (and 100% open source). And, finally, we get some relief on memory usage as well because we build _shared_ libraries out of the enormous java core libraries as opposed to each process JITting it's own copy of the code. I guess that's enough evangelism for one day :-) AG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1017330145.2206.84.camel>