Date: Wed, 27 Mar 2002 22:42:18 -0800 From: Bill Huey <billh@gnuppy.monkey.org> To: Brian Behlendorf <brian@hyperreal.org> Cc: freebsd-java@FreeBSD.ORG Subject: Re: [press@apache.org: PRESS RELEASE: ASF Reaches Agreement with Sun to Allow Open Source Java Implementations] Message-ID: <20020328064218.GA2973@gnuppy.monkey.org> In-Reply-To: <20020327221634.M1335-100000@yez.hyperreal.org> References: <20020328002610.GA2023@gnuppy.monkey.org> <20020327221634.M1335-100000@yez.hyperreal.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 27, 2002 at 10:22:19PM -0800, Brian Behlendorf wrote: > It'd be tough to start one from scratch; I'd wager it's about the same > amount of code complexity as the GNU C toolchain today. What's more > likely is someone open sourcing an existing JVM, and putting their > existing dev resources (or enough dev resources) on it. Or throwing > their weight behind Kaffe or something like that, but more likely > releasing a new one. 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. > > Slightly off topic, but the Mono folks have a better chance of getting > > a .NET compatible system useable more so that the JVM folks it seems. > > > > I'm quite interested in CLR and CIL in .NET in that having an universal > > typing system across all languages targetted to it is very cool. > > It would be really interesting to hear whether Mono's CLR and > Java-to-CLR-bytecode compiler was a faster route to a stable and reliable > runtime than the pure-bred JVMs. Certainly it would be a nice way to The problem here is that the JVM uses a more coarse grain runtime typing system that's difficult to translate onto CLR terms. I can't remember the details exactly, but it's got speed optimization specifically for the runtime invocation of Java methods that make it a conceptual mismatch to CLR. RMI is also effected by this as are other things that use JVM first class types facilities directly. The differences in security models are also problem. Java's much more restricted bytecode is easier to verify. I'm not a security expert so I can't comment much more on this topic. I wish I had more time to investigate this since it's such an interesting topic and really believe that .NET/CLR is technically good enough that it might really profoundly effect things over the entire industry. MS has a half crippled way of implementing things, but that doesn't take away from the core technology, specifically type meta-data descriptions CIL, etc... > address Java's biggest shortcoming, IMHO, which is that it just doesn't > play nice with other apps (unless you go over slow interfaces like XML-RPC > or SOAP). Regardless, soon we'll be able to do that experiment legally. > :) Sure, I'd imagine so, but I don't do EJB work, etc... so I can't really comment ;) That's all I can think of to ramble about right now. ;) bill 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?20020328064218.GA2973>