Java 9 viivästyy – saatavana heinäkuussa 2017

Tuoretta uutista, tosin ei yllättävää. Java 9 – jota on jo lykätty useita kertoja, ja jonka ominaisuudet ovat kaikki aiemmista versioista lykättyjä – viivästyy vielä. Tällä kertaa ihan ymmärrettävästä syystä. Se ei vain ole vielä valmis, ei ehdi, ja muutokset ovat merkittäviä.

Mutta käytännössä siis mennään Java 8:lla vielä tovi, ja aikaa on oppia mikä kaikki muuttuu Java 9 myötä. Tämä viimeisin lykkäys ei ole kuin 4kk lykkäys, ja toki nyt jo saatavana olevat EA buildit ovat varsin pitkällä. Mutta kun corea sorkitaan, pienikin muutos on iso muutos ja vaatii aikaa ja rakkautta. 😉

Tieto ei ole toki vielä vahvistettua, mutta lykkäystä on ehdotettu, ja ehdotus menenee läpi koska valmista ei vain tule aiemmalla aikataululla.

Lähde: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004887.html

Mainokset

JavaOne 2014 käynnissä

Jep, JavaOne 2014 on taas käynnissä San Franciscossa. En ole tänä vuonna itse paikan päällä, mutta aika on merkattuna kalenteriin ja seuraan mielenkiinnolla etänä.

Missä mennään tällä hetkellä on Java 8 SE käyttöönotto Lambdoineen kaikkineen, ja ME 8 on myös julkaistu, ja EE 8 työn alla seuraavaksi. Olen blogaillut aiemmin jo Javan seuraavista askelista, Java SE 9 tulee ehkä viimein näyttämään mitä Project Jigsaw – Javan modulaarisuusjärjestelmä tarkoittaa. Se ei ole lopulta erityisen seksikäs aihe, mutta se on tärkeä. Javasta on vuosien saatossa tullut aikamoinen bloat, turvoke 😉 Ajatus modulaarisemmasta Javasta on hyvä skaalatessa pienempään päin, ja Mavenin suosio näyttää että moduulien avulla skaalaus ylöspäin on myös tärkeää. Jos viimein saadaan Javaan tukea myös moduulien versioiden huomioimiseen ihan ydintasolla, paketista tulee aika kova. Brian Goetz valitettavasti komennettiin alas lavalta kesken Java 10 mallailun 😉

Jigsaw projektissa on hyvä huomata kaksi vaihetta. Vaihe 1 on purkaa Javan hurja ristiinviittaus-spaghetti pakettien välillä ja saada Javan parikymmentämegaisesta ytimestä aidosti modulaarisempi. Tätähän aloitettiin jo joskus Java 6u10 aikoihin nimellä kernel. Toinen askel on sitten alkaa käyttämään tätä moduulijärjestelmää omien ohjelmistojen kehitykseen yhtälailla, Mavenin tapaan. Tarkoituksena ei näillä näkymin ole kuitenkaan korvata Maveniä repository-puolella, lähinnä moduulien riippuvuuksien julistuksessa. Riippuvuudethan sitten voivat olla paikallisia tai verkon yli noudettavia.

Vaikka on mukava tarkkailla mitä tulevaisuus tuo mukanaan, Java 9 on vielä aika kaukaista. Tämä vuosi 2014 on edelleen Java version 8 ramp-up aikaa: Lambdoissa, rajapintojen oletusmetodeissa, ja kokoelmakirjastojen uusissa stream-piirteissä on sulateltavaa runsaasti ja harva niitä vielä arjessa käyttää. Sertifiointi Java 8:lle on tätä kirjoittaessa vasta beta-tasossa, ja sekin mielenkiintoisella tavalla uusittu.

Tuolla tech keynote joka on klassisesti ollut kiinnostava avaus koko tapahtumalle:

http://medianetwork.oracle.com/video/player/3811045975001

Goetz saa kyytiä kohdassa 34:27 alkaen 😉

JavaOne lähestyy – TJ 9

Java One 2013 seminaariin San Franciscossa on enää reipas viikko aikaa. Siellä on taas luvassa täyteen pakattu viikko täynnä tietoa nykypäivän jännittävimmistä sovelluskehitysalustoista – ja tehdyistä projekteista. Tämä on kuin muotinäytös nörteille: Catwalkilla astelee sorjasääristen kaunottarien sijasta intomielisiä insinöörejä puhumassa asioista jotka ovat lähellä sydäntä. Kun Java-koodaajia löytyy maailmanlaajuisesti jo yli 10 miljoonaa – ja tänne suurimpaan tapahtumaan kokoontuvat kaikki kynnelle kykenevät – ilmassa on niinsanotusti urheilujuhlan tuntua 😉

