Tuesday, January 11, 2011

OSGi 4.3 Early Draft 3 now available

The latest draft spec from OSGi is now available for download. It contains the final RFCs for the changes to the Core 4.3 specifications. Also included are draft RFCs for some new specs for the next releases of the Compendium, Enterprise and Residential specifications.

Since this draft is just a draft, understand that things can change, even substantially, before the final specifications are completed.

Tuesday, December 07, 2010

The Pipes Are Calling

On the osgi-dev list, there was an interest raised into having a Planet OSGi feed aggregator like the Planet Eclipse and other similar planets.

So initially I looked into planet software I could run on the OSGi server. I found Planet 2.0 and Venus which is a fork or successor to Planet 2.0. Both of these are Python scripts which of course depend upon other python scripts. However I could get neither of them to work on the RHEL 4 based OSGi server. The runtests.py sanity test failed for each choice. The failures were different and are probably based upon the Python version on the RHEL 4 system and possibly some dependent python scripts I did not have installed. Given that RHN manages the OS including the Python version, I was not keen to attempt to update it to a later version of Python that I would have to manage myself. And so I gave up on the python scripts. I have the feeling that if these tools were written in Java (or some JVM based language) it would have been mush easier to get them to run on different machines since there is a uniform basic machine and libraries to depend upon.

In any case, I needed some other solution. Some more use of a popular search engine lead me to Yahoo Pipes. I was fairly easily able to create a "pipe" to collect a bunch of feeds, sort the feeds by publication date and generate a new feed of the aggregate! I had heard of Yahoo Pipes before but never played with them. They are pretty cool and it was quite easy to mash up a bunch of feeds into a new feed.

So checkout the new Planet OSGi feed served up by Yahoo Pipes.

Wednesday, September 16, 2009

OSGi 4.2 specs are now available!

After a lot of work on the part of the OSGi expert groups, the OSGi members have approved the Core and Compendium 4.2 specifications as final. You can download them here.

Work continues in the OSGi expert groups on the specifications for the enterprise spec.

Wednesday, May 20, 2009

Eclipse Galileo update site organization could be more useful

I saw Wayne's call for Mac users to try the Eclipse 3.5 RC1 Cocoa port. So being an Eclipse user and a Mac user, I thought I would give it a try out. I have been using 3.4 for my OSGi development work since it came out last June. I have updated to each point release and am 3.4.2 now. I started with the EPP for RCP developers since that very closely described what I needed to do. All that I needed to add to that was an svn team provider.

