After working with Java for almost 15 years and deep knowledge of Java generics on the class format level I learned something very basic the really, really hard way. I knew the collections in Java were not that good in comparison what you find in other environments (immutable anyone?) but now I learned that even adding all that extra cruft on my classes is useless when you have a major refactoring.
This week I learned that for the collections and maps the get, remove, containsKey, containsValue, and equals methods do not use the generic type parameter. This means you can call it with any type and you do not get an error if you call it with a type that is not compatible with the generic type of the collection.
I found this out when I changed many Map types to take another key type, expecting that Eclipse would nicely point me out what to change. Well it does not. The puts and parameter calls are nicely pointed out but a significant amount of code fails because it always fails because the object is now no longer found. Fortunately I am saved by having hundreds of solid test cases that tell me where to look.
I understand these methods were not generified because things became too hairy. Why that did not raise concerns about the power of the generics at the time beats me.
Well, guess I learned something.
Peter Kriens
OSGi Blog
Wednesday, January 11, 2012
Monday, January 2, 2012
Moving On
A bit more than 13 years ago I was asked to go to Linköping, Sweden to help out an Ericsson business unit to get the Java Embedded Server running on their e-box. This single appointment quickly cascaded into an almost full time job managing the OSGi specification process on behalf of Ericsson. In 2001 I switched to the OSGi Alliance to become the Technical Director and in that capacity the editor of the specifications. A hectic decade followed with too much travel, several economic booms and busts, various controversies, working with some really great people, and many rock solid specifications to show for it. When I look at my bookshelf I see a satisfying sight of two shelves with OSGi specifications and books. All said, it was a pretty good decade.
However, it is time to move on. Not because I feel OSGi is not the right answer, on the contrary. I think the OSGi service model is as important as structured programming and object orientation was in the previous decades to increase productivity in the software industry. The reason to leave is that I see a business opportunity in the gap between the mainstream Java developer and where OSGi is today. Working with the myriad of problems around modularity has given me a solid background to ease the transition of existing applications into more modular software. And after a decade of writing specifications creating real systems again looks pretty attractive.
I will stay on until after OSGi DevCon 2012 in Reston, Virginia at the end of March. During that time I will finish the upcoming Core and Enterprise specifications that are currently in the pipeline. After that, well, to find out you have to follow me on Twitter (@pkriens) ...
If you want to show your like what I've done in the OSGi then I would appreciate if you linked with me at LinkedIn and/or provide a recommendation.
Now back to work on my last two OSGi specifications.
Peter Kriens
However, it is time to move on. Not because I feel OSGi is not the right answer, on the contrary. I think the OSGi service model is as important as structured programming and object orientation was in the previous decades to increase productivity in the software industry. The reason to leave is that I see a business opportunity in the gap between the mainstream Java developer and where OSGi is today. Working with the myriad of problems around modularity has given me a solid background to ease the transition of existing applications into more modular software. And after a decade of writing specifications creating real systems again looks pretty attractive.
I will stay on until after OSGi DevCon 2012 in Reston, Virginia at the end of March. During that time I will finish the upcoming Core and Enterprise specifications that are currently in the pipeline. After that, well, to find out you have to follow me on Twitter (@pkriens) ...
If you want to show your like what I've done in the OSGi then I would appreciate if you linked with me at LinkedIn and/or provide a recommendation.
Now back to work on my last two OSGi specifications.
Peter Kriens
Monday, December 12, 2011
OSGi DevCon March 2012, Reston Virginia
After a slow start we suddenly got a lot and very good submissions for the OSGi DevCon 2012 in Reston Virgina. Though this made the life of the program committee harder (thanks to BJ Hargrave (IBM), Neil Bartlett (Paremus), David Bosschaert (JBoss), and Christer Larsson (Makewave)!) it resulted in a fabulous program. There is really no excuse for not visiting this premier OSGi conference in the US considering we're also throwing in a free registration for Agile Connected and EclipseCon which are co-located!
You can find all the submissions here: http://tinyurl.com/osgidevcon2012selections
There really is a lot of interesting stuff:
REGISTRATION FOR THE CONFERENCE IS NOW OPEN.
Registration for OSGi DevCon 2012 and EclipseCon 2012 is open and you should book by Dec 31, 2011 to secure the best price. Employees of OSGi Members are also entitled to an extra discount by using the coupon code: OSGI
If you come for the OSGi DevCon conference please do not forget to check that OSGi is of your interest during the registration since we found out this year that this is actually important for future OSGi DevCons.
Finally, don’t forget to make your hotel reservation too. The conference hotel room booking system for the Hyatt Regency Reston is also available; it is best to book early to secure your place.
Looking forward to seeing you in Reston in March next year!
OSGi DevCon Committee:
You can find all the submissions here: http://tinyurl.com/osgidevcon2012selections
There really is a lot of interesting stuff:
- Apache Felix Web Console - Web Based OSGi Framework Administration — The Apache Felix Web Console has been created out of a need to remotely administer an OSGi Framework. This administration includes maintenance of bundles, editing Configuration, and introspecting ...
- Best Practices for (Enterprise) OSGi applications — Since the first release of the OSGi Enterprise specification in March 2010 the use of OSGi in the enterprise has increased dramatically. Moving traditional Java EE applications to an OSGi stack is...
- Dynamic RIAs with Equinox and Vaadin — When you want to use OSGi on the server-side, there are only a few options when it comes to dynamic and modular UIs. Besides RAP (Rich Ajax Platform), Vaadin is another UI toolkit that integrates...
- Experiences from Building the Fastest OSGi Container on the Planet — What is the fastest OSGi container? Felix or...
- Liberate your components with OSGi services — Converting any large application to be OSGi based is a difficult and complex process. Many projects find the fences that OSGi put in place puts insurmountable barriers in the way of success. Many...
- Mastering OSGi with Ease — This tutorial is a compressed version of the renowned Masterclass on OSGi. Its goal is to take you into areas of OSGi that are extremely useful, but seldom discovered through independent...
- Micro Services in JavaScript — Although modularity concepts from OSGi might not map cleanly to programming languages other than Java, the ideas around OSGi Micro Services might be universally applicable. In this talk we will...
- Moving the Guidewire platform to OSGi — Guidewire Software builds advanced applications for the insurance industry. With over a hundred customers in a dozen countries, including global giants like AXA, Geico, and Tokyo Marine, our...
- OSGi in the cloud - quo vadis? — Modularity as in OSGi solves a major issue with architecting elastic applications for the cloud. Cloud resources are inherently dynamic in their nature and undergo frequent changes either due to...
- Smart Home Mashups: A New Application Opportunity — The number of smart devices in the home is exploding. These devices no longer just include TVs, Bluray players and game consoles. They now include door locks, thermostats, refrigerators, washer...em—
- What's new in the OSGi Enterprise Release 5.0 — The Enterprise OSGi Release 5.0 will be generally available at EclipseCon/OSGiCon 2012. A number of significant enhancements have been made since the previous release, ...
REGISTRATION FOR THE CONFERENCE IS NOW OPEN.
Registration for OSGi DevCon 2012 and EclipseCon 2012 is open and you should book by Dec 31, 2011 to secure the best price. Employees of OSGi Members are also entitled to an extra discount by using the coupon code: OSGI
If you come for the OSGi DevCon conference please do not forget to check that OSGi is of your interest during the registration since we found out this year that this is actually important for future OSGi DevCons.
Finally, don’t forget to make your hotel reservation too. The conference hotel room booking system for the Hyatt Regency Reston is also available; it is best to book early to secure your place.
Looking forward to seeing you in Reston in March next year!
OSGi DevCon Committee:
Peter Kriens(corrected 13/12/2011: left David out of the program committee list)
Mike Francis
Thursday, November 10, 2011
OSGi DevCon Subsmissions, You've Got Until Nov 18!
The submission system for OSGi DevCon was supposed to close tomorrow but as seems customary nowadays the submission time has been extended to serve all those people out there that did not have enough time ... So the deadline is now November 18!
We already have an interesting list of submissions but it would be nice to have a larger set. There are so many issues that seem to generate some controversy that I would expect more pundits. Some topics that seem to scream for the use of the wonderful soap box a presentation at OSGi DevCon is:
- Jigsaw versus OSGi
- Package imports versus Module dependencies
- Manifest first like PDE versus manifest as output like bndtools
- Subsystem versus bundles
- Inversion of Control versus Delegation of Control
- Semantic Versioning
- Relase models
- Extending type safety into the Module system
- Statics versus instances
- Services versus Central control
Of course we also want presentations about experiences (good or bad) or that show interesting products/frameworks based on OSGi.. There is always room and more than enough interest in these presentations.
So given this extra week, you no longer have an excuse not to submit a presentation. Looking at the issues that are currently playing, combined with the enthusiasm of the EclipseCon organization I expect this to become a very good OSGi DevCon/EclipseCon in 2012. You're surely do not want to miss this premier event to interact with the key players in the OSGi eco system.
You can submit here until Nov 18 2012: http://www.eclipsecon.org/2012/submissions-are-open
Hope to see many of you in Reston in March 2012.
Peter Kriens
Monday, October 24, 2011
What to Depend On
Why do we need modularity in the first place? Lets get rid of this extraneous layer and make life simpler as Erlang's Joe Armstrong argues. Then again, maybe not.
The reason we need modules is that Object Oriented (OO) technology is starting to fail us. OO gave us a tremendous boost in productivity for 25 years but it is running out of steam for today's systems and especially for statically typed languages like Java. The reason is simply too much coupling. Using a single class from a library drags in its whole transitive dependency, to run even a simple program we have to download the internet. The independent evolution of these dependencies tend to create nightmares like JAR hell. After assemblers, subroutines/functions, modules, classes, and packages it is time for the next paradigm in software! A paradigm that must explicitly address the problem of too much coupling in Java systems.
Jigsaw and JBoss A7 claim to provide the solution to the dependency pains of Java by providing modularity since modularity provides encapsulation; we all know that encapsulation can reduce coupling. But do they? Sure, they make it much simpler to assemble a large class path because it becomes largely self assembling. However, they do not fundamentally change the way the class path works today. That is, they actually only provide a more convenient way towards JAR hell (Personally, I prefer a slightly different destination).
Worse, the hallmark of modularity, encapsulation, is severely compromised by the Jigsaw/JBoss model and Java's best practices.Virtually all Java code has become contaminated with class loading hacks to fight coupling. Java interfaces provided us with a tool to make clean decoupled class diagrams but at the same time created the problem of instance coupling: how to get the instance that implements that interface. In Java, instance coupling is generally achieved with dynamic class loading hacks. Unfortunately, most of those patterns need to violate the module's boundaries to get access to the client and implementation classes.
Once you see this problem (and it is not obvious), the solution is rather clear: we need a concept to handle the interaction between modules, a contract. Just like a class can implement one or more interfaces (the type contract), a module should be able to provide one or more services (the module contract). A module should depend on the services it needs, not on the JAR that holds those implementations. Exactly like a type should depend on an interface and not on an implementation class.
How to specify the service contract? An interface? The granularity of an interface is too small in almost all of the most trivial cases. In general a contract describes a collaboration between multiple actors, defined in interfaces, abstract or base classes, permissions, utility functions, etc. Like Jigsaw, could we (ab)use the virtual module as the "interface" of a module? Nope. That model has no representation in the type system and is therefore fundamentally unsafe. It also is wrong to restrict a module to providing a single service; remember why interfaces were added to Java? Only because we had single inheritance and it was felt that the 1:1 relation was too constraining.
The logical choice in Java is obviously the package. A Java package is already the Java module: it provides encapsulation, a namespace, is part of the Java language, is part of the type system, it has a name, can easily be versioned, and it has the proper granularity for a contract. A module should provide a number of packages and depend on a number of packages that specify contracts between the modules. Just like methods provide the contract between classes. Since the dependencies are expressed in packages, modules can be substituted.
Anybody that doubts package imports/exports are a bad idea should consider that OSGi also supports the module-to-module dependency of Jigsaw/Maven/JBoss, it can even separate types. Since each OSGi user has the choice, why do you think that over time they use packages? Maybe because it works?
The need for package imports/exports is crystal clear when you really understand the violation of encapsulation caused by the interaction of the Jigsaw/JBoss programming model and popular Java patterns. Five years from now I might be able to say: "I told you so," but I still have hope that enough people will put in an effort to understand the looming problem to prevent another 5 years lost to the gains of true Java modularity.
Peter Kriens
The reason we need modules is that Object Oriented (OO) technology is starting to fail us. OO gave us a tremendous boost in productivity for 25 years but it is running out of steam for today's systems and especially for statically typed languages like Java. The reason is simply too much coupling. Using a single class from a library drags in its whole transitive dependency, to run even a simple program we have to download the internet. The independent evolution of these dependencies tend to create nightmares like JAR hell. After assemblers, subroutines/functions, modules, classes, and packages it is time for the next paradigm in software! A paradigm that must explicitly address the problem of too much coupling in Java systems.
Jigsaw and JBoss A7 claim to provide the solution to the dependency pains of Java by providing modularity since modularity provides encapsulation; we all know that encapsulation can reduce coupling. But do they? Sure, they make it much simpler to assemble a large class path because it becomes largely self assembling. However, they do not fundamentally change the way the class path works today. That is, they actually only provide a more convenient way towards JAR hell (Personally, I prefer a slightly different destination).
Worse, the hallmark of modularity, encapsulation, is severely compromised by the Jigsaw/JBoss model and Java's best practices.Virtually all Java code has become contaminated with class loading hacks to fight coupling. Java interfaces provided us with a tool to make clean decoupled class diagrams but at the same time created the problem of instance coupling: how to get the instance that implements that interface. In Java, instance coupling is generally achieved with dynamic class loading hacks. Unfortunately, most of those patterns need to violate the module's boundaries to get access to the client and implementation classes.
Once you see this problem (and it is not obvious), the solution is rather clear: we need a concept to handle the interaction between modules, a contract. Just like a class can implement one or more interfaces (the type contract), a module should be able to provide one or more services (the module contract). A module should depend on the services it needs, not on the JAR that holds those implementations. Exactly like a type should depend on an interface and not on an implementation class.
How to specify the service contract? An interface? The granularity of an interface is too small in almost all of the most trivial cases. In general a contract describes a collaboration between multiple actors, defined in interfaces, abstract or base classes, permissions, utility functions, etc. Like Jigsaw, could we (ab)use the virtual module as the "interface" of a module? Nope. That model has no representation in the type system and is therefore fundamentally unsafe. It also is wrong to restrict a module to providing a single service; remember why interfaces were added to Java? Only because we had single inheritance and it was felt that the 1:1 relation was too constraining.
The logical choice in Java is obviously the package. A Java package is already the Java module: it provides encapsulation, a namespace, is part of the Java language, is part of the type system, it has a name, can easily be versioned, and it has the proper granularity for a contract. A module should provide a number of packages and depend on a number of packages that specify contracts between the modules. Just like methods provide the contract between classes. Since the dependencies are expressed in packages, modules can be substituted.
Anybody that doubts package imports/exports are a bad idea should consider that OSGi also supports the module-to-module dependency of Jigsaw/Maven/JBoss, it can even separate types. Since each OSGi user has the choice, why do you think that over time they use packages? Maybe because it works?
The need for package imports/exports is crystal clear when you really understand the violation of encapsulation caused by the interaction of the Jigsaw/JBoss programming model and popular Java patterns. Five years from now I might be able to say: "I told you so," but I still have hope that enough people will put in an effort to understand the looming problem to prevent another 5 years lost to the gains of true Java modularity.
Peter Kriens
Saturday, October 15, 2011
Another bndtools Hackathon
The house feels rather silent after 4 days of intense hacking on bndtools with PK Sörelde, Neil Bartlett, Joakim, Stuart McCulloch, David Savage (remote from the UK), and Ferry Huberts here in my house. We closed a lot of bugs and we (well almost) reached our goal to run bndtools on the OSGi build faster than anything else. Then again, maybe I should say we reached our goal since Neil just informed me with Skype from an English bus that he was now really close.
Neil Bartlett started already quite some time ago to create the ultimate OSGi IDE based on Eclipse. Since he was using bnd to do the low level building I convinced him to also use the more advanced build features in bnd, which resulted in a fruitful collaboration. This brought ComActivity into the game. A couple of years ago they hired me as a consultant to help them with their OSGi work. At that time we used bnd as an Eclipse plugin to do the build. Last year they switched to bndtools since it has a much more extensive GUI. PK Sörelde from ComActivity even contributed the version release management tool. With over an increasing number of listeners on the bndtools list we were getting in an area that bndtools needed to become rock solid stable so it could be used by more people. Two weeks ago PK proposed to do an intense round of finalizing open issues and I gladly offered my house.
We also had Stuart McCulloch from Sonatype here to help us out with maven. Since maven is quite popular as an OSGi build tool with the maven bundle plugin, which is based on bnd, collaborating is quite natural. Initially we wanted to do the complete build in bndtools but after brainstorming we found out that we could use the m2-eclipse plugin quite elegantly for building, leaving the bundle development (coding, manifest, debugging, etc) to bndtools. Using m2-eclipse will give us full fidelity with the offline and IDE build.
The coming week we will test the heck out of bnd and bndtools and hope to release a rock solid fast new version next week.
So lots of bugs closed, lots of fun (the weather was fantastic!), interesting discussions, good food, lots of plans, and a very nice result.
Peter Kriens
Neil Bartlett started already quite some time ago to create the ultimate OSGi IDE based on Eclipse. Since he was using bnd to do the low level building I convinced him to also use the more advanced build features in bnd, which resulted in a fruitful collaboration. This brought ComActivity into the game. A couple of years ago they hired me as a consultant to help them with their OSGi work. At that time we used bnd as an Eclipse plugin to do the build. Last year they switched to bndtools since it has a much more extensive GUI. PK Sörelde from ComActivity even contributed the version release management tool. With over an increasing number of listeners on the bndtools list we were getting in an area that bndtools needed to become rock solid stable so it could be used by more people. Two weeks ago PK proposed to do an intense round of finalizing open issues and I gladly offered my house.
We also had Stuart McCulloch from Sonatype here to help us out with maven. Since maven is quite popular as an OSGi build tool with the maven bundle plugin, which is based on bnd, collaborating is quite natural. Initially we wanted to do the complete build in bndtools but after brainstorming we found out that we could use the m2-eclipse plugin quite elegantly for building, leaving the bundle development (coding, manifest, debugging, etc) to bndtools. Using m2-eclipse will give us full fidelity with the offline and IDE build.
The coming week we will test the heck out of bnd and bndtools and hope to release a rock solid fast new version next week.
So lots of bugs closed, lots of fun (the weather was fantastic!), interesting discussions, good food, lots of plans, and a very nice result.
Peter Kriens
Monday, October 10, 2011
American Pie
"Steve Jobs died," someone yelled in the San Francisco Hilton lobby. First a wave of sadness descended upon me and then I got angry at myself for giving in to celebritis. Yes, he is a big part part of the tools I use daily to get my work done and he is part of the many Apple gadgets around the house as well as much of their content, as so many people today. And it is likely he will sorely be missed in the coming years for not providing his constant stream of innovations. Every death is sad because something is lost forever but the death of a well known figure should not feel like someone close to you died. So why was it so hard to shake of this sadness?
There is of course the identification: Steve Jobs was only 3 years older, he worked in the same industry, and in moments of grandeur I have envisioned myself as a Steve Jobs if only I had been born a bit earlier and in the US instead of Rotterdam. When someone that plays such a role for you his death confronts you with your own mortality. So was this sadness only caused by a rather solipsistic fear of death?
I guess there was his constant presence through my career. When I soldered my first computer, he made the Apple II. When I designed our newspaper page make-up terminal in the eighties we got inspired by Smalltalk and Steve Jobs was inspired by the Alto, both closely related results from Xerox' PARC Place. Also Postscript, another result of PARC Place, was a shared inspiration though admittedly Apple made it viable with their LaserWriter. Around 1985 I developed an object oriented language called CO2. I had been inspired by Brad Cox, the inventor of Objective-C. So when Steve Jobs came up with the NeXT, largely based on Objective-C, I had to get one. A mind blowing experience only numbed by the excruciatingly slow optical drive.
So maybe the reason for the sadness was not egocentric but more the loss of the rare someone that shared the same enthusiasm for the combination of computers and esthetics. Someone that struggled with the same problems (though he admittedly much more successful than I ever did) in the eighties. Maybe the sadness is caused by losing the subject of a my rather rare envy. Though I share his focus on tomorrow but I do lack his ruthlessness and risk taking nature that is required for great products. His gusto to break backward compatibility only so that tomorrow's product could become better than anything else. I unfortunately tend to cave in because the others really seem desperate to want to have that feature ...
Of course I can rationalize that the almost absolute powers granted to a Steve Jobs are an anomaly and that in general we have to balance the interest of different parties. The route I've taken in my life is to find a better way to develop software, software based on collaboration and open environments like the OSGi Alliance. In such an environment compromises are inevitable but maybe the sadness is caused because Steve Jobs' death shines such a harsh light on all the compromises I agreed to only for backward compatibility and special interests.
And maybe one should not analyze those feelings to deeply and just accept the sadness, it will pass. And maybe after all it is just celebritis; for someone with very few heroes I guess am just not used to it.
Peter Kriens
There is of course the identification: Steve Jobs was only 3 years older, he worked in the same industry, and in moments of grandeur I have envisioned myself as a Steve Jobs if only I had been born a bit earlier and in the US instead of Rotterdam. When someone that plays such a role for you his death confronts you with your own mortality. So was this sadness only caused by a rather solipsistic fear of death?
I guess there was his constant presence through my career. When I soldered my first computer, he made the Apple II. When I designed our newspaper page make-up terminal in the eighties we got inspired by Smalltalk and Steve Jobs was inspired by the Alto, both closely related results from Xerox' PARC Place. Also Postscript, another result of PARC Place, was a shared inspiration though admittedly Apple made it viable with their LaserWriter. Around 1985 I developed an object oriented language called CO2. I had been inspired by Brad Cox, the inventor of Objective-C. So when Steve Jobs came up with the NeXT, largely based on Objective-C, I had to get one. A mind blowing experience only numbed by the excruciatingly slow optical drive.
So maybe the reason for the sadness was not egocentric but more the loss of the rare someone that shared the same enthusiasm for the combination of computers and esthetics. Someone that struggled with the same problems (though he admittedly much more successful than I ever did) in the eighties. Maybe the sadness is caused by losing the subject of a my rather rare envy. Though I share his focus on tomorrow but I do lack his ruthlessness and risk taking nature that is required for great products. His gusto to break backward compatibility only so that tomorrow's product could become better than anything else. I unfortunately tend to cave in because the others really seem desperate to want to have that feature ...
Of course I can rationalize that the almost absolute powers granted to a Steve Jobs are an anomaly and that in general we have to balance the interest of different parties. The route I've taken in my life is to find a better way to develop software, software based on collaboration and open environments like the OSGi Alliance. In such an environment compromises are inevitable but maybe the sadness is caused because Steve Jobs' death shines such a harsh light on all the compromises I agreed to only for backward compatibility and special interests.
And maybe one should not analyze those feelings to deeply and just accept the sadness, it will pass. And maybe after all it is just celebritis; for someone with very few heroes I guess am just not used to it.
Peter Kriens
Subscribe to:
Posts (Atom)