Tim Ellison wrote: > Dalibor Topic wrote: > Agreed -- and if we agree on using OSGi bundles as the technology for > generic class library interop then I think we simply need to agree on > the small number of non-JSE API dependencies between the bundles to > allow for component interop.
+lots:) > I'm inclined to start with the higher level components and work down > towards those that require knowledge of bootsequence etc. I believe we > can get early agreement on the interface to components that have no VM > dependencies (i.e. those that will be most likely to be implemented in > pure Java code), and work from there. Even demonstrating this simple > use case will show how we can/will interop. Cool. > Agreed, and some VMs will be prepared to work on both models. Yup. I think Kaffe would provide a bad testbed for that, because of the licensing jam (can't ship the new code easily). Archie's contribution is ASLv2, though, and it has been able to interact with GNU classpath in the past :) so it should work as a better test bed for evaluating and merging both interface models. > I think > this gives people the right choice about where they want to put their > effort. VMs can target one, the other, or both class libraries; class > lib developers can contribute to one, the other, or both; and users can > mix and match the components to get whatever characteristics are on offer. Yeah. > >>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. :) > > > Yes, though I'd still like to have that discussion at some point because > that would be the grand unification. It's also the mechanism we will be > using for VMs developed under the Hy umberella. Sure, same here. We don't have to run the full mile at once at full speed though. The 1.5 certed free runtime goal is huge and painful enough, to naturally lead to unification at some point in time, when the cost of not unifying implementations is higher than maintaining separate ones. That point should be reached in a few years (worst case), and by then I assume all the possible licensing bridges will exist in one form or another, so that stuff would no longer be an obstacle. > Just want to clarify the distinction between the OS portability layer > and the VMI. The OS portability layer is in the Hy project already, so > that is not your 'problem' as a VM-guy. > > Providing an implementation of a few non-portable functions for the VMI > is your problem; and I promise to write down exactly what they are > (since I agree they are not easily deduced from the VMI documentation). Yeah, I know, I was painting it with a much too broad brush by concentrating on the portability layer. I would like to postpone the grand unification discussion until we've got practical experience with different implementations in a single VM, though. I believe then we'll have a better picture how the different interfaces can be merged, and what the respective advantages are. > I hope that this is another mis-communication area, so I'll take it as a > challenge to persuade you otherwise ;-) Let's take it to private mail. That's the best way to quickly correct miscommunication on my side in my experience. :) >>>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. >> > > > Then let's show what can be done. > Good. It would be nice to know what sort of concrete benefits one could expect as a user / developer / runtime developer from a more modular core class library. I have a rather vague picture about concrete pros that would provide for Kaffe, but I assume you've given the pros and cons a lot of thought already, so it'd be nice to see what the use cases you have in mind. cheers, dalibor topic
