Nicolas Williams wrote: > But that model fits other things that need it for the same reasons as > Java. Or is there something really special to Java and, possibly, Perl > that there isn't to Python, Ruby, Apache, PHP, etc...? The common > thread isn't that they are languages -- they aren't all -- nor that they > are OSS -- they weren't all always -- but that for better or for worse > they are or we can expect they to ultimately be versioned, and that > minor backwards incompatibilities between versions will necessitate > temporary, or even permanent bloat, abhorrent though that might be. > The special thing about Java is that we'd encouraged, yes ENCOURAGED, ISVs to bundle a private version of Java with their applications. The support for multiple versions WHICH WE COULD PATCH was the special reason. By the time we got this done, the ISVs were willing to It has nothing to depend upon any update in a Minor release series, but they hadn't gained enough confidence to just trust the newest version like they are willing to do with libc. It had nothing to do with it being a language (BTW: You could be shot in Sun for calling Java a language. It is an enviroment. C# and mono are languages. Seriously, be careful about that. Its the major distinguishing feature.)
The need to patch became very apparent when indeed a bug in Java showed up where it depended on the pagesize. This caused us to leave a significant performance enhancement (larger page sizes) on the table. Sigh. Lots of dirty laundry here for an open discussion. Keep that in mind next time we get accused of being secretive. Oh heck, its a good story... The Java folk were doing their best to be an ABI compliant application. They thought they were one. They passed all the tests they could find, but those tests pretty much concentrated on functional interfaces. Well, it turns out the ABI allows any power-of-two pagesize between 512 bytes (VAX forever!) and 64k bytes. Unfortunately, the Java Virtual Machine defined an internal stack of 128k bytes and marked the top and bottom pages as unwritable as red zones. Lets see, 128k minus a 64k page at the top and a 64k page at the bottom. Not much left. >> Maybe an easier task (rather than a general best practice) would be to >> articulate why this is like Perl. I still haven't found time to review the >> Perl decision, but I suspect you may find the reason we did this for >> Perl was also an exception (one time event) and doesn't apply here. >> Then again, I'm old enough to have lost many, many neurons, so >> maybe not. >> > > Without looking I find it _hard_ to believe that there is anything > particularly special in the case of Perl that does not apply to AMP. I > would not count Sun-internal dependencies on multiple versions of Perl > as "something special" -- that would seem unfair to customers who > develop similar dependencies over time. > I seem to remember that the special thing about Perl was that we misclassifed an interface too highly. This has been corrected. Hence Perl was a special case to allow fallback because we misled about the stability of (I think) the plug-in interface. I'm hazy about this which is why I haven't said too much until I get a chance to re-examine the Perl case. I think everyone else should also stop talking about the Perl precedent until they re-examine the case to see why this was allowed. Proof by lack of imagination: "I can't imagine why it would be different". Often a dangerous thing. (Credit for the expression: Joe Ekholt.) - jek3 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070327/269f7946/attachment.html>
