Oracle: a Java böngészőplugin deprecated lesz a JDK9-ben

Java

Az Oracle tegnap bejelentette, hogy a legújabb plugin kiírtási trendeknek megfelelően "deprecated" állapotba billenti a Java böngészőplugint a JDK9-ben:

Oracle plans to deprecate the Java browser plugin in JDK 9. This technology will be removed from the Oracle JDK and JRE in a future Java SE release.

Részletek a bejelentésben.

( sz332 v | 2016. 01. 28., cs – 09:05 )

Java fejlesztőként már nagyon vártam, hogy meglépik ezt...

( sibike | 2016. 01. 28., cs – 09:23 )

És a tudomány kitalált már valamit a remote management console-ok kiváltására?

Évek óta nem nagyon tudok olyan dolgot mondani, amihez applet kellene. Az, hogy bizonyos gyártók máig applet alapokon nyújtják a remote console szolgáltatást kényelmi okokból, arról az adott gyártón kívül senki nem tehet.

Tisztán HTML5 és JS itt tart nagyjából: http://bellard.org/jslinux/tech.html (http://bellard.org/jslinux/)

--
https://portal.gacivs.info

Én is kíváncsi leszek, hogy mi lesz a nagy megoldás a mondjuk 5 éves storage-ok adminisztrációs felületével, vagy éppen az pár éves ILO-k web konzoljaival, vagy mondjuk a SuperMicro ugyanilyen tooljaival.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.1 | 3.10.84-janos

( abalole | 2016. 01. 28., cs – 09:22 )

With modern browser vendors working to restrict and reduce plugin support in their products, developers of
applications that rely on the Java browser plugin need to consider alternative options such as migrating from
Java Applets (which rely on a browser plugin) to the plugin-free Java Web Start technology.

Az ugyfelkapu tomeges bevallas feltoltes szempontjabol ez mit jelent?
Az plugint hasznal. Tehat nekik valtani kell?

Amikor mi próbáltuk használni (~2-3 éve), akkor túl sok probléma volt vele.

A legnagyobb gond az volt, hogy egyes kliensekre valamiért nem jutottak el frissített JAR-ok, ami már egy ilyen disztribúciós rendszernél önmagában is show-stopper. (ezek vszeg egyes JRE release-ekben maradt hibák miatt voltak bár ezt nem sikerült egyértelműen leszögezni anno)

Voltak kisebb inkompatibilitások is a desktop futtatási módhoz képest, amelyek a JWS és a desktop class-loader-ek közötti különbségekből adódtak (pl.: classpath scanning-nél az erőforrások megtalálási sorrendje). Ezeket lehetett körbeprogramozással kezelni, de csak nem publikus API-kon keresztül és emiatt a cucc időnként fejreállt, amikor az Oracle-ösök fejlesztettek valamit egy-egy újabb JRE release-ben.

Másodlagos dolog, hogy certifikátumot kell kiváltanod, ahhoz, hogy egyáltalán ne szólogasson be a felhasználóidnak (figyelmeztetés, hogy az alkalmazás nem biztonságos). Ez nagyobb cégnél nem probléma, kicsiknél és OSS projekteknél azért zavaró körülmény.

Összességében többet kellett vele foglalkozni, mint amit egészségesnek éreztünk, ezért úgy döntöttünk, hogy a kliens HTML5-ös újraírása hosszabb távon jobban szolgálja az alkalmazás érdekeit (pl.: most már megy tableteken, telefonokon is).

Ha az Oracle atom-stabillá tenné a JWS-t és legalább olyan széles körű oprendszer támogatást adna a Swing-nek vagy a JavaFX-nek, mint a HTML5, akkor talán megérné vele foglalkozni (mivel a HTML5 alkalmazásokat sújtó böngésző inkompatibilitások sem elhanyagolhatóak)

> Másodlagos dolog, hogy certifikátumot kell kiváltanod, ahhoz, hogy egyáltalán ne szólogasson be a felhasználóidnak (figyelmeztetés, hogy az alkalmazás nem biztonságos). Ez nagyobb cégnél nem probléma, kicsiknél és OSS projekteknél azért zavaró körülmény.

Egy ideje már hitelesített cert nélkül el sem indul, hacsak a security beállításoknál nagyonnagyonnagyon nem veszed rá, hogy fogadjon el minden szir-szart. És még akkor is hisztizik.
--
blogom

Arra gondolok. A problémák meg ugyanazok vele, mint a java cuccal, kivéve a több jvm verzió dolgot.
Azaz:
- az assembly cache nem megfelelő verziózás esetén teljesen meg tud dögleni
- a .application fájlt mindenképpen alá kell írni, ami sokszor plusz macera (mondjuk az üzemeltetöé...)
- a .application fájlban nem lehet az alkalmazásnak paramétereket átadni

