Wednesday, June 1, 2011

Java Components and Package Visibility

I have a recurring problem: I want to build a component within a large application. Here's an example: I want to synchronize QuickBooks Invoices with my application's invoices. The component API produces and consumes application invoices, sales reps, accounts, and customers, but the internals of the sync task are very complicated, involving 3rd-party Invoices, maps to interface invoice-like objects, synchronizers, etc. The main app has no need to know most of this stuff.

Java provides no mechanism to build a subclass structure for my sync component--I must either build the whole thing in a single package containing hundreds of package-scoped objects, or I must build public objects visible to the rest of my app so my component can have an internal package structure which models its behavior.

What I really need is a visibility modifier making classes only visible to their sub-packages.

I want my component to have a well-defined interface, and I want to be able to structure its internals cleanly. The component is complex, so it needs large-scale internal structure. My component wants to consume and emit objects key to the application--typically important domain objects--so it has a few dependencies outside of its package, and it's thus not a true component. Java gives me a small number of very heavy-weight ways to do this: write an EJB, write a web service, write a domain VO package and a set of dependent packages. All these approaches are hard to back-fit into existing projects, and tend to require a full app-server to implement. All I really needs is some kind if hierarchical visibility within the package structure, but instead, I have to deploy a huge heavyweight thingy to get what should be easilly done, done.

Java needs package-level visibility declarations. By that I mean: we need to be able to say "this class is visible to this package and sub-packages". Alternately: this package is visible to sub-packages except when classes are defined as public. Either way, I'd get the ability to define a component within a package, within the context of an enterprise app, and without the heavyweight behavior that comes with EJBs and web services and other large-scale things.

Bottom line: I want to build large-scale apps with small-scale tools. Give me that, and I can do a lot with not much memory and not much CPU.

Is it time for a JSR on visibility?

1 comment:

  1. A very interesting idea ... often in larger-scale units of work, we'd really like to have more than one package for good organization, and making a method public could provide more visibility than we'd really like.


    John Woodward
    Improving Enterprises