Peter B. West wrote: > I like statics. They are smaller and faster; what's not to like? > Before continuing with them, though, I need to make sure that I > understand the problems.
Yes to smaller and faster, though if the existance of statics forces you to use synchronization, your mileage may vary 8-). And indeed there's a general - though not widely known - problem with statics (if properly encapsulated) in Java, as follows: Since JDK 1.1, there's a concept of unloading of classes. If a class is implemented after the singleton pattern (for example using the widely used "private constructor + getInstance method" mechanism), you may have moments (unexpected by you) in the lifetime of the VM where only the class itself holds a reference to its single instance. If that happens, the class is eligible for garbage collection. If it is actually garbage collected, this either just impacts performance or crashes the app, because you never anticipated re-initialization of the class. I typically work around this by maintaining a "singleton registry" that keeps a reference to each singleton instance in my app. This problem does not occur very often, but if it occurs, it's pretty nasty. 8-) > does not need to be synchronized. (I'm assuming here that all statics > are global relative to the JVM.) Yes, that's what the spec says (assuming that by 'global' you mean there's just the one instance). > It seems to me, of what I have heard so far, that there is no problem > with statics _per se_. If they are used with an awareness of the > possibility of multi-threading, they should present no special > difficulties. I have heard it said, though, that statics are forbidden > in EJB environments. Is this true? If so, what are the special > constraints that apply to EJBs? Ok, concerning EJBs, statics (besides constants, of course) are forbidden because you don't instantiate the server-side EJBs, the application server does. There's also an activation mechanism in addition to instantiation, used to implement EJB instance pooling on the server. Since this makes statics extremely dangerous in EJBs, they are forbidden. I wouldn't be surprised if some appservers would even enforce this rule in their classloader. > Regarding configuration in FOP, it is interesting to note that there are > two different config hierarchies depending on whether the environment is > uniform, as, e.g., in a single thread, or diverse, as in the example > Arnd offered. (That is, a separate process constructs stylesheet > information and other variables into an instance-specific storage > location, and invokes a fop thread with a reference to that location.) > In the second scenario, the most instance-specific data is in the user > config file (if that is being used to pass the instance data) or in some > other instance-specific config source. So the hierarchy looks like: > > system config > command line > user config > > or > > system config > user config > command line > instance config > >I like the second idea better. Me too. However, what about: > system config > user config > instance config To me, command line configuration is just an example of instance configuration, not an added level. In the FOP application, the commandline configuration IS the instance configuration. In embedded uses of FOP, the commandline never arrives in FOP's classes. > Not knowing a great deal about JVMs and class loaders, I'm curious to > know how dynamic data can be introduced into threads started within a > pre-existing JVM. One solution of Arnd's problem would seem to be to > control the process of setting up the FOP thread configuration > subdirectories from within the JVM, and allow for new FOP objects to be > initialised with this information. That is not a general solution ot > the problem though. How is it usually done? Had this been possible with FOP, I'd have created two separate instances of FOP on startup of my application. Then, each instance would have run in a separate thread. As for a more general approach, I do not see a perfect one-size-fits-all solution. I see two extremes (perhaps the middle between the extremes is best, perhaps it's not): 1. On the one hand, removing all statics in FOP would give maximum performance for each single instance as synchronization could be eliminated completely. This should outweigh possible penalties for carrying references to "global" objects. 2. Use excessive pooling of "expensive" objects, including fonts, font metrics, factories of any kind, just everything that's expensive to create and somewhat likely to be reused by other "jobs" in a server environment. This is both much more complex to get right and also carries an overhead for synchronization in many places. Which way to go? This should depend on where FOP is expected to be used. For most of "my" applications, 2. would be better, though I could perfectly live with 1. Going with a clean 1. would probably result in the most stable implementation. Still, pooling of fonts or worse things is tempting... Arnd Beissner -- Cappelino Informationstechnologie GmbH Arnd Beißner Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
