Kategorien
Arbeit Java Programmiersprachen

Calender.roll() vs. Calendar.add()

Die Klasse java.util.Calendar ist scheiße mächtig. Gerade beschäftige ich mich wieder ein bißchen damit und bin auf folgendes gestoßen

Was ist der Unterschied? Letztendlich machen beide etwas Ähnliches, nämlich das Erhöhen/Erniedrigen eines Datums um einen Wert. Bei roll() werden nur die „größeren“ Einheiten so gelassen wie sie sind. D.h. (laut API) das beim 31. August 1999 ein roll(Calendar.MONTH, 8 ) im 30. April 1999 endet (weil die Jahres-Einheit „größer“ ist als die Monats-Einheit). Der Tag wird nur deshalb verändert, weil der 31. April nicht existiert und so das Nächstbeste genommen wird.

Ein add(Calender.MONTH, 8 ) führt allerdings dazu, dass die nächst größere Einheit bei Bedarf angepasst wird, d.h. aus dem 31. August 1999 wird dann der 30. April 2000.

Ein Kollege merkt sich den Unterschied so: Wie beim Zahlenschloß. Das hilft nicht bei add(), aber bei roll() wird ja auch jeweils nur der eine Ring des Zahlenschloß weiterge“roll“t und der Rest bleibt unbeeinflußt.

Zusätzlich noch ein Hinweis: Calendar.MONTH ist null-basiert, d.h. geht von 0-11 und 2 ist der März. Ein Calendar.getInstance().getTime().toLocaleString() passt das allerdings „intern“ an und bei der Ausgabe ist dann der März wieder der 3. Monat des Jahres.

Kategorien
Java

Eclipse Galileo (aka 3.5)

… ist frisch draußen. Javathreads.de hat schon ’ne schöne Übersicht über die Verbesserungen. Gleich mal ausprobieren 🙂

Kategorien
Java

JUnit und Eclipse

Ich nehm immer gerne die neuste Version einer Software. Vor allem wenn ich diese zum ersten Mal richtig benutze 🙂

So geschehen mit Eclipse und JUnit. Eclipse nutz ich in Version 3.4.2 und JUnit in 4.3.1. So weit so gut. Eclipse hat jetzt eine wunderbare Integration von JUnit. Man kann, in der Theorie, sowohl alle Tests einer Suite ausführen, oder auch nur einen. Ausser man macht das so wie ich:

public class TestClient {
  public static junit.framework.Test suite() {
    return new JUnit4TestAdapter(RMITestClient.class);
}

  public static void main(String[] args) {
    junit.textui.TestRunner.run(suite());
  }

  @Test
  public void someTest {
    Value value = getSomeAction();
    assertTrue("should be true", value);
  }

  @Test
  public void someOtherTest {
    Value value = getSomeAction();
    assertTrue("should be true", value);
  }
}

So, wie man sieht, habe ich zwei Tests (mit der @Test-Annotation) und zwei Funktionen die die Abwärtskompatibiliät für JUnit <4.0 geben soll. Irgendwo ausm Internet[tm]. Nunja, mit diesen beiden Abwärtskompatibilitätsfunktionen kann die Eclipse-UI nicht mehr nur einzelne Tests ausführen, sondern führt den einen Test den man markiert aus, und dann den Rest trotzdem. Suboptimal. Deswegen einfach die Funktionen sich schenken, die Abwärtskompatibilität ebenso und dann klappt's auch mit den Nachbarn.

Kategorien
Java

Maven

Eine meiner diversen Aufgaben wird es sein ein Java-Projekt von Ant auf Maven zu „portieren“. Nunja, es gäbe natürlich Abkürzungen wie AntRun, aber „wir“ wollen das ja richtig machen. Und als Goodie obendrauf gibts jetzt noch ein Buch über Maven, SOGAR auf Deutsch (gibt aber auch eine englische Variante):

Maven: The Definitive Guide
Englisch
Deutsch

Kategorien
Arbeit Java

EJB 3.1 – Charakteristiken

Ich beschäftige mich gerade mit EJBs. Und damit ich das alles verstehe, blog ich halt immer wieder bissle was 🙂

Was ist eigentlich eine EJB? Ich mach es mir einfach und übersetz einfach den passenden Teil aus der JSR 318 Abschnitt 2.3.1 Characteristics of Enterprise Beans

Die wesentlichen Teile einer Enterprise-Beans sind:

  • Eine Enterprise-Bean enthält normalerweise Geschäftslogik die auf den Daten des Geschäftes operiert
  • Die Instanzen einer EJB werden zur Laufzeit durch einen Container verwaltet.
  • Eine EJB kann zur Deployment-Zeit verändert werden, indem man ihre Umgebungsvariablen verändert.
  • Verschiedene Serviceinformationen, wie beispielsweise Transaktionen und Sicherheitsattribute, können zusammen mit der Geschäftslogik einer EJB-Klasse anhand von Annotations oder XML-Deployment-Deskriptoren spezifiziert werden. Diese Meta-Informationen können von anderen Werkzeugen während der Anwendungs-Zusammenstellung oder des Deployments genutzt werden.
  • Der Zugriff für Clients wird über den Container verwaltet in dem die EJBs deployed wurden.
  • Wenn die EJB nur Dienste anbietet die durch die EJB-Spezifikation vorgegeben sind, dann kann diese Bean in jeglichen EJB-kompatiblen Container deployed werden. Speziellere Container können zusätzliche Dienste, die über die Spezifikation hinaus gehen, anbieten. Eine EJB die auf solche zusätzlichen Dienste zugreift, kann nur in solche Container deployed werden, die einen solchen Service anbieten.
  • Eine EJB kann in eine zusammengestellte Anwendung eingefügt werden, ohne das irgendwas am Quellcode geändert werden muss. Auch ein erneutes Kompilieren ist nicht notwendig.
  • Der Bean-Provider definiert die Client-Sicht einer EJB. Dies kann manuell geschehen, oder automatisch durch Anwendungs-Deployment-Werkzeuge. Die Client-Sicht wird weder durch den Container oder den Server beeinflusst in dem die Bean deployed wurde. Somit ist sichergestellt das sowohl die Bean als auch ihre Clients in verschiedene Umgebungen deployed werden können, ohne Änderungen vorzunehmen oder neu zu kompilieren.

Dies ist eigentlich alles selbstverständlich und logisch, aber man muss ja mal klein anfangen 🙂

Kategorien
Java PC & Accessoires Praxissemester Studium

Java Collection Interface

Java hat ein paar nette Klassen. Und weil ich mir nie merken kann was jetzt der Unterschied zwischen ‚Set‘ und ‚List‘ ist, hier die Erklaerung. Deutsch/Englisch gemischt, zumindest was die Benennung angeht.

  • Collection — Die Wurzel der Collection-Hierarchie. Eine Collection repraesentiert eine Gruppe von Objekten, auch bekannt als seine Elemente. Das Collection Interface ist die gemeinsame Basis aller Unterklassen und wird benutzt um die Collections untereinander kompatibel zu machen. Ausserdem ermoeglich es einen allgemeinen Zugang zu allen Collections. Manche Untertypen erlauben Duplikate, andere nicht. Manche sind sortiert, andere nicht.
  • Set — Eine Collection die keine doppelten Elemente erhalten kann. Am Besten erklaert ist das an einem Pokerblatt, bei dem keine Karte doppelt vorkommt. Ausser jemand schwindelt und betruegt, aber das gehoert hier nicht hin.
  • List — eine sortierte Collection (manchmal Sequenz genannt). Listen koennen Duplikate enthalten. Im Prinzip also eine Menge von Football-Star-Sammelkarten, von denen man auch welche doppelt haben kann. Wer Vector kennt, dem kommt das bekannt vor.
  • Queue — eine Collection die mehrere Elemente beinhalten kann. Uebersetzt ist das eine Warteschlange, was auch die Funktion erklaert. Meistens wird FIFO benutzt (aber nicht zwingenderweise), d.h. das was als erstes reinkommt, kommt auch als erstes wieder raus. Warteschlange am Metzger halt.
  • Map — ein Objekt das eine Schluessel-Wert-Beziehung repraesentiert. Hier sind wieder keine doppelten Eintraege erlaubt. Vergleichbar mit Schluessel-Schloss, jeder Schluessel passt nur in ein Schloss. Gut, mein VW-Schluessel passt auch in den Polo eines bekannten, aber wir sprechen hier nicht von Autos 🙂

Quelle: http://java.sun.com/docs/books/tutorial/collections/interfaces/index.html

UPDATE: Noch eine Entscheidungshilfe als Bild:

Java Collections Entscheidungshilfe
Java Collections Entscheidungshilfe