So I downloaded the 3.5 RC1 Cocoa driver, unzipped it and started it. But it was rather bare bones. I was missing the extra goodies from the RCP EPP download and, of course, an svn team provider. So I went to the Install New Software dialog and selected the Galileo site. But it took me quite some time to figure out what I needed to select to get back to the function I already had in my 3.4 install. It would have been much more useful to have the update organized like the EPPs. That is by the type of developer I am and the things I need to do. Then I could have found a grouping for RCP developer and installed all the things under that grouping. Since that was not there, I had to consult the 3.4 EPP pages to figure out what RCP EPP build added and then search for those things on the update site (as well as the subversive svn team providers sans svn connector :-( ).

So I think I have all the function I need installed, but it could have been much easier.

Tuesday, April 21, 2009

Java Posse interview on OSGi

At EclipseCon 2009, Peter Kriens and I were interviewed by the Java Posse about OSGi. The podcast of the interview is now available.

Tuesday, March 24, 2009

I am Visible but am I Accessible?

During the JSR 294 Expert Groupt meeting this Monday, we fell in to a long conversation about the distinction between visibility and accessibility in Java. This is an important distinction as we work on modularity for Java.

Visibility is whether one type can see another type. In the JLS, this is discussed as observability. In the JVMS, this is about class loading. Basically, this can be described as whether type T is visible to type S. At compile time, this means that the compiler can locate type T when compiling type S. At runtime, this means that the class loader for type S can load (either directly or through delegation) type T. A type can also be visible through reflection. Even if the class loader of type S cannot load type T, type S may come across type T while reflecting. For example, an object may be of type T even though type S directly refers to it via an interface type I.

Accessibility is whether one type can access another type or a member of another type. This is discussed in the JLS and the JVMS. Most people know accessibility by the public, protected, and private keywords. Also see AccessibleObject.

Visibility and accessibility interact, but they are discrete concepts that must be understood separately as we work on modularity for Java. First a type must be visible in order to use it. Then the type must be accessible or the interesting member of the type must be accessible. It is possible for a type to be visible but not accessible.

OSGi provides it modularity though restricting visibility. This makes sense since OSGi is built on the ClassLoader model. So if bundle A imports packages which are exported by bundle B, bundle A's class loader will not have visibility to any other package in bundle B. But if bundle B registers a service implemented by a type which is not visible to the class loader of bundle A, bundle A can still get the class object of the service (e.g. service.getClass()). If that class has public methods which are not part of the service interface, bundle A is able to call them.

Adding a module accessibility keyword to Java will allow the VM to enforce access control when access is attempted across a module boundary. So in the example above, if bundle A and B are in different modules (as to-be-defined by JSR 294) bundle A cannot access the module accessible member of the service implementation class from bundle B. This would give bundle authors more control and encapsulation.

The difficult part is to define the module boundary so the VM can enforce access and this is still an area of ongoing discussion in the JSR 294 EG. Related to this is also the desire to have Java compilers begin to understand module boundaries with respect to visibility and also the new module accessibility keyword. javac currently has a simplistic view of visibility: -classpath/-sourcepath. This has none of the restricted visibility of a current module system like OSGi. How to enable java compilers to have visibilty which better matches the runtime will be a major challenge.

[2013-10-14 - Updated links to fix link rot from Oracle acquisition of Sun.]

Tuesday, December 23, 2008

Presenting on OSGi at EclipseCon 2009

Well it looks like 2 of my session proposals were accepted by the EclipseCon 2009 program committee. So I will be doing a long talk on Symmetric Service Oriented Programming and short talk on Using BundleTracker to support the OSGi Extender Pattern. Looking forward to EclipseCon again. It is a great conference. Hope to see you there.

Tuesday, December 02, 2008

Another Early Draft of 4.2 from OSGi

The OSGi Alliance just announced the release of an updated Early Draft of new content for the OSGi Service Platform Release 4 Version 4.2 spec which is planned to be published in late 2Q2009.

Some of the designs in the draft are already being implemented in the Equinox 3.5 code stream. In fact, I already implemented RFC 126 Service Hooks there.

If some of my EclipseCon 2009 session proposals are accepted, I will present some of these new features there.

Saturday, November 22, 2008

Øredev and the Renaissance?

I am on my way home from Øredev 2008 where I presented on OSGi which seemed to have been well received by my kind audience.

This was an interesting conference for me (aside from the blizzard I walked into as I left the conference on Friday evening). Most of the conferences I attend are all Java (JavaOne, EclipseCon). This one had Java but also .Net and other things relevant to programmers. One area that got a bunch of focus was programming methodologies like Agile, Scrum, etc. I will confess to be not very familiar with their details but I think it is great that these things are discussed at conferences.

During the final session of the conference, a panel discussion which featured some of the bigger names of the conference, a lot of the discussion centered on these programming methodologies. The discussion included things like how they should be applied, whether one methodology was better than another or even whether one should rigorously follow a methodology or just pick the parts you like. The term Renaissance was used quite often (in fact it appeared in the titles of the daily keynotes) as if there was some renaissance in progress in the programming community. Perhaps people using these programming methodologies means a renaissance?

But what really started to bother me as I thought about it during this panel discussion, was that no one seemed to discuss any science behind these methods which prove their effectiveness and utility. Is there any scientific studies which demonstrate these methods really help? or hurt? That some are better than others? Perhaps we don't need so much of a renaissance as we need an enlightenment and apply some rational science to evaluating these different ideas instead of being dogmatic about them. If we programmers want to be professional, we need operate based upon science (like astronomers) and not pseudoscience (like astrologers).

One of the panelists quoted Bill and Ted and simply suggested we programmers Be Excellent! That is great advice for all things in life but not specifically helpful for programmers.

Thursday, May 08, 2008

Hot off the press: my JavaOne presentation

You can now download the JavaOne 2008 presentation Converting (Large) Applications to OSGi I just delivered with Peter Kriens.

The presentation went really well. There was around 700-800 people there and we had some really good questions asked during the 5 minutes we had left for questions. And then many more questions after we left the stage. I felt like a JavaOne Rock Star! :-)

