On Fri, 27 Jun 2003, Stefano Mazzocchi wrote: > Nono, you didn't get my point: I think it's possible to get *existing* > java classes and re-compile them into CLI.
Why would you do that ? AFAIK the CLI is more complex ( i.e. more bugs, harder to port, harder to optimize ) than the JVM. And the security model in java has been tested much more. At least for me one of the reasons to use java was the sandbox and the guarantees of the security model - which are one of the reason the integration with other languages and JNI is so difficult. If you don't care about the security - then it's easier and faster to just compile to native using GCJ. > Why bothering? > > 1) we have no access to the JVM code, we can't make it faster, even if > we wanted and knew how (java would be *so* much faster if we could > reimplement part of the standard library natively! expecially Strings!) The GCJ library is available, nothing stops you to make it faster. It shares the optimizer with the C++ compiler - so your work will have double value :-) And the class library is shared by almost all free VMs ( the classpath project ). > 2) the JVM bytecode was created for settop boxes. one register and one > stack. most of the operations are performed in getting data in and out > of that single register. Maybe it was cool 10 years ago when targetting > *7, but today it's pure bullshit. CLI is designed as a modern CPU and > it's much easier to compile into native code. That's featurism talking :-) Or we are going to go into RISC vs CISC religious debate. If you believe the RISC argument - the JVM is easier to optimize, more stable and may have fewer security problems ( the last one is more important for me at least ). Usually more features and bloat in the instruction set results doesn't help. I know today CISC are as powerfull or more - but that doesn't mean that "simpler" is completely outdated. > If I had time and energy, I would submit a JSR to modernize the > bytecode. But then politics would get in, corporations would slow things > down, marketing would impose visions and all that shit. "Modernizing" ( bloating ) the bytecode - as well as the core APIs - would be very bad IMO. So for one the politics would do the right thing :-) > I don't have it, so I think I'll just route around the big obstacle to > the evolution of java which is called JCP. > > And they go around saying that JCP means innovation. > > I guess that in a world of perennial stagnation, anything that changes > is named "innovation". Funny - I dislike JCP for oposite reasons, I think it's hurting java by adding lots of bloat and by trying to "innovate". I don't think "inovating" and "standardization" fit very well togheter... And I dislike the fact that JCP leads to a world of continuous change and bloating - instead of stability and depth ( what you call "stagnation" :-). Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