The Duke

Odotettavissa on tiivis annos kesällä julkaistusta Java EE 7 alustasta ja sen käytöstä, edelleen paukutetaan jo laajassa käytössä olevan Java EE 6 alustan parhaita puolia, ja odotellaan ensi vuodeksi kypsyvää Java SE 8 versiota. Näiden ohella tehokkaat vaihtoehtokielet kukoistavat. Vastakkain pistetään Groovy, Clojure ja Scala – ja Grails vs Play. NoSQL kannat, Riak, MongoDB, big data, business intelligence, dashboardit ja eräajot kukoistavat. Käyttöliittymiä koristellaan nykyisen vaativan maun mukaan niin webissä kuin mobiilissa. Skaalautuvuutta pitää piisata miljardeille käyttäjille 😉

Fork&Join

Puuhailen tässä itsekin esittelyvideota EE 7 alustasta – jonka parissa on tullut vietettyä aikaa. Tieturin Java EE ohjelmointi-kurssi on ollut viime kevään hittejä, ja syyskaudellekin mahtuu vielä lisää osallistujia. Kurssi painottuu pääosin EE 6  -tasoon, mutta EE 7 -päivityksiäkin on jo luvassa. Kyseessä on sikäli mahtava paketti että pistimme sinne kaikki tärkeimmät Java EE teknologiat yhteen nippuun joita aiemmin joutui metsästämään kolmen päivän paketeissa. Ja mikä tärkeintä, nyt pääsee näkemään kokonaisuuden. Härskiä promootiotahan tämä on mutta koulutus on oikeasti mahtava jos nykymaailmassa Java EE alusta toimenkuvaan millään lailla kuuluu. 😉

IMG_8172

Jo viime kerralla JavaOnessa bloggasin ja twiittasin ahkerasti reaaliajassa mitä kaikkea osui tutkaimiin. Nyt kollega antoi vinkin Vine-nimisestä palvelusta jossa ideana on kuuden sekunnin videot aiheesta mistä hyvänsä. Kissavideot näyttivät olevan suosiossa nykyisellään, mutta vaikutti sen verran hauskalta Nexus 7 tabletista käsin että saatan pajauttaa pari mietelmää paikan päältä sinnekin puolelle.

JavaOne taskuversio oli lifesaver kun sessioita oli siellä sun täällä. Go mobile! ;)

Se tämän hetken kovin Java-kurssi eli Java EE -ohjelmointi löytyy täältä – mukaan vain jos rahkeet riittävät:

http://www.tieturi.fi/kurssit/kurssi.html?course=85000180

Kaikki Tieturin Java-kurssit (Ja Scala ja Groovy) tarjolla osoitteessa:

http://www.tieturi.fi/java

JavaOne 2013 agenda – jos olet tulossa niin moikkaa toki paikan päällä:

http://www.oracle.com/javaone/agenda/index.html

JavaOne 2011 Loppuraportti (Koodaajan yhteenveto)

No niin, JavaOne 2011 San Franciscossa on ohi. Viikko tiivistä toimintaa on siis takana ja on aika katsoa mitä jäi käteen. Tässä avaukseksi musavideo jolla ensimmäisen tech keynoten ensimmäiset puheet avattiin: Java 4 Life 😉

http://www.youtube.com/watch?v=b-Cr0EWwaTk&feature=player_embedded

Miinusta tapahtumasta saa antaa hieman. Viime vuonna valiteltiin kovasti epäkohtia jotka pääosin liittyvät siihen että JavaOne on toisen luokan sidekick show verrattuna Open Worldiin – alkaen sen hajautuksesta eri hotelleihin. Näiden suhteen ei ole tapahtunut mitään muutosta, pikemmin huonompaan suuntaan menty. Samoin uskomatonta miten wifi yhteyttä ei saada vakaaksi, eikä langallisiakaan yhteyksiä ole tarjolla.