Wednesday, May 07, 2008

An AJO is not a POJO

A POJO is a plain old Java object. Everyone talks POJOs these days. They are easy to compose and unit test. They are free of coupling to specific infrastructure details. So you can take your POJO to another infrastructure. For example, from JavaEE to Spring or OSGi. I like them and I think it is the right way to do things.

However, people are also fascinated with annotations now. Things like Guice and EJB3 and Glassfish all want you to annotate your POJO. But once you do that, your POJO ceases to be plain. While the non-annotation part of your code is still the same, the annotations in your code mean that your source now has coupling to specific infrastructure details and it is wrong to call is a POJO anymore. You can't compile your code without the proper support for those annotations. If you want to deploy your code in another infrastructure that uses annotations to describe the infrastructure details, you have to add more annotations to your source.

While I see the interest in putting the infrastructure information in the source near where it is used. We need to be honest. Your code is not a POJO anymore. It is now an AJO: an annotated Java object.

Thursday, March 27, 2008

Equinox and Google Summer of Code

An implementation of an OSGi resolver is a complex beast. Just ask Tom Watson, the Equinox dev lead :-) The Equinox p2 project, a new provisioning system for Eclipse, also has similar and complex resolve algorithm. Recently the p2 project, changed to use the SAT4J SAT solver to drive their resolve algorithm.

We have proposed a Google Summer of Code project for someone to investigate replacing the current Equinox runtime resolver with SAT4J (or another suitable constraint solver). So if this project sounds interesting to you, please sign up for it!

Tuesday, March 25, 2008

OSGi and eRCP on Mobile Phones

Sprint (a US mobile operator) has a new OSGi based mobile phone platform called Titan. There was a session at EclipseCon announcing this. But if you missed the session at EclipseCon and want to learn more, there is a webcast on Wednesday March 26 at 1pm EDT.

Sunday, March 23, 2008

Call for Speakers at 2008 OSGi Community Event

The OSGi Alliance is holding the 2008 OSGi Community Event June 10-11 in Berlin, Germany. The Call for Speakers was just issued. Please consider submitting a session proposal and attending the Community Event. I hope to see you there.

EclipseCon is over and a MacBook Pro for me!

Another great EclipseCon is over. The OSGi DevCon portion of EclipseCon had a great set of sessions this year. Kudos to Peter Kriens for another great job as OSGi DevCon program chair! This is the third year that OSGi has been featured at EclipseCon. The first year we spent a lot of time educating people on what OSGi was. The second year more people knew about OSGi but there was still more educating to do. This year was different. Everyone knew about OSGi. I kept overhearing people mention OSGi in conversations. There were many presentation not in the OSGi DevCon track of which OSGi was a topic. I am thrilled! Now the focus can move from teaching people about what OSGi is to how best to use OSGi. And the new Eclipse Runtime top-level project and Equinox portal are great news as well.

It was a long and busy trip for me. We had OSGi expert group meetings (hosted by Siemens in San Jose) the Thur/Fri before EclipseCon. Then we had four days of EclipseCon where I was involved in 5 presentations. Just to make things even more exciting, my trusty laptop decided to stop cooperating. It began to hang almost every time I closed it (during suspend). I don't know what the cause was. I can only imagine it was suffering from the entropy and decay that seems to happen to Windows systems over time. I defragged the hard disk, I deleted a boatload of programs. Nothing seemed to really help. And then just before my final presentation, it hung again and this time would not reboot. Fortunately, I had a copy of my charts on a USB flash drive and presented from that using a borrowed laptop. I was finally able to get the laptop booting again after running chkdsk for 2.5 hours in the airport between flights. But I have no idea if/when it will hang again (sigh).

During EclipseCon I could not help but notice how many people had MacBooks this year. I feel like almost half of the attendees did. (iPhone penetration was pretty deep too!). Peter Kriens got a MacBook recently as well. After watching him and Neil Bartlett use their MacBooks, I was very impressed with MacOS X. And then my own windows problems with my laptop pushed me over the edge. I just ordered a new 15" MacBook Pro. I almost feel guilty now for calling Peter an Apple fan boy... :-)

