Tim Ellison wrote: > Dalibor Topic wrote: > > Just to be clear, the kernel classes are VM-dependent types that are not > typically reusable since the VM typically will 'know' the shape of the > class/instances. I think it is useful to minimize that set. >
Yeah, I think we were talking past each other here. :) The interface in the Wiki is going to be implemented by the Apache Harmony class of VMs, and there specifying the need for JNI, etc. is OK. I believe you're talking about that interface which is specific to Apache Harmony class of VMs and the Apache Harmony class library implementation. Let's assume that the other VMs out there also have their own ways of binding to a class library, and vice versa, portability helper functions, and so on. The other runtimes out there may want to reuse Apache's code, but chances are they have their own stuff for running OSGi code already with the class libs they use, be they proprietary or open, so let's just make it as simple as possible to leverage what they have. For the OSGi partitioning work, all people we to agree on is a and b from the previous mail. So when I was talking about the VM interface, I mean a core set of bootstrap classes. I just meant a minimal set of classes that need to be present to be able to work with a minimal OSGi implementation, and the resulting class library partitioning. How a VM interfaces with its own class library, then no longer matters. Neither does it matter how the VM partitions that bootstrap class set internally: Harmony may prefer to partition the bootstrap set into different subsets that are more efficient given its kernel layout, other VMs may just chose to just lump the classes together. The wonderful part of that story is that noone needs to share any code of any component: how VMs implement the bootstrap set of classes, which OSGi implementation they chose, if they use JNI or avian carrier pidgeons :) fails to matter, and noone needs to listen to arguments about the ideal way to bind a class library to a VM, or what the best OSGi implementation is. :) More interestingly, though, everyone can use whichever component they want internally, and it won't matter if it's proprietary of not, as long as the bootstrap set of classes is there, a minimal osgi implementation is included, and the partitioning is agreed upon. > You may prove me wrong now, but are there any VMs targetting JSE that > don't do JNI? Yes. There are platforms where C is not the lingua franca. GNU Classpath has a few such users, afair. > If we raise the semantic level far enough Classpath and Harmony are > bound to be able to interoperate at some level <g> > That may be desireable, yeah. I can hope. :) > Take a look at the interface and how much is already implemented for > you, and let me know if you think it is not a lazy weekend job. The > Doxygen includes all the code that is in the Hy codebase already -- I > guess it would be helpful to have a step-by-step guide of what a VM > needs to do. Oh, it's not that I don't think I could not write yet another portability layer into Kaffe, it's just a bit superfluous to add a third one, since it already has two of them: one for the core vm, and one from GNU classpath's class libraries. It's not that I don't like portability layers, either, it's just that they create a lot of boring maintainance work as soon as one has several on one's hands, and has a VM that has users on a few dozens of platforms. That in general means facing portability problems where noone else has gone before, and there are nicer things to do than making some portability layer work with gcc2 on m68k-a/ux on a sunny friday afternoon. I don't want to allude that your C code isn't flawless, it's just that I am not interested in maintaining yet another portability layer if I can possibly avoid it. Been there, done that, etc. :) Nevermind that I'd have to write my own implementation of the C code, as I can't ship ASLv2 licensed code inside Kaffe (GPL2). While maintaining portability layers is bad enough, I can't imagine what would drive me to write another one ... [1] :) > I think so -- though I've probably confused things by talking about the > VMI and talking about class lib componentization in a single thread. > > The summary is : > (1) we should aim for complimentary classlib componentization to get > interop of large functional units; That's the interesting part for me. >>p.s. you know that after talking about all this stuff for the next week, >>I'll drag you come for FOSDEM to give us an introduction into how it all >>fits together, and why, and so on. > > > You'll have to translate that paragraph for me -- I can't parse it ;-) > It means, if you come to the Classpath dev room at FOSDEM, we'll have a few beers together, and you can explain me IBM's grand vision for the class libs. :) cheers, dalibor topic [1] Well, if I was offered one million US dollars in small bills for a weekend of work, then we could talk about me overcoming that aversion to writing portability layers in C ... :)
