Java IPP and general Merry X-Mas

Max Rydahl Andersen

It sure is christmas time now ;)

The first OS Java IPP implementation (called Jipsi) have been made available from

Great stuff, based/inspired by CUPS - but unfortunately Jipsi is been released under GPL instead of LGPL which makes it impossible for me to use ;( ....but hey, it's a start ;)

Secondly, JGoodies have showed me how to do proper validation UI's - see (yes - it was relased on the 10th, but hey it's close to x-mas ;)

Thirdly, JDK 1.5 Alpha have been made available for JavaLobbist's from (require registration)

Fourth, Eclipse M6 is still working great ;)

Fifth, Happy X-Mas ;)


Dmitri Colebatch

Are you kidding me.... just had a skim of the source, check this out:

catch (IllegalAccessException ex) {



catch (InvocationTargetException ex) {



I'm sorry, but that is not appropriate exception handling for any sort of library...

been a while since I've done some swing, so cant comment on 'better' appropaches, but that code snipped I posted jumps out at me and says "I'm not ready"...

Anthony Eden

I've been using something like this long before Sun added it to the JDK. Instead of invoking a property set method I can invoke any method. In one sense it is good because it removes a lot of extra code, on the other hand it probably makes more sense in many cases to use an Action implementation instead.


well - as i said, it's good - not perfect ;)

The stacktrace stuff i had not noticed - thanks for pointing it out...another reason for building my own ;)

...Action's is much more preferred, but for example in the BeanContext API we got horrible names and complex classes for simple EventHandler (or a better replacement) would make wonders to the readability of the code.


There is no solution for the public v. private issue. Its a side effect of the security restrictions placed on reflection. Reflection can not invoke a method unless the class that's doing the invoking is doing it within the appropriate scope, so even package-protected things have to be invoked in the same package.

Trouble is the invoker in this case belongs to java.beans, not to the package of your gui code. There's simply no way around that unless the JDK opens up more aspects of the .classfile, and that opens up a larger can of worms that I'd really rather not deal with.

Besides, IMHO, if something can be called via the GUI, its "public", and thus the method that invokes it on my Object should also be public. Its part of what something from the outside can do to my object. By having it public, it also gives me the room to test it with external testing tools.

As one noted, one could instead advertise what actions are available by making public an array of Action objects.

With the stack-trace, that was just plain bad, although my version had the same issue. The trouble in that case is the general problem of dispatching Exceptions in any GUI program. If you can't catch them, they propagate up to the AWT event queue, where they'll be printStackTraced anyways, and in the case of InvocationException (written before JDK 1.4 built-in nested exceptions) the real source of the problem may end up not displayed in the dump.

Really, in any framework for a GUI, one should have the means to add an ExceptionHandler type of Object to deal with that sort of thing, but the JDK didn't build it in.


Joe, that is not true - otherwise persitenceengines and many J2EE servers or other highly reflection based systems (such as Hibernate) would be living on a lie ;)

Yes - there is some security breachees, but in general it is possible to call also private and protected methods via reflection.

Yes - i'm al for it being public on e.g. anonymous inner classes, but the AIC's just fills up to much compared to what they provide. And often they just relay the event to a protected method in the outer-class....thus using EventHandler or similar would allow me to express what I actually do in much less code.

Regarding AWT exceptions there is an ExceptionHandler object. Look for "sun.awt.exception.handler" via google.


Well, first off, as a security feature, it is possible to turn it off at start-up time. I believe the start-up systems/scripts of most J2EE servers do that, but I haven't the time to confirm.

Second, several persistence engines work by code-generation, and in the case of many OODBMS's, work by modifying the .class files themselves. There are lots of options for getting to private data. One approach I've seen used is parsing serialization streams.

In any case, that's not invoking a public/private method, thats reading the value of a member variable, which is not quite the same thing. Hibernate, for example, uses RunTime bytecode generation, meaning it creates new classes that internally have access to the private fields they need to access to persist. In effect, its doing much the same as the OODBMS approach, but at runtime instead of using a pre-processor. This is possible because of how much faster machines and JVMs are over what they were in the early OODBMS days of 1997.

Part of the real problem with this is the degree to which GUIs should remain Object-Oriented. Object-Oriented approaches that are designed to protect behavioural classes and data classes have a tendency to hide internals that in actuallity the GUI needs to be extremely public in order to display and manipulate correctly. The trouble with making them more public than they should be from an OO standpoint is that other developers may see that they are public and use them improperly. The trouble with hiding them is that the GUI has to go through rediculous hoops in order to get the info it needs to display or execute properly.

Basically there are two options. First is just make things public, and document in the javadocs that certain methods or properties are for GUI access only, not to be called by other parts of the codebase, and hope that other developers pay attention to that. Second is to encapsulate the GUI through inner classes as Allen Holub wrote in JavaWorld back in 1999. That approach of extremely-tight coupling of the GUI to the model has the negative effects of

placing too much GUI code in something that may get moved out to a web application or web service, and requires that one do the GUI design and implementation by hand. Few code generators will "think" like that and be able to manage that kind of architecture.

Sun is not going to blindly give developers the tools to break their own OO & security standards. I wouldn't expect them to. So either grin and bear it and make your button-clicking methods public, or write your own reflection tool that bypasses the standard security restriction.


As one of the developers of Hibernate :), I can promise you that Hibernate is NOT depending on using runtime bytecode generation to access fields inside an object. (the runtime bytecode gen is mostly for performance and to realize lazyloading)

Hibernate uses Reflection to access PROPERTIES - not fields. Direct field access have actually only been made available lately, before we only accessed properties (public, protected, private whatever ;)

But putting that aside - I refrain from making the event listeners part of my public interface of my gui classes...thus I use inner anonymous classes....and thus i'm also very much considering using EventHandler ;)

...but i don't follow your argument saying that having inner classes tightly couples the gui to the model ?


you need to read the article Holub wrote (its in 6 parts, rather long, but he writes a LOT). The design is that the "Object" is responsible for its own GUI, and internalizes its own GUI entirely, either in an inner class, or just by directly having a JPanel as a member.

The idea is that the outer object that manages the inner object does its own layout, asking the inner object for its gui component, which it then embeds in its own JPanel, which becomes its component to advertise out to any object that contains it.

The idea of using an inner class is simply to keep having SOME separation of Object from GUI interface by having the GUI be its own class, just an inner class embedded inside the object's own class. Extremely-tight coupling, but its definitely Object-Oriented.

The problem then comes to a head. Is that amount of adherance to Object-Oriented really better in the long run for application maintainance? When you have separate Swing and Model programmers, you have two people manipulating the same file in developing the work, which may lead to problems if your CM isn't perfect (and no CM is).

Another significant drawback with that approach is that sometimes in GUI layout design, pieces that conceptually are part of the same Object don't necessarilly belong together on the screen. Status display information is different from controllers, and usually goes in a different place, but when the GUI only allows one component per Object at that level, there's no way to separate them without significant rearchitecture.


Do you have a link to the article ?

But your small resume indicate to me that i do not agree on his viewpoints ;)

I normally disagree with people saying that the objectmodels should have a "getPresentation()" method or similar...that simply does not work .... most of the time i see gui much like persistence, it is something orthogonal on the domain - something that is best "externalized" and modelled in its own right.

And yes - if Holub write about objects having their own presentation then i do understand what you mean about strong coupling...and that is bad ;)