Ook die java web start maar achterwege laten.https://www.java.com/nl/download/faq/java_webstart.xml
Elke locale applicatie gaat de java versie die web-browser kent delen. Een ramp voor release management als meerdere applicaties een andere java-run time versie vereisen. Beter kan je met een private runtime java versie per aparte tool/applicatie werken zodat je die onafhankelijk door een life cycle management kan trekken.

Wat??!

Om eens een concreet voorbeeld te noemen, doe ik niet, mis ik niet.
Kan Java missen als adware-kiespijn.

'Benieuwd' of de lichten bij Oracle weer/nog steeds/opnieuw hebben bedacht de volledige Java 9 installatie voor Mac's in de systeembrede internet-plugins directory te plaatsen (jawel daar staat het tot op heden!).

Dus geheel Java 9 (zonder browser plugin) als pakket in de internetplugins folder te installeren!
Java als een soort plugin aanbieden zonder plugin ?
Een contradictie in termino.

Adware/Spyware? Dat was toch een Windows 10 discussie?


Mac? Wie gebruikt die dingen nog?


Een contradictio in terminis dan toch.

Pardon? Java is backwards compatible dus de nieuwste versie moet alle software kunnen draaien. Indien dat niet het geval is dan heeft de ontwikkelaar van de software slecht werk geleverd en gebruik gemaakt van constructies die als problematisch zijn aangegeven door Oracle. Dat moet je niet doen en als je het hebt gedaan dan moet je het z.s.m. oplossen, zodat je klanten er geen last mee krijgen.

Ik moet zeggen dat ik me zo geen software voor de geest kan halen waar een specifieke Java run-time nodig is.

Hiep hiep hoera! Nu hopen dat IP camera's niet nog eens 10 jaar met Java-plugins worden geleverd.

Helaas de praktijkervaring als het om meer complexere situaties dan "hello world" gaat.
Er is een verschil tussen wat er beloofd wordt en wat de werkelijkheid is. Bedenk JRE is een eigenlijk een virtule machine met de bedoeling om los van het OS te komen. Zie het als een OS op zich. Met elk OS loop je ook soms tegen incompatibliteitsproblemen aan met gebruik van onderliggende applicaties. Zie de java classes als de applicaties.
Een lijst van settings voor de runtime omgeving.

Wat stuur parameters
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html
https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html
In een citric Windows VM is de mogelijke setting van de xmx beperkt. http://docs.citrix.com/en-us/cloudportal-business-manager/2-4/cpbm-faq-wrapper-con.html

Als je daar thuis in bent.. http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
"However, there are some minor potential source and binary incompatibilities in the JRE and JDK that involve rare circumstances and "corner cases" that are documented here for completeness."

Als de bouwer/onderhouder zelf aangeeft dat er incompatibliteits delen zijn. Waarom zou je het dan gaan ontkennen?
En nee het is niet zo maar gevonden het is echt door praktijkervaringen.

Als gebruiker van netwerkmanament tools van diverse grote fabrikanten loop ik er wel degelijk tegenaan dat java niet backwards compatible is. Er wordt bij opstarten gewoon gechecked op aanwezigheid van een bepaalde versie. Heb je die precieze versie niet, dan wil de software gewoon niet werken. Updates ? Ha, ha, ha..... Een grote, onwerkbare, puinhoop hebben ze er met zijn allen van gemaakt. En wie wordt daar beter van ?

Je negeert even het probleem dat Oracle dingen als problematisch aangeeft NADAT de applicatie geprogrammeerd is
die er gebruik van maakt. Neem bijvoorbeeld de hele kermis rond wat er wel en niet mag in plugins, en rond die
"security manifest" of hoe het ook weer heette. Applicaties die 10 jaar prima werkten storten daardoor ineens in,
en daar kon de programmeur niks van weten.

Dat heet onderhoud van software en dat is de verantwoordelijkheid van de fabrikant. De programmeurs die het destijds schreven konden er natuurlijk niets van weten maar als fabrikant kan je software niet over de schutting gooien en er jarenlang niets meer aan doen.

De fabrikanten van dergelijke networkmanagement tools hebben de verantwoordelijkheid om deze up to date te houden. Wanneer er nieuwe informatie beschikbaar komt over compatibiliteit met modernere platformen dan moeten zij hun software daaraan aanpassen.

Spreek de fabrikanten van de tools die je gebruikt erop aan maar leg de bal niet bij het snel moderniserende platform.

Hopelijk past de site waar mijn moeder altijd klaverjast zich snel aan, want anders kan dat niet meer. Die site heeft java nodig.

Leuke houding maar gespeend van elke realiteit. Als je wat kritische systemen hebt die echt betrouwbaar moeten zijn en dan hap snap wat updates aanbrengen? Misschien leuk voor speelgoedtreintjes op zolder.
Om echt betrouwbare systemen te krijgen moet je een heel test cyclus met schaduwdraaien etc door. Daar geen weken en soms maanden overheen (een +half jaar doorlooptijd kan heel normaal zijn).

Jullie stellen voor dat je de testen/validaties maar moet gaan overslaan omdat het je niet uitkomt? Nou als je secuur betrouwbaar werken en security op het oog hebt dan is die houding een tegenstelling van jewelste.

Je gaat me toch niet vertellen dat bij een systeem van een dergelijke complexiteit het functioneren van bedrijfskritische programmatuur afhankelijk wordt gemaakt van welke Java versie de browsers van gebruikers hebben geïnstalleerd? Indien er op de server specifieke versies nodig zijn dan zijn die er toch bij die programmatuur bij gezet? (Zeker niet afhankelijk van wat er in browsers voor versie draait.)

Mag je hopen. Indien niet dan is dat nogal knullig en dan krijg je inderdaad problemen wanneer nieuwe versies moeten worden uitgerold.

Er zijn nog steeds heel veel bedrijfkritische systemen die van allerlei verouderde technieken afhankelijk zijn (qua hardware, software, security richtlijnen, beheer en instandhouding, enz). Het betreft echt niet alleen een Java of IE versie. Denk aan, bijvoorbeeld, meet- en regelsystemen in ziekenhuizen, nucleaire installaties (niet alleen kerncentrales), verkeerbegeleidingssystemen (luchtvaart, zeevaart, enz), nutsbedrijven (gas, drinkwater, riolering, enz), zware chemische industrie, sluiscomplexen en heel veel meer.

De aansprakelijkheden, sancties en boetes zijn bijzonder slecht geregeld (in de praktijk). Dus de gemiddelde verantwoordelijke kiest voor het goedkoopste en het wijzen met de vinger als er zich iets voor doet.

Dus er verandert niets wezenlijks in de (manager) mentaliteit in deze tak van sport. Er zal eerder gekozen gaan worden om de boel te bevriezen. Wat wil zeggen: helemaal niets wijzigen, of updaten, want anders valt de applicatie misschien om.
Want doen zoals het volgens velen, op papier dan, zou moeten zou beschikbare budgeten breken, gigantisch veel manuren vergen en duck-taped kritische systemen nog meer op losse schroeven zetten (want fabrikant/leverancier zegt dan doodleuk: dat ondersteunen wij niet).

Het type specialist dat om weet te gaan met dit spreekwoordelijke "prikken met een stok in een wespennest" is er over het algemeen een die zich ook afvraagt of de applicatie, na de updates, nog steeds code 0101 geeft in situatie xyz. Waarbij xyz dan staat voor iets als "meltdown", en 0101 voor "noodstop uitvoeren".