on 6/27/03 6:43 AM Danny Angus wrote:
Stephano wrote:
And in order to do this, we must commit a few sins, one of which could
be compiling our existing code for .NET CLI
Funny you should mention that... because I'm porting the Mailet API to .NET.
The problem isn't with the API, but with the dependance on javax.mail in particular MimeMessage et al. For which an OS (or at least free) .NET version doesn't exist.
Nono, you didn't get my point: I think it's possible to get *existing* java classes and re-compile them into CLI.
If I understood it correctly, running java.* or javax.* under a non Sun VM is a license violation.
I discovered it while I was trying to run swing applications under kaffe. I had to use javax.swing.* classes and it worked (partly, some native patches were required in kaffe). I was evaluating the possibility of a VNC-based AWT for the classic headless-java problem under Linux.
We could use classpath (or however they call it now) for this.
Since java and C# are converging into two different syntaxes of the exact same functionality, and we have millions of lines of java code, I think that working at the bytecode level will give us a much better (and easier) portability choice.
And, if that could do it for CLI or Parrot at the same time, it would be even better, more choice equals more freedom.
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 hotspot is supposed to do this, isn't it? (I would treat some standard classes as *very* special if I was in the hotspot team).
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.
3) parrot has native continuations. I expect Java to have continuations in 1.6 or sooner if .NET adds them. But the VM functionalities are converging.
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.
It can be done (I'm not saying "I'd" or "You could" just in case someone thinks I'm volunteering ;-) ) by "embrace and extend", aka "Just do it!". I mean, completely outside of the JCP, as a "de facto" standard. If they are slow, we can invite them to join us in the future. This would only work if it effectively outpaced java evolution while being a solid alternative.
It could not be named java (jamaica is a nice island too ;-) ), also licensing could bring problems, see above. But it could be a way to expose that the "Emperor new clothes" are really thin to the public.
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".
Bah, there is nobody blinder that those who don't want to see.
-- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
