More of Vista: Java integration, JOGL, resource utlization

Java integration needs some work: when Java Settings application is launched (this one is AWT-based, innit?), Vista disables some of its eye-candy.


My fears are dispelled: OpenGL is very much supported on Vista (at least by NVidia) as is demonstrated here by running JOGL demo application that uses, among other things, programmable shaders. More curiously, 3D applications like this Java-to-OpenGL demo continue running at full speed when windows are stacked.



Those nice features are not coming for free, are they? No-o-o!!! Freshly booted system runs HOW MANY SERVICES? ...and uses HOW MUCH RAM?



But, again, those are nice features. Another example of Java-to-OpenGL program running and the small thingie (how do they call it?) that appears when you mouse-over a button representing program on the task bar. Amazing, animation in the small frame copies the one in the real app window! Very pretty. Thank you, Apple (did I mean Xerox, really?).

 

Vista, continued (transparency, protection, Java)

Transparent window borders are extremely pretty



This one was designed to drive you mad: overprotective is seemingly synonymous to secure as far as Microsoft is concerned. Every non-trivial action results in this warning banner... infuriating.



While Java Runtime is being installed, NVidia drivers download. Big question for me was whether OpenGL is really banished from Windows as some people were saying it would be.



Applets are running happily in Firefox with Sun's JVM installed.

 

Installing MS Vista on Sun Java Workstation V

One hour later, installation reboots.



Pretty, mesmerizing intermission.



Widely appraised pretty themes



 

Installing MS Vista on Sun Java Workstation IV

Next day, at 1:20 p.m., installation begins. No option to upgrade a 32-bit version of Windows XP is offered.



This is where I'd like Vista to reside: in the same partition with Win XP 32. After all, Windows 95 coexisted with Windows 3.11



Bad assumption :) Windows Vista (Beta) prefers to decimate the older cousin (am I using the word appropriately?)



Well, crap, I have to cut another 20GB slice of the drive and give it to Vista exclusively.



This was a beginning of a long... long wait. (And for good reason, too. 1 installation DVD needs to produce 14 GB of reach content on the hard drive.) 

Installing MS Vista on Sun Java Workstation III (Upgrading Win XP x64)

In upgrade mode, installation will try to download updates. That should be helpful to many users, given device driver readiness.





Looks like I've exhausted the easy options... On to prepare the drive to be repartiotioned. 

Installing MS Vista on Sun Java Workstation II (Upgrading Win XP x64)

Windows Vista hardware comatibility tool display, as seen on Win XP Pro x64



Trying to have Vista use Win XP Pro x64's drivers (which BTW do not work in Win XP either)



Nope, refuses to work



Hoping for a miracle, launch upgrade anyway

 

Installing MS Vista on Sun Java Workstation I

Since the original hard dive has been already all consumed by the 4 OSes I have installed, I thought adding an extra HD would solve this problem. A trip to Fry's Electronincs buys me 200GB SATA for $69.90. Fine, had the drive installed (using slides I cut out of an old DVD box, as slides for drives are not available for purchase separately from storage itself. Nice one there, Sun.)


So far so good...



Now what?



Oh, no....



Yep, I'm screwed. Even though I tried to have Vista use drivers written for Windows XP Professional 64-bit edition. Before I'm to move on to archiving files from all filesystems in preparation to repartitioning the IDE drive, let me try going the "Upgrade" way. 

Is log4j causing a liveness issue?

Wow, this big word, "liveness"... A couple of weeks ago I had, again, forgotten what it means (and hope to forget again in a month, maybe). We're seeing this situation, when with increased number of requests, server's CPU usage can not exceed 1/4th of available resource (meaning, only 1 CPU out of available 4 gets pegged). Many man-days were spent trying to find the culprit. Today I just woke up with this thought, correlating that the issue manifested after all our application logging was converted to use commons-logging and log4j.

<rant&rt; (as if the prior part was not): there's a saying, roughly translated as "how you name a ship, so she will sail". There might be some truth, after all, to commons-logging being christened as "Clogging" by our fearless Hani.</rant&rt;

And there it was: synchronization on logger category in org.apache.log4j.Category.java

/**
    Call the appenders in the hierrachy starting at
    this.  If no appenders could be found, emit a
    warning.   
     This method calls all the appenders inherited from the
    hierarchy circumventing any evaluation of whether to log or not
    to log the particular log request.
    @param event the event to log.  */
 public
 void callAppenders(LoggingEvent event) {
   int writes = 0;

   for(Category c = this; c != null; c=c.parent) {
     // Protected against simultaneous call to addAppender, removeAppender,...
     synchronized(c) {
       if(c.aai != null) {
         writes += c.aai.appendLoopOnAppenders(event);
       }
       if(!c.additive) {
         break;
       }
     }
   }

   if(writes == 0) {
     repository.emitNoAppenderWarning(this);
   }
 }

So, for the duration that this event gets logged (most likely, including the time while data is written to a file on disk), the lock prevents other events to be logged in the same category. It's true that we're logging a lot :) But it's not an excuse for this. This synchronization is here for the sake of changing the set of appenders at runtime. Now, how often should THAT happen? (never!) IMO, letting the underlying collection to throw a ConcurrentModificationException in such unlikely case when set of appenders is being changed while events are being logged would be much preferred outcome. More elegant workaround is possible, too, but I'm probably too bad a person to submit this to Apache. I feel much better bitching about it here :)