Hintaan minkä osallistuminen maksaa jokainen osallistuja voisi saada oman tukiaseman käyttöönsä 😉 Kun yrittää testata oppimiaan asioita ja kirjoittaa blogia oli pakko turvautua hotellihuoneen langalliseen yhteyteen aika ajoin, se on taas pois yhteisöllisyydestä ja verkostoitumisesta. Tästä myös pitkä miinus. Miinusta myös keynote osioiden pitkistä javaan liittymättömistä diamond partner puheenvuorolässytyksistä. Ne taitavat tosin olla seminaareissa pakollinen riesa, mutta ainakin allekirjoittaneen osalta seminaareissa itse pyrimme välttämään moisia. Onnistutaanko siinä aina, en tiedä. Ehkä tämän kaliiberin seminaareissa on vain pakko sietää jonkun verran poliittisesti jaettuja mainospuheita. Mutta onko ne pakko sijoittaa keynoten alkuun? Osallistujat näyttivät oppivan tämän aika nopeasti ja viimeisiin keynoteihin alkoi valumaan ihmisiä paikalle puoli tuntia tai tunnin myöhässä.

Ok, siinä ne huonot puolet. Hyviäkin löytyy onneksi, itse asian tiimoilta. Yleinen reaktio tapahtumaan blogeissa on ollut positiivinen, joku vertaili tätä jopa Woodstockiin. Julkistukset ovat olleet upeita, ajoin jopa odottamattomia, ja taas olisi Java alustan roadmappiä näkyvissä vuosiksi eteenpäin. Jo käytössä oleva Java 7, tulevat Java versiot 8 ja 9, enterprise Java 7 ja 8, ja tietysti paljon esillä ollut JavaFX ovat olleet esillä aiemminkin mutta nyt suunnitelmat ja käytäntö realisoituivat. Kiintoisaa oli myös katsoa mitkä sessiot vetivät väkeä. Pilvipalvelut, soa ja RESTful servicet eivät olleet suuri yllätys. Tänä vuonna näytti kuitenkin olevan poikkeuksellisen paljon suorituskyvyn tuunauksen ja rikkaseen käyttöliittymään liittyvää sisältöä. Rinnakkaisuus fork&join muodossa ja actor ja thread muodossa kiinnostivat myös. Osa huoneista oli täpösen täynnä ja mukaan ei mahtunutkaan.

Mitäpä sitten tulevaisuus tuo Java SE alustalle?

Kesällä julkaistu Java 7 versio hiipii hiljalleen ympäristöihin. Se tuo mukanaan ohjelmoijan kannalta varsin kivoja uudistuksia, jotka auttavat tekemään ratkaisut helpommin ja turvallisemmin. Tieturi teki niistä jo kesällä koulutuksen, Java 7 Uudet Piirteet – jota on jo asiakkaille koulutettukin. Jos vanhat merkit pitävät paikkansa, ensimmäiset opiskelijat ovat taloja jotka käyttävät paljon open sourcea ja ketteryyttä – ja suurempia ja vanhempia järjestelmiä omaavat talot siirtyvät sitten parin vuoden kuluessa toisena piikkinä. Sen verran hyvää on versiossa 7 että miksipä ei siihen siirtyisi heti tilaisuuden tullen. Kyseessä on kuitenkin evoluutio, ei revoluutio tässä versiossa. Kielen muutokset project coin muodossa ovat nimenomaan koodaajille mukavia ja työtä tehostavia, Fork&Join framework auttaa eräajoissa ja muussa prosessori-intensiivisessä rinnakkaistekemisessä.

Java versio 6 menee end-of-life tilaan 2012 loppuun mennessä. Jos ajaa Javaa vielä vanhemmilla alustoilla – hyi miten tuhmaa! 😉 No, rahallahan saa tukea vanhempiinkin alustoihin mutta ilman rahaa ei päivityksiä eikä varsinkaan turvapaikkauksia tipu.

Hiljalleen voi sitten suunnata tutkaimet jo kohti tulevaa Java 8 päivitystä – se julkaistaan nyt sitten 2013 kesällä, eikä 2012 kuten alunperin kaavailtiin. Syynä mm. mahdollisuus sertifioitua versioon ja stabilisoida vähän alustaa, mikä on mielestäni ihan hyvä. Versio 8 tulee nyt sitten olemaan se revolution. LambdaJ ja Jigsaw ovat jo yksinään riittävän kova juttu – ja tuohon päälle kun lisää vielä uudistetun Date&Time APIn ja uudistetun JavaScript moottorin, on luvassa kaikkea kivaa. Kivalla tarkoitan tietysti ohjelmoijille motivoivaa hauskaa uutta opiskeltavaa, projekteille vähemmän koodirivejä, enemmän mahdollisuuksia ratkoa ongelmia taas helposti ja luotettavasti. Ja tuo modulaarisuus on projekteille todella kova. Maveniä jo käyttäneet tietävät mitä tarkoitan, mutta eiköhän tässä Maven heviusereillekin ole jotain uutta ja arvokasta 😉

