Gleich zwei Termine zum Thema Java Concurrency stehen in der Region an:
Java User Group Karlsruhe - "The Secrets of Concurrency"
Mittwoch, 2009-02-11 19:15 Uhr
Dr Heinz Kabutz (PhD CompSci) Author des The Java(tm) Specialists' Newsletter
Ort: Uni Karlsruhe, ATIS, Am Fasanengarten 5, Geb. 50.34, 76131 Karlsruhe, Raum UG102
und
ObjektForum Stuttgart - Herausforderung Multikern-Systeme
Montag, 2009-02-16, 18.30 Uhr
Prof. Dr. Walter F. Tichy Universität Karlsruhe / FZI
Ort: Alte Scheuer, Degerloch
Ich bin auf der Suche nach (bezahlten) Experten im Bereich JbossMQ. Wir haben uns natürlich zuerst an RedHat gewannt mit unserer Anfrage. Die Annahme war, wir könnten uns eine Fragestunde mit einem der Entwickler kaufen (für eine spezifische 4.2 JBoss Version). Leider bietet RedHat diese Option nicht an. Deswegen haben wir uns sogar überlegt eine entsprechende Partnerschaft mit Support Vertrag abzuschliessen. Leider würde uns auch die nicht ermöglichen unsere bisherige Release Stratagie weiterzufahren, mal ganz abgesehen davon dass wir erheblichen Zusatzaufwand (Arbeit, Geld) für die Kundenlizensierung aufbringen müßten. Effektiv wäre dies ein embedded kommerzielles Produkt, was wir uns damit einhandeln würden.
Diese unflexiblen Haltung ist eine Enttäuschung für uns. Es sieht danach aus, dass RH sich für dieses Vorgehen entschieden hat aus der Angst mit bezahltem Support für Jboss.org sich das Geschäftsmodell für JBoss.com kaputt zu machen. Diese Strenge Trennung zwischen den Produkten und die Distanzierung von der Community war mir so bis dahin noch nicht bewusst geworden.
Aus dem Grund suche ich jetzt Entwickler (idealerweise Commiter) die sich mit JBossMQ auskennen (konkret geht es um das bekannte Problem dass MDBs sich aufhängen). Wir bezahlen nach Aufwand, bitte direkt Kontakt mit mir aufnehmen.
Es ist immer wieder interessant die Analysen von Dan Dyer zu lesen. Er ist der Kopf hinter Java library uncommons-math, die insbesondere brauchbare Alternativen für Zufallszahlengeneratoren liefert.
int[] vals = new int[8];
for (int i = 0; i < 1500; i++)
vals[new Random(i).nextInt(8)]++;
System.out.println(Arrays.toString(vals));Dass dieser Code "falsch" ist weil er jeweils einen neuen PRNG erzeugt ist offensichtlich, warum es aber keinerlei vernünftig verteilte Zufallszahlen liefert (trotz den unterschiedlichen Seeds) ist eine ganz andere Sache, die er in seinem
Artikel gut beschreibt.