Der Fehler verursacht die aktuell ausgewählte Java-Version (und das ist bei den meisten Leuten der Standard Java 1.5.0). Wenn jedoch die Jar mit Java 1.6 kompiliert wurde, kann der 1.5-Loader damit nichts anfangen bzw. schützt aus naheliegenden Gründen vor der Ausführung. Zwar ist auf Mac OS X System der Version 10.5 auch Java 1.6 installiert, dieses ist jedoch kein Standard.

Es gibt dafür nun drei Möglichkeiten:

1. Der Benutzer startet die JAR nicht mit Doppelklick bzw. dem Kommando “java -jar JarFile.jar” sondern mit der direkten Angabe im Frameworkverzeichnis.. diese Lösung ist inakzeptabel.
2. Der Benutzer stellt seine Default-JVM auf 1.6 um.. das machen die Entwickler eh, aber der Benutzer wird auch damit überfordert sein. Auch keine akzeptable Lösung.
3. Man erstellt eine Mac-Application mit entsprechenden Application-Bootloader und einer Art Manifest, wo eingestellt wird, welche Java-Version verwendet werden muss. Damit findet sich Java 1.6 sogar dann, wenn man als Default 1.4 eingestellt hat. Außerdem hat es den positiven Nebeneffekt, dass die “technische” Jar vor dem Benutzer durch ein Anwendungsymbol kaschiert wird.

MacUtils.makeWindowLeopardStyle(getRootPane());

If I disable (comment out) this line there will no exceptions. What a..

The structure of components: One Mainframe with BorderLayout (Toolbar, Sidebar and MainContent). The MainContent contains eventually the graph, the corresponding satellite component is in the sidebar.

Original post:

I had already posted about it last week. But now it seems that is was not a reasonable solution.

I have a java swing application which uses standard java swing elements and the jung2 graph framework visualizing graphs. The application is developed under java 1.6 and mac os x 10.5.6.

The actual problem is that since yesterday the AWT-Eventthread crashed, for example like this:

Thu May 7 15:04:28 X.localdomain java[2002]Â : CGSResolveShmemReference : reference offset (65232) exceeds bounds (32768) on shmem obj 0x257e
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Non-Java exception raised, not handled! (Original problem: Error (1000) creating CGSWindow)
at apple.awt.CRenderer.doRect(Native Method)
at apple.awt.OSXSurfaceData.doRect(OSXSurfaceData.java:1247)
at apple.awt.CRenderer.fillRect(CRenderer.java:157)
at apple.awt.CRenderer.fillRect(CRenderer.java:145)
at sun.java2d.pipe.ValidatePipe.fillRect(ValidatePipe.java:58)
at sun.java2d.SunGraphics2D.fillRect(SunGraphics2D.java:2501)
at edu.uci.ics.jung.visualization.BasicVisualizationServer.renderGraph(BasicVisualizationServer.java:341)
at edu.uci.ics.jung.visualization.BasicVisualizationServer.paintComponent(BasicVisualizationServer.java:321)
at javax.swing.JComponent.paint(JComponent.java:1027)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JComponent._paintImmediately(JComponent.java:5096)
at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:749)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:300)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:210)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:200)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:195)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:187)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

This happens in the event thread, so the application is “still” useable. Well, of course, the graph painting is a mess.

After googling, I found some solutions:

1. Execute the file access rights (permissions)-fix via disk utilities & reboot the maschine. Yes, this will fix the problem for some starts, but then.. what a dejavu.
2. Assure that the paint-process is not outside of the awt-thread.. yes it is. See trace. (Link developer.apple.com)
3. Exclude the SWT jar.. well, I do not use this and I have not include it. (Link publicobject.com)
4. Use not the apple ui manager.. well, i replace the manager for the components of jung, i disabled my own selfwritten graph vertex renderer.. no changes. No less exceptions, nothing.

Perhaps this could be an issue by jung, but..

• why only on this mac – but no error/exception on others systems like windows and linux? Also I have a 2 years older macbookpro.. no problem there.
• why, or some time, is there no problem after fixing the file access rights (permissions) and rebooting the machine?

Currently, I have no solution.. the exeptions raises while painting the graph (which uses many paint()/Graphs objects ofc) moving/zooming it. I was able to catch some of the strange exceptions overriding the default visualizerviewer (by jung) and put in a small try-catch-wrapper of the corresponding method (here renderGraph). But other exceptions raised within javax.swing.Component and so on…

And.. how strange: the line

Thu May  7 15:04:28 X.localdomain java[2002] <Warning>: CGSResolveShmemReference : reference offset (65232) exceeds bounds (32768) on shmem obj 0x257e

I’m very appreciate if someone has an idea or solution.

