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.
Wednesday, May 20, 2009
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.
Thursday, March 26, 2009
EclipseCon 2009 Presentations for download
I have uploaded PDFs of my EclipseCon 2009 presentations.
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)
