After 4 years it seems Oracle broke Apache's last straw, they left the JCP. Together with the independents. Sun originally promised to make Java a free platform, and I believed them. Guess I am naive but Sun's track record was pretty good at the time. Oracle originally objected to the fields of use restrictions before they bought Java but changed their mind now they're the owner and I guess IBM was bought off. It is surprising how Oracle seems to be aiming straight at their foot, do they regard the open source community as a minor aspect of Java? Is this (long gone after Android & iPhone) mobile market worth the cost of alienating their most fervent supporters?
It is a mess because I do not want to choose. I like the big corporations because the give credence to the Java platform and provide numerous resources to work on the platform. I do not think Java could have been created in an open source environment of volunteers. However, I also like Apache and other open source foundations because they provide diversity and innovation beyond corporate interest. And then again I do not like big corporations because politics often trump best technical solutions and I do not like open source communities because they too often mix idealism and work. Working together they keep each other in a good balance.
What is needed, and what was clearly promised by Sun all those years ago, is an independent organization where industry and open source community can meet and standardize without any one party being special. The OSGi is such an organization. An organization that has a lot of experience with Java specifications as well. Maybe the OSGi Alliance needs to make some organizational changes but it is and independent and experienced place to standardize where there currently is no other place like it.
It is sad to see how a closed eco-system like Apple's iPhone and iPad is thriving and how we are going to waste a lot of energy in the next years because we direct that energy on destroying and not creation. The tragedy of the commons revisited.
Peter Kriens
P.S. Neil Bartlett and I will hold another master class int the US Bay Area on January 18-21. The first one was a very good experience (also according to the participants!), though intense.
OSGi Blog
Friday, December 10, 2010
Friday, December 3, 2010
Modularization
Reading blogs about Java modularization gives me the sincere impression that (too) few people understand what modularization really is all about and how OSGi implements it.
Modularization is a fractal, it is a process that has happened several times over the last 50 years. The reason for these disruptive process was that it allowed us to scale software development to the next level. Assembly was a clear form of modularization where the bits were hidden from us humans. Functions with local variables were the next step. The industry then went on with modules (functions + data) and objects that are basically modules that could be instantiated. Java added packages, which grouped classes, again a form of modularization.
What these efforts did was encapsulate, they created a boundary between inside and outside and controlled the internal name space by importing and exporting. You could import from the outside world and you could control what was exported. What you did on the inside was your problem, it was not visible to the outside world. For example, it is impossible to detect that the name of a local variable used in a function. This kind of encapsulation is important, it means what happens in the inside is invisible to other parts of the system. Invisibility is good, you can't be wrong about something you do not know!
Except for OSGi, other modularity efforts seem to forget about this crucial encapsulation required for the next modularization step. The efforts I've seen so far focus on accessibility. The difference between accessibility and visibility is that accessibility requires a single name space. Where in OSGi each bundle (the module) has its own name space as we've done in the past when we took a modularization step, in other forms this aspect is ignored. All other proposals I've seen so far assume that there is a single name space for classes.
A single name space works well for small to medium systems. However, today we are building systems that consists of a large number of subsystems. Forcing a single name space on these large systems is in the long run asking for problems. The clearest example is if you have two subsystems that depend on different versions of a third subsystem than you're in trouble. Unless you build on OSGi.
Peter Kriens
Modularization is a fractal, it is a process that has happened several times over the last 50 years. The reason for these disruptive process was that it allowed us to scale software development to the next level. Assembly was a clear form of modularization where the bits were hidden from us humans. Functions with local variables were the next step. The industry then went on with modules (functions + data) and objects that are basically modules that could be instantiated. Java added packages, which grouped classes, again a form of modularization.
What these efforts did was encapsulate, they created a boundary between inside and outside and controlled the internal name space by importing and exporting. You could import from the outside world and you could control what was exported. What you did on the inside was your problem, it was not visible to the outside world. For example, it is impossible to detect that the name of a local variable used in a function. This kind of encapsulation is important, it means what happens in the inside is invisible to other parts of the system. Invisibility is good, you can't be wrong about something you do not know!
Except for OSGi, other modularity efforts seem to forget about this crucial encapsulation required for the next modularization step. The efforts I've seen so far focus on accessibility. The difference between accessibility and visibility is that accessibility requires a single name space. Where in OSGi each bundle (the module) has its own name space as we've done in the past when we took a modularization step, in other forms this aspect is ignored. All other proposals I've seen so far assume that there is a single name space for classes.
A single name space works well for small to medium systems. However, today we are building systems that consists of a large number of subsystems. Forcing a single name space on these large systems is in the long run asking for problems. The clearest example is if you have two subsystems that depend on different versions of a third subsystem than you're in trouble. Unless you build on OSGi.
Peter Kriens
Subscribe to:
Posts (Atom)