Hi there,
I am currently porting a very large legancy codebase to java-1.3+ and the code contains tons of calls to sun.awt.ScreenUpdater and some classes implement sun.awtUpdateClient.
Is there any documentation available what these classes do and how this code could be made “nice”?
Thank you in advance, lg Clemens
Hi Clemens,
Unfortunately there is no documentation available for these classes (as far as i know 
its a non-public api.
I just had a look at the decompiled classes of jdk 1.1.5 and my guess is that the purpose of ScreenUpdater
UpdateClient and ScreenUpdaterEntry is a time scheduling queue for calls to the UpdateClient interface.
Typically the UpdateClient interface is implemented by the ComponentPeers (the platform specific instances
of the components) and its purpose is to do a repaint. (native pTriggerRepaint())
So it intended purpose is a repaint mechanism. What is in a name The question now is why did they use this
non public api ? Did they intend to trigger repaints, in that case you should be able to use a plain ordinary
repaint(). However, as it is a generic time scheduler, you could also use it for something different… and there
is this evil object parameter that you can pass around to do strange things with… . .
Good luck
Erik
WHoever wrote this code seriosuly broke the rules,
The answer is “undefined and may chnage or disappear between VM versions.” App code should NEVER reference sun.* classes
You should re-write it not to break the rules 'cause sooner or later your gonan have to anyway and its better you do it now then after it breaks on a user…
If I read the first post correctly, I think that is exactly why he is asking the question in the first place.
why people can do it then? … if I were in Sun I would disallow access to the packeges then
That would be sorta problematic. But generating some warning message as long as there isnt a specific ignore switch, would be somewhat sensible. But I doubt that its really worth it.
Well this stuff uses some ansynchronous image loading/painting mechanism and was heavily threaded - now computers and jvms are fast, I just removed asynchonous loading and made everything single-threaded.
Its really a shame the code is totally clever and really on an advanced level and I put my hands on with almost no clue how it works.
One exmaple is this image loading stuff, totally advanced and complex - it just short-circuit it 
I am sure I broke thousands of things … however it works now on any JVM starting from Netscape-4.7 (had to rename all resource files to .gif zz) /MSJVM up to mustang :-))
lg Clemens
Because, thanks to dynamic class loading and user defined class loaders, the only way to enforce such a band would be to put security chcekcs in every method of every sun. class.
The cost in performance was deemed not worth it. You are clearly advised not to refernce them in the docs that come with the JDK, after that it up to you not to do yourself damage,.
I hate ‘clever’ code. It’s a right pain to maintain. >:(
Yeah, clever code is only good when you did it your self… and it only remains clever for about 1 week after you finish it… after that it degrades to “smart-alec pain-in-the-ass code”.
Of course you don’t realize this until you try to explain to someone how clever you were and you have to ask them to come back later after you figure it out all over again
Clever code and algorithms is what makes the world go round. Seriously, almost anything of any interest has cleverness associated with it. The beauty in cleverness is hiding it behind simple and elegant interfaces.
If you’re writing CRUD business apps, then ignore everything I just said.