Bug fix to fix an NPE when attempting to wrap an already wrapped object. Also includes improved documentation.
Source Tarball, Binary Tarball, and Javadocs
A comment I missed a while back asked about the performance of Signature.matches(...). Bo's concern was that calling this on every interceptor on every invocation would be painfuly slow. Rest easy, this isn't done. The broker builds match information when the interceptor is added and when a new class (not new instance, just new class) is first wrapped. It caches the interception information on a per-class/per-method basis so that the invocation sequence looks like:
MethodInterceptMatrix is key as it allows a hash lookup speed interceptor stack generation (plus interceptor instantiation time for the "new interceptor for every invocation" style interceptors). As mentioned, I am pretty sure I can reduce this to an array index, but havent had time/need to do so yet. The MethodInterceptMatrix is responsible for keeping track of what interceptors care about what methods and builds this information when new interceptors are added, or when new MethodInterceptMatrix instances are created when a class is generated.
The benefit to this design is faster interceptor stack invocation. The drawbacks are that adding a new interceptor to a broker with a lot of classes registered is slow, and adding a class to a broker with a lot of interceptors is slow. An additional drawback is that you only have java.util.reflect.Method information in the Signature.matches(...) test. There have been cases where I want to match calls against a specific instance only intead of all calls to that type's method. This has to be filtered at invocation time (as Bo was afraid of) so needs to be done in the interceptor instead of the Signature which is ugly =/ I have thought about splitting signatures into two types -- compile-time and invocation-time in order to make this cleaner, but haven't yet as I haven't had the need and no one has asked for it.
0 writebacks [/src/java/commons-intercept] permanent link
Syndication of Project Announcements
I just realized yet-another-good-use-for-syndication: syndicate release announcements for projects. I want to know when there is a stable release of certain tools that I use, and the typical "subscribe to the -users or -annouce mailing list" is not so hot for automation. I would prefer to have an arbitrary pull that is scripting friendly. Wheee, syndication wins again.
For example, the RSS feed from my interception library category serves as a nice pull style announcement. Now if a standard schema for announcements can be created the requirements for a much more useful freshmeat/version tracker are there -- where you can subscribe to a feed for just the packages you care about.
0 writebacks [/tech] permanent link
Microsoft Taking Over O/R Mapping?
I was skimming through blog comments at weblogs.asp.net and a lot of people are talking about Frans Bouma's post about the MS employees moving over there now that GotDotNet is dead. That is fine and dandy, but his comment that MS is performing anti-competitive practices by releasing ObjectSpaces is interesting.
Frans appears to work on LLBLGen which looks like a decent, Torque-style, O/R mapping tool. It points at database metadata and generates your classes with the ability to customize your codegen templates. I couldn't tell from the marketing material if it supports arbitrary object to arbitrary table mappings, and don't have a convenient VS.NET install to trial the product. I'll presume its a good product.
I have never been in a position, luckily, where I am developing a product that competes directly against Microsoft in the same market segment. I guess OJB competes against ObjectSpaces, but for very different target audiences -- and I don't make any money from OJB directly anyway, so not the same fear. I can imagine that Richard Adams's "tharn" probably describes the state of people who realize their livelihood will in a short time be in direct comptition with Microsoft products. Not fun.
Does Microsoft entering a developer market mean that everyone else with a competing library is doomed? I know that certainly didn't happen to O/R mapping with CMP Entity Beans in J2EE, CMP probably helped the other O/R libraries find greater acceptance. It helped that CMP is tied to Entity Beans, which are the handmaidens of Evil, but it also helped to raise awareness that there are strong alternatives to handcoded SQL. Most MS platform developers I know are barely aware of O/R mapping, and if they are think that ADO is O/R mapping because it is higher level than the C interfaces to whatever RDBMS they are using. Microsoft telling their minions that O/R mapping tools are an officially sanctioned "good idea" would seem to increase the market size more than take users from existing technologies. Again, I haven't gone head to head against Microsoft though, so cannot say for sure.
The bigger problem, I think, that Frans and other commercial O/R vendors face is that O/R mapping is not a nice field to be making money from right now. It is not that it is going to be commoditized soon, it is already commoditized. This may not be true in the .NET user space, but it is true in the Java space. There are dozens of O/R tools available freely, and half a dozen which are rock solid -- and at least three of those have good communities, good unit tests, and good support available. Microsoft, if they bundle ObjectSpaces with VS.Net EA or whatever their absurdly overpriced IDE is named for the next release, will not be found guilty of any anticompetitive practices for doing so. They are far from having a monopoly on IDE's or language platforms. They have a monopoly on .NET, yes, but that is because they own .NET -- many other enterprise grade platforms exist that run happily on Windows, and many more on the same hardware.