Wednesday, February 27, 2008

Speaking at JavaOne 2008

I will be presenting a session at JavaOne 2008 with Peter Kriens titled Converting (Large) Applications to OSGi.

Wednesday, January 02, 2008

Wednesday, September 19, 2007

Class.forName caches defined class in the initiating class loader

In my previous entry, I wrote about how how there is a difference in behavior between Class.forName and ClassLoader.loadClass. Since then I wrote a simple (for class loaders :-) test case to demonstrate the difference.

When calling ClassLoader.loadClass to load a class, the initiating class loader delegates to another class loader which actually defines the class. The defined class is only added to the defining class loader's cache. The cache of the initiating class loader's cache is not altered. So if the initiating class loader delegates to a different defining class loader on a future request for the class, the class is always returned from the defining class loader to which the delegation occurred. This is of course how the ContextFinder from Eclipse is intended to work. ContextFinder is the initiating class loader which uses context from the call stack to select the right bundle class loader to delegate the actual class load request.

However, if Class.forName is used to call the initiating class loader, the behavior with respect to caching and the returned class is quite different. In this case, when the class is first defined, it is cached by the defining class loader as expected. But it is also cached by the initiating class loader which is not expected. Even more unusual and unexpected is that Class.forName, through its native implementation, seems to consult the initiating class loader's cache directly before calling loadClass on the initiating class loader which is the normal place where the class loader's cache is consulted (via ClassLoader.findLoadedClass). As a result, all calls to Class.forName to a initiating class loader always return the same class object (the first one loaded), even if the implementation of the initiating class loader does not define classes or directly consult its own cache.

The test case also showed that ClassLoader.loadClass always works as expected even when interleaved with calls to Class.forName.

If every one always used ClassLoader.loadClass to consult the Thread Context Class Loader (TCCL), then a ContextFinder style TCCL choice would work very well in OSGi (or any similar module system) . However a lot of code uses Class.forName to consult the TCCL which means that a ContextFinder style TCCL is not going to help those callers.

The test case also includes a test to see whether having Class.forName add the class object to the initiating class loader's cache would result in pinning the class in the heap after the class and its defining class loader became garbage collected. This would also be a problem for OSGi since it would cause a ContextFinder style TCCL (which would have a lifetime of the framework) to potentially pin a bundle's class loader and all loaded classes in the heap. Fortunately, this was not an issue. The class object was removed from the initiating class loader's cache once the class and its defining class loader were garbage collected. So, interestingly enough, the reference to the class from the initiating class loader's cache must be a sort of weak reference which allows the class to be garbage collected.

This unexpected behavior of Class.forName does not seem to be documented or explained anywhere that I have located. If you know of any such documentation, please let me know! In any case, there is a problem in designing a useful TCCL solution for OSGi.

Thursday, July 19, 2007

Why do Class.forName and ClassLoader.loadClass behave different?

ClassLoader.loadClass or Class.forName seem to be synonyms for the same basic operation: request a dynamic class load. Yet calling Class.forName does additional "checking" which is not very useful (certainly in OSGi).

When doing a dynamic class load, the returned type has no implied type by the code. The code must use reflection to access static members or to create an instance. A created instance can either be reflected upon or cast to a type which must already implicitly know by the code. This cast will result in a runtime type check which will ensure type safety.

This is very different than an implicit class load done by the VM to resolve a class constant pool entry. Since it is the goal of these implicit class loads to avoid runtime type checks, the loader constraints are used to ensure type safety.

It does not seem necessary or reasonable to impose loader constraint checks on some dynamic class load requests. That is, code calling Class.forName (or ClassLoader.loadClass) and the VM resolving a class constant pool entry have different type safety needs. The former does not require loader constraint checks since that will be done at runtime by a type cast if needed. The latter does require loader constraint checks to avoid the need for runtime type checks.

So it does seem reasonable to have Class.forName behavior altered to avoid loader constraint checks. Only internal VM class load requests need to check loader constraints.

[2013-10-14 - Updated links to fix link rot from Oracle acquisition of Sun.]