Nun gibt es einige, dass es für diesen Fall ja X-Chat Aqua gibt. Das kostenlose und freie X-Chat Aqua ist dabei die Mac-Version von XChat, also demeinem IRC-Client für Linux/Unix & Co. Eins ist sicher: Das Programm hat mit 99% Wahrscheinlichkeit das Feature und die Funktion, die man haben will. Aber es 0 Design. Es sieht nicht nur aus wie ein Fremdkörper, die GUI und Benutzerführung ist scheiße und alles andere als “Mac”. Da kann man sich ja auch direkt XChat installieren.. jedes schlecht zusammengeschusterte Mac-Java-Programm sieht besser aus!

Eher zufällig fand ich heute die Software Linkinus. Ebenfalls für Macs, sieht es im Gegensatz zu Colloquy sogar noch eine Idee besser aus und hat auch mehr Funktionalitäten. Alleine das Menu der Einstellungen – aufgemacht wie die Systemeinstellungen – erschlägt einen. Colloquy ist dagegen sehr.. dezent. Ein Minuspunkt ist sicherlich, dass Linkinus Geld kostet; mit 15 Euro (Studenten) ist man dabei. Sollte die Software sehr gut sein, kann man darüber reden… aber ist sie das auch?

Ein Problem, was ich bei Colloquy habe: Bestehen mehrere parallele Verbindungen, so kann es durchaus passieren, dass sowohl Colloquy als auch der Benutzer – also ich — durcheinander kommt. Denn alle Channels und Queries landen in einer (!) gemeinsamen Liste. In der Regel funktionieren manuelle Queries, Joins, etc über die IRC-Befehle im Kontext der verknüpften Verbindung.. normalerweise. Mindestens einmal ist es mir aber schon passiert, das es durcheinander kam. In diesem Szenario hatte ich zwei unterschiedliche BNCs (Shroud), der /jump im zweiten Fenster löste einen Reconnect im ersten aus. Arg!

Hier ist Linkinus wesentlich besser organisiert, da alle Fenster nach Verbindung getrennt werden (zumindestens schon mal rein optisch).

Ein weiteres Problem: Enkodierung. Ich hatte lange Zeit UTF-8 eingestellt, aber leider sind die IRC’ler Windoofnutzer ein paar Hinterwändler, die per Standard einen Win-ISO-Code nutzen (wohl den *15?). Mittlerweile konnte ich Colloquy auch richtig einstellen, ich kann jetzt Sonderzeichen richtig senden – und lesen. Bei Linkinus wiederum kann man dies auch einstellen; während das Schreiben nun auch keine Probleme macht, kriegt das Lesen nicht hin: Es kommen bei bestimmten (wie ß) andere Zeichen an. Strange!

Das größe Manko an Linkinus ist aber, dass es einen einen kleinen, aber dennoch dummen Fehler hat: Farben & Formatierungen. Ein IRC-Benutzer kann ja seine Nachricht farblich verändern, bzw. fett, kursiv, unterstrichen. Unterstützt man diese Formatierungen, so führen zusätzliche Sonderzeichen ([, ]) dazu, dass aus Farben keine werden, Wörter verschwinden und Zeilenumbrüche eingeführt werden. Deaktiviert man diese Formatierungen, so gibt es naheliegenderweise keine Farben mehr; aber es fehlen aus unverständlichen Gründen Buchstaben der Nachricht. Mit Colloquy und X-Chat wiederum alles kein Problem.

Falls jemand ernsthafte Alternativen hat: Her damit. Meinen absoluten Wunschclient habe ich noch nicht.. bin eben nicht der Poweruser, aber bin auch kein IRC-Noob

Löscht man die Datei ~/Library/Preferences/com.apple.sidebarlists.plist, loggt sich aus und wieder neu ein, so ist die Sidebar wieder aufgeräumt. Man muss allerdings die Places wieder neu einstellen und ggf. Tweaks wie das Ausblenden der iDisk reaktivieren.

1. Spotlight-Index neu aufbauen lassen.
2. Boot-Cache und Kernel-Cache löschen & neustarten

Und alles ist wieder fast so schnell wie am Anfang..

Wunderbar einfach mit Onxy.

Time Machine Launcher

Mit diesem Widget kann man die TimeMaschine ein- und ausschalten, ohne in die Systemeinstellungen zu wechseln. Außerdem sind die Operationen “Jetzt sichern” und “TimeMaschine starten” mit einem Klick erreichbar.

Link: Lifehacker Top 10: Top 10 Things You Forgot Your Mac Can Do

Abhilfe: Einfach das betreffende Minitool (inkl. Ordner) löschen (Umbennen reicht scheinbar nicht).

Siehe auch.