9:36
28/1/2016

Java ogłosiła ubicie projektu wtyczki dla przeglądarek. SunOracle nie mógł podjąć innej decyzji, ponieważ przeglądarki (Chrome i Firefox) już w zeszłym roku zapowiedziały, że same rezygnują z wsparcia dla tej wtyczki, a microsoftowy Edge w ogóle nie wspiera wtyczek. Krok słuszny.

To się nasz e-goverment zdziwi… Taki PFRON na przykład, albo inne instytucje korzystające z “apletów Java” np. do obsługi skrzynek podawczych niebawem będą musiały rozpisać nowe przetargi na “multisystemowe” oprogramowanie do kontaktu z obywatelem.


Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.


74 komentarzy

Dodaj komentarz
  1. sluszny jak sluszny. mam kvm po ip i uzywa toto wlasnie apletu do wystawiania ekranow. sprzet ma swoje lata i nie bedzie aktualizacji do niego. i co, mam teraz kupowac nowego kvma?

    • To proste. Zostaw sobie na którymś sprzęcie niezaktualizowaną przeglądarkę i starą wtyczkę JAVY. O ile nie będziesz tym przeglądać internet, to do KVM nie widzę przeszkód, by się nie nadawał.

    • Albo VM
      Do tego zblokować w hosts wszystkie podsieci oprócz swojej coby komuś się FB nie kliknęło na virtualce, a najlepiej korzystać z dysku różnicowego bez zapisywania zmian

    • Tylko że FF i chrome się “same” aktualizują.

    • FF daje możliwość pobrania określonej wersji, która się nie aktualizuje. Nie wiem jak z Chrome.
      Artykuł: https://support.mozilla.org/en-US/kb/install-older-version-of-firefox
      Katalog: https://ftp.mozilla.org/pub/firefox/releases/

    • Tak, właśnie – to się nazywa postęp. Słabe technologie upadają, a ich użytkownicy muszą zainwestować w nowe.

    • kitor: a na tym wszystkim korzystają firmy zarabiając w taki albo inny sposób.

    • kitor to się nazywa kapitalizm a nie postęp, muszą być zmiany, bo by firmy nie zarobiły, każdy by się trzymał tego co zna i jest mu wygodne zamiast kupować nowe

  2. Chyba Sun nie mial nic do gadania w tej sprawie.

    • Sun już dawno nie ma nic do gadania w tej sprawie :D

    • Oracle najwyraźniej nie zależy, Chrome i FF przestają obsługiwać wtyczki ze starym API. Gdyby przekompilowali na nowe, mogłoby działać nadal.

  3. > ponieważ przeglądarki (Chrome i Firefox) już w zeszłym roku zapowiedziały, że same rezygnują z wsparcia dla tej wtyczki

    Smart te przeglądarki, tak same z siebie podejmują decyzje ;-)))

    • Ale gownianego flasha, mozilla dalej bedzie wspierac.

  4. wystarczy na Java Web-start przejść…. po za tym ubijają od Javy 9 dopiero…

  5. Na każdej stronie pojawi się wersja instalacyjna starego Firefoxa i starej Javy z instrukcją jak nią zastąpić obecną wersję.

  6. a to jest nic. przecież nowy e-zdrowie system to też jest na tym oparty.. :)

  7. W źródle też jest to wykorzystywane. Ba nawet zalecają nie aktualizować bo przestaje działać źródełko.
    Same kłopoty z tą Javą.

  8. Tak ubiją od wymuszenia instalacji Javy 9 gdzieś w 2017, ale wcześniej chrome i firefox przestaną obsługiwać wtyczki ( w tym roku ? ), Java tak szybko nie kończy wsparcia, nawet 1.8 na dzień dzisiejszy instaluje się i działa poprawnie na XP, oczywiście z komunikatem ostrzegającym o przestarzałym systemie. Na dzień dzisiejszy JUŻ POWINNY BYĆ REALIZOWANE ZMIANY w oprogramowaniu: PFRON (refundacje), PFRON 2(zgłoszenia), EPUAP ( cała komunikacja z urzędami ), PUE (komunikacja z ZUS) pluginy do podpisu i generowania kluczy, oraz logowania kartami z podpisami, wszystko to do przejścia na np. Java Web-start. Znając opieszałość i zainteresowanie problemem urzędów, zaleceniem będzie stara wersja przeglądarki oraz Javy :) na “dobry” początek.

    • Chrome już od dawna nie wspiera pluginów NPAPI, a na PPAPI jest dostępny tylko Flash. Java więc od dawna w Chromie nie działa, w Edge’u nigdy. Firefox dołączy do nich do końca 2016 roku.

  9. No i jest jeszcze NBP/bankowość, która już ma problemy z najnowszym FF/Java

    • Nie tylko.

  10. I bardzo dobrze. Te wtyczki to mój najgorszy koszmar. Oprócz całego naszego “e-govermentu” lubują się w tym jeszcze banki w odmianach korporacyjnych. Ile to razy miałem sytuację, że wspomniany PFRON chciał najnowszą wersję JAVY po zainstalowaniu której przestawał działać CITI albo DB bo te z kolei chciały starszej. Teraz doszedł do tego ZUS PUE który chce środkową…

    • problemem nie był sam rząd, a firmy które przetargi wygrały i użyły tej “technologii”, a nie innej….niestety…

    • Jeszcze całkiem niedawno tu i ówdzie można było napotkać ustrojstwa wymagające IE6 i wirtualnej maszyny Javy z Microsoftu…

  11. Cała infrastruktura podpisu elektronicznego stoi w oparciu o aplety Java. Logowanie do CEIDG, pue.zus.pl itp. Sporo przedsiębiorców ma taki podpis jako token usb. Ciekawe jak rozwiążą ten problem.

    • Będą zamiast dziurawej javy oracla będą używać openjdk (zresztą ten kto teraz używa jawy prawdopodobnie od dawna tak robi).

    • Dlaczego technologia tak popularna i powszechna jak Java w wykonaniu takiego giganta jak Oracle jest tak groteskowo dziurawa? Cała kasa idzie na kolejne jachty pana Ellisona…?

  12. I nie tylko e-goverment ale i dużo różnych producentów, których zarządzajki Javą stały…

  13. Hehe to może napiszcie do nich już teraz bo się obudzą po fakcie z ręką w nocniku :)

  14. z tego co wiem to banki,które korzystają z czytników kart jako autoryzacji używaja wtyczki java :D

  15. To się zdziwi cały ePUAP :) Wszystkie podpisy cyfrowe działają na apletach java w naszych ministerstwach. Np. taki KIR udostępnia aplet java dla programistów http://www.elektronicznypodpis.pl/oferta/narzedzia-programityczne/ . Mają w prawdzie biblioteki dll dla windowsa ale przecież nie wszyscy programiści pracują w C# :) I teraz najlepsze: jeśli firma programistyczna wykupiła taki aplet to może szykować się juz na kupno apki pod nowy plugin Java Web Start. Oj będzie przetarg ów :)

    • Obecnie produkcyjnie korzystamy z SDK KIR-u i uruchamiamy to jako Java WebStart i spokojnie to działa.
      Wydaje mi się że nie do końca wiesz o czym piszesz :)

      Problem apletów do podpisu to klasyczny przykład na to jak kończy się pisanie “aplikacji” w HTML (czy ogólnie w przeglądarce). Niestety czasem lepiej mieć starego, dobrego “grubego klienta”, jeśli wymagany jest dostęp do zasobów lokalnych.

  16. Stosowanie appletów Javy było pomyłką od samego początku.

    • Jeżeli tak uważasz to podaj argumenty popierające twój punkt widzenia

    • // włączam subskrypcję

    • argumenty dlaczego pluginy javy są złe? Proszę bardzo:
      1) brak kompatybilności pomiędzy wersjami. Aby zarządzać serwerami różnych producentów i mając kilka generacji serwerów muszę mieć wirtualki z javą 1.6, 7, 8 bo każdy KVM wymaga innej wersji. Co więcej czasem nie chodzi o główną wersję, ale o to co jest po 3 kropce :P
      2) Różnice w implementacji javy w zależności od jej producenta: microsoftu, ibma, suna, oracla, openjdk (icedtea). Na szczęście obecnie zostały na rynku tylko te 2 ostatnie, niestety różnią się.
      3) java miała być niezalężna od platformy – ale nawet ta sama wersja javy od oracle czasem działa inaczej w windowsach a inaczej w linuxach
      4) co chwile pojawiające się problemy bezpieczeństwa. Co jest wysoko niekonfortowe w połączeniu z pkt1 i koniecznością utrzymywania starych wersji.
      5) wydajnościowo to było zawsze słabe rozwiązanie. Prawie wszystkie interface’y w javie które pamiętam się ślamazarzyły.

    • @barchan

      Pytanie czy rozmawiamy o samej Javie czy konkretnie o apletach/pluginach.

      Wszystkie podane przez ciebie punkty podane zostały przez ciebie przez pryzmat wygody użytkownika i wydaje mi się, że były związane ogólnie z Javą, a nie tylko apletami/pluginami. Różne wersje Javy – różnice w implementacji / kwestie bezpieczeństwa, sam się z tym spotkałem w przypadku wersji SE/EE. Nawet kiedyś opisałem w jaki sposób wykrzaczyć aplikację aby po części uzyskać zawartość jej pamięci. Ad.2) Różnice w DZIAŁANIU implrementacji – nooo tutaj niestety jest to bardzo mocny argument który doświadczyłem między impl. IBM vs Sun, wtedy wygrała wersja Sun’a. Ad.5) Java applet to nie jest forumła 1 i wyścigi. To jest coś co ma działać i dostarczyć jakąś funkcjonalność której nie zapewnia/ł HTML/JS.

      Reasumując Java nie jest wygodna do wszystkiego. Dodam też, że nie jestem zaślepionym fanatykiem Javy.

  17. Posypie się także PL.id :) i cała masa systemów regionalnych np. wrotamazowsza.pl :)

  18. Rząd rządem ale jak będę wyrywał lachony na czaterii?

  19. Kurnik.pl też przestanie działać?

    • Akurat kurnik ma dwie wersje: java, i html czysty.

    • Kurnik dziala na html5 od kilku lat, nie potrzeba tam javy

  20. Programy pt. “dziennik lekcyjny” też oparty na javie, można powiedzieć i jak tu kontrolować młodzież “zdalnie” czy jest np. na lekcjach
    Cały ten segment do wymiany się szykuję, albo praca na “starych”, “dziurawych” przeglądarkach

    • u mnie wszystko działa bez apletu, jedyne co mi przeszkadzało to białe ekrany po kilka razy kiedy był wyłączony js. dla każdego białego ekranu po kolei (były ze 3), rozwalonego menu i samego dziennika trzeba było zrobić nową regułę w ScriptBlocku, bo ciągle przełączało na inne domeny. z tego co widzę w szkole to nauczyciele podpinają się pod zdalne komputery z windows server (zwiększone ryzyko keyloggera, może się pojawić na jednym z dwóch systemów; 1 dnia miesiąca nauczyciele piszą hasło 3 razy – system chce zachęcić do jego zmiany), po czym otwierają Firefoxa i znowu wpisują to samo, jeśli oczywiście już nie zapisali go sobie w przeglądarce (bez master password oczywiście; wiecie co to oznacza?). bardzo ciekawe jest to że wszyscy logują się pod tym samym url. w każdym razie javy nigdy nie widziałem przy tym, bo jeszcze nie chodzili po informatyków :P. problemy mają może jedynie użytkownicy kart wirtualnych, ale na szczęście nikt tego u mnie nie używa.

  21. skrzynki podawcze to *uj, wszystkie mechanizmy podpisu elektronicznego które znam wymagają Javy, banki itp będą miały przesrane:)

    • Nareszcie.

    • nie banki tylko ludzie którzy tym się zajmuję/serwisują/programują

  22. Chrome przestaje obsługiwać aplety od ładnych kilku miesięcy. W październiku miałem już problemy przy obsłudze pewnej strony. A co z e-goverment? Pewnie na stronaj pojawi się informacja żeby nie aktualizować ani javy ani przeglądarek..

  23. IE11

  24. Nareszcie bedzie troche spokoju. A nasz e-rząd juz niech sie bierze za html5 tylko bez udziwnień.

    • Renomowana firma Nabino zapewne nie będzie mogła opędzić się od zleceń.

  25. No cóż… kto pierwszy zaimplementuje WebCryptoAPI ten wygra internety. Co do java Web Start to jest w pewnym sensie jeszcze gorsze niż applety.

  26. Niektóre instytucje nic sobie z tego nie zrobią, brak wsparcia? Trudno! Nie raz miałem styczność z aplikacjami urzędowymi gdzie jasno było napisane, że wymagana jest java 6.x, bo z wyższymi nie chciało współpracować, hitem była jedna instytucja (nazwy nie przytoczę) gdzie wymagana była java 5.x, ale tamtejszy administrator mądrze zostawił ją tylko na jednym komputerze ;) w związku z czym, jeżeli ktoś chciał skorzystać z tego systemu musiał podsiąść koleżankę ;)

  27. Atman do KVM też używa nappleta. Co ciekawe nie działał poprawnie na linuxie i instalację serwera musiałem przeprowadzać z windowsa.

  28. Czekamy teraz aż zdechnie Silverlight i Flash.

    • lub też same serwisy (YouTube) zaczną przechodzić na HTML5

    • Problem w tym że podczas gdy Flash rzeczywiście jest mulasty, to HTML5 muli jeszcze dużo bardziej (przynajmniej na nieco starszych kompach).

  29. Ale jak to możliwe przecież java ponoć jest multiplatformowa i najszybciej rozwijającym się językiem i najwięcej się w niej programuje i tak dalej. Czyli że co przeglądarki ją ubiją ??

    • Java jako język daje sobie radę już długi czas. Chodzi o te obskurne (n)applety które wymagają pluginu w przeglądarce. Kiedyś to było częstym widokiem w internecie, ale teraz już pozbywa się tego rozwiązania gdzie się da. Niestety nie da się np. w przypadku modułów kryptograficznych (podpis elektroniczny) co już dawno powinno być rozwiązane w inny sposób. Celem jest ustandaryzowany i bezpieczny HTML5 który nie wymaga uruchamiania programów po stronie przeglądarki. Jako że “gospodarz” Javy, Oracle odżegnuje się już od wtykania wtyczek w przeglądarki, może się to kiedyś udać.

  30. iLO, DRAC, Supermicro :(

    • iLO jest java-free więc nie rozumiem wpisu.

  31. finally! piekna wiadomosc na piatkowy poranek ;) teraz jeszcze silverlight

    • Tak, niechaj HTML5 podąża śladem systemd i pochłania wszystko co “w pobliżu” – dyskontynuować Flasha, Silverlight’a, Javę, Javascript, CSS, PHP, SQL, i co tam jeszcze, i zintegrować wszystko w HTML5 – hurra!

  32. Problem jest taki, że w administracji publicznej jest wymagany podpis elektroniczny.
    API przeglądarki nie obsługuje podpisu kartami (WebCrypto API ciągle się jeszcze zmienia), a co najśmieszniejsze Firefox przez chwilę to obsługiwał, ale wykreślili to ze standardu.
    Więc trzeba albo napisać wtyczkę do podpisu do każdej przeglądarki/platformy, co jest upierdliwe, bo wersje przeglądarki często się zmieniają co wymaga stałej konserwacji wtyczek, praw administratora do instalacji oraz restartu przeglądarki po instalacji.
    Do tej pory alternatywą były applety Java w której podpis działał na każdej przeglądarce i, przy odrobinie starań, także na Linuxie.
    Teraz zapewne większość tych rozwiązań zostanie przerobionych na web start – czyli dla użytkownika będzie jeszcze trudniej.
    Oczywiście też uważam, że bardzo dobrze się stało bo Java była dziurawa, ale z mogli najpierw dopracować Crypto Api.

    • @li-on, @Koziołek, @Sławek: WebCrypto API nie rozwiąże problemu bo np. pl.ID musi też skanować dokumenty. Nasze rozwiązanie zakłada (stety-niestety) daemona słuchającego lokalnie na kompie, który ma swój aktualizator i z którym aplikacja komunikuje się via AJAX. Alternatywa to Java Webstart, która ma swoje inne bolączki.

      Trzeba w tym modelu zapewnić bezpieczeństwo, zapewnić aktualizacje i jakiś fallback. Może lepsze pomysły?

    • zawsze można zaimplemetować szyfrowanie w javascriptcie

  33. Będę tęsknił za czasami Sun Java.

    • Niektórzy do dziś tęsknią za MSJVM…

  34. No pięknie, a mamy tyle stron, gdzie Java obsługuje czytnik do składania podpisów: ePUAP, CEIDG, ZUS PUE, bankowość korporacyjna. Nawet aplikacja ŹRÓDŁO w urzędach korzysta z Javy.

  35. Z appletami javy były kłopoty od kiedy się pojawiły w latach 90. Ogółem z javą jest kłopot, bo była reklamowana jako “łatwa i szybka”, a tak na serio napisać wydajny program w javie jest wcale nie prosto (przez co większość to wielkie mulące kobyły). Krew mnie zalewa jak gdzieś muszę użyć appletu javy, bo zanim się załaduje (zakładając że w ogóle to zrobi), to wyświetli mi na twarz ze 20 popupów z pytaniami czy na pewno chcę odpalić i czy mi nie przeszkadza self signed cert i brak jakiegoś inszego wpisu w pliku konfiguracyjnym appletu itp itd. Orgia okienek to jak np łączę się do webconfiga jednego ze switchy w pracy, który ładuje 3 applety w osobnych ramkach – kilka minut klikania potwierdzeń, a w każdym inna pozycja buttona.

    A polskie urzędy itp? Tak jak już parę osób wspominało – będzie notka że wymagana któraś stara wersja przeglądarki. Z resztą, o czym my w ogóle mówimy jak zazwyczaj “zalecany” jest ie6? (zalecany tzn na niczym innym nie działa)

    • ProCurve poza HTML i serial ma też interfejsy telnet i ssh. I nawet możesz na nich wywołać konfigurację opierającą się o menu gdybyś tak bardzo nie lubił linii komend. :-)

  36. I pojawi się wymaganie posiadania starej wersji IE do wejścia na niektóre strony.

    • w przypadku intranetów to tak będzie

  37. Wszystko pięknie, a jak do cholery mam korzystać z bibliotek cyfrowych, skoro Java już nie działa, co widać przy próbach korzystania i dodawania wyjątków (też już nie funkcjonuje).
    Czy naprawdę trzeba wierzyć w niebo, żeby kiedykolwiek mogłoby być NORMALNIE?

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: