equals() und hashcode() überschreiben

Das leidige Thema equals() und hashcode()… Man muß glaube ich nicht erklären, wieso man die zwei Methoden überschreiben soll. Vielmehr ist es interessanter, wie man diese richtig überschreibt. Folgende Punkte müssen dabei berücksichtigt werden:

  • Welche Felder sind wichtig für den Vergleich auf Gleichheit?
  • Wie wichtig ist die Ausführungsgeschwindigkeit?
  • Wie sorge ich dafür, daß ich nicht vergesse equals() und hashcode() zu erweitern, wenn die Klasse geändert wurde (neue Felder kamen hinzu)?

Im Hinblick auf diese Punkte, betrachten wir diese drei Möglichkeiten equals() und hashcode() zu implementieren:

  1. Reguläre Implementierung ohne Hilfsbibliotheken.
  2. EqualsBuilder & HashcodeBuilder aus commons-lang3 per Builderklasse
  3. EqualsBuilder & HashcodeBuilder aus commons-lang3 per Reflection

Die Implementierungen werden an folgender sehr einfachen (Kontainer- oder DTO-) Klasse getestet:

Weiterlesen

Beschränkung der API-Zugriffsrate mit nginx als Proxy-Server

Jeder Entwickler, der mal mit Googles APIs gearbeitet hat, kennt das Problem – bei zu vielen Requests pro Minute werden die Anfragen nicht mehr verarbeitet und man bekommt einen 403 Fehler mit Statuscode OVER_QUERY_LIMIT. Und das ist gut so, denn damit möchte man beispielsweise folgendes erreichen:

  • Die Rechenzeit soll fair verteilt werden
  • Die Applikation soll nicht mehr Daten empfangen, als sie verarbeiten kann
  • Der Datenklau durch “Data scanning” bzw. “Data scraping” soll zumindest erschwert werden
  • Brute-Force Login-Versuche können so erschwert werden

Welche Möglichkeiten gibt es derartige Limitierung umzusetzen? Na gut, die erste und sehr naive Methode (habe ich tatsächlich mal gemacht…) wäre zum Beispiel ein Anfrage-Zähler in der Applikation selbst. Man implementiere einen ServletFilter in dem die IP-Adresse sowie die letzten Anfragen (Requests) inkl. Zeitstempel des Clients gespeichert und ausgewertet werden. Weiterlesen

Abhängigkeiten verbannen mit maven-enforcer-plugin

Wenn mehrere Entwickler an einem maven-(multimodul-)Projekt arbeiten, ist es ja normal, dass neue Bibliotheken (mit oder ohne Absprache) über maven angebunden werden. Falls aber bestimmte Bibliotheken unerwünscht sind, sei es aus Lizenzgründen oder weil der Chef es einfach nicht will, ist es möglich solche Abhängigkeiten ein einer Art “Schwarze Liste” festzuhalten. Beim Bauen der Anwendung prüft maven, ob die Abhängigkeit verwendet werden darf. Falls nicht, wird der Compile-Vorgang mit einer Fehlermeldung abgebrochen.

Abhängigkeit verbannen

Nehmen wir mal als Beispiel die Bibliothek Lombok. Um Lombok unternehmensweit zu verbannen, muss in jeder pom.xml maven-enforcer-plugin wie folgt konfiguriert werden:

Nur bestimmte Version zulassen

Es ist außerdem möglich das Plugin so zu konfigurieren, dass nur eine bestimmte Version einer Bibliothek zugelassen wird. Nehmen wir an, es soll nur die Version 2.4.1 des Jackson-Mappers verwendet werden. Weiterlesen

Unnötige maven Abhängigkeiten entfernen – mvn dependency:analyze

Problemstellung

maven ist ein mächtiges Build-Management-Tool. Es ist sehr komplex, enthält Unmengen von Erweiterungen und ist leider sehr dürftig dokumentiert.

Copy-Paste. Man fügt eine neue Abhängigkeit, die IDE bindet die Bibliotheken an und nach einigen Sekunden kann man loslegen. Mit der Zeit wächst die pom.xml und öfters vergisst man die nicht mehr benötigten Abhängigkeiten zu entfernen. Als Resultat wird die kompilierte Anwendung unnötig größer . Ferner dauert das Kompilieren deutlich länger, wenn die Abhängigkeiten erst mal heruntergeladen werden müssen.

Wie auch immer. Unnötige Abhängigkeiten sollen entfernt werden. Und so geht’s. Weiterlesen