JavaFX on musta hevonen. 2007 SUN yli-hypetti sen ensimmäistä versiota joka oli jo aikanaan kiinnostava, mutta itseäkin arvelutti haluavatko java koodaajat tai muut opiskella uutta kieltä tähän tarkoitukseen. Onneksi nyt ei enää tarvitse. JavaFX 2.0 GA on julkaistu, heti saatavilla ja käytettävillä, ja Netbeansissä tuettuna. Sitä koodataan ihan perus Javalla, ei tarvitse oppia uusia kieliä, vain uudet rajapinnat. Ja se kytkeytyy toki sulavasti kaikkiin Java kirjastoihin kuten JAXB, JAX-RS, JPA,  ja tietysti Swing. Demot mitä näytettiin alkoivat olemaan tänä vuonna käytännönläheisempiä.. Mm. näyttäviä BI työkaluja. Satelliittien ohjaukseen käytettiin jo tuotannossa JavaFX:ää. Yksi wow efektin aikaansaanut demo oli se jossa JavaFX ajettiin IPad laitteessa iOS:n päällä. Ja tietysti julkistettiin myös että JavaFX menee open sourceksi ja tullaan jakelemaan osana Java SE alustaa. Myös siis iOS:lle ja Linuxille. Itse osallistuin hauskaan workshoppiin jossa tehtiin Oracle Coherence hajautetun Grid-cachen päälle hallintanäyttö (dashboard) JavaFX:llä – vanhan Swing pohjaisen tilalle. Ja oli muuten nopeata hommaa!

Mielenkiintoinen ilmoitus oli myös että Swing on nyt viimein tiensä päässä: Se ei tule saamaan enää uusia päivityksiä. Buh-bye Swing..

Java EE 7 alustaa analysoin jo aikalailla kolmospäivän blogissani, mutta tosiaan multi-tenancy tuki tarkoittaa kykyä ajaa koodiaan eri pilvissä, vuokrapilvessä tai omassa private cloudissa sen mukaan missä on milloinkin tarve. Saataisiin viimein siirrettävyyttä pilvipalveluihin joka vapauttaisi vendor lock-inistä jonkin verran ja tekisi pilveen investoinnin vähemmän riskaapeliksi – jos homma ei toimi pilvessä pystytetään sitten se oma privaattipilvi konehuoneeseen. Katsotaan meneekö se näin tulevaisuudessa – kiintoisaa nähdä syleilevätkö pilvipalveluiden tarjoajat standardia vai haluavatko pitää kiinni lock-inistä. Azuressa tuskin tulemme tukea näkemään 😉 Tuon äärimmäisen siirrettävyyden ohella tietysti EE 7:ssä on kosolti suoraan koodaajan elämään vaikuttavia elementtejä kuten uudet versiot mm. EJB, JSF, JPA, JAX-WS ja JAX-RS spesifikaatioista, ja kaikissa näistä oli tuloillaan hyvinkin mielenkiintoisia piirteitä.

Tuotteita tuli katseltua myös runsaasti – tuotteita löytyi mm. kehitysympäristön vuokraamiseen ja ajamiseen pilvessä (Cloudbees), Java sovellusten asentamiseen palvelimeen ilman buutteja (JRebel), ja sovellusten reaaliaikaiseen profilointiin ja monitorointiin virhetilojen varalta (New Relic). Suomessa on usein kaivattu ratkaisuja näihin – onpa meikäläistä tilattu joskus konsulttina jäljittämään virhettä järjestelmästä jossa kuvaus oli: Jollakin käyttäjällä joskus softa kaatuu. 🙂 Tarkemmilla seurantavälineillä pääsee paremmin ja ennen kaikkea nopeammin kiinni siihen mistä kiikastaa. Missä on muistivuoto, pullonkaula, tai nullpointerexception?

Kaiken kaikkiaan on erittäin positiivista että Java alustalla on roadmap – on suunnitelmia jopa versioon 12 asti, kun nykyisellään totutellaan vasta versioon 7. Yhteisön vire on myös positiivinen, ja energinen, ja se taas tapaa siirtymään innovaatioiksi ja ratkaisuiksi – jos haluaa saada jotain aikaan siihen pitää ensin uskoa. Enterprise puoli on menossa järkevään suuntaan ja seurailee myös uusimpia trendejä. Ja monessa sessiossa puhuttiin käytännön tuunauksista ja viilauksista sinänsä j0 kovin toimiviin nykyrajapintoihin nähden. Tästä ponnistetaan taas vahvasti käyntiin.

