Is 9903520300447984150353281023 Too Small?
2008-05-30
JSR 277's Stanley Ho published a rationale why (in the so far unpublished EDR2) JAva Modules (JAM) invent a brand new version scheme. A rationale that needs a lot of text. I could go in painstaking detail, but I think the rationale derails in one of the first paragraphs where the requirements are (implicitly) described. I highlighted the part that describes in what kind of situations you use the major, minor, micro, update, and qualifier version parts:
Can you spot the difference between minor and micro? I can't, and that is the reason that OSGi proposes the following convention: incompatible (major), backward compatible (minor), no API change/bugfix (micro), and builds or variations (qualifier). That is, our micro is Sun's update because Sun's minor and micro appear to have an identical purpose.
And ever thought about the concept of largely backward compatible? Isn't that something like a little bit pregnant?
There are always reason to improve on existing schemes, but any improvement should be balanced against the interests of the existing and future audiences. I am not stating that the OSGi version is the mother of all version schemes, we are as fallible as all of us. Maybe we were too rationalistic; we looked at a lot of schemes and saw how people were also looking for more room at the low-end of the version scheme and hardly ever incremented the first numbers. If you standardize there is always a tension between allowing as much freedom as possible but also minimizing the complexity of the implementations that are depending on the variations you offer. We chose simplicity.
Is the OSGi scheme usable? Well, we have no outstanding requirements or bugs in this area, nor were any proposed in JSR 291, while at the same time it is heavily used. Jason van Zyl, Maven, told me they were thinking of adopting the scheme as well. SpringSource converted almost 400 open source projects to bundles and they did not complain. Seems there is a lot of practical usage out there.
Wouldn't it be a lot more productive for all of us if Sun would just adopt the OSGi scheme? There is lots of work to do on the module API, why not reuse existing specifications where you can? And if the OSGi scheme has burning issues, why not report that as a bug or change request, after all Sun is a distinguished OSGi member.
With an infinite number of builds or variations, 9903520300447984150353281023 possible bug fixes (80.000 fixes per microsecond until the Sun implodes), 4611686014132420609 backward compatible changes, and 2147483647 incompatible releases, the OSGi spec seems to have enough room to breathe for mere mortals.
Peter Kriens
P.S. You did register for the OSGi Community Event in Berlin, June 10-11? Please do so, we have a very strong program prepared with lots of cool demos. Hope to see you there!
- Major version number should be incremented for making changes that are not backward-compatible. The minor and the micro numbers should then be reset to zero and the update number omitted.
- Minor version number should be incremented for making medium or minor changes where the software remains largely backward-compatible (although minor incompatibilities might be possible); the micro number should then be reset to zero and the update number omitted.
- Micro version number should be incremented for changing implementation details where the software remains largely backward compatible (although minor incompatibilities might be possible); the update number should then be omitted.
- Update version number should be incremented for adding bug fixes or performance improvements in a highly compatible fashion.
- Qualifier should be changed when the build number or milestone is changed.
Can you spot the difference between minor and micro? I can't, and that is the reason that OSGi proposes the following convention: incompatible (major), backward compatible (minor), no API change/bugfix (micro), and builds or variations (qualifier). That is, our micro is Sun's update because Sun's minor and micro appear to have an identical purpose.
And ever thought about the concept of largely backward compatible? Isn't that something like a little bit pregnant?
There are always reason to improve on existing schemes, but any improvement should be balanced against the interests of the existing and future audiences. I am not stating that the OSGi version is the mother of all version schemes, we are as fallible as all of us. Maybe we were too rationalistic; we looked at a lot of schemes and saw how people were also looking for more room at the low-end of the version scheme and hardly ever incremented the first numbers. If you standardize there is always a tension between allowing as much freedom as possible but also minimizing the complexity of the implementations that are depending on the variations you offer. We chose simplicity.
Is the OSGi scheme usable? Well, we have no outstanding requirements or bugs in this area, nor were any proposed in JSR 291, while at the same time it is heavily used. Jason van Zyl, Maven, told me they were thinking of adopting the scheme as well. SpringSource converted almost 400 open source projects to bundles and they did not complain. Seems there is a lot of practical usage out there.
Wouldn't it be a lot more productive for all of us if Sun would just adopt the OSGi scheme? There is lots of work to do on the module API, why not reuse existing specifications where you can? And if the OSGi scheme has burning issues, why not report that as a bug or change request, after all Sun is a distinguished OSGi member.
With an infinite number of builds or variations, 9903520300447984150353281023 possible bug fixes (80.000 fixes per microsecond until the Sun implodes), 4611686014132420609 backward compatible changes, and 2147483647 incompatible releases, the OSGi spec seems to have enough room to breathe for mere mortals.
Peter Kriens
P.S. You did register for the OSGi Community Event in Berlin, June 10-11? Please do so, we have a very strong program prepared with lots of cool demos. Hope to see you there!
Comments
BUGs I Like!
2008-05-27
Last week I blackmailed Ken Gilmer of Buglabs into finally sending me an evaluation set. He had promised me this set for some time and I wanted him to show this kit on the OSGi Community Event on June 10-11 (You did register I hope?). Ken could not come due to other obligations so I promised to make a demo if he would send me an evaluation kit.
So yesterday Fedex delivered a nice red box at my doorstep! It is always nice when a company spends a bit of effort on designing the box; this package reminded me of my first TomTom, a company that also took care in making the unwrapping experience fun.
The content was a BUG with 4 modules. The BUG itself is the core computer that drives (hopefully) cheap modules. The core contains a small LCD, a minimal joystick, a push button and 4 LEDs that can also be pressed. It is powered through a separate (universal) power supply. Unfortunately, the also present small USB connector is not used to power the device; it is only there for the communications with the development computer. A slide-switch acts as on-off button.
There are 4 modules included:
The development environment is based on (surprise!) Eclipse, called DragonFly. They told me to use Eclipse 3.3 (Europa) but I decided to live risky and use my current 3.4 Ganymede copy of Eclipse. At least this way I can only blame myself for some of the things that did not work. DragonFly replaces PDE but there are a number of similarities. Also, the manifest file is the driver for the generation. Overall it was very simple to write a new bundle when you are familiar with Eclipse. DragonFly nicely creates a complete project for you with the classpath setup correctly.
For debugging there is a pretty good emulator that reuses the same Java code and implements the services that abstract the devices. You just ask a project to "Debug As" and the select the Virtual Bug. Very smooth. Once the Virtual BUG is running it appears as a device in the list of Bugs. You can drag and drop your project to these devices and that will install them. This drag and drop interface works very well for device management.
The runtime is of course the most interesting part of this device. It runs the (now) open source PhoneME project. This is a CDC VM that supports most of the core Java SE libraries. On top of this VM, BUGLabs uses a Concierge framework. Concierge took the decision to not move to Release 4 but stick on Release 3 because of size reasons. This makes my feelings toward concierge slightly ambivalent. Release 4 added some very important changes that I hate to miss. I know that size matters, but the difference is not that dramatic with today's memory prices. Ok, I prefer OSGi over no OSGi, but staying behind on release level is very tricky. Lots of bundles now use the Bundle.getBundleContext() method, like Declarative Services, which is not part of R3. Also, the modularity layer got an important boost in R4. However, the biggest problem is compliance. Concierge was not tested for compliance and with the OSGi's current rules we cannot certify it anymore. During the development of R4 we seriously discussed the problem of the size the new features would take. Siemens, who had their own OSGi implementation for the vehicle market, even did a study to the impact. We very consciously decided that these new features were worth the added memory. I guess there is not much we can do about this, but it is a pity that we now have a split in OSGi, a split which we tried to avoid so hard. Anyway, better an OSGi R3 than no OSGi I guess ...
I decided to build a little application to get a feel for the whole thing. I decided to build an automatic camera that would take a picture whenever the GPS indicated that you had moved more than 50 meters. The track thus created would then be available over a web interface. Formatted as a KML file, it can be displayed in Google Earth. Simple.
Well, writing the application was quite smooth and the debugger was great. Getting it to run on the device was a bit harder because it just did not take pictures. It took some time to figure out how to use the Concierge shell. Even that did not help, there was something with the GPS service. Anyway, I guess with some help this will work before the community event. See if I can get my trip to Berlin recorded!
I wish I had had this device while I was working for Ericsson Research in 1998. It is absolutely perfect for trying out automation scenarios. I remember soldering an IO board, a movement sensor and a mobile phone to demonstrate a burglar alarm system based on sending a picture to the police. This scenario would have been a snap with the BUG.
So what are the application areas for the BUG? If you are one of those lucky people that can now and then wander from the virtual world into reality, then this is abslutely your device. You get a quite powerful computer that can be extended with a snap, ehh, 4 snaps. Obviously, if you still can get excited of what you can do with computers (like me), then it is just too much fun to miss. And if you give OSGi tutorials, well, this kind of device makes OSGi shine.
This is not to say they have arrived. BUG labs still has a lot of work carved out for them. The success will depend on amount of modules they can turn out in the coming years. I wish they had developed a breadboard module first so other companies and individuals could make modules. In earlier times I played a lot with the PIC processors from Microchip and it would be quite easy to interface these into the system. Also, a 1-Wire interface would be really fantastic. 1-wire devices are relatively cheap, and very easy to interface. For a few dollars you could extend a BUG with a temperature sensor, humidity sensor, unique ids, switches, cryptography tokens, etc. Remember the famous Java ring? Well, that was a 1-wire device.
The development environment and the documentation also require some work. As a true open source project they use a Wiki for their documentation so do not hesitate to help to make the BUG more popular. There is also a need for more BUG modules as well: Wifi, audio in/out, power switches, video, bar code readers, proximity detectors, RFID readers, fingerprint readers, Zigbee I/O, Bluetooth, infra-red, geiger-tellers, etc., etc.. There is a mighty amount of work awaiting them.
I really do hope other companies will pick up this concept and start to leverage it. Again, I wish I had had this device in 1998 when we were struggling to create demos!
Peter Kriens
P.S. But what on earth is the Teleporter module going to do???
So yesterday Fedex delivered a nice red box at my doorstep! It is always nice when a company spends a bit of effort on designing the box; this package reminded me of my first TomTom, a company that also took care in making the unwrapping experience fun.The content was a BUG with 4 modules. The BUG itself is the core computer that drives (hopefully) cheap modules. The core contains a small LCD, a minimal joystick, a push button and 4 LEDs that can also be pressed. It is powered through a separate (universal) power supply. Unfortunately, the also present small USB connector is not used to power the device; it is only there for the communications with the development computer. A slide-switch acts as on-off button.
There are 4 modules included:
- LCD Display
- GPS
- Motion Detector
- Camera
The development environment is based on (surprise!) Eclipse, called DragonFly. They told me to use Eclipse 3.3 (Europa) but I decided to live risky and use my current 3.4 Ganymede copy of Eclipse. At least this way I can only blame myself for some of the things that did not work. DragonFly replaces PDE but there are a number of similarities. Also, the manifest file is the driver for the generation. Overall it was very simple to write a new bundle when you are familiar with Eclipse. DragonFly nicely creates a complete project for you with the classpath setup correctly.
For debugging there is a pretty good emulator that reuses the same Java code and implements the services that abstract the devices. You just ask a project to "Debug As" and the select the Virtual Bug. Very smooth. Once the Virtual BUG is running it appears as a device in the list of Bugs. You can drag and drop your project to these devices and that will install them. This drag and drop interface works very well for device management.
The runtime is of course the most interesting part of this device. It runs the (now) open source PhoneME project. This is a CDC VM that supports most of the core Java SE libraries. On top of this VM, BUGLabs uses a Concierge framework. Concierge took the decision to not move to Release 4 but stick on Release 3 because of size reasons. This makes my feelings toward concierge slightly ambivalent. Release 4 added some very important changes that I hate to miss. I know that size matters, but the difference is not that dramatic with today's memory prices. Ok, I prefer OSGi over no OSGi, but staying behind on release level is very tricky. Lots of bundles now use the Bundle.getBundleContext() method, like Declarative Services, which is not part of R3. Also, the modularity layer got an important boost in R4. However, the biggest problem is compliance. Concierge was not tested for compliance and with the OSGi's current rules we cannot certify it anymore. During the development of R4 we seriously discussed the problem of the size the new features would take. Siemens, who had their own OSGi implementation for the vehicle market, even did a study to the impact. We very consciously decided that these new features were worth the added memory. I guess there is not much we can do about this, but it is a pity that we now have a split in OSGi, a split which we tried to avoid so hard. Anyway, better an OSGi R3 than no OSGi I guess ...
I decided to build a little application to get a feel for the whole thing. I decided to build an automatic camera that would take a picture whenever the GPS indicated that you had moved more than 50 meters. The track thus created would then be available over a web interface. Formatted as a KML file, it can be displayed in Google Earth. Simple.
Well, writing the application was quite smooth and the debugger was great. Getting it to run on the device was a bit harder because it just did not take pictures. It took some time to figure out how to use the Concierge shell. Even that did not help, there was something with the GPS service. Anyway, I guess with some help this will work before the community event. See if I can get my trip to Berlin recorded!
I wish I had had this device while I was working for Ericsson Research in 1998. It is absolutely perfect for trying out automation scenarios. I remember soldering an IO board, a movement sensor and a mobile phone to demonstrate a burglar alarm system based on sending a picture to the police. This scenario would have been a snap with the BUG.
So what are the application areas for the BUG? If you are one of those lucky people that can now and then wander from the virtual world into reality, then this is abslutely your device. You get a quite powerful computer that can be extended with a snap, ehh, 4 snaps. Obviously, if you still can get excited of what you can do with computers (like me), then it is just too much fun to miss. And if you give OSGi tutorials, well, this kind of device makes OSGi shine.
This is not to say they have arrived. BUG labs still has a lot of work carved out for them. The success will depend on amount of modules they can turn out in the coming years. I wish they had developed a breadboard module first so other companies and individuals could make modules. In earlier times I played a lot with the PIC processors from Microchip and it would be quite easy to interface these into the system. Also, a 1-Wire interface would be really fantastic. 1-wire devices are relatively cheap, and very easy to interface. For a few dollars you could extend a BUG with a temperature sensor, humidity sensor, unique ids, switches, cryptography tokens, etc. Remember the famous Java ring? Well, that was a 1-wire device.
The development environment and the documentation also require some work. As a true open source project they use a Wiki for their documentation so do not hesitate to help to make the BUG more popular. There is also a need for more BUG modules as well: Wifi, audio in/out, power switches, video, bar code readers, proximity detectors, RFID readers, fingerprint readers, Zigbee I/O, Bluetooth, infra-red, geiger-tellers, etc., etc.. There is a mighty amount of work awaiting them.
I really do hope other companies will pick up this concept and start to leverage it. Again, I wish I had had this device in 1998 when we were struggling to create demos!
Peter Kriens
P.S. But what on earth is the Teleporter module going to do???
Comments
Jan S. Rellermeyer
:
Peter, I agree that memory consumption is far less an issue nowadays and in fact the BUG has plenty of it. What still matters a lot, especially when it comes to mobile embedded systems, is power consumption. Unfortunately, batteries do not scale with Moore's Law. Therefore, a framework implementation like Concierge which has a lot less cycles per, let's say, service request can effectively pay off.
When it comes to the advantages of R4, I agree that there has been some significant progress made on the module layer which is important for a lot of applications. However, I so far haven't encountered too many embedded applications that require many different versions of the same bundle running in disjoint class loader spaces.
I would personally love to see OSGi more emerging into a kind of microkernel architecture (where you have the choice to use or not to use feature X) than increasingly pushing more functionality into the framework to support more fancy applications.
As a matter of fact, OSGi is a modular system but the framework is not...
I never said I would never bring Concierge to R4. In fact, would be a nice challenge to find out how small an R4 framework can be (and maybe also how fast Eclipse would start on an R4-compliant Concierge :-)) Unfortunately, this is more an engineering challenge than a research challenge, meaning that I can probably do such a project only as skunk work and this will take some time.
Well, finally, as you mention declarative services, forgive me for being so bold, but I think that's a bad example for (without doubt existing) technical progress made with R4.X. Declarative services have been IMHO broken from the very beginning because they broke the relationship between the service and the bundle which registers it (well, wants do register it by declaring it). Consequently, in R4.1 you had to introduce the hack with Bundle.getBundleContext() to fix this so that the DS service could really register declarative services on behalf of the bundle. Well, passing the bundle context between bundles has always been considered to be bad practice (e.g., R3 specs page 62). Technically more mature implementations of the idea of declarative services like iPOJO, which inject services rather than acting externally on behalf of the declaring bundle, do not require such a hack.
Cheers,
Jan.
When it comes to the advantages of R4, I agree that there has been some significant progress made on the module layer which is important for a lot of applications. However, I so far haven't encountered too many embedded applications that require many different versions of the same bundle running in disjoint class loader spaces.
I would personally love to see OSGi more emerging into a kind of microkernel architecture (where you have the choice to use or not to use feature X) than increasingly pushing more functionality into the framework to support more fancy applications.
As a matter of fact, OSGi is a modular system but the framework is not...
I never said I would never bring Concierge to R4. In fact, would be a nice challenge to find out how small an R4 framework can be (and maybe also how fast Eclipse would start on an R4-compliant Concierge :-)) Unfortunately, this is more an engineering challenge than a research challenge, meaning that I can probably do such a project only as skunk work and this will take some time.
Well, finally, as you mention declarative services, forgive me for being so bold, but I think that's a bad example for (without doubt existing) technical progress made with R4.X. Declarative services have been IMHO broken from the very beginning because they broke the relationship between the service and the bundle which registers it (well, wants do register it by declaring it). Consequently, in R4.1 you had to introduce the hack with Bundle.getBundleContext() to fix this so that the DS service could really register declarative services on behalf of the bundle. Well, passing the bundle context between bundles has always been considered to be bad practice (e.g., R3 specs page 62). Technically more mature implementations of the idea of declarative services like iPOJO, which inject services rather than acting externally on behalf of the declaring bundle, do not require such a hack.
Cheers,
Jan.
Peter
:
1. Power Consumption
Well, this argument is one red herring. I do not think there is any relationship between size and battery consumption. A linear search is much smaller than a hash search but the hash will use much less CPU cycles. If there is a relation, it is probable reverse from what you indicate.
E.g. a large part of Equinox' code base is devoted to minimize CPU cycles at startup to improve the user experience. I'd love to see you try to beat them at start up time, but I think you will have a terribly hard time because they spent an insane amount of effort to improve startup time ....
To conclude this point, you can only make such a claim when you measured it because minimization of power consumption is awfully hard to predict.
2. Microkernel
Sigh. You better team up with Richard Hall, he has been ganging up on me forever about this (though I think he is turning around very slowly).
Modularity has two aspects: coupling and cohesion. You want to minimize coupling and maximize cohesion. In JSR 291 we tried to break out the service layer. However, we found that we then needed another extension mechanism. Throwing away a small and perfectly good extension mechanism to replace it with a lousy one did not seem a good idea.
As Exupery said: 'Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.' I think leaving out the service layer would have done more harm than good, indicating that we were not totally wrong.
As a researcher a module toolbox is cool and challenging, I can absolutely sympathize. However, for the industrial programmers there is an advantage to have a minimum granularity.
In R4 we added Require-Bundle and Fragments as options because we tried hard to keep OSGi viable for embedded as well. However, options create confusion and incompatibilities, which was the reason we removed the optionality in R4.1. We really asked the members, and the ones focused embedded extra hard, if they saw this as an issue, and they did not.
To conclude this point, I think the granularity of the framework is not bad, I definitely do not want to break out the layers. There is some garbage but that is inevitable with a spec that has 10 years of history.
3. Declarative Services (DS)
Well, first get your facts straight :-)
DS was never intended to register services with its own Bundle Context. From day one, it was clear that these services needed to originate from the declaring service.
However, we had this false assumption that it was safer to hide the Bundle Context from other bundles. So DS was made a framework extension, it would require a framework specific back door to get the Bundle Context of the target bundle.
Two things happened. The extender pattern became more and more popular because it showed some very interesting decoupling characteristics. Second, one day we realized that you can get to the Bundle Context with reflection if you wanted. Only a security manager can make this safe.
So the getBundleContext() was added to Bundle because it turned out to be very useful and we did not enable anything new, just made it more convenient.
Yes, we warned against this in R3 page 62, and I still think one should be careful with handing out Bundle Context objects. However, since then we learned how incredibly value the extender pattern is. The extender pattern allows you to minimize the complexity of application bundles and offload some of the work to the extenders, with very little work. Would it not be strange if we had not added getBundleContext() because we once warned against it?
A hack is one you take a shortcut because you do not want to do it right. I really fail to see why getBundleContext() falls under this category?
iPOJO is an incredibly interesting approach but it requires development time programming. This can be useful in certain cases, and sometimes the runtime option is better. I do not think it would be good if OSGi would promote one or the other.
I actually like DS a lot ... :-)
4. Multiple versions
Last but not least, the multiple versions, the biggest step we made in R4. I agree they might not be a compelling argument in the embedded world. Though I am sure that in the next decade this problem will also happen in that world.
However, the value of R4 is not in this or some other features. The cost of staying at R3 is the the fork in the OSGi world. Your customers choose a dead end in the long run, with potentially costly consequences in the future. Is that really worth the $0.002 for the 200K extra flash?
Anyway, I think you are doing great work but I strongly believe that the best road forward is to add R4 compatibility pass run the test suites.
Kind regards,
Peter Kriens
Well, this argument is one red herring. I do not think there is any relationship between size and battery consumption. A linear search is much smaller than a hash search but the hash will use much less CPU cycles. If there is a relation, it is probable reverse from what you indicate.
E.g. a large part of Equinox' code base is devoted to minimize CPU cycles at startup to improve the user experience. I'd love to see you try to beat them at start up time, but I think you will have a terribly hard time because they spent an insane amount of effort to improve startup time ....
To conclude this point, you can only make such a claim when you measured it because minimization of power consumption is awfully hard to predict.
2. Microkernel
Sigh. You better team up with Richard Hall, he has been ganging up on me forever about this (though I think he is turning around very slowly).
Modularity has two aspects: coupling and cohesion. You want to minimize coupling and maximize cohesion. In JSR 291 we tried to break out the service layer. However, we found that we then needed another extension mechanism. Throwing away a small and perfectly good extension mechanism to replace it with a lousy one did not seem a good idea.
As Exupery said: 'Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.' I think leaving out the service layer would have done more harm than good, indicating that we were not totally wrong.
As a researcher a module toolbox is cool and challenging, I can absolutely sympathize. However, for the industrial programmers there is an advantage to have a minimum granularity.
In R4 we added Require-Bundle and Fragments as options because we tried hard to keep OSGi viable for embedded as well. However, options create confusion and incompatibilities, which was the reason we removed the optionality in R4.1. We really asked the members, and the ones focused embedded extra hard, if they saw this as an issue, and they did not.
To conclude this point, I think the granularity of the framework is not bad, I definitely do not want to break out the layers. There is some garbage but that is inevitable with a spec that has 10 years of history.
3. Declarative Services (DS)
Well, first get your facts straight :-)
DS was never intended to register services with its own Bundle Context. From day one, it was clear that these services needed to originate from the declaring service.
However, we had this false assumption that it was safer to hide the Bundle Context from other bundles. So DS was made a framework extension, it would require a framework specific back door to get the Bundle Context of the target bundle.
Two things happened. The extender pattern became more and more popular because it showed some very interesting decoupling characteristics. Second, one day we realized that you can get to the Bundle Context with reflection if you wanted. Only a security manager can make this safe.
So the getBundleContext() was added to Bundle because it turned out to be very useful and we did not enable anything new, just made it more convenient.
Yes, we warned against this in R3 page 62, and I still think one should be careful with handing out Bundle Context objects. However, since then we learned how incredibly value the extender pattern is. The extender pattern allows you to minimize the complexity of application bundles and offload some of the work to the extenders, with very little work. Would it not be strange if we had not added getBundleContext() because we once warned against it?
A hack is one you take a shortcut because you do not want to do it right. I really fail to see why getBundleContext() falls under this category?
iPOJO is an incredibly interesting approach but it requires development time programming. This can be useful in certain cases, and sometimes the runtime option is better. I do not think it would be good if OSGi would promote one or the other.
I actually like DS a lot ... :-)
4. Multiple versions
Last but not least, the multiple versions, the biggest step we made in R4. I agree they might not be a compelling argument in the embedded world. Though I am sure that in the next decade this problem will also happen in that world.
However, the value of R4 is not in this or some other features. The cost of staying at R3 is the the fork in the OSGi world. Your customers choose a dead end in the long run, with potentially costly consequences in the future. Is that really worth the $0.002 for the 200K extra flash?
Anyway, I think you are doing great work but I strongly believe that the best road forward is to add R4 compatibility pass run the test suites.
Kind regards,
Peter Kriens
Jan S. Rellermeyer
:
1) You can (often) trade a higher memory consumption for CPU time (e.g., through hashing, indexing, ...), no doubt. But I am talking about the relationship of the amount of code executed and the power consumption and I don't see how in a general case, significantly more bytecode executed could save energy. I essentially measured and optimized Concierge for months when I wrote the EuroSys paper and even though I agree that measuring precise power consumption on mobile devices is tricky, the difference in execution- and CPU time when running the same (pretty long-running) set of bundles where so striking when I compared to the R3 frameworks of that time that I feel pretty on the safe side. Meaning, it's not only a difference in SLOC, there is a difference in instructions executed.
(And I don't say that Equinox is slow. But, why couldn't a minimalistic design like Concierge be faster? RISCs have been typically faster than CISCs, haven't they :-) We'll see).
2) The service layer is the last that I would remove. How could I do remote services then?
Actually, it's not so much about removing anything particular, it's more about how to enable new future ideas and directions without too often extending the frameworks and/or drilling new holes. Microkernel-like architectures are pretty good in this regard.
3) Interesting to hear about the background of getBundleContext(). The extender pattern is great and I frequently use it. E.g., R-OSGi is one big extender pattern. However, I rarely needed getBundleContext(). (But, since I only have to sell ideas and never products, I only build systems and rarely have to write complex applications, which could be a reason)
4) I am pretty sure that I will have R4.1 Concierge ready before the next decade :-) And I would even implement DS for Concierge if this would just help to finally wipe out CLDC on embedded devices (like mobile phones). I guess, slightly more worrying than a poor old-fashioned R3 framework are the amount of up-to-date devices that still cannot run OSGi at all.
Cheers,
Jan.
(And I don't say that Equinox is slow. But, why couldn't a minimalistic design like Concierge be faster? RISCs have been typically faster than CISCs, haven't they :-) We'll see).
2) The service layer is the last that I would remove. How could I do remote services then?
Actually, it's not so much about removing anything particular, it's more about how to enable new future ideas and directions without too often extending the frameworks and/or drilling new holes. Microkernel-like architectures are pretty good in this regard.
3) Interesting to hear about the background of getBundleContext(). The extender pattern is great and I frequently use it. E.g., R-OSGi is one big extender pattern. However, I rarely needed getBundleContext(). (But, since I only have to sell ideas and never products, I only build systems and rarely have to write complex applications, which could be a reason)
4) I am pretty sure that I will have R4.1 Concierge ready before the next decade :-) And I would even implement DS for Concierge if this would just help to finally wipe out CLDC on embedded devices (like mobile phones). I guess, slightly more worrying than a poor old-fashioned R3 framework are the amount of up-to-date devices that still cannot run OSGi at all.
Cheers,
Jan.
Java Modularity
2008-05-13
Before JavaOne, there were clearly changes in the air with respect to JSR 277 Modules for Java and JSR 294 Superpackages. The announcement of Glassfish to support OSGi and the project Fuji (an ESB/JBI implementation based on OSGi) represent a significant mind-shift at Sun. We also saw Stanley Ho's interoperability paper on the JSR 277 mailing list. I therefore was happily surprised when the JSR 277 Java Modularity spec leads, Alex Buckley and Stanley Ho, when they asked me if I still wanted to join JSR 277.This question posed a dilemma for me. Was I still interested? Two years ago when JSR 277 started I was rejected and I made a big fuzz about this, which obviously puts a moral burden on me now. Also, the changes around JSR 294 Superpackages definitely inclined me to join. JSR 294 was now folded back in JSR 277 and its course had changed 180 degrees. Instead of an overly redundant poorly thought out model Alex had kicked the bucket under the superpackages draft and proposed the much simpler concept of an access modifier called module. Though this idea had not been worked out in detail, it clearly was much, much, more feasible. Modules setup this way could be very usable in the OSGi world. My technical me would love to work on this aspect.
However, JSR 277 now consists of two good (Repository and Language modules) and one bad part (JAM). Just before JavaOne 2008 Stanley had published a brief OSGi interoperability document. This document was not only very thin on details, it also referred in many places to an invisible Early Draft #2 (EDR2). I asked the EG members BJ Hargrave and Richard Hall if they had seen this EDR2, but it was unknown to them as well. I had recently complained about the lack of discussions on the JSR 277 mailing list, so it seems that work had been going on stealthily.
During the JSR 277 presentations Alex and Stanley it became clear to me that a lot of work had happened behind the scenes; Without any communications on the mailing lists. For somebody in the audience it was absolutely not clear that almost everything that was said was never discussed in the EG. How could I participate in an EG if the only option would be to approve work done at Sun behind the curtains? How much change can there be if the unpublished EDR2 is presented at JavaOne as the stable result for JSR 277? Should I join an EG where most of the work was already done? How many fundamental changes can you achieve in this situation?
I wish it was differently. Bryan Atsatt did a lot of work to convince Sun to open up, and it worked better than one could have expected. So, there is a lot of moral pressure on me to compromise and accept. As several people said: "Sun will not give up their JAMs, so get over it." Now, it is in my nature to compromise; I prefer working together on technical details instead of fighting. However, I just turned 50 years old and I can recall too many painful events where I compromised against my technical instinct. Years later the forces behind the compromise were forgotten and the inferior technical design remained with my name attached to it. I really do not like that and this seems one of those cases.
So why do I not like JAMs? Well, who needs them? Do they provide something that OSGi not already provides? Alex and Stanley stressed the "fact" that JAMs are "deterministic" and "simple", the Siren's song of simplistic solutions. Only when you do not fully understand the problem is JAM an attractive solution. The truth is, JAM creates unnecessary complexity, the worst of all.
There is only one argument that makes sense for a special module layer for the VM: The boot classes. Obviously during the boot phase a full-blown OSGi framework is not feasible because OSGi is written in Java. However, JAM will have exactly the same problems loading java.lang.Object because the environment to run the framework is not loaded yet. How do you process annotations without having the Class class loaded? Write an annotation layer in C? I will not even go into initialization and custom module binding support. Clearly, a special solution is required to modularize the core language packages. This problem was also faced by Apache Harmony. They also did not want to support a full blown OSGi framework in their VM, but they did understand the importance of existing standards. Apache Harmony modularized the bootpath classes and provides them as OSGi bundles using the standardized metadata. Because headers are in the manifest and easy to parse, no complex redundancy is required as with JAM's annotation support. Using the same metadata makes a seamless transition possible from booting all the way to running one of the many application servers defined on top of OSGi. For management systems it is ideal if they only have to worry about a single format.
We are now at a crucial point in time. Though I'd love to participate in the discussions about modules in the Java language and the repositories, I cannot become responsible for a module system in Java that is creating this complexity for no rational reason. I do hope Sun will take this last step as well, and drop JAM in favor of the much simpler approach of using the OSGi metadata throughout the system. In the last months we have gotten so far! Please?
Peter Kriens
P.S. Did you register at the Community Event yet? There are only 190 places and I think they will be filled up. After Sun's embrace of OSGi, a lot more people got interested. You surely do not want to miss it. Last week we finalized the program it looks surprisingly strong.
P.P.S. Do you regularly read this blog? Do you know you can become an OSGi supporter? This free of charge and it helps us make it more clear to people that you support OSGi, sometimes numbers help, becoming a supporter does help. Of course if you can afford it, we'd love even better to have you as a full member or adopter. Take a look at the conditions. Appreciated!
SpringSource Application Platform + Bundle Repository
2008-05-06
When SpringSource announced their Application Platform and Bundle Repository I was very excited. I had been informed something was coming and picked up rumors from the grapevine.The bundle repository was in one word: stunning. I had been looking into providing such a service but had decided that I could not afford it, despite the fact that I think that many companies would really benefit from such a service. This bundle repository must have been a terrible job to do. Kudos!The Spring Source Application Platform was, however, a bit of a shock. Looking through the documentation I found lots of headers that felt like OSGi but that I did not recognize: Import-Library, Import-Bundle, Application, etc. It looked like SpringSource had “improved” OSGi extensively. This was a bit of a shock, especially because they looked so much like standard OSGi headers.
I learned over the past 10 years that just adding a number of headers that solve a particular problem usually backfires. Something that sounds really good, does not have to be that good at all when you inspect it from a different perspective. The problem with standards is, is that it is very easy to add something but impossible to remove. You really have to get right as much as possible the first time; it is therefore better to err on the side of leaving things out. Due to the embedded origin of OSGi we have always been extremely careful to minimize the number of feature. Each additional feature require a lot of eyes and discussions and a very thorough analysis before it makes into the specification. Especially today, with a mature specification the feature interaction can be quite painful.
Do not get me wrong, as a practitioner I do know the importance of getting things to work and standards, by definition, are not always sufficient. I also know that a standardization process feels sometimes excruciatingly slow when you live in the trenches, and I love experiments.
However, Eclipse has the same problem, but they have always been a good citizen in this respect. They always added proprietary headers in their own name space, learned from their experiences, and then proposed a new standard. In all cases so far, the specification process was able to make the concept more general and fit better in the overall OSGi model. Having a separate name space was also a convenience for their customers. A specification process will undoubtedly change the semantics, requiring awkward constructs to distinguish between the SpringSource defined meanings and the OSGi defined meanings. I do realize that OSGi does not own the name space in the manifest, and I do regret heavily that we did no better scope our header names, however, this did not seem overly important 10 years ago.
Why would the standardized version be better? Because more eyes looked at it, from different perspectives (which sometimes can be quite bad for one's ego). One man's convenience is another man's complexity. This is why so far we have always focused on providing the primitives and not convenience functions because convenience is often in the eye of the beholder and can be provided during the development process in the IDE or run-time libraries.
The biggest danger of a standard like OSGi today is feature creep. The leanness of OSGi is one of its main attractions for many newcomers. It really took real hard work and untold man hours to make it this lean, believe me. Maybe the SpringSource headers are a significant improvement over the existing specification, maybe they turn out to be superfluous. Time will tell. I guess it is a sign of becoming more popular that companies try to stretch the specification in their world view. However, I do hope that most developers realize that restricting oneself to the standard may sometimes be a little bit less convenient, but it does provide one with a more options and no vendor lock-in down the line.
So sadly, my feelings are mixed. I love what they have done with the bundle repository, and also many parts of the S2AP look very impressive, Neil Bartlett's blog provides an overview that I can very much sympathize with. I know several Spring Sourcerers and they are very clever and capable people. SpringSource undeniably is meaning a lot for the OSGi organization and the adoption of the specifications. However, multiplying bundle headers feels more like coming from an apprentice than from the experts I know them to be.
Peter Kriens
P.S. On a more positive note. We are reaching the first deadline for registration of the OSGi Community event in Berlin, June 10-11. I am part of the program committee and I can ensure you that it is worth coming. We actually had to split the second day into two tracks because we had so many good sessions submitted. Looking at the number of submissions it will look like we will sell out the places we have this year. This is the premier OSGi event in Europe, we are really expecting all the key OSGi people to be there. Take advantage of the early registration fee and register today!
Comments
Steve
:
I had the same misgivings on reading about the Import-Library and Import-Bundle, but on further reading I had thought these were only syntactic sugar, as they expand to Import-Package under the covers.
I've also read that the bundles available from the SpringSource repository will only use standard OSGi headers; not the new Import-* headers. This still leaves me a bit confused on how the new Import-* headers are used and where - playing with the Spring app platform will, hopefully, answer those questions.
I've also read that the bundles available from the SpringSource repository will only use standard OSGi headers; not the new Import-* headers. This still leaves me a bit confused on how the new Import-* headers are used and where - playing with the Spring app platform will, hopefully, answer those questions.
Peter
:
I did not comment the semantics of the headers. It is great that they are experimenting and this will provide invaluable feedback. Even if it is only syntactic sugar, these headers look like they are part of the OSGi family and that concerns me. All OSGi headers have been analyzed and vetted to death, these are very interesting experiments and will likely influence the spec in the long run. They should have made this more clear by naming them S2AP-Import-Library or so.
Kind regards,
Peter Kriens
Kind regards,
Peter Kriens
Adrian
:
Peter,
I actually think we are in violent agreement about many of the points you raise in your post. There seem to be three basic points of confusion/contention about the new manifest headers supported by the SpringSource Application Platform being raised here and elsewhere, namely:
* The fact the we introduced new headers at all
* The fact that Import-Library and Import-Bundle sound similar to existing headers
* The fact that we didn't attempt to standardize these headers before including them in our beta (not a criticism made in your post, but heard elsewhere)
Let me address each of these points in turn, responding to some of your comments as we go.
* The fact that we have introduced new headers (at all)
Peter wrote:
>The Spring Source Application Platform was, however, a bit of a shock. Looking through the documentation I found lots of headers that felt like OSGi but that I did not recognize: Import-Library, Import-Bundle, Application, etc.
The "lots" of headers that you refer to for MANIFEST.MF basically boil down to Import-Library and Import-Bundle (there is no "Application" manifest header).
>It looked like SpringSource had “improved” OSGi extensively.
The important thing to understand about these headers is that they add no new underlying semantics to an OSGi Service Platform, and are essentially just syntactic sugar for a set of Import-Package statements. Any bundle that uses these headers could be deployed on any OSGi R4 compliant Service Platform following a simple mechanistic expansion of the headers into their Import-Package equivalent (more on that later, we'll be shipping the tools to perform exactly this translation). The SpringSource Application Platform uses the OSGi RI (Equinox) unmodified at its core.
>I learned over the past 10 years that just adding a number of headers that solve a particular problem usually backfires. Something that sounds really good, does not have to be that good at all when you inspect it from a different perspective. The problem with standards is, is that it is very easy to add something but impossible to remove. You really have to get right as much as possible the first time; it is therefore better to err on the side of leaving things out.
I completely agree. The key point is, *we haven't changed the standard*! At SpringSource we firmly believe in standardizing solutions that have been proven to work in the field, as opposed to solutions that have not yet been battle hardened. What we have done is added syntactic sugar particular to the SpringSource Application Platform, that if it proves to be successful in the marketplace we would then put forward through the OSGi RFP/RFC process for potential standardization. I agree it would be a mistake to add these headers to the specification now. The specification should err on the side of leaving things out, and only include new features that have proven their worth in the field.
>This is why so far we have always focused on providing the primitives and not convenience functions because convenience is often in the eye of the beholder and can be provided during the development process in the IDE or run-time libraries.
The SpringSource Application Platform is a demonstration of this split you describe working in practice. The OSGi R4 specification defines the primitive (in this case Import-Package) and the SpringSource Application Platform provides two convenience functions on top of that (Import-Package and Import-Bundle). These are supported during the development process (in the Eclipse tools that accompany the Application Platform) and in the runtime libraries that translate the convenience headers into their standard equivalents before deployment into a standard OSGi Service Platform. So once again we find ourselves in agreement.
* The fact that Import-Library and Import-Bundle sound similar to existing headers
>>This was a bit of a shock, especially because they looked so much like standard OSGi headers.
The headers are of course designed to feel like a natural fit on top of the OSGi standard. From a usability point of view, I argue that this is a good thing! I've heard two arguments made as to why this "usability" is a bad idea:
1) Users may be confused about when they are using standard headers and when they are using non-standard headers, and
2) A future OSGi specification process may want to use exactly the same names, and that would cause confusion.
Taking these points in turn...
1) Users may be confused about when they are using standard headers and when they are using non-standard headers.
The fear here is clearly one of "accidental lock-in" to the SpringSource Application Platform by inadvertent use of non-standard headers. The fact is that since the headers introduce no new underlying semantics, any bundle using these headers can be trivially converted back to a bundle that will deploy on any vanilla OSGi Service Platform: there is no intention on our part to create lock-in with these headers. We will be shipping the tools (both command-line, and as part of our Eclipse-based tool suite) to convert any bundle using these new headers into one that uses only Import-Package instead. So anyone developing bundles for the SpringSource Application Platform and that uses these headers has a trivial path to port them to any OSGi Service Platform implementation. Moreover, we like Neal Bartlett's suggestion of a warning marker in Eclipse whenever one of these headers is used, and will be building it into our Eclipse tools as a "strict OSGi compliance" mode that can be enabled if desired. (So you don't need to write the plugin Neal, we'll be doing it for you ;) ). The SpringSource Application Platform is just as happy with Import-Package as it is with Import-Library or Bundle.
2) A future OSGi specification process may want to use exactly the same names, and that would cause confusion.
>A specification process will undoubtedly change the semantics, requiring awkward constructs to distinguish between the SpringSource defined meanings and the OSGi defined meanings. I do realize that OSGi does not own the namespace in the manifest, and I do regret heavily that we did no better scope our header names, however, this did not seem overly important 10 years ago.
First a general point. The underlying issue here is really that Java itself has no conventions for qualifying manifest headers in the same way that for example the package namespace is segregated. As you point out, OSGi does not own the manifest namespace and is an equal partner with everyone else in defining headers for use in a manifest and associating semantics with them.
Let's examine the hypothetical "worst case" : the OSGi Alliance decides it wants to introduce standardized headers with exactly the same names as the ones used by SpringSource, but with semantic differences. These headers would clearly not be recognized by an R4.1 based OSGi Service Platform. The "awkward constructs" to distinguish between the SpringSource meanings and the standard meanings therefore already exist and aren't really that awkward at all: it's the existing Bundle-ManifestVersion header. At Bundle-ManifestVersion 3.0 (for sake of argument) these headers would clearly have whatever semantics the OSGi specification defined for them, and it would be a problem for the SpringSource Application Platform itself (not the OSGi specification) to deal with the migration of existing bundles written at Bundle-ManifestVersion 2.0 to bundles at Bundle-ManifestVersion 3.0.
I guess it's fortunate for SpringSource therefore that the OSGi Alliance exhibits such a deep belief that new manifest headers should be qualified. Clearly it would be a hypocritical position for the Alliance to further propagate its "mistake" of 10 years ago by introducing new headers without (e.g.) an "OSGi" qualifier. (And if the Alliance doesn't qualify any new headers, on what grounds can it legitimately expect anyone else to do so??). Therefore the chance of a clash (which in any case would be easily resolved by Bundle-ManifestVersion) appears to be negligible.
I would actually fully support an RFP proposing that in R5 all OSGi manifest headers get an "OSGi" qualifier, and the existing unqualified headers be deprecated for removal in some future version of the specification. This is I believe the right solution to the perceived problem as the OSGi Alliance *can* legitimately claim some ownership of manifest headers starting with the OSGi qualifier.
* The fact that we didn't attempt to standardize these headers before including them in our beta
It sounds like both you and I are in strong agreement that premature inclusion of new headers in the standard before they have been proven in the field would be a mistake. See my post on the spring-osgi mailing list for a fuller discussion of this point.
The next OSGi CPEG and EEG meetings will be held at the SpringSource offices in a couple of weeks time. I'm looking forward to continuing this debate in that forum. The SpringSource Application Platform is still in beta, and now that it is in the public domain I'm looking forward to the EG feedback on what we have done so far. Making changes to the model we are putting forward is definitely still within scope, but so far I'm not persuaded by the arguments that we need to do so in this particular case.
-- The Apprentice ;)
I actually think we are in violent agreement about many of the points you raise in your post. There seem to be three basic points of confusion/contention about the new manifest headers supported by the SpringSource Application Platform being raised here and elsewhere, namely:
* The fact the we introduced new headers at all
* The fact that Import-Library and Import-Bundle sound similar to existing headers
* The fact that we didn't attempt to standardize these headers before including them in our beta (not a criticism made in your post, but heard elsewhere)
Let me address each of these points in turn, responding to some of your comments as we go.
* The fact that we have introduced new headers (at all)
Peter wrote:
>The Spring Source Application Platform was, however, a bit of a shock. Looking through the documentation I found lots of headers that felt like OSGi but that I did not recognize: Import-Library, Import-Bundle, Application, etc.
The "lots" of headers that you refer to for MANIFEST.MF basically boil down to Import-Library and Import-Bundle (there is no "Application" manifest header).
>It looked like SpringSource had “improved” OSGi extensively.
The important thing to understand about these headers is that they add no new underlying semantics to an OSGi Service Platform, and are essentially just syntactic sugar for a set of Import-Package statements. Any bundle that uses these headers could be deployed on any OSGi R4 compliant Service Platform following a simple mechanistic expansion of the headers into their Import-Package equivalent (more on that later, we'll be shipping the tools to perform exactly this translation). The SpringSource Application Platform uses the OSGi RI (Equinox) unmodified at its core.
>I learned over the past 10 years that just adding a number of headers that solve a particular problem usually backfires. Something that sounds really good, does not have to be that good at all when you inspect it from a different perspective. The problem with standards is, is that it is very easy to add something but impossible to remove. You really have to get right as much as possible the first time; it is therefore better to err on the side of leaving things out.
I completely agree. The key point is, *we haven't changed the standard*! At SpringSource we firmly believe in standardizing solutions that have been proven to work in the field, as opposed to solutions that have not yet been battle hardened. What we have done is added syntactic sugar particular to the SpringSource Application Platform, that if it proves to be successful in the marketplace we would then put forward through the OSGi RFP/RFC process for potential standardization. I agree it would be a mistake to add these headers to the specification now. The specification should err on the side of leaving things out, and only include new features that have proven their worth in the field.
>This is why so far we have always focused on providing the primitives and not convenience functions because convenience is often in the eye of the beholder and can be provided during the development process in the IDE or run-time libraries.
The SpringSource Application Platform is a demonstration of this split you describe working in practice. The OSGi R4 specification defines the primitive (in this case Import-Package) and the SpringSource Application Platform provides two convenience functions on top of that (Import-Package and Import-Bundle). These are supported during the development process (in the Eclipse tools that accompany the Application Platform) and in the runtime libraries that translate the convenience headers into their standard equivalents before deployment into a standard OSGi Service Platform. So once again we find ourselves in agreement.
* The fact that Import-Library and Import-Bundle sound similar to existing headers
>>This was a bit of a shock, especially because they looked so much like standard OSGi headers.
The headers are of course designed to feel like a natural fit on top of the OSGi standard. From a usability point of view, I argue that this is a good thing! I've heard two arguments made as to why this "usability" is a bad idea:
1) Users may be confused about when they are using standard headers and when they are using non-standard headers, and
2) A future OSGi specification process may want to use exactly the same names, and that would cause confusion.
Taking these points in turn...
1) Users may be confused about when they are using standard headers and when they are using non-standard headers.
The fear here is clearly one of "accidental lock-in" to the SpringSource Application Platform by inadvertent use of non-standard headers. The fact is that since the headers introduce no new underlying semantics, any bundle using these headers can be trivially converted back to a bundle that will deploy on any vanilla OSGi Service Platform: there is no intention on our part to create lock-in with these headers. We will be shipping the tools (both command-line, and as part of our Eclipse-based tool suite) to convert any bundle using these new headers into one that uses only Import-Package instead. So anyone developing bundles for the SpringSource Application Platform and that uses these headers has a trivial path to port them to any OSGi Service Platform implementation. Moreover, we like Neal Bartlett's suggestion of a warning marker in Eclipse whenever one of these headers is used, and will be building it into our Eclipse tools as a "strict OSGi compliance" mode that can be enabled if desired. (So you don't need to write the plugin Neal, we'll be doing it for you ;) ). The SpringSource Application Platform is just as happy with Import-Package as it is with Import-Library or Bundle.
2) A future OSGi specification process may want to use exactly the same names, and that would cause confusion.
>A specification process will undoubtedly change the semantics, requiring awkward constructs to distinguish between the SpringSource defined meanings and the OSGi defined meanings. I do realize that OSGi does not own the namespace in the manifest, and I do regret heavily that we did no better scope our header names, however, this did not seem overly important 10 years ago.
First a general point. The underlying issue here is really that Java itself has no conventions for qualifying manifest headers in the same way that for example the package namespace is segregated. As you point out, OSGi does not own the manifest namespace and is an equal partner with everyone else in defining headers for use in a manifest and associating semantics with them.
Let's examine the hypothetical "worst case" : the OSGi Alliance decides it wants to introduce standardized headers with exactly the same names as the ones used by SpringSource, but with semantic differences. These headers would clearly not be recognized by an R4.1 based OSGi Service Platform. The "awkward constructs" to distinguish between the SpringSource meanings and the standard meanings therefore already exist and aren't really that awkward at all: it's the existing Bundle-ManifestVersion header. At Bundle-ManifestVersion 3.0 (for sake of argument) these headers would clearly have whatever semantics the OSGi specification defined for them, and it would be a problem for the SpringSource Application Platform itself (not the OSGi specification) to deal with the migration of existing bundles written at Bundle-ManifestVersion 2.0 to bundles at Bundle-ManifestVersion 3.0.
I guess it's fortunate for SpringSource therefore that the OSGi Alliance exhibits such a deep belief that new manifest headers should be qualified. Clearly it would be a hypocritical position for the Alliance to further propagate its "mistake" of 10 years ago by introducing new headers without (e.g.) an "OSGi" qualifier. (And if the Alliance doesn't qualify any new headers, on what grounds can it legitimately expect anyone else to do so??). Therefore the chance of a clash (which in any case would be easily resolved by Bundle-ManifestVersion) appears to be negligible.
I would actually fully support an RFP proposing that in R5 all OSGi manifest headers get an "OSGi" qualifier, and the existing unqualified headers be deprecated for removal in some future version of the specification. This is I believe the right solution to the perceived problem as the OSGi Alliance *can* legitimately claim some ownership of manifest headers starting with the OSGi qualifier.
* The fact that we didn't attempt to standardize these headers before including them in our beta
It sounds like both you and I are in strong agreement that premature inclusion of new headers in the standard before they have been proven in the field would be a mistake. See my post on the spring-osgi mailing list for a fuller discussion of this point.
The next OSGi CPEG and EEG meetings will be held at the SpringSource offices in a couple of weeks time. I'm looking forward to continuing this debate in that forum. The SpringSource Application Platform is still in beta, and now that it is in the public domain I'm looking forward to the EG feedback on what we have done so far. Making changes to the model we are putting forward is definitely still within scope, but so far I'm not persuaded by the arguments that we need to do so in this particular case.
-- The Apprentice ;)
Adrian
:
Steve wrote:
>I had the same misgivings on reading about the Import-Library and Import-Bundle, but on further reading I had thought these were only syntactic sugar, as they expand to Import-Package under the covers.
That's absolutely correct. They are syntactic sugar and using the tools we will provide any bundle that uses these headers can be easily converted into one that uses only Import-Package with no change in semantics.
>I've also read that the bundles available from the SpringSource repository will only use standard OSGi headers; not the new Import-* headers. This still leaves me a bit confused on how the new Import-* headers are used and where - playing with the Spring app platform will, hopefully, answer those questions.
This is a very good question, and one that deserves a longer answer in a dedicated blog posting of its own (which Glyn Normington has posted on the SpringSource blog). The short answer is that Import-Bundle and Import-Library are intended for use when referring to existing enterprise libraries that a bundle depends on (and not for use for importing e.g. user-defined application bundles). We do this for two reasons: (a) it more naturally expresses the user intention (the statement "my application depends on Spring Framework 2.5.4" is at a higher level of abstraction than 50 or 60 import package statements), and crucially (b) the set of Import-Package statements needed for many enterprise libraries that use load-time weaving, runtime subclass generation and other enterprise tricks is non-obvious to the user (it's not just the set of packages they explicitly depend on in their own code at runtime) and would require a tedious trial-and-error process to get right - and even then it would depend on internal implementation details of the library in question and may change with future versions making the construct fragile.
>I had the same misgivings on reading about the Import-Library and Import-Bundle, but on further reading I had thought these were only syntactic sugar, as they expand to Import-Package under the covers.
That's absolutely correct. They are syntactic sugar and using the tools we will provide any bundle that uses these headers can be easily converted into one that uses only Import-Package with no change in semantics.
>I've also read that the bundles available from the SpringSource repository will only use standard OSGi headers; not the new Import-* headers. This still leaves me a bit confused on how the new Import-* headers are used and where - playing with the Spring app platform will, hopefully, answer those questions.
This is a very good question, and one that deserves a longer answer in a dedicated blog posting of its own (which Glyn Normington has posted on the SpringSource blog). The short answer is that Import-Bundle and Import-Library are intended for use when referring to existing enterprise libraries that a bundle depends on (and not for use for importing e.g. user-defined application bundles). We do this for two reasons: (a) it more naturally expresses the user intention (the statement "my application depends on Spring Framework 2.5.4" is at a higher level of abstraction than 50 or 60 import package statements), and crucially (b) the set of Import-Package statements needed for many enterprise libraries that use load-time weaving, runtime subclass generation and other enterprise tricks is non-obvious to the user (it's not just the set of packages they explicitly depend on in their own code at runtime) and would require a tedious trial-and-error process to get right - and even then it would depend on internal implementation details of the library in question and may change with future versions making the construct fragile.
Niclas
:
Adrian,
Although you are right in principle about the Import-* naming, SpringSource should act as a well-behaved OSGi citizen, as Eclipse has done in the past, and chosen a prefix.
I certainly don't believe that S2 has not made a conscious decision that a non-prefixed header serves the corporation better, i.e. accidental lock-ins, since(as you point out) you have chosen the risk of dealing with a very possible problem in the future.
I would urge S2 to make this change (prefix) prior to 1.0-final, to keep its status as one of the most outstanding contributors to OSGi technology. It is not too late.
Although you are right in principle about the Import-* naming, SpringSource should act as a well-behaved OSGi citizen, as Eclipse has done in the past, and chosen a prefix.
I certainly don't believe that S2 has not made a conscious decision that a non-prefixed header serves the corporation better, i.e. accidental lock-ins, since(as you point out) you have chosen the risk of dealing with a very possible problem in the future.
I would urge S2 to make this change (prefix) prior to 1.0-final, to keep its status as one of the most outstanding contributors to OSGi technology. It is not too late.
Niclas
:
Other than the above, I am generally positive to this new product. The choice of GPL/dual-licensing is a sign that S2 is now looking into making some money out of all their market-share, which I can easily sympathize with. Whether it will work is a different story, but I think the big winner here is the OSGi community at large.
Good Luck with S2AP (just add the prefix... ;o) )
Good Luck with S2AP (just add the prefix... ;o) )
Per Olesen
:
@Adrian and @Niclas
I too, would urge S2 to add a prefix on their non-standard headers. I read Adrians response, I can see the points in there, and I *still* would like clearly spoken in the header name, that it is S2-specific.
It is not as if it is a new concept, to do this when "enhancing" a spec. It is just plain playing nice. Something S2 has a reputation for (playing nice), and I urge you to keep that reputation.
In short: Add the damned prefix to the non-standard headers! :-)
I too, would urge S2 to add a prefix on their non-standard headers. I read Adrians response, I can see the points in there, and I *still* would like clearly spoken in the header name, that it is S2-specific.
It is not as if it is a new concept, to do this when "enhancing" a spec. It is just plain playing nice. Something S2 has a reputation for (playing nice), and I urge you to keep that reputation.
In short: Add the damned prefix to the non-standard headers! :-)
| Previous Posts | Archives |
|---|---|
http://alblue.blogspot.com/2008/05/version-numbers-and-jsr277.html
Peter Kriens
Peter Kriens
Actually I was working on a system to determine the correct version number of the latest version of the API for a bundle (in a syntactic and semantic way). With this it would be guaranteed, that version ranges can always be applied correctly, without having the human factor causing problems - components, you can actually trust. But I guess, I can just relax and write a random number generator. That’ll be as reliable as the new versioning scheme. Sorry, but sometimes only sarcasm helps.
Mirko