Dalibor Topic wrote: > 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.
Agreed. > I believe you're talking about that interface which is specific to > Apache Harmony class of VMs and the Apache Harmony class library > implementation. Well I was switching between a discussion of the VM<->Hy Class lib interface and a discussion of generic classlib interfacing with OSGi, within the same note, just to confuse you ;-) > 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. 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. > 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. 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. > 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. Agreed, and some VMs will be prepared to work on both 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. > 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. > 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. Yes, let's start there since attempts to start bottom-up have floundered. <snip> >>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. 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). > 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. :) I hope that this is another mis-communication area, so I'll take it as a challenge to persuade you otherwise ;-) > 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). Yes, this could open the can of worms again, which is why agreeing on the classlib components (as you described above) is something we should do in parallel at least. > 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. > Then let's show what can be done. >>>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. :) I'll be at ApacheCon next week and will be happy to discuss with anyone there; plans around FOSDEM are uncertain. > 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 ... :) A guess a T-shirt won't do then :-) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