Huom! Kaikki keynotet ovat katseltavana julkisesti osoitteessa http://www.oracle.com/javaone/live/on-demand/index.html

Tässä vielä linkkivinkkinä erinomainen blogi JavaOne päivityksistä päivä päivältä ja esitys esitykseltä amerikaksi: http://marxsoftware.blogspot.com/

Java, optimointi, ja muistivuodot

Hiljattain tuli konsultoinnin yhteydessä pohdiskeltua tarkemmin miten huonosti käyttäytyviä Java-sovelluksia tuunataan. Javassa alustanahan on pari erityispiirrettä jonka vuoksi se toimii eri tavalla kuin esim. C++.

– Koska Java on dynaaminen alusta, sen kokonaisympäristö selviää vasta ajon aikana, ja voi mahdollisesti poiketa kehitysympäristöstä. Tarkoittaa että esim. log4j kirjastosta voi olla eri tavoin toimiva kirjasto ajon aikana. Kenties näin ei pitäisi olla mutta näin useinkin on.

– Tehokkuudesta vastaa pääosin virtuaalikone, eli ajoympäristö, ja se onkin uskomattoman hyvä optimoimaan. Java koodi benchmarkattuna C++ koodia vastaan on viime aikoina useasti jopa rökittänyt kilpailijansa suoritusnopeudessa. Mutta virtuaalikone tekee parhaiten työntä koodille joka on selkeää ja kikkailematonta, vähän kuin rautalangasta väännettyä. Yksi pahimpia hölmöilyjä mitä voi tehdä on lisätä koodiinsa kutsu System.gc() sinne sun tänne. Virtuaalikoneen idea on nimenomaan skaalata sovellus ympäristön mukaan aina parhaiten optimoiduksi. Mitä enemmän koodi pyrkii pakottamaan ja rajoittamaan sitä huonommin automaattioptimointi voi toimia.

– Kooditasolla ei ole mitään erityisiä optimointi-avainsanoja kuten esim. inline.. Koodin optimoinnilla on muutenkin hyvin vähän merkitystä sujuvuuteen – kunhan siellä ei ole hölmöilty. Pääosa koodin optimointia on siis hölmöilyjen purkamista.

– Automaattinen roskankeruu on tunnettu tehosyöppö, edellämainityt hölmöilyt ovat usein koodia joka aiheuttaa tarpeetonta roskankeruuta. Tarpeeton roskankeruu syö prosessoritehoa ja pysäyttää suorittavat säikeet, eli mitä enemmän roskankeruuta tehdään sitä enemmän varastetaan kellosyklejä suorittavilta osilta. Näin ollen roskankeruun minimoiminen on hyvä lähtökohta suorituskyvyn parantamiselle. Mutta huom. tarpeettoman roskankeruun.

Suorituskykyä parannetaan siis roskankeruuta vähentämällä – tarpeetonta sellaista. Miten tämä tapahtuu? Pidentämällä olioiden elinkaarta ja lisäämällä uudelleenkäyttöä, välttämällä kaikkea turhaa olioiden luontia ja tuhoamista.  Tähän on monia keinoja: staattiset muuttujat ja alustusblokit, objektipoolit, cachet, valmiiksi lasketut tulokset, jne.

Muistivuotoja ei pitäisi Javassa periaatteessa olla – automaattisen roskankeruun ansiosta. Javassa kun ohjelmoija ei itse varaa muistia eikä vapauta muistia vaan nämä piirteet on abstraktoitu virtuaalikoneen tehtäviksi. Mutta virtuaalikoneessakin voi olla bugeja, ja missä hyvänsä JNI palikoissa voi olla ja todella usein onkin muistivuoto-ongelmia. Ja jos ohjelma yksinkertaisesti varaa olioita muistiin jatkuvasti eikä milloinkaan päästä niistä irti niin eipä roskankeruukaan voi toimia ja toki siinä muisti aikanaan sitten loppuu. Jos haluat saada java-sovelluksen kaatumaan muistiongelmaan et tarvi tätä enempää:

        List<String> list = new ArrayList();
        while(true)
            list.add("HELLOWORLD" + list.toString());

Tässä on IBM:n Developerworks-sivuilta hienostuneempi esimerkki joka esittää paria vivahdetta:

