0. Javában íródott C++ helyett
1. Deprecated API használata - Nashorn, import jdk.nashorn.api.scripting.ScriptObjectMirror és hasonló sorok több helyen. Egy olyan programnál, ami cutting edge enterprise megoldásként hirdeti magát, fontos lenne, hogy igyekezzünk a legfrissebb LTS JDK által biztosított könyvtárakat használni.
2. Java internal API-k használata, pl. sun.misc.Signal, sun.misc.SignalHandler, sun.misc.Unsafe. Ez sokkal súlyosabb, mint pusztán a deprecated API, mivel a deprecated cuccokhoz legalább van dokumentáció, és megbízható a működésük, csak legfeljebb korlátozzuk magunkat korábbi Java verziókra (ami biztonsági kockázat, meg egy idő után kínos is, de lássuk be, frissíteni is kellemetlen). Egyrészt ezeknek a működése JDK implementációtól (és a Signal esetében operációs rendszertől) függ, tehát a deprecation problémákon kívül elveszítjük a Java egyik fő vonzerejét, a platformfüggetlenséget, másrészt rendkívül sok programozói hibát lehetővé tesznek, ami ellen egyébként a JVM védekezni próbál.
3. Unsafe Unsafe. Az Unsafe API-ban, a Signallal ellentétben (ami teljes mértékben oprendszer specifikus, és az egyszeri Java devnek nem is kéne vele foglalkoznia) vannak hasznos, publikus API-ba is átemelhető funkciók. Az OrientDB a saját dokumentációjában büszkélkedik, hogy mallocol. Pofátlanul. Ha már úgyis oprendszer-specifikus a kód, nem lenne egyszerűbb megírni C++-ban, ahol proprietary internal API-kon alkalmazott, frissebb Java verziókban már teljes mértékben ellehetetlenített reflection hackek nélkül, két sor teljesen általános kóddal szabadon allokálhatunk olyan memóriát, amilyet csak akarunk? Ráadásul debugoláshoz is rendelkezésünkre állnak eszközök, mivel egy C++ fejlesztőnél lehet számítani arra, hogy elfelejt felszabadítani egy ötven byte-os tömböt, amiből aztán összejön fél nap alatt két giga memleak.

  @Test
  public void shouldShutdownServerWithDirectCall() throws Exception {

    OServerShutdownMain shutdownMain = new OServerShutdownMain("localhost", "2424", "root", "rootPassword");
    shutdownMain.connect(5000);

    TimeUnit.SECONDS.sleep(2);
    assertThat(server.isActive()).isFalse();

  }
D:\Sulisszar\Tesztalap\TA_Echo_3\server\src\test\java\com\orientechnologies\orient\server\OServerShutdownMainTest.java, 79. sor.
Ez egy négy soros metódus.
4. Thread.Sleep használata unit tesztben. Google első keresési találata, amikor megkérdezzük tőle, hogy használjunk-e Java unit tesztben thread sleepet, vastagon kiemelve, hogy NE használj ilyet. További találatok: Hogyan kerülhetem el? Miért rossz ötlet? Vannak alternatívái? A szerver modul tesztjeinek első ránézésre fele használ Thread.Sleepet.
Anekdota: D:\Sulisszar\Tesztalap\TA_Echo_3\core\src\test\java\com\orientechnologies\orient\core\db\OrientDBEmbeddedTests.java file 261. sorában van egy elsőre értelmesnek kinéző teszt. Ami történik: 3000 ms-re inicializáljuk a shutdown timert, ennek a harmadára az update timert, és 4100 ms múlva megnézzük, hogy leállt-e már. Ugyanazon a gépen, ugyanazzal a JDK-val, többszöri próbálkozás során kétszer átment, nyolcszor megbukott. Azért nem szabad Thread.Sleepet használni, mert egyáltalán nem reprodukálhatóak az eredmények, tehát értelmét veszti a tesztelés. Például ugye ez:
[ERROR] autoClose(com.orientechnologies.orient.core.db.OrientDBEmbeddedTests)  Time elapsed: 23.891 s  <<< FAILURE!
java.lang.AssertionError: expected null, but was:<D:\Sulisszar\Tesztalap\TA_Echo_3\core\.\target/test>
	at com.orientechnologies.orient.core.db.OrientDBEmbeddedTests.autoClose(OrientDBEmbeddedTests.java:262)
5. A shutdownMain.connect metódus paraméterét iTimeoutnak hívják, első ránézésre milliszekundumban van. De ha 5 másodpercre inicializáljuk a timeoutot, és két másodperc múlva asserteljük, hogy már inaktív-e, ez a teszt mindig elbukik, nem?
6. Nem, mert a connect soha nem használja a paraméterét. Nem ez az
7. Hungarian notation használata. Mert 2007-ben írunk C++ libraryt. Egy erősen típusos nyelvben, mint a Java, modern fejlesztői környezetekkel teljes mértékben szükségtelen típus-információt belekódolni
7.5. És azt is ostoba módon. Az előző példából az OServerShutdownMain konstruktora úgy néz ki, hogy
public OServerShutdownMain(final String iServerAddress, final String iServerPorts, final String iRootUser, final String iRootPassword) { ... }
Kap négy integer paramétert. (Az i itt feltételezhetően immutable-t jelent, de Javában ugye az is része a típus-információnak, amihez csak fölé kell mennünk a kurzorral)
8. Saját Deprecated osztályok használata. A core modul fordításakor (Java8, szóval a Nashorn itt még nem deprecated) a ~100 sornyi kezdő warningnak a fele saját deprecation probléma, a másik fele a Java internal API-k használata.
9. Assert spam.
D:\Sulisszar\Tesztalap\TA_Echo_3\server\src\test\java\com\orientechnologies\orient\server\OClientConnectionTest.java
Ebben a tesztben például az "egység" a kliens-szerver kapcsolat, és minden egység saját tesztje önmagában három assertből áll. Emellett ugyanazt az egységet (kezdeti kapcsolat felépítése) mindenhol letesztelik, ahol valamiféle erre rákövetkező lépést tesztelnek. Fölösleges, nehezen olvasható, nehezen értelmezhető, már az is komoly problémára utalhat, hogy egy egység működését három különböző assertionnel ellenőrzik, de hogy ezt miért kellett mindenhova odamásolni, azt sem értjük.
10. Hiba-propagáció a server modulban, amikor minden teszt-sorozat után leáll a szerver, és minden leálláskor teszteli, hogy van-e memleak, és a saját készítésű memleak teszt (mivel Javában vagyunk, itt nincs Valgrind) elég keményen assertel. Ha volt egy memleak, az ott is marad, és az összes utána következő teszt meghal rajta. És van memleak.