Skip to end of metadata
Go to start of metadata

Az elmúlt másfél év során sok információ került ki a Project Jigsaw kapcsán, mint a Java7, majd a Java8 egyik nagy erőssége, s a jelen állás szerint csak a Java9 nagy dobása lesz, mivel a Mark Reinhold úgy ítélte a projekt állását, hogy az elkövetkező bő egy évben (a Java8 majd csak 2013 őszén fog kiadódni) nem lehet tisztességesen befejezni, legalábbis ez olvasható a blogbejegyzésében. , így továbbra se lesz semmi a JSR 337 kódnéven emlegetett modularitási és profilozási lehetőségekből a következő nagyobb Java kiadásban. Mark megemlítette a főbb dilemmáját is: fejezzék be a modularitást és adják ki később a Java8-at vagy adják ki időben, és a következő kiadásba kerüljön bele egy letisztult és korszerű modularitást támogató megoldás.

A bejelentés viszonylag nagyobb port vert fel a Java közeli blogokon és portálokon, s a vélemények között akad mindkét opcióhoz támogató, a dzone.com oldalon idéztek kettő ilyen véleményt:

We didn't go too far with modularity in Groovy 2... because we didn't want to duplicate what was supposed to be coming in Java 8.
But now, it means it won't be in the hands of developers before 2 years, and in production before 3 years :-(
It means that Jigsaw, if it ever ships, will have been 5+ years in the making. That sounds a lot, even for such a big feature and task.

Guillaume Laforge (major Groovy contributor)

Illetve:

DON'T HOLD THE TRAIN. The five years from Java 6 (which itself was disappointing) to Java 7 nearly killed the language.

Johannes Brodwall

A nagy kérdés az, hogy a platform kibír-e még 2-3 évet, amíg a Java9 megjelenik, és nem jelenik-e meg a jelenlegi JCP támogatással bíró de jure szabvány Jigsaw helyett egy alternatív megoldás, amely de facto szabvány lesz. Sokan az OSGi-t emlegetik, illetve a Maven mintáját gondolják átvehetőnek...

Saját vélemény

A Jigsaw – mint modularizációs ötlet – alapvetően a JavaFX miatt született 2009-2010 környékén, mivel a kliens oldalon (asztali, hordozható vagy hordható eszközökön) futó beépülő programok csak akkor képesek hatékonyan futni, ha nem kell maguk alá telepíteni egy 50-150MBájt méretű futtató környezetet, hanem csak a futásukhoz szükséges modulokat töltik le és indítják el. Ezen modularizáció nélkül a JavaFX programocskák indulása akár másodpercekig is eltarthat, ha a felhasználó sikeresen feltelepítette a JRE-t, amelyhez rendszergazdai jog kell... nyilvánvaló, hogy ezen okból fel kell darabolni a Java platformot jelentő API-t.

Azonban az elmúlt két-három évben a JavaFX egy fikarcnyit se mozdult el a nullával jellemezhető piaci részesedéséről, az elterjedőben lévő platformok közül az iOS biztos nem fogja támogatni se a Java, se a JavaFX környezetet; az Android esetén kevéssé számít az, hogy modulárisan induljon el a VM, mert alapjaiban más megoldást alkalmaz erre a problémára; s végül a Windows Phone se fog Java/JavaFX programokat futtatni. A meglévő platformok közül az asztali és laptop/notebook vonal nem igényli a modularitást, a szerver oldali Java esetén pedig ott van az OSGi a futás idejű modularitásra (Eclipse, Glassfish és még néhány szerver oldali megoldás használja az OSGi-t), a fordítás idejű modularitásra pedig ott a Maven és a többi függőséget jól kezelő rendszer.

Felmerül a kérdés, hogy kell-e a JDK modularizációja, vagy már elhaladt felette a kor?

      
      
Page viewed times

8 Comments

  1. Szerintem nem JDK, hanem JRE modularizációról van elsősorban szó.

    Én is a JavaFX-nek tulajdonítanám ezt, de nem erről az oldalról nézve. A JAvaFX úgy volt pozícionálva, mint a Java alapú megjelenítés jövője, emelett inkább az aránylag nagy méretű elavult maradékoktól akartak megszabadulni, mint az applet, Swing és az AWT. Ezek gyakorlatilag használaton kívül vannak a Java felhasználók gépeinek nagy részén, így letöltésük, frissítésük úgyszólván teljesen fölösleges.

    Figyelembe véve az akkori átlagos Internet sávszélességet a JRE-t le akarták szorítani a Flash méretére, ezeknek a kiírtásával, hogy a JavaFX- berobbanásakor ne kelljen a felhasználók panaszáradatát hallgatni, a hatalmas letöltési méretek miatt. Az okostelefonok fejlődésével a JME-t is ki szerették volna JSE-vel váltani, amit egy kisebb méretű a készülékeken futó JRE kiválóan megoldott volna, így a szerteágazó fejlesztéseken is lehetett volna egyszerűsíteni.

    A JavaFX berobbanás helyett akkorát sem tudott pukkanni, mint egy CO2 patronnal felfújt levelibéka, emellett a sávszélességek kellően megemelkedtek a pár 10M letöltés fel se tűnik a reklámok mellett, az okostelefonokra meg Java helyett az Android lett a befutó.

    Szerintem nem fogják túlzottan pörgetni, de már túlzottan be volt harangozva, hogy visszaszívják.

    1. Csak a JavaFx miatt én sem látom értelmét a modularizációnak, mert egyre inkább jelennek meg olyan Java technológiák mint pl. Vaadin(szerver oldali), Codenamre one(mobil telefonokra) és még sok más(gwt) melyek nem igényélnek semmilyen java telepítést a kliens gépén. Persze ha modularizáció lehetővé teszi a java "akármilyen" program telepítését egy kliens gépre akkor már megérte...

      1. Auth Gábor AUTHOR

        Mit értesz "akármilyen" program alatt?

        1. Akármilyen programot most is lehet futtatni, de már javitják. (smile)

          1. Anonymous

            Igen és most már nem csak akármilyen program lesz, hanem javafx, mert a jre tartalmazza már a javafx futtatási környezetet is

          2. Auth Gábor AUTHOR

            Áh, marad még a lyukakból... (smile)

            Arra mondjuk kíváncsi vagyok, hogy a legutóbbi JRE5/6/7 környezet érintő hibák meg vannak-e Android alatt is...

  2. Anonymous

    lenyeg h lambda legyen benne, jigsawt leszarom

    1. Auth Gábor AUTHOR

      Érdemes megnézni a Jigsaw szavazásokat, egyharmad úgy gondolja, hogy adják ki időben a Java8-at, egyharmad úgy gondolja, hogy a Java8 Jigsaw nélkül használhatatlan, a maradék egyharmad pedig úgy gondolja, hogy van már néhány modularizációs implementáció vagy nem érdekli a téma... (smile)

       

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))