import java.io.IOException;
import java.util.HashSet;
import java.util.Random;
import java.util.Vector;

public class LeakExample {
	static Vector myVector = new Vector();
	static HashSet pendingRequests = new HashSet();

	public void slowlyLeakingVector(int iter, int count) {
		for (int i=0; i<iter; i++) {
			for (int n=0; n<count; n++) {
				myVector.add(Integer.toString(n+i));
			}
			for (int n=count-1; n>0; n--) {
				// Oops, it should be n>=0
				myVector.removeElementAt(n);
			}
		}
	}

	public void leakingRequestLog(int iter) {
		Random requestQueue = new Random();
		for (int i=0; i<iter; i++) {
			int newRequest = requestQueue.nextInt();
			pendingRequests.add(new Integer(newRequest));
			// processed request, but forgot to remove it
			// from pending requests
		}
	}

	public void noLeak(int size) {
		HashSet tmpStore = new HashSet();
		for (int i=0; i<size; ++i) {
			String leakingUnit = new String("Object: " + i);
			tmpStore.add(leakingUnit);
		}
		// Though highest memory allocation happens in this
		// function, but all these objects get garbage
		// collected at the end of this method, so no leak.
	}

	public static void main(String[] args) throws IOException {
		LeakExample javaLeaks = new LeakExample();
		for (int i=0; true; i++) {
			try { // sleep to slow down leaking process
				Thread.sleep(1000);
			} catch (InterruptedException e) { /* do nothing */ }
			System.out.println("Iteration: " + i);
			javaLeaks.slowlyLeakingVector(1000,10);
			javaLeaks.leakingRequestLog(5000);
			javaLeaks.noLeak(100000);
		}
	}
}

Miten tällaisia roskankeruuseen tai muistivuotoon liittyviä ongelmia sitten voi jahdata? Aika monellakin tapaa, Java tuo mukanaan jo useita työkaluja joiden avulla pääsee näkemään tarkemmin mitä virtuaalikoneen sisällä tapahtuu. Näistä on monesta kursseillakin asiaa, mutta viime aikoina olen perehtynyt enemmän visualvm työkaluun joka on jdk 6  uudemmissa versioissa sekä jdk 7:ssa vakiovarusteena. Sen saa ladatuksi myös erillisenä verkosta. VisualVM sisältää mahdollisuuden profiloida prosessorin käyttöä tai muistin käyttöä, ja sillä voi ottaa snapshotteja joita voi analysoida kaikessa rauhassa myöhemmin. Näin voi kiinnittää huomiota pisteisiin jossa käytetään paljon aikaa, tai jossa luodaan paljon olioita.

Miten em. muistivuoto sitten Javasta löytyy? Helposti. Otetaan snapshot tilanteesta, ja toinen snapshot jonkin aikaa myöhemmin. Muistivuodon tunnusmerkki ei ole että olio varaa paljon muistia. Muistivuodon tunnusmerkki on kasvu, josta kertoo kahden snapshotin delta, ero. Ja visualvm pystyy ottamaan kaksi snapshottia ja vertailemaan niitä, jolloin voidaan pistää oliot kasvun mukaan järjestykseen. Kovasti kasvava olio ei ole välttämättä signaali muistivuodosta, voi olla että se on vain kovasti kasvava olio 😉 Mutta jos ohjelmassa on muistivuoto, näiden joukosta se löytyy. Ellei se ole esim. virtuaalikoneen tai JNI moduulin bugi – koska nämä ovat java heapin ulkopuolella toimivia, ei niihin javan sisäiset välineet pure.

Yksi muistivuodoksi nimetty ongelma on se kun vastaanottaa ihastuttavan OutOfPermGenSpace -poikkeuksen. Tämä ei ole tosiasiassa varsinainen muistivuoto vaan ilmiö joka on joissain versioissa ilmentynyt mm. Tomcat ja JBOSS palvelimilla. Se aiheutuu kun serverille tehdään hot deploy operaatioita uudelleen ja uudelleen. Riippuen hot deploy toteutuksesta, java asentaessaan softan uuden version saattaa päätyä käyttämään enemmän ja enemmän permgen-aluetta kunnes se loppuu kesken. Tähän voi reagoida joko lisäämällä permgen alueen viipaletta (joka lykkää ongelman esiintymistä vähän pidemmälle), tai buuttaamalla serverin ihan oikeasti aika ajoin, esim. aina neljän hot deployn jälkeen, tai tarkistamalla että oma serveri tukee hot deployta ilman näitä oireita.

