On Tue, 2005-06-07 at 08:15 -0400, Geir Magnusson Jr. wrote: > On Jun 6, 2005, at 2:29 PM, Sven de Marothy wrote: > > Sun has not documented how their VM works with rt.jar. Therefore it is > > not possible to develop a Sun class library-compatible VM in a > > clean-room fashion. > > Not *now*, but Harmony has the potential to be a long-running, far- > reaching project, and our interest from the beginning is to have Sun > involved. So it's not unthinkable to assume that Sun might be > interested in participating at some point in the future.
I don't quite see what the one has to do with the other here. > > 1) GNU Classpath's VM interface doesn't include things necessary for > > J2SE 5. > > > > (My take on it: There is no VM which needs them yet.) > > But you absolutely know we will. Right. But because no VM needs them yet, nobody around (who's made themself known) has worked out *exactly* what demands that puts on the VM interface. And without that detail Harmony can't devise a Java 5 VM interface any more than GNU Classpath can. > > 2) GNU Classpath's VM interface uses language protection such as > > package-privacy to hide the VM classes. > > > > (My take on it: Why is that a problem?) > > You are misrepresenting the problem. it's not that it's language > protection, but that you extend java.lang namespace and are hoping > that you don't get tromped by the spec at some point in the future. > (Nor is it clear that it's good citizenship working in that namespace > as well...) I still don't see the problem. You may always get tromped by the spec in the future. And as for namespace issues; We're not extending the public namespace. I don't see the issue. And it's not just about the VM interface. In fact, I don't see how its possible to do a good implementation of the class library *at all* without adding package-private methods, or classes. (And while I can't be certain offhand like this, I think there are parts which are simply *impossible* to implement without adding package-private parts.) > But just as GNU Classpath thought it wise to keep the door open for > multiple VM implementations, we are trying to do the same for mutiple > class library implementations. This is a job for the JCP. If you want a standard interface, get the JCP to create a spec for one. But if you develop your own interface and only GNU Classpath uses it, it's not keeping the door open. (And worse, if GNU Classpath doesn't use it, all you've got is yet another inofficial interface. And that'll be even worse for interoperability.) /Sven
