A Red Hat bejelentette a WildFly 8 első stabil kiadását, amely implementálja a JavaEE 7 specifikáció Web és Full profilját is, így a Glassfish után ez az alkalmazás szerver teljesítette az teszteket. A WildFly a JBoss Community Edition utója, a Red Hat tavaly választotta a WildFly nevet, hogy a JBoss Enterprise Application Platform (EAP) és a Community Edition (CE) változatokat jobban megkülönböztesse... illetve jobban elválassza a kódbázist tekintve... Külön érdekesség, hogy az Oracle azon bejelentése után, hogy a Glassfish hivatalos támogatását megszüntette, Arun Gupta átigazolt a Red Hat csapatához.
De nézzük inkább az újításokat és javításokat:
- Undertow.io került a korábbi Tomcat származék Web szerver helyére
- Az alkalmazás szerveren kettő nyitott port maradt: a 8080 és a 9090
- A menedzsment konzol támogat több szerepkört, így egy szerveren lehet több adminisztrátor felhasználó
- JDK8 kompatibilitás
- Régi technológiák kivezetése (CMP helyett JPA, JAX-RPC helyett JAX-WS, JSR-88 helyett CLI)
- ...és még sok más apróság
Érdemes kipróbálni... én már a Beta1 óta próbálgatom, ígéretes... 
A http://java.sys-con.com/node/2958235 oldalon a Parasoft szponzorációjával elkészült egy infógrafika, amely a Continuous Testing folyamatát, jellemzőit és előnyeit mutatja be, a végén egy diszkrét reklámmal...
Érdemes végigböngészni, hasznos dolgok vannak alább:
A tavaly és tavaly előtt kiderült biztonsági hibák kapcsán nem lehet elégszer mondani: a Java futtatókörnyezet legyen friss vagy legyen kikapcsolva a böngészőben, mivel egyre több rosszindulatú program használja ki a Java környezetben meglévő biztonsági hibákat. Legutóbb a Java7 update 21 alatti verziókat támadó programra (malware-re) találtak rá a Kaspersky munkatársai, amely DDoS támadásokra felhasználható multiplatformos botnetet telepít a megfertőzött gépre.
Ideje lecserélni a Java7 update 51 alatti Java verziókat a munkaállomásokon, mivel a víruskeresők mindig egy kicsit le vannak maradva a hibát kihasználó programok mögött és már nem nyújt védelmet az se, hogy kevéssé elterjedt operációs rendszert használunk.
Szóval: frissíteni, frissíteni, frissíteni!
A Technical Debt fogalom már rég befészkelte magát a (vezető) fejlesztők és az architektek fejébe, ugyanis ez a "technikai adósság" egy darab szám, ami többé-kevésbé jól jellemzi a forráskód állapotát.
A forráskód ugyanis olyan, hogy a fejlesztés során folyamatosan változik. Ha rendszeresen jönnek üzleti igények, amelyeket az üzlet minél hamarabb éles üzembe szeretne látni, hogy pénzt tudjon keresni, akkor a gyors megoldások mentén beszivárognak rossz megoldások is. Ezeket a tákolásokat előbb-utóbb kell oldani, mivel hibákat rejtenek magukban a le nem kezelt használati esetekre, illetve a fejlesztők képesek precedens értékűnek tekinteni ezeket a megoldásokat és egyszerűen lemásolják, mint gyors megoldás.
A forráskód teremtette adósság növekedésnek másik ága az, hogy a világ is változik a meglévő forráskód körül, ami jó megoldás volt pár hónapja vagy éve, az mára már elavult. A használt keretrendszerek is változtak, esetleg új keretrendszerek jöttek ki, amelyekkel megoldhatóak az eddigi kerülő megoldások...
The biggest difference between the two types of debt is that while technical debt grows faster the more you change a codebase, competence debt grows faster if you stop changing it!
Szóval itt az új fogalom, a Competence Debt, amely sokkal rejtettebb, mint a technikai adósság, ugyanis a fejlesztők kompetenciájáról van szó: arról, hogy a meglévő kódbázist és a használt keretrendszereket mennyire ismerik, mennyire járatosak ezeken a területeken. A nagy különbség pedig az, hogy ha nem nyúlunk a forráskódhoz, akkor a kompetencia adósság jobban növekszik, mint a technikai, amely általában akkor növekszik, ha üzleti nyomásra módosítjuk a kódot és nem állunk meg rendet tenni.
Nálatok mekkora a Competence Debt?