Yksi itseä kiehtova asia on rinnakkaisuuden jatkuva lisääntyminen. Omassa Xoom tabletissani on pari prosessoriydintä, samoin puhelimessani. Pöytäkoneissa on jo 2, 4, 8, ja pian 64 ydintä. Lisäboostia saa tekemällä asiat rinnakkain, silloin kun se on mahdollista, ja tähän tarvitaan tietysti osaamista jo suunnittelun alusta alkaen aina toteutustekniikoihin asti. Miten rinnakkaisessa maailmassa hallitaan jaettuja resursseja? Kiinnostavat projektit kuten Akka ja Scala vastaavat että Actor frameworkeillä ja postilaatikoilla. Java sanoo että synkronoinnilla ja lukituksilla. NIO tarjoaa sokettien osalta mukavan selector mallin jossa säikeitä tarvitaan vain kaksi, ja asiakkaita voi silti olla vaikka tuhat. Tässä ollaan vielä lastenkengissä, ja 2010 luku on rinnakkaisuuden vuosiluku, sanokaa minun sanoneen.

Tämä kirjoitelma syntyi Tehokas Java-kurssin tiimoilta, eli jos suorituskyvyn säätö Java-alustalla herättää kiinnostusta ja tässä artikkelissa tuli jotain uutta, niin kannattaa kurkata http://www.tieturi.fi/java alta ko kurssi esille.

Java ja OpenJDK tulevaisuus

Nyt on taas tapahtunut lyhyessä ajassa Java puolella paljon, ainakin mitä tulee pelureihin ja alustan tulevaisuuteen. Javan ydin on tietysti Java SE, ja sen ensi vuonna tuleva versio 7 muovaa suunnan mihin ollaan menossa. Tämän verran tiedämme OpenJDK 7:stä:

– Oracle yhdistää JRockit ja HotSpot virtuaalikoneiden parhaat piirteet ja siitä syntyy uusi JRE eli Javan virtuaalikone

– OpenJDK:n takana seisovat nyt myös IBM ja Apple, Apple lakkasi tekemästä omaa virtuaalikonettaan ja IBM näyttäisi olevan irtautumassa myös omastaan sekä kenties Apache Harmonystä

– Toisaalta, ei niin hyvää ettei jotain huonoakin. Apache on kiukustunut Harmony projektin saamasta kohtalosta niin paljon että uhkaa äänestää Java SE 7 spesifikaation nurin ellei homma muutu avoimemmaksi. Ei ole ensimmäinen kerta että spesifikaatioita pidetään panttivankina, mutta mielenkiintoista on että Apachella on aika paljon kuuluvuutta ja uskottavuutta, organisaationa Apache nauttii suurta luottamusta ja suosiota.

– Sitten on tietysti Oracle-Google oikeusjupakka, joka ei suoranaisesti liity OpenJDK:hon. Siinä viimeisin juonne on, että Oracle listasi tiettyjä spesifisiä kohtia Android alustassa joissa olisi kopioitu koodia. Googlen vastaus on että koodit eivät ole heidän tekemiään vaan kolmansien osapuolien, avoimella alustalla. Erään asiantuntijan mukaan myös koodien välillä oli suuria eroavaisuuksia, ja vedottiin siihen että on lopulta vain rajattu määrä eri tapoja tehdä sama tietty asia, eli jos esim. autoa ollaan keksimässä, voi kaksi insinööriä erillään päätyä siihen että pyörä toimii muotona paremmin kuin neliö, mitä auton renkaisiin tulee. Mielenkiintoista pöllytystä, saapa nähdä miten tilanne kehittyy. Jos nuo tekijänoikeusjutut kiinnostavat, hyvä huomata että sekä openjdk että android ovat open sourcea eli lähdekoodit voi ladata ja eroavaisuuksia/samankaltaisuuksia arvioida ihan itse.

Pistetään loppuun vielä aivan täysin asiaan liittymätön kuva Dukesta rokkaamassa.

Java 7 ja Java 8

Yksi JavaOne julkistuksista oli tarkempi selvyys Java SE versioiden roadmapistä ja sisällöistä. Java 7 on tuloillaan nyt vuoden 2011 puolessavälissä, ja Java 8 julkaistaan jo vuonna 2012 – tosin loppupuolella – eli aika pikatulta!

 

