tag:blogger.com,1999:blog-188343852024-03-08T16:25:59.617-05:00The Programming DelusionDelusional thoughts on Java, OSGi, Eclipse and other thingsBJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.comBlogger36125tag:blogger.com,1999:blog-18834385.post-27732221660578589422019-10-17T17:26:00.001-04:002019-10-17T17:26:16.069-04:00A Tool for Jakarta EE Package Renaming in BinariesIn a <a href="https://blog.hargrave.io/2019/05/jakarta-ee-and-package-renaming.html">previous post</a>, I laid out my thinking on how to approach the package renaming problem which the Jakarta EE community now faces. Regardless of whether the community chooses big bang or incremental, there are still existing artifacts in the world using the Java EE package names that the community will need to use together with the new Jakarta EE package names.<br />
<br />
Tools are always important to take the drudgery away from developers. So I have put together a <a href="https://github.com/bjhargrave/transformer">tool</a> prototype which can be used to transform binaries such as individual class files and complete JARs and WARs to rename uses of the Java EE package names to their new Jakarta EE package names.<br />
<br />
The tools is rule driven which is nice since the Jakarta EE community still needs to define the actual package renames for Jakarta EE 9. The rules also allow the users to control which class files in a JAR/WAR are transformed. Different users may want different rules depending upon their specific needs. And the tool can be used for any package renaming challenge, not just the specific Jakarta EE package renames.<br />
<br />
The tools provides an API allowing it to be embedded in a runtime to dynamically <a href="https://github.com/bjhargrave/transformer/blob/5b2ba77f4647cce275567219e4e97cd7b41ef0b1/src/main/java/dev/hargrave/transformer/Transformer.java#L231">transform class files</a> during the class loader definition process. The API also supports <a href="https://github.com/bjhargrave/transformer/blob/5b2ba77f4647cce275567219e4e97cd7b41ef0b1/src/main/java/dev/hargrave/transformer/Transformer.java#L158">transforming JAR files</a>. A <a href="https://github.com/bjhargrave/transformer#command-line">CLI</a> is also provided to allow use from the command line. Ultimately, the tool can be packaged as Gradle and Maven plugins to incorporate in a broader tool chain.<br />
<br />
Given that the tool is prototype, and there is much work to be done in the Jakarta EE community regarding the package renames, I have started a <a href="https://github.com/bjhargrave/transformer/labels/enhancement">list of TODOs</a> in the project' issues for known work items.<br />
<br />
Please try out the tool and let me know what you think. I am hoping that tooling such as this will ease the community cost of dealing with the package renames in Jakarta EE.<br />
<br />
PS. Package renaming in source code is also something the community will need to deal with. But most IDEs are pretty good at this sort of thing, so I think there is probably sufficient tooling in existence for handling the package renames in source code.BJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-13879390041165181082019-05-17T13:11:00.000-04:002019-05-17T13:11:18.591-04:00I am an Incrementalist: Jakarta EE and package renaming<br />
<div class="MsoNormal">
Eclipse Jakarta EE has been placed in the position that it
may not evolve the enterprise APIs under their existing package names. That is,
the package names starting with <span style="font-family: "courier new" , "courier" , monospace;">java</span> or <span style="font-family: "courier new" , "courier" , monospace;">javax</span>. See <a href="https://blogs.eclipse.org/post/mike-milinkovich/update-jakarta-ee-rights-java-trademarks">Update on Jakarta EE Rights to Java Trademarks</a>
for the background on how we arrived at this state.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So this means that after Jakarta EE 8 (which is API
identical to Java EE 8 from which it descends), whenever an API in Jakarta EE
is to be updated for a new specification version, the package names used by the
API must be renamed away from <span style="font-family: "courier new" , "courier" , monospace;">java</span> or <span style="font-family: "courier new" , "courier" , monospace;">javax</span>. (Note: some other things will
also need to be renamed such as system property names, property file names, and
XML schema namespaces if those things start with <span style="font-family: "courier new" , "courier" , monospace;">java</span> or <span style="font-family: "courier new" , "courier" , monospace;">javax</span>. For
example, the property file <span style="font-family: "courier new" , "courier" , monospace;">META-INF/services/javax.persistence.PersistenceProvider</span>.)
But this also means that if an API does not need to be changed, then it is free
to remain in its current package names. Only a change to the signature of a
package, that is, adding or removing types in the package or adding or removing
members in the existing types in the package, will require a name change to the
package. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
There has been much discussion on the Jakarta EE mail lists
and in blogs about what to do given the above constraint and David Blevins has kindly
summed up the two main choices being discussed by the Jakarta EE Specification
Committee: <a href="https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html">https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html</a>.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
In a nutshell, the two main choices are (1) “Big Bang” and
(2) Incremental. Big Bang says: Let’s rename all the packages in all the
Jakarta EE specifications all at once for the Jakarta EE release after Jakarta
EE 8. Incremental says: Let’s rename packages only when necessary such as when,
in the normal course of specification innovation, a Jakarta EE specification
project wants to update its API.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I would like to argue that Jakarta EE should chose the
Incremental option.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Big Bang has no technical value and large, up-front
community costs.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The names of the packages are of little technical value in
and of themselves. They just need to be unique and descriptive to programmers.
In source code, developers almost never see the package names. They are generally
in <span style="font-family: "courier new" , "courier" , monospace;">import</span> statements at the top of the source file and most IDEs kindly
collapse the view of the import statements so they are not “in the way” of the
developer. So, a developer will generally not really know or care if the
Jakarta EE API being used in the source code is a mix of package names starting
with <span style="font-family: "courier new" , "courier" , monospace;">java</span> or <span style="font-family: "courier new" , "courier" , monospace;">javax</span>, unchanged since Jakarta EE 8, and updated API with
package names starting with <span style="font-family: "courier new" , "courier" , monospace;">jakarta</span>. That is, there is little mental cost to
such a mixture. The Jakarta EE 8 API are already spread across many, many
package names and developers can easily deal with this. That some will start
with <span style="font-family: "courier new" , "courier" , monospace;">java</span> or <span style="font-family: "courier new" , "courier" , monospace;">javax</span> and some with <span style="font-family: "courier new" , "courier" , monospace;">jakarta</span> is largely irrelevant to a
developer. The developer mostly works with type and member names which are not
subject to the package rename problem.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
But once source code is compiled into class files, packaged
into artifacts, and distributed to repositories, the package names are baked in
to the artifacts and play an important role in interoperation between artifacts:
binary compatibility. Modern Java applications generally include many 3<sup>rd</sup>
party open source artifacts from public repositories such as Maven Central and
there are many such artifacts in Maven Central which use the current package
names. If Jakarta EE 9 were to rename all packages, then the corpus of existing
artifacts is no longer usable in Jakarta EE 9 and later. At least not without
some technical “magic” in builds, deployments, and/or runtimes to attempt to
rename package references on-the-fly. Such magic may be incomplete and will
break jar signatures and will complicate builds and tool chains. It will not be
transparent.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Jakarta EE must minimize the inflection point/blast radius on
the Java community caused by the undesired constraint to rename packages if
they are changed. The larger the inflection point, the more reason you give to
developers to consider alternatives to Jakarta EE and to Java in general. The
Incremental approach minimizes the inflection point providing an evolutionary
approach to the package naming changes rather than the revolutionary approach
of the Big Bang.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Some Jakarta EE specification may never be updated. They
have long been stable in the Java EE world and will likely remain so in Jakarta
EE. So why rename their packages? The Big Bang proposal even recognizes this by
indicating that some specification will be “frozen” in their current package
names. But, of course, there is the possibility that one day, Jakarta EE will
want to update a frozen specification. And then the package names will need to
be changed. The Incremental approach takes this approach to all Jakarta EE
specifications. Only rename packages when absolutely necessary to minimize the
impact on the Java community.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Renaming packages incrementally, as needed, does not reduce
the freedom of action for Jakarta EE to innovate. It is just a necessary part
of the first innovation of a Jakarta EE specification.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
A Big Bang approach does not remove the need to run existing
applications on earlier platform versions.<span style="mso-spacerun: yes;">
</span>It increases the burden on customers since they must update all parts of
their application for the complete package renaming when the need to access a
new innovation in a single updated Jakarta EE specification when none of the
other Jakarta EE specifications they use have any new innovations. Just package
renames for no technical reason.<span style="mso-spacerun: yes;"> </span>It also
puts a large burden on all application server vendors. Rather than having to
update parts of their implementations to support the package name changes of a
Jakarta EE specification when the specification is updated for some new
innovation, they must spend a lot of resources to support both old and new
packages name for the implementations of all Jakarta EE specifications.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
There are some arguments in favor of a Big Bang approach. It
“gets the job done” once and for all and for new specifications and
implementations the old <span style="font-family: "courier new" , "courier" , monospace;">java</span> or <span style="font-family: "courier new" , "courier" , monospace;">javax</span> package names will fade from
collective memories. In addition, the requirement to use a certified Java SE implementation
licensed by Oracle to claim compliance with Eclipse Jakarta EE evaporates once there
are no longer any <span style="font-family: "courier new" , "courier" , monospace;">java</span> or <span style="font-family: "courier new" , "courier" , monospace;">javax</span> package names in a Jakarta EE specification.
However, these arguments do not seem sufficient motivation to disrupt the
ability of all existing applications to run on a future Jakarta EE 9 platform.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
In general, lazy evaluation is a good strategy in
programming. Don’t do a thing until the thing needs to be done. We should apply
that strategy in Jakarta EE to package renaming and take the Incremental approach.
Finally, I am reminded of Æsop’s fable, <a href="http://www.read.gov/aesop/025.html">The Tortoise & the Hare</a>. “The
race is not always to the swift.”</div>
<div class="MsoNormal">
<br /></div>
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:0;
mso-generic-font-family:roman;
mso-font-pitch:variable;
mso-font-signature:-536870145 1107305727 0 0 415 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-536858881 -1073732485 9 0 511 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
mso-themecolor:hyperlink;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-noshow:yes;
mso-style-priority:99;
color:#954F72;
mso-themecolor:followedhyperlink;
text-decoration:underline;
text-underline:single;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.WordSection1
{page:WordSection1;}
-->
</style>BJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-806964650536797702014-04-04T14:51:00.000-04:002014-08-06T13:14:07.265-04:00Java 8, bnd and references to compile-time constantsJava 8 was recently released and I wanted to test it out with the OSGi build. I installed JDK 8 on my Mac, pointed <span style="font-family: "Courier New",Courier,monospace;">JAVA_HOME</span> at it and started a clean build of OSGi. After the build completed, I ran the Core Compliance Tests to verify the build. Unfortunately several of the tests were now failing.<br />
<br />
In order to diagnose the issue, I compared it to the same build built with JDK 7. The JDK 7 build passed all the tests running under JDK 7 or JDK 8. The JDK 8 build failed the same tests running under JDK 7 or JDK 8. So the issue was in the building with JDK 8 not the running under JDK 8. The failure was that one of the test bundles was failing to resolve. This was caused by an import for a package that was not exported by any bundle. When building with JDK 8, <a href="https://github.com/bndtools/bnd">bnd</a> added a package to the test bundle's <span style="font-family: "Courier New",Courier,monospace;">Import-Package</span> statement that is not present in the <span style="font-family: "Courier New",Courier,monospace;">Import-Package</span> statement when building with JDK 7.<br />
<br />
Digging further into the test bundle, the only reference to that package was to a <span style="font-family: "Courier New",Courier,monospace;">static final String</span> constant. During compilation, javac must copy the referenced string into the compiled class since the <a href="http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.12.4">final String</a> is a compile-time constant and thus the referenced field is not <a href="http://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.1-110-C">referenced at runtime</a>.<br />
<br />
So in the example code:<br />
<blockquote class="tr_bq">
public class Referencer {<br />
public static void main(String[] args) {<br />
System.out.println(Constant.hello);<br />
}<br />
}<br />
class Constant {<br />
static final String hello = "Hello, World!";<br />
} </blockquote>
the class file for Referencer has its own copy of the string "Hello, World!" and does not access Constant at runtime to obtain the string to print it out. In fact, the Referencer class file compiled by JDK 7 has no references to Constant.<br />
<br />
But when compiling with JDK 8, javac adds a <a href="http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4.1">constant pool entry for the class</a> holding the referenced constant even though this class it not reference at runtime by the compiled class. So for the example above, the Referencer class file now has a constant pool entry for the Constant class.<br />
<br />
During the building of a bundle, bnd analyzes the class files in the bundle to find class references to generate the necessary <span style="font-family: "Courier New",Courier,monospace;">Import-Package</span> statement. So the presence of this new constant pool entry for the constant holding class caused bnd to add the package of that class to the <span style="font-family: "Courier New",Courier,monospace;">Import-Package</span> statement. bnd assumed that all class entries in the constant pool were runtime references.<br />
<br />
An email conversation with <a href="https://blogs.oracle.com/abuckley/">Alex Buckley</a>, JLS spec lead, confirmed that this new behavior for javac in JDK 8 is intentional. javac is now adding compile-time dependencies to the constant pool to support compile-time dependency analysis using class files.<br />
<br />
This means that bnd's assumption that all class entries in the constant pool were runtime references is no longer valid for classes compiled by JDK 8. So <a href="https://github.com/pkriens">Peter Kriens</a> is making fixes to bnd for the 2.3 release to do deeper analysis so only runtime references to classes will result in their packages being added to the <span style="font-family: "Courier New",Courier,monospace;">Import-Package</span> statement. Compile-time only dependencies wont result in their packages being added to the <span style="font-family: "Courier New",Courier,monospace;">Import-Package</span> statement. So stay tuned for bnd 2.3 if you plan on using JDK 8 to build your bundles.<br />
<br />
This also means that anyone doing bytecode analysis for runtime dependencies of class files needs to be aware that the constant pool can now also contain compile-time only dependencies.BJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.com3tag:blogger.com,1999:blog-18834385.post-46424431678070489352013-10-14T17:17:00.000-04:002013-10-14T17:17:46.600-04:00API Design Practices That Work Well With OSGi<h4>
Introduction</h4>
This post describes some API design practices that should be applied when designing Java API to ensure the API can be used properly in an OSGi environment. Some of the practices are prescriptive and some are proscriptive. And, of course, other good API design practices also apply.<br />
<br />
The OSGi environment provides a modular runtime using the Java class loader concept to enforce type visibility encapsulation. Each module will have its own class loader which will be <i>wired</i> to the class loaders of other modules to share exported packages and consume imported packages.<br />
<br />
A package can contain an API. There are two <i>roles</i> of clients for these API packages: <i>API consumers</i> and <i>API providers</i>. API consumers use the API which is implemented by an API provider.<br />
<br />
In the following design practices, we are discussing the public portions of a package. The members and types of a package which are not public or protected (that is, private or default accessible) are not visible outside of the package and are implementation details of the package. <br />
<h4>
Packages must be a cohesive, stable unit</h4>
A Java package must be designed to ensure that it is a <i>cohesive</i> and <i>stable</i> unit. In OSGi, the package is the shared entity between modules. One module may export a package that another module can import. Because the package is the unit of sharing between modules, a package must be cohesive in that all the types in the package must be related to the specific purpose of the package. Grab bag packages like <span style="font-family: "Courier New",Courier,monospace;">java.util</span> are discouraged because the types in such a package often have no relation to each other. Such non-cohesive packages can result in lots of dependencies as the unrelated parts of the package reference other unrelated packages and changes to one aspect of the package impacts all modules that depend on the package even though a module may not actually use the part of the package which was modified.<br />
<br />
Since the package is the unit is sharing, its contents must be well known and the contained API only subject to change in compatible ways as the package evolves in future versions. This means a package must not support API supersets or subsets; for example, see <span style="font-family: "Courier New",Courier,monospace;">javax.transaction</span> as a package whose contents are very unstable. The user of a package must be able to know what types are available in the package. This also means that packages should be delivered by a single entity (for example, a jar file) and not split across multiple entities since the user of the package must know that the entire package is present.<br />
<br />
Finally, the package must evolve in a compatible way over future versions. So a package should be versioned and its version number must evolve according to the rules for <a href="http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf">semantic versioning</a>.<br />
<h4>
Minimize package coupling</h4>
The types in a package can refer to the types in other packages. For example, the parameter types and return type of a method and the type of a field. This inter-package coupling creates what are called <i>uses</i> constraints on the package. This means that an API consumer must use the same referenced packages as the API provider in order for them to both understand the referenced types.<br />
<br />
In general, we want to minimize this package coupling to minimize the uses constraints on a package. This simplifies wiring resolution in the OSGi environment and minimizes dependency fan-out simplifying deployment.<br />
<h4>
Interfaces preferred over classes</h4>
For an API, interfaces are preferred over classes. This is a fairly common API design practice that is also important for OSGi. The use of interfaces allow implementation freedom as well as multiple implementations. Interfaces are important to decouple the API consumer from the API provider. It allows a package containing the API interfaces to be used by both the API provider who implements the interfaces and the API consumer who call methods on the interfaces. In this way, API consumers have no direct dependencies on an API provider. They both only depend upon the API package.<br />
<br />
Abstract classes are sometimes a valid design choice instead of interfaces, but generally interfaces are the first choice.<br />
<br />
Finally, an API will often need a number of small of concrete classes such as event types and exception types. This is fine but the types should generally be immutable and not intended for subclassing by API consumers.<br />
<h4>
Avoid statics</h4>
Statics should be avoided in an API. Types should not have static members. Static factories should be avoided. Instance creation should be decoupled from the API. For example, API consumers should receive object instances of API types through dependency injection or an object registry like the OSGi service registry.<br />
<br />
The avoidance of statics is also good practice for making testable API since statics cannot be easily mocked.<br />
<h4>
Singletons</h4>
Sometimes there are singleton objects in an API design. However access to the singleton object should not be through statics like a static <span style="font-family: "Courier New",Courier,monospace;">getInstance</span> method or static field. When a singleton object is necessary, the object should be defined by the API as a singleton and provided to API consumers through dependency injection or an object registry as mentioned above.<br />
<h4>
Avoid class loader assumptions</h4>
APIs often have extensibility mechanisms where the API consumer can supply the name of a class the API provider must load. The API provider must then use <span style="font-family: "Courier New",Courier,monospace;">Class.forName</span> (possibly using the thread context class loader) to load the class. This sort of mechanism assumes class visibility from the API provider (or thread context class loader) to the API consumer. API designs must avoid class loader assumptions. One of the main points of modularity is type encapsulation. One module (for example, API provider) must not have visibility to the implementation details of another module (for example, API consumer).<br />
<br />
API designs must avoid passing class names between the API consumer and API provider and must avoid assumptions regarding the class loader hierarchy and type visibility. To provide an extensibility model, an API design should have the API consumer pass class objects, or better yet, instance objects to the API provider. This can be done through a method in the API or through an object registry such as the OSGi service registry. See the <a href="http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf">whiteboard pattern</a>.<br />
<br />
The <span style="font-family: "Courier New",Courier,monospace;">java.util.ServiceLoader</span> class also suffers from class loader assumptions in that it assumes all the providers are visible from the thread context class loader or the supplied class loader. This assumption is generally not true in a modular environment.<br />
<h4>
Don't assume permanence</h4>
Many API designs assume only a construction phase where objects are instantiated and added to the API but ignore the destruction phase which can happen in a dynamic system. API designs should consider that object can come and they can go. For example, most listener APIs allow for listeners to be added and removed. But many API designs only assume objects are added and never removed. For example, many dependency injection systems have no means to withdraw an injected object.<br />
<br />
In a modular system, modules can be added and removed, so an API design that can accommodate such dynamics is important. The OSGi Declarative Services specification defines a dependency injection model for OSGi which supports these dynamics including the withdrawal of injected objects.<br />
<h4>
Clearly document type roles for API consumers and API providers</h4>
As mentioned in the introduction, there are two roles for clients of an API package: API consumers and API providers. API consumers use the API and API providers implement the API. For the interface (and abstract class) types in an API, it is important that the API design clearly document which of those types are only to be implemented by API providers vs. those types which can be implemented by API consumers. For example, listener interfaces are generally implemented by API consumers and instances passed to API providers.<br />
<br />
API providers are sensitive to changes in types implemented by both API consumers and API providers. The provider must implement any new changes in API provider types and must understand and likely invoke any new changes in API consumer types. An API consumer can generally ignore (compatible) changes in API provider type unless it wants to change to invoke the new function. But an API consumer is sensitive to changes in API consumer types and will probably need modification to implement the new function. For example, in the <span style="font-family: "Courier New",Courier,monospace;">javax.servlet</span> package, the <span style="font-family: "Courier New",Courier,monospace;">ServletContext</span> type is implemented by API providers such as a servlet container. Adding a new method to <span style="font-family: "Courier New",Courier,monospace;">ServletContext</span> will require all API providers to be updated to implement the new method but API consumers do not have to change unless they wish to call the new method. However, the <span style="font-family: "Courier New",Courier,monospace;">Servlet</span> type is implemented by API consumers and adding a new method to <span style="font-family: "Courier New",Courier,monospace;">Servlet</span> will require all API consumers to be modified to implement the new method and will also require all API providers to be modified to utilize the new method. Thus the <span style="font-family: "Courier New",Courier,monospace;">ServletContext</span> type has an API provider role and the <span style="font-family: "Courier New",Courier,monospace;">Servlet</span> type has an API consumer role.<br />
<br />
Since there are generally many API consumer and few API providers, API evolution must be very careful when considering changes to API consumer types while being more relaxed about changing API provider types. This is because, you will need to change the few API providers to support an updated API but you do not want to require the many existing API consumers to change when an API is updated. API consumers should only need to change when the API consumer wants to take advantage of new API. OSGi is now defining <a href="https://github.com/osgi/design/raw/master/rfcs/rfc0197/rfc-0197-OSGiPackageTypeAnnotations.pdf">documentary annotations</a>, <span style="font-family: "Courier New",Courier,monospace;">@ProviderType</span> and <span style="font-family: "Courier New",Courier,monospace;">@ConsumerType</span>, to mark the roles of types in an API package.<br />
<h4>
Conclusion</h4>
When next designing an API, please consider these API design practices. Your API will then be usable in both OSGi and non-OSGi environments.BJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-87379861909076235712012-01-20T14:14:00.003-05:002012-01-20T14:24:23.342-05:00Juke Box Hero, Got Stars In His Eyes<img style="float:left; margin:0 10px 10px 0;width: 150px; height: 128px;" src="http://java.sun.com/javaone/images/RockStar_DukewithGuitar_small.gif" alt="" border="0" /><br />I learned Wednesday that I was named a <a href="http://www.oracle.com/javaone/quick-links/rock-star/2011-rock-stars-1453436.html">JavaOne Rock Star</a> for my <a href="http://www.slideshare.net/bjhargrave/why-osgi"><span style="font-style: italic;">Why OSGi?</span></a> presentation with <a href="https://twitter.com/#%21/pkriens">Peter Kriens</a> at JavaOne 2011. Nice!BJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-48619386272587098162011-12-09T09:54:00.003-05:002011-12-09T10:11:47.765-05:00Bndtools at the OSGi AllianceThe OSGi Alliance has been using <a href="https://github.com/bndtools/bnd">bnd</a> for a long time in the OSGi build. bnd is used by the ant build to create the bundles and execute the compliance tests as part of our continuous builds. It is also installed in Eclipse as an IDE plugin to provide IDE support for compilation classpath and test execution by OSGi members working in the Expert Groups.<br /><br />Recently <a href="http://bndtools.org/">Bndtools</a> development has been underway to create a better integration of bnd with the Eclipse IDE for bundle development. Bndtools 1.0 was just <a href="http://bndtools.org/posts/2011-11-27-bndtools-1-0-0-released.html">released</a> and is available for <a href="http://bndtools.org/installation.html">installation</a> into the Eclipse IDE as a replacement for bnd's Eclipse IDE support.<br /><br />Since the OSGi Alliance has long used bnd, we already had the bnd infrastructure in place for our build. All that we needed to do to start using Bndtools was to update each project's <span style="font-family: courier new;">.project</span> file (using the <span style="font-style: italic;">Add Bndtools Project Nature</span> menu item). This simple change then enabled Bndtools to manage the project within the Eclipse IDE. The OSGi Alliance will continue to use bnd in the ant build, but for our Eclipse IDE use we have moved to Bndtools.<br /><br />Thanks to Neil Bartlett, Peter Kriens and the other bnd and Bndtools contributors for their hard work in making bnd and Bndtools the premier tooling for OSGi development.BJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-54082476367981102272011-10-04T00:21:00.004-04:002011-10-04T00:51:25.231-04:00Java 8 and the 1990sI attended the first Jigsaw session at JavaOne today where Mark Reinhold presented the latest on Jigsaw. After what appeared to be the end of the presentation, Mark continued on and began discussing why OSGi is wrong for using packages as the primary unit import and export between modules and why Jigsaw is right for requiring (aka. importing) modules (but apparently, and non-symmetrically, exporting packages and types). Mark made several strange arguments.<br /><br />He found the idea of a resolver matching package importers up to package exports (essentially a broker pattern where the resolver acts as the broker) to be bad/complicated/etc. He prefers the developer to effectively be the "resolver" and declare the specific modules to be imported. This removes an important level of indirection between the thing being provided and the artifact providing it. This is like saying, "Don't use interfaces, use concrete implementation types," because we don't want to have to figure out how to map the use of the interface onto a concrete implementation type.<br /><br />Mark also stated that requiring modules mapped well onto native package managers (e.g. rpm, apt) while importing package provided for no simple mapping. So therefore requiring modules is the way to go. It seems rather sad to me that the design of modules for Java 8 is being driven by the capabilities of native package managers designed in the 1990s for native code. Shouldn't the design of a module system for Java be driven by the capabilities and attributes of Java?BJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.com4tag:blogger.com,1999:blog-18834385.post-14614907435543703262011-09-30T14:47:00.003-04:002011-09-30T15:27:38.363-04:00The Needs of the Many Outweigh the Needs of the FewThere is a discussion on the <a href="http://mail-archives.apache.org/mod_mbox/aries-dev/201109.mbox/%3cCAECq3A_x8S+8XqGwQAEM1vqdt8bsKE6nGRKqxoBpgZCa1TM=mQ@mail.gmail.com%3e">Aries dev mail list</a> about a tool for checking <a href="http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf">semantic versioning</a>. One of the issues misunderstood in the discussion is about the asymmetry in the treatment of versions for the roles of API consumer and API provider discussed in the whitepaper.<br /><br />An API package <span style="font-family:courier new;">p</span> can contains several types. Some types must be implemented by the API provider and some are intended to be implemented by the API consumer. <span style="font-family:courier new;">p.S</span> may be a service provided by the API provider and used by the API consumer. <span style="font-family:courier new;">p.L</span> may be a listener implemented by the API consumer and user by the API provider. A syntactic analysis tool for versioning needs to understand the <span style="font-style: italic;">orientation</span> of a type to decide whether a change to the type constitutes a major version change for the package or a minor version change.<br /><br />The whitepaper does not discuss how the orientation of the type should be marked. It is beyond the scope of the whitepaper. OSGi now uses the <a href="http://wiki.eclipse.org/API_Javadoc_tags"><span style="font-family:courier new;">@noimplement</span> javadoc tag</a> (from Eclipse) to indicate the type is not to be implemented by the API consumer (<span style="font-style: italic;">e.g.</span> <span style="font-family:courier new;">p.S</span>). Types not marked <span style="font-family:courier new;">@noimplement</span> may be implemented by the API consumers (<span style="font-style: italic;">e.g.</span> <span style="font-family:courier new;">p.L</span>). Adding a new method to <span style="font-family:courier new;">p.S</span> represents a minor version increment to package <span style="font-family: courier new;">p</span> as API consumers are not broken (while API providers are broken; but they have tighter version constraints, <span style="font-style: italic;">e.g.</span> <span style="font-family:courier new;">[1.0,1.1)</span>). Adding a new method to <span style="font-family:courier new;">p.L</span> represents a major version increment to package <span style="font-family: courier new;">p</span> as API consumers are broken. Furthermore adding a new type to package <span style="font-family:courier new;">p</span> will not break API consumers. They are free to ignore it. But API providers must change to support the new type.<br /><br />These are examples of the asymmetry between API providers and API consumers: an API provider must provide <span style="font-style: italic;">all</span> of the API while an API consumer is free to use any subset of the API.<br /><br />So in order for any syntactic analysis tool to properly work, the orientation of the types in the package must be properly marked so the tool can decide whether a change warrants incrementing the major or minor version. What is missing is an agreement on how to mark the types. I think this is something <a href="https://github.com/bnd/bnd">bnd</a> and <a href="https://github.com/njbartlett/bndtools">bndtools</a> should provide. Perhaps a set of standard annotations.<br /><br />For any API, we see there is an asymmetry in the relationships is has with API providers and API consumers. In general, there will (hopefully) be many more consumers than providers. So the semantic versioning scheme is oriented towards the many: the API consumers.<br /><br /><span style="font-style: italic;">"... the needs of the many outweigh the needs of the few."</span> - Spock.<br /><br />PS. It has also been suggested that segregating consumer oriented types from provider oriented types by placing them in different packages is useful. But this does not remove the need for syntactic analysis tools to understand the orientation of each type (or each package) to provide proper advice about necessary versioning changes. And now you have 2 packages which each provider and consumer must import...BJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.com12tag:blogger.com,1999:blog-18834385.post-58208039662377244002011-05-19T09:17:00.003-04:002011-05-19T09:28:11.071-04:00OSGi issue of Java Tech JournalJava Tech Journal has just published an <a href="http://jaxenter.com/java-tech-journal/JTJ-2011-04">OSGi issue</a>. It contains a number of great articles about OSGi including one I co-wrote with <a href="https://twitter.com/pkriens">Peter Kriens</a> on the new <a href="http://www.osgi.org/Download/Release4V43">Core 4.3 spec</a>. Check it out!BJ Hargravehttp://www.blogger.com/profile/05791451307210957698noreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-87632962755071304352011-01-11T13:53:00.002-05:002011-01-11T14:02:50.024-05:00OSGi 4.3 Early Draft 3 now availableThe latest draft spec from OSGi is now available for <a href="http://www.osgi.org/Download/File?url=/download/osgi-4.3-early-draft3.pdf">download</a>. 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.<br /><br />Since this draft is just a draft, understand that things can change, even substantially, before the final specifications are completed.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-49730009486889900602010-12-07T13:19:00.002-05:002010-12-07T13:45:25.312-05:00The Pipes Are CallingOn the <a href="http://mail.osgi.org/mailman/listinfo/osgi-dev">osgi-dev</a> list, there was an interest raised into having a Planet OSGi feed aggregator like the <a href="http://www.planeteclipse.org/">Planet Eclipse</a> and other similar planets.<br /><br />So initially I looked into planet software I could run on the OSGi server. I found <a href="http://www.planetplanet.org/">Planet 2.0</a> and <a href="https://github.com/rubys/venus">Venus</a> 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 <a href="https://rhn.redhat.com/help/about.pxt">RHN</a> 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.<br /><br />In any case, I needed some other solution. Some more use of a popular search engine lead me to <a href="http://pipes.yahoo.com/pipes/">Yahoo Pipes</a>. I was fairly easily able to create a "<a href="http://pipes.yahoo.com/osgi/planet">pipe</a>" 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.<br /><br />So checkout the new <a href="http://www.osgi.org/Planet/HomePage">Planet OSGi</a> feed <a href="http://www.osgi.org/Planet/Feed"><img src="http://www.osgi.org/www/feed.png" /></a> served up by Yahoo Pipes.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-18834385.post-77876535655364247132009-09-16T13:06:00.002-04:002009-09-16T13:09:00.629-04:00OSGi 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 <a href="http://www.osgi.org/Specifications/HomePage">here</a>.<br /><br />Work continues in the OSGi expert groups on the specifications for the enterprise spec.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-88234875301870999512009-05-20T11:32:00.004-04:002009-05-20T11:59:23.878-04:00Eclipse Galileo update site organization could be more usefulI saw <a href="http://dev.eclipse.org/blogs/wayne/2009/05/19/calling-all-maceclipse-enthusiasts/">Wayne's call for Mac users to try the Eclipse 3.5 RC1 Cocoa port</a>. 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 <a href="http://www.eclipse.org/downloads/packages/eclipse-rcpplug-developers/ganymedesr2">EPP for RCP developers</a> since that very closely described what I needed to do. All that I needed to add to that was an svn team provider.<br /><br />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 :-( ).<br /><br />So I think I have all the function I need installed, but it could have been much easier.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-18834385.post-46451225990357149232009-04-21T12:17:00.001-04:002009-04-21T12:19:19.817-04:00Java Posse interview on OSGiAt EclipseCon 2009, Peter Kriens and I were interviewed by the <a href="http://javaposse.com/">Java Posse</a> about OSGi. The <a href="http://javaposse.com/index.php?post_id=456475">podcast</a> of the interview is now available.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-50850870237949162752009-03-26T13:48:00.002-04:002009-03-26T13:52:38.997-04:00EclipseCon 2009 Presentations for downloadI have uploaded PDFs of my <a href="http://www.eclipsecon.org/2009/">EclipseCon 2009</a> presentations.<br /><ul><li><a href="http://wiki.bjhargrave.com/local--files/start/ServiceOrientedProgramming-644.pdf">Symmetric Service Oriented Programming</a></li><li><a href="http://wiki.bjhargrave.com/local--files/start/BundleTracker-634.pdf">Using BundleTracker to support the OSGi Extender Pattern</a></li><li><a href="http://wiki.bjhargrave.com/local--files/start/OSGiFramework2.0-771.pdf">OSGi Framework 2.0 Modernization BOF</a><br /></li></ul>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-33775988962232814262009-03-24T18:42:00.007-04:002013-10-14T16:00:49.741-04:00I 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.<br />
<br />
<span style="font-style: italic;">Visibility</span> is whether one type can see another type. In the <a href="http://docs.oracle.com/javase/specs/jls/se5.0/html/packages.html#7.3">JLS</a>, this is discussed as observability. In the <a href="http://docs.oracle.com/javase/specs/jvms/se5.0/html/Concepts.doc.html#19175">JVMS</a>, 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.<br />
<br />
<span style="font-style: italic;">Accessibility</span> is whether one type can access another type or a member of another type. This is discussed in the <a href="http://docs.oracle.com/javase/specs/jls/se5.0/html/names.html#6.6">JLS</a> and the <a href="http://docs.oracle.com/javase/specs/jvms/se5.0/html/Concepts.doc.html#18914">JVMS</a>. Most people know accessibility by the <span style="font-family: courier new;">public</span>, <span style="font-family: courier new;">protected</span>, and <span style="font-family: courier new;">private</span> keywords. Also see <a href="http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/AccessibleObject.html">AccessibleObject</a>.<br />
<br />
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.<br />
<br />
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. <span style="font-family: courier new;">service.getClass()</span>). If that class has public methods which are not part of the service interface, bundle A is able to call them.<br />
<br />
Adding a <span style="font-family: courier new;">module</span> 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.<br />
<br />
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. <span style="font-family: courier new;">javac</span> currently has a simplistic view of visibility: <span style="font-family: courier new;">-classpath</span>/<span style="font-family: courier new;">-sourcepath</span>. 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.<br />
<br />
[2013-10-14 - Updated links to fix link rot from Oracle acquisition of Sun.] Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-47936295860196138492008-12-23T10:39:00.003-05:002008-12-23T10:58:03.589-05:00Presenting on OSGi at EclipseCon 2009Well it looks like 2 of <a href="https://www.eclipsecon.org/submissions/2009/search.php?search=authors+%7E+%27hargrave%27">my session proposals</a> were accepted by the <a href="http://www.eclipsecon.org/2009/">EclipseCon 2009</a> program committee. So I will be doing a long talk on <a href="http://www.eclipsecon.org/2009/sessions?id=644">Symmetric Service Oriented Programming</a> and short talk on <a href="http://www.eclipsecon.org/2009/sessions?id=634">Using BundleTracker to support the OSGi Extender Pattern</a>. Looking forward to EclipseCon again. It is a great conference. Hope to see you there.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-75900094854056305962008-12-02T12:16:00.006-05:002008-12-23T11:00:39.609-05:00Another Early Draft of 4.2 from OSGiThe OSGi Alliance just <a href="http://www.osgi.org/News/20081202">announced</a> the release of an updated <a href="http://www.osgi.org/Download/File?url=/download/osgi-4.2-early-draft2.pdf">Early Draft</a> of new content for the OSGi Service Platform Release 4 Version 4.2 spec which is planned to be published in late 2Q2009.<br /><br />Some of the designs in the draft are already being implemented in the Equinox 3.5 code stream. In fact, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=244625">I already implemented</a> RFC 126 Service Hooks there.<br /><br />If some of <a href="https://www.eclipsecon.org/submissions/2009/search.php?search=authors+%7E+%27hargrave%27">my EclipseCon 2009 session proposals</a> are accepted, I will present some of these new features there.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-3239366154674972142008-11-22T18:28:00.005-05:002008-12-23T11:00:13.548-05:00Øredev and the Renaissance?I am on my way home from <a href="http://www.oredev.org/"><span class="blsp-spelling-error" id="SPELLING_ERROR_0">Øredev</span> 2008</a> where I <a href="http://wiki.bjhargrave.com/local--files/start/%C3%98redev2008-BJHargrave.pdf">presented on <span class="blsp-spelling-error" id="SPELLING_ERROR_1">OSGi</span></a> which seemed to have been well received by my kind audience.<br /><br />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 (<span class="blsp-spelling-error" id="SPELLING_ERROR_2">JavaOne</span>, <span class="blsp-spelling-error" id="SPELLING_ERROR_3">EclipseCon</span>). 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.<br /><br />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 <span class="blsp-spelling-corrected" id="SPELLING_ERROR_4">methodologies</span>. 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 <span class="blsp-spelling-corrected" id="SPELLING_ERROR_5">methodology</span> 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?<br /><br />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 <span class="blsp-spelling-corrected" id="SPELLING_ERROR_6">astronomers</span>) and not <a href="http://en.wikipedia.org/wiki/Pseudoscience">pseudoscience</a> (like astrologers).<br /><br />One of the panelists quoted <a href="http://en.wikipedia.org/wiki/Bill_&_Ted%27s_Excellent_Adventure">Bill and Ted</a> and simply suggested we programmers Be Excellent! That is great advice for all things in life but not specifically helpful for programmers.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-18834385.post-89597925871335224632008-05-08T20:48:00.005-04:002008-12-23T10:59:39.751-05:00Hot off the press: my JavaOne presentationYou can now <a href="http://wiki.bjhargrave.com/local--files/start/TS-5122.pdf">download</a> the JavaOne 2008 presentation <span style="font-style: italic;">Converting (Large) Applications to OSGi</span> I just delivered with Peter Kriens.<br /><br />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 <a href="http://java.sun.com/javaone/sf/rockstar_wall_of_fame.jsp">JavaOne Rock Star</a>! :-)Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-18834385.post-55875451538503810452008-05-07T02:14:00.003-04:002008-12-23T11:01:49.379-05:00An AJO is not a POJOA POJO is a <span style="font-weight: bold;">p</span>lain <span style="font-weight: bold;">o</span>ld <span style="font-weight: bold;">J</span>ava <span style="font-weight: bold;">o</span>bject. 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.<br /><br />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 <span style="font-style: italic;">plain</span>. 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.<br /><br />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.Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-18834385.post-89523976391008104742008-03-27T15:30:00.004-04:002008-12-23T10:59:28.143-05:00Equinox and Google Summer of CodeAn implementation of an OSGi resolver is a complex beast. Just ask Tom Watson, the Equinox dev lead :-) The <a href="http://wiki.eclipse.org/Equinox_p2">Equinox p2</a> project, a new provisioning system for Eclipse, also has similar and complex resolve algorithm. Recently the p2 project, changed to use the <a href="http://www.sat4j.org/">SAT4J</a> <a href="http://en.wikipedia.org/wiki/Boolean_satisfiability_problem">SAT solver</a> to drive their resolve algorithm.<br /><br />We have <a href="http://wiki.eclipse.org/Google_Summer_of_Code_2008_Ideas">proposed</a> a <a href="http://code.google.com/soc/2008/">Google Summer of Code</a> 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 <a href="http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants">sign up</a> for it!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-46902980206905973952008-03-25T10:22:00.005-04:002008-12-23T10:59:13.166-05:00OSGi and eRCP on Mobile Phones<a href="http://www.sprint.com/">Sprint</a> (a US mobile operator) has a new OSGi based mobile phone platform called Titan. There was a <a href="http://www.eclipsecon.org/2008/?page=sub/&id=596">session</a> at <a href="http://www.eclipsecon.org/2008/">EclipseCon</a> announcing this. But if you missed the session at EclipseCon and want to learn more, there is a <a href="http://webcast.streamlogics.com/audience/index.asp?eventid=98388">webcast</a> on Wednesday March 26 at <a href="http://www.timeanddate.com/worldclock/fixedtime.html?month=3&day=26&year=2008&hour=13&min=0&sec=0&p1=179">1pm EDT</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-6669544721129661282008-03-23T22:44:00.003-04:002008-03-23T22:47:41.840-04:00Call for Speakers at 2008 OSGi Community EventThe <a href="http://www.osgi.org/">OSGi Alliance</a> is holding the 2008 OSGi Community Event June 10-11 in Berlin, Germany. The <a href="http://www.osgi.org/CommunityEvent/CFP">Call for Speakers</a> was just issued. Please consider submitting a session proposal and attending the Community Event. I hope to see you there.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-18834385.post-46553536228185705832008-03-23T01:31:00.008-04:002008-03-23T02:22:33.363-04:00EclipseCon is over and a MacBook Pro for me!Another great <a href="http://www.eclipsecon.org/2008/">EclipseCon </a>is over. The <a href="http://www.eclipsecon.org/2008/index.php?page=sub/&category=OSGi+DevCon">OSGi DevCon</a> 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 <a href="http://www.eclipse.org/org/press-release/20080317_Equinox.php">Eclipse Runtime</a> top-level project and <a href="http://www.eclipse.org/equinox-portal/">Equinox portal</a> are great news as well.<br /><br />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 <a href="http://blog.bjhargrave.com/2008/01/speaking-at-eclipsecon-2008.html">5 presentations</a>. 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).<br /><br />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... :-)Unknownnoreply@blogger.com3