Aki használ Sonar-t (illetve mostanában már SonarQube a neve, mert lett egy támogatott és egy közösségi kiadás belőle), annak ismerős lehet a magas számosságú Magic number (jobban mondva Unnamed numerical constants) bejegyzés, mint Minor súlyosságú hiba. A Magic number – mint programozástechnikai hiba – elismert és létező jelenség, az alábbi (a Wikipedia linkről idézett) kódrészletben az 52 és az 53 tipikusan ilyen szám:
for i from 1 to 52
j := i + randomInt(53 - i) - 1
a.swapEntries(i, j)
Logikus kicserélni arra egy változóra, amely megmagyarázza az értelmét:
constant int deckSize := 52
for i from 1 to deckSize
j := i + randomInt(deckSize + 1 - i) - 1
a.swapEntries(i, j)
Ettől egy kicsit javult a programunk olvashatósága és könnyebb érhetősége, de még maradt egy szám, amelyet nem magyaráztunk meg, az 1, amelynek ráadásul több értelmezése is van:
- egytől kezdjük a ciklusban a számolást
- egyet adunk hozzá a kártyák számához
- egyet vonunk le a kiszámolt indexből
Nyilvánvaló, hogy ha kicserélnénk ezt a számot három különböző konstansra, akkor a könnyen olvasható és és érthető programunkból olvashatatlan és érthetetlen program lesz:
constant int deckSize := 52
constant int deckStart := 1
constant int deckOffset := 1
constant int randomOffset := 1
for i from deckStart to deckSize
j := i + randomInt(deckSize + deckOffset - i) - randomOffset
a.swapEntries(i, j)
Ebből kifolyólag a Magic number ellenőrzésekor létezik egy kivétellista, amely ezeket a gyakori – és általában nem változtatott – számokat tartalmazza; SonarQube esetén ez öt elemű:
- -2, -1, 0, 1, 2
Ezzel sikerült átesni a ló másik oldalára, több száz Magic number hiba keletkezik a projektekben, amelyeknek a bűne alapvetően az, hogy a használt konstans például 3 vagy 4. Ha kicsit körülnézünk, akkor láthatunk több nagyobb projektet, ahol ezt a listát kibővítették azokkal a konstansokkal, amelyek gyakran előfordulnak és a hibák kijavítása többet ront a programon, például:
- http://maven.apache.org/plugins/maven-deploy-plugin/checkstyle.html: -4, -3, -2, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 32, 64, 100, 128, 256, 512, 1000, 1024
A tavaly májusi bejelentésnek megfelelően a Google folyamatosan kikapcsolja a Google Code kiszolgálón a bináris letöltések lehetőségét, jobban mondva erre a célra a Drive használatát szorgalmazza.
A döntést több fejlesztő is dühösen fogadta, a szkriptek megjelenésével valószínűleg jelentősebb migráció indul majd meg a többi nyílt forrású rendszereket kezelő szolgáltatások felé, mint a GitHub vagy a SourceForge. A Google Code projektek közül jó pár több lábon áll, a népszerű K-9 levelező kliens például a forráskódját a GitHub-on tartja, a hibajegyek és igények kezelésére a Google Code megoldását használja, a Wikit is már átköltöztette a GitHub-ra... az elkészült bináris állományokat eddig a Google Code-on tárolták, ha erre nem lesz lehetőségük a továbbiakban, akkor már csak az issue kezelő rendszer miatt van csak Google Code függőségük.
A fejlesztőkben felmerül az a kérdés is, hogy mik a Google tervei ezzel a szolgáltatással kapcsolatban... sok fejlesztés nem történt az utóbbi években, a felület és a működésmód – kis sarkítással – pont annyira fapados, ahogy az indulásakor volt, nyoma nincs a többi Google terméket jellemző a folyamatos fejlődésnek, vagy akár csak az ergonómiai javulásnak. Vajon a többi kukázott Google termék sorsára jut a Google Code is, vagy ez csak egy nagyobb koncepcionális váltás előszele?
A Java EE 8 kérdőív első része után megérkezett a második rész, amely indításképp egy bejelentéssel kezd, hogy a Java EE 8 fő fókusza a cloud támogatás mellett a PaaS, a SaaS és a Multitenancy. Ezen túl kérdéseket válaszolhatunk meg a szabványosított naplózásról, a korrekt jelszókezeléséről, a group-to-role összerendelésről, a JASPIC (Java Authentication Service Provider Interface for Containers) szabványosításáról, a SecurityProvider kiterjesztésről, a beágyazható EJB konténerről, a deploy és monitoring API újratervezéséről, illetve a CORBA/IIOP, a JSR77 és az EJB2.x kivezetéséről.
A kérdések és a lehetséges válaszok alapján az látszik, hogy valóban a Java EE fájdalmas pontjaira böktek rá, így remélhetőleg a lendület nem törik meg és valóban megoldódnak ezek a problémák.
A kérdőív: https://www.surveymonkey.com/s/JavaEE8-Part2
A 2010. januárjában lezárult felvásárlás negyedik évfordulóján James Gosling (jelenleg vezető szoftverarchitekt a Liquid Robotics cégnél) egy amerikai stílusú értékelést adott ki, mégpedig az alábbi képen láthatót:
Lehet vitatni az értékelését, sok igazság van benne... 
A többször is módosított (immár múltbeli) kiadási dátumok után az Oracle bejelentette, hogy március 18-án kerül kiadásra a véglegesnek nevezett Java 8, akkor is, ha maradnak benne ismert hibák. Mint ismert, a Java 8 kiadásból már kidobásra kerültek anno fontosnak vagy hasznosnak tartott modulok, így például a Jigsaw (Java8: Jigsaw nélkül?) is a Java 9 kiadásba csúszott. Mathias Axelsson, az Oracle JDK 8 release manager-e szerint már csak blokkoló hibák miatt csúszhat a kiadás, így célszerű már most letölteni a készülő előzetes kiadásokat a http://openjdk.java.net/projects/jdk8/ oldalról, illetve körültekintően tesztelni az új verzióval az éles üzemben lévő fejlesztéseinket, ugyanis a felhasználóknál a Java 7 frissülni fog Java 8 verzióra...
Az early-access kiadásokat nem kedvelőknek a január 23-át kell felvésni a naptárba, ekkor kerül kiadásra a release-candidate, amelyben már csak apró simítások történnek a GA kiadás előtt.
Az Oracle – rá nem jellemző módon – egy kérdőívet tett közzé a Java EE 8 fejlesztési irányaival kapcsolatban, amelyet a közeljövőben egy újabb fog követni. A kérdőív érinti a Java EE 8 specifikációba emelendő JSR-ek szükségességét, a JavaScript támogatás és a szerver oldali eseménykezelést, a JSF szükségességéről, a Security Interceptor lehetőségéről, a CDI általánosabbá tételéről, a NoSQL támogatásról és végül egy szabad szöveges vélemény rovattal is találkozhatunk.
A kérdőív: https://www.surveymonkey.com/s/KGV7RWS