Java 7 osoittautui alunperin liian kunnianhimoiseksi tavoitteiltaan ja siitä karsittiin nyt osia jotka päätyvät Java 8:n. Yksi päämuutos oli siirtää Project Jigsaw Java 8:n puolelle. Samoin LamdaJ ja Closures siirtyi vuodelle 2012.

Mitä sitten on lupa odottaa ensi vuonna Java 7 versiossa?  Tässä tuorein feature list:

  • Support for dynamically-typed languages – InvokeDynamic (JSR 292)
  • Small language enhancements – Project Coin (JSR TBD)
  • Updated class loader architecture
  • Method to close a URLClassLoader
  • Concurrency and collections updates
  • Unicode 6.0
  • Locale enhancement – Support for IETF BCP 47 and UTR 35
  • More new I/O APIs for the Java platform – NIO.2 (JSR 203)
  • TLS 1.2
  • Elliptic-curve cryptography (ECC)
  • JDBC 4.1
  • New platform APIs for 6u10 graphics features
  • Swing Nimbus look-and-feel
  • Swing JLayer component
  • Updated XML stack

Mitä tuo kaikki tarkoittaa? Ehkä kiinnostavin muutos on Project Coin – eli small change. Java 5 aikanaan ensi kertaa koski kielen perusrakenteisiin – esiteltiin Annotations ja Generics – ja monet koodaajat katsoivat silmät kierossa uutta Javaa jossa monet asiat näyttivät kovin oudoilta. Coin ei tee niin dramaattisia muutoksia – mutta esim. switch lause jossa vertaillaan merkkijonoja, ja try-catch poikkeuskäsittely jossa voi käsitellä monta poikkeusta yhdessä catch lohkossa vaativat varmasti totuttelua. Samoin type inference helpottaa generics käsittelyyn liittyvää turhaa toistoa ja näin lyhentää taas koodin määrää mitä tarvitaan. Ja moni varmaan tykkää kovasti autoclose-toiminnosta ja Closeable rajapinnasta: ei enää unohtuneita tiedoston tai tietokannan sulkemisia! 😉

Nimbus on uusi vektorigrafiikkapohjainen Swing plaf – se ei merkitse mitään jos et käytä Swingiä, mutta jos käytät se merkitsee paljonkin. Vektorigrafiikka kun on bittikarttoja skaalautuvampaa ja myös vähemmän muistisyöppöä – ja Nimbus on tietysti uutena kirjastona myös paljon kauniimpaa kuin vanha Swing – pähkinänkuoressa pyöristetympää, tyylitellympää, varjostetumpaa, vähemmän neliskanttista ja latteaa.

Ja lopuksi: InvokeDynamic a la Da Vinci Machine Project antaa entistä paremman rajapinnan dynaamisten koodiosien suoritukseen, kuten Groovy, Ruby ja JavaScript. Odotettavissa on siis parempaa suorituskykyä ja kaksisuuntaisia kutsuja. Dynaaminen scriptikoodi pystyy siis paremmin hyödyntämään äärimmilleen viritetyn virtuaalikoneen tehokkuutta. JSR223 eli scripting komponentti oli esiaskel, mutta tässä mennään paaaaljon syvemmälle. Ja siksi siis JSR292 – parempi tuki ei-staattisesti tyypitetyille kielille.

Tuolta voi ihmetellä lisää:

http://openjdk.java.net/projects/jdk7/features/

Java 8 tulee sisältämään seuraavaa:

  • Module system and modularization (JSR TBD, JSR 294)
  • Closures – Project Lambda (JSR TBD)
  • Annotations on Java types (JSR 308)
  • Language support for collections – Project Coin, part 2 (JSR TBD)

Eli vaikka lista on lyhyt, ensimmäinen osa eli JigSaw on MIELETTÖMÄN iso muutos – modulaarisuusjärjestelmä tapaan Maven/Ivy/OSGI – mutta rakennettuna javan ytimeen. Päästäänkö viimein eroon jar/classpath helvetistä? En tiedä, mutta yritys on kova. Paljon kysytty piirre on myös Closures ja LambdaJ – jotka tuovat funktionaalisten kielten voimaa olio-javaan.

En aio ennustella tulevaa Java 8:aa turhan paljoa nyt, koska vielä voi paljon muuttua matkalla joten arvailuksi menisi. Mutta Java siis pitkästä aikaa elää ja voi vahvasti, ja tulevat vuodet tuovat mielenkiintoisia lisäpiirteitä ihan kaikkeen Java kehitykseen. Ja pienet muutokset kasautuvat nopeasti…