Most ezek jutnak az eszembe. Főleg az első pont volt, ami sok bosszúságot okozott.

lehet én ismerem a webstartot nem eléggé, de nekem maga a koncepció (letöltök valamit a böngészőből, ami lokálisan fut, de azért online app) nem tetszik.

tessék mindenhol HTML5-öt használni. Vagy ha nem, akkor egy rendes, multi-platform értelmezőt kiadni hozzá.
--
blogom

Sajnos nagyon sok helyen használnak még appletet, ahol igazából már szükség nem lenne rá. Ott a webstart, és akkor adjunk a felhasználónak alkalmazást,
vagy ott a html5 + js + css, és akkor kapjon rendes webes alkalmazást. Mindkettő indokolható, a weboldalba hegesztett java applet az nem.

Szerintem félreértesz, egyáltalán nem védem az appleteket. Néhány (valós business reason miatt létező) appletet leszámítva nyugodtan pusztuljanak mind egy szálig.

Azt mondtam csak, hogy a "HTML5-öt mindenhova" című dolog egy baromság, mert sok helyre teljesen alkalmatlan. Ha más nem, lásd ugyanebben a threadben a példát az ÁNYK mass upload-dal.

"lásd ugyanebben a threadben a példát az ÁNYK mass upload-dal"

Az ÁNYK-ból megy a tömeges feltöltés közvetlenül WebService interfészen át. A magyarorszag.hu portálon nem megy Applet nélkül, ami nem azért van, mert a HTML5 képtelen erre, hanem azért, mert szimplán balfaszok és/vagy leszarják, hogy mi kell a felhasználóknak...

Ez most egy állapot, szerintem szabványokhoz képest elég jól haladnak a bevezetéssel. Tudtommal már elég nagy része le van fektetve a szabványnak, csak apróságokon vitáznak, de lényeges változás már talán nem nagyon lesz. Ahhoz képest egész jó a böngésző támogatottsága, a nem túl friss böngészőkre a polyfill meg egy szükséges rossz, de szerintem nincs vele baj, sokkal rosszabb dolgokat is kitalált már az emberiség a régi böngészőkből hiányzó dolgok kipótlására.

--

2006-ban nem volt még, "mindössze" 6 éve van erre lehetőség... :)

Külön ki van emelve a menüsorba "Kapcsolat az Ügyfélkapuval" néven, szóval még akár kíváncsiságból is rákattint az ember és meglátja a "Nyomtatvány közvetlen beküldése az Ügyfélkapun keresztül" menüpontot, ami ránézésre szerintem egyértelmű.

( friedmannt v | 2016. 01. 28., cs – 10:21 )

Akkor most igazán be fog indulni a Java WebStart szekere.

( agostonl | 2016. 01. 28., cs – 13:10 )

HP és Cisco Web kliens fog szívni, na meg az Álomkincstár! :)
Ja, és a CIB bank, akikkel 1 éve levelezek erről.
Kézcsók.

Lassan ott tartunk, hogy Virtuális gép, befagyasztott XP telepítővel és a Java klienssel.

Zsír!

"Értem én, hogy villanyos autó, de mi hajtja?"

Nem az államkincstár fog szívni, hanem mi, akiknek azt a francos KIRÁt kell használnunk. Bámulatos, hogy x év fejlesztés után eljutottak oda, hogy 1.7-es java kell nekik, nem pedig valami ősibb verzió mint a KIR3ban...

És kétlem, hogy egyhamar lecserélnék, tekintve, hogy csak most lett bevezetve élesben.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

( shadow21 | 2016. 01. 28., cs – 14:31 )

Ideje volt.
Adobe is megléphetné ezt a flashnél.

nem lehet majd tiltani a csillivilit
3d kocka az oldalsó menüben
új js motorokról ne is álmodjunk
ezt nem szeretem

én sokat használtam beépülõket anno, még mielõtt Jobs nem konstatálta hogy csak nem lesz rendes érintõ támogatás a falshekben.
fõleg játékokhoz, meg, volt amikor a videólejátszásba be tudta vonni a GPU-t a flash (azóta ez talán kikerült)

Más: miért nem fut .apk a böngészõben, dobozban? Szerintem igény van rá.
Nem tudom, hogy milyen korlátai vannak (talán csak a nagy méret lehet), de, nem hiszem hogy több lenne, mint a .jar-oknak.

( Celtic v | 2016. 01. 29., p – 07:29 )

Csodalatos...Huzhatok fel egy virt. gepet XP-vel meg az aktualis bongeszovel/javaval, amit nem frissitek, hoyg lassam a Mikulast :(

--
http://www.micros~1
Rekurzió: lásd rekurzió.