Java 17 krijgt nieuwe implementatie voor randomnummergenerators

Java 17 krijgt een betere implementatie voor nummergenerators. In de development kit zit een voorstel voor nieuwe generators, en een interface waarin nieuwe generators via een api kunnen worden aangesproken.

Het gaat om voorstel voor een aanpassing van de OpenJDK 17, de Java Development Kit. Daarin staat dat de makers een nieuwe interface en nieuwe implementaties willen voor pseudorandom number generators, of PRNGs. Het doel daarvan is om het makkelijker te maken voor ontwikkelaars om verschillende PRNG-algoritmes in applicaties in te kunnen bouwen, en om code duidelijker en kleiner te maken door duplicaties te verwijderen. De makers zeggen dat het niet de bedoeling is om veel nieuwe generators in Java te implementeren, maar om een framework te maken waarmee dat makkelijker kan.

De legacy-systemen Random, ThreadLocalRandom en SplittableRandom worden toegevoegd aan JDK 17 omdat die 'veelvuldig gebruikt worden in andere programmeertalen'. Volgens de makers hebben die drie classes overlappende kenmerken waarvoor het in sommige gevallen makkelijker is om die via een interface aan te passen.

Die nieuwe interface heet RandomGenerator. Daarin zit een algemene api waarmee bestaande en nieuwe nummergenerators kunnen worden toegevoegd en beheerd. Ook voegen de makers vier nieuwe PRNGs toe aan die interface. Dat zijn SplittableRandomGenerator, JumpableRandomGenerator, LeapableRandomGenerator en ArbitrarilyJumpableRandomGenerator.

De Java Development Kit 17 komt pas in september uit. Het gaat dan om een lts-release die drie jaar ondersteuning krijgt. In maart komt eerst JDK 16 uit, maar die versie krijgt maar ondersteuning voor een half jaar.

Reacties (136)

[IndigoX]

Is random écht random?
Ik had altijd begrepen dat écht random niet bestond, aangezien alles gebaseerd is op formules.

[SinergyX]

Abstract gezien, random is niet vast te stellen, anders is het namelijk niet random

Zelfs de random-generator van de lava-lampen is aangegeven dat als je alle physics in een algoritme gooi, je theoretisch dit kan breken, ruis op een televisie, background radiation mapping, de vleugelklappen van een groep vogels, je kan altijd alles terugbrengen tot formules (tot bijna oneindig hoeveelheid data, maar het is mogelijk).

Maar secondair, als dit ooit mogelijk zou zijn (bv quantum state van 100.000.000 atomen), je zit met efficiency. Je wil niet dat een random 1024 string 1,5 dag duurt om te maken, als je deze wil inzetten voor bijvoorbeeld encryptie voor internet of waar een supercomputer voor nodig is. Je moet random in kunnen zetten op zaken als een telefoon of computer, moet binnen aanzienlijke tijd kunnen worden gemaakt, dus waar we theorisch infinity-1 random kunnen gaan, is het praktisch gewoon niet handig.

[johnkeates]

Je moet ook kijken naar de reden waarom je iets 'random' wil hebben. Stel dat het over cryptografische sleutels gaat dan moet de moeite die je moet doen groot genoeg zijn om het zinloos te maken, en daar komt ook de invoer van random data bij kijken. Stel dat je 1000 jaar nodig hebt om alle sleutels te proberen, maar ook 1000 jaar nodig hebt om alle mogelijke random states tijdens het genereren van die sleutel te achterhalen, dan maakt het al niet meer uit als je data na 200 jaar niet meer geheim hoeft te zijn.

[Tjidde]

Je moet echter wel met dat soort berekeningen rekening houden met progressie in computerkracht.
Quantum computing zal echt random cryptografie noodzakelijk maken.

Echter komt er wel de vraag waarvoor heb je dat nodig? Staatsgeheimen? Zullen veel mensen ja zeggen. Wat als het nu Gmail is? Hoeveel echt geheime data staat daarin? Maar als je het daar niet doet kan bijvoorbeeld iemand met toegang tot een QC mogelijk in je data. Want je wilt niet dat elke veiligheidsdienst jouw privedata kan decrypten.

Nu is het echter wel zo dat het theoretisch mogelijk is om veel crypto snel te breken met een QC. Echter of dat in de praktijk ook zal zijn moet nog aangetoond worden. Zover ik begrijp van QC's dat wij nog niet heel ver zijn maar ook toch wel.

[theguyofdoom]

> Quantum computing zal echt random cryptografie noodzakelijk maken.

"echt random cryptografie" is een onzinterm.

Gangbare Cryptographically Secure Pseudo Random Number Generators (CSPRNGs) worden geïmplementeerd op basis van symmetrische cryptografie. Die algoritmen zijn ook niet noemenswaardig kwetsbaar voor quantumaanvallen. De enige bekende quantumaanval op symmetrische cryptografie is Grover's Algorithm. Grover's algorithm is makkelijk te verslaan door de sleutellengte te verdubbelen. Daarnaast zijn er wat praktische eigenschappen van Grover's Algorithm die het waarschijnlijk maken dat het _heel_ erg lang niet praktisch blijft.

Asymmetrische cryptografie die gebruikt wordt om verbindingen te beveiligen is wel kwetsbaar (Shor's Algorithm), maar dat is een ander verhaal en daar wordt aan gewerkt (post-quantum cryptografie).

[Geekomatic]

" "echt random cryptografie" is een onzinterm."
Ummm,
Er bestaan natuurlijk wel hardware "fysieke" random number generators
https://en.wikipedia.org/...e_random_number_generator
Die samen met het simpele "one time pad" algoritme bewijsbaar onkraakbaar zijn.
https://en.wikipedia.org/wiki/One-time_pad
.
Maar praktisch gezien is dit idd niet zo bruikbaar, want:
- Speciale hardware nodig om keys te genereren.
- Key distributie moet fysiek gebeuren.
- Niet geschikt voor grote hoeveelheden data, want de key moet even lang zijn als de data.
.
Maar het is dus geen "onzin"

[Reactie gewijzigd door Geekomatic op 23 juli 2024 06:32]

[sjongenelen]

Hah mooie eindzin.

[keesdewit]

Vaak wordt over het hoofd gezien dat er een verschil zit tussen "willekeurig" en "onvoorspelbaar". Beiden hebben een andere toepassing.

[Goderic]

Niet waar, kwantummechanica is inherent willekeurig. Zelfs als je alle formules en de begin status exact hebt kun je nog niet voorspellen wat er gaat gebeuren.

[the_stickie]

maar dat is niet de technologie die we nu gebruiken

Analyse hierboven over de theoretische onmogelijkheid van volledig random op computers is wmb correct. Een oneindige entropie is onbreikbaar. We kunnen ons wel statisch verzekeren dat de entropie die we gebruiken voldoende is voor de toepasssing.
Over de jaren komen meer implemntaties in bereik door de toegenomen rekenkracht, wat verklaart waarom er een voortdurende onwtikkeling is op dit soort algoritmes.

[Goderic]

Niet direct, maar wel indirect, thermische ruis wordt door kwantum effecten veroorzaakt.

Ik snap niet precies wat je bedoelt met "oneindige entropie" bereiken maar het is wel gewoon mogelijk om een entropie van bijvoorbeeld 0.997/ bit te krijgen. Dat betekent dat met een sleutel van 128 bits nog steeds 127.6 bits entropie hebt.

[Verwijderd]

Zelfs als je alle formules en de begin status exact hebt kun je nog niet voorspellen wat er gaat gebeuren.

Dat klopt niet helemaal: je kàn de beginstatus niet exact kennen, zelfs niet in principe.

[PTR]

Niet waar, niet waar...determinisme, het kennisniveau en non dualiteit vinden er ook iets van ;-)

[pumpidumpi]

Totdat we er achter komen dat er 'achter' kwantummechanica nog een diepere laag is en we daarmee kwantummechanica ook kunnen voorspellen. Maar voor nu heb je gelijk.

[MSalters]

Sorry, maar dat is kolder.

Fundamenteel zijn je formules quantum-mechanica, en op quantumnivo zijn je gebeurtenissen onvoorspelbaar. Dat is geen aanname meer, dat is de vorige eeuw bewezen. Het is geen "missende informatie" waardoor sommige dingen onvoorspelbaar zijn, het is fundamenteel random.

Het meest bekende voorbeeld is het radioactief verval van een atoom. Geen enkele informatie die je nu hebt zegt iets over het verval in de aankomende nano-seconde.

En Schrödinger's kat is het bekende voorbeeld dat zelfs de meest kleine random events een onbeperkt groot gevolg kunnen hebben. Dat ene atoom kan ervoor zorgen dat de denkbeeldige kat dood gaat.

De lava-lampen zijn ook zo'n voorbeeld. Daarvan is met formules aangetoond dat het macroscopische patroon het directe en onvoorspelbare gevolg is van quantummechanische randomness.

[uiltje]

Er bestaat wel degelijk entropie. Entropie kan worden gebruikt als seed, waarmee je een random generator kan opstarten. Daarna zal een random generator bijna oneindig veel pseudo-willekeurige getallen kunnen genereren. Eventueel kan je nog extra entropie bij mixen door te "re-seeden" tijdens de werking van de generator. Een goede random number generator zal echter nooit in een "cycle" terecht komen en dezelfde (lange) reeks van getallen opnieuw produceren.

Het verkrijgen van entropie is natuurlijk het pijnpunt. Dit wordt meestal betrokken van het OS, die de entropie verzameld van bijvoorbeeld delta timings van je network interface. Vandaag de dag hebben processoren tevens een entropie bron die een on-die random nummer generator voedt (de RDRAND instructie op x86/64 bijvoorbeeld) die hierin mee gemixed kan worden.

Echt random bestaat wel degelijk, zeker op quantum-niveau, zie het onzekerheidsprincipe van Heisenberg. In de praktijk zijn er echter heel veel bronnen "willekeurig genoeg" om een random number generator op te starten. Bijvoorbeeld de witte ruis (achtergrondstraling) die je op oude TV schermen zag werkt prima (zolang niemand er expres er een test beeld op zet natuurlijk ).

[.oisyn]

Een goede random number generator zal echter nooit in een "cycle" terecht komen en dezelfde (lange) reeks van getallen opnieuw produceren.

Maar dat kan simpelweg niet. Een PRNG heeft een bepaalde state, en zonder invloed van buitenaf is dat een deterministisch proces. De gehele state bepaalt wat de volgende state is. Aangezien het aantal verschillende states gelimiteerd is, kan het dus niet anders dat hij op een gegeven moment weer dezelfde reeks van getallen produceert.

De enige manier om cycles te voorkomen is het reseeden met entropie van buitenaf. Maar goed, zo heel erg zijn cycles ook weer niet, als ze maar lang genoeg zijn en de output onvoorspelbaar.

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:32]

[uiltje]

Er zijn altijd cycles omdat de "state" eindig groot is, maar als die pas na 2^1000 bits plaats gaan vinden dan heb je er technisch gesproken geen last van.

[.oisyn]

Zoals ik al zei: "zo heel erg zijn cycles ook weer niet, als ze maar lang genoeg zijn en de output onvoorspelbaar."
Maar het is dus niet juist om te stellen dat er nooit een cycle zal ontstaan, want daaraan ten grondslag ligt nou juist het deterministische van een algoritme.

[nandervv]

Je hebt er geen last van in de gevallen waarbij er geen aanvaller is. Het gebruiken van een pseudo random generator is niet goed genoeg voor encryptie.

[uiltje]

Wat een onzin, het is aan te raden om een CS-PRNG te gebruiken voor versleuteling. Het is gevaarlijk om een TRNG rechtstreeks te gebruiken; een PRNG heeft normaal gesproken een betere verdeling. Natuurlijk moet je de CS-PRNG wel goed seeden met een TRNG vantevoren.

Zelfs smart cards gebruiken tegenwoordig een CS-PRNG, en als je RDRAND gebruikt op de chip van Intel gebruik je ook een CS-PRNG (of een DRBG in NIST-speak). Probeer maar eens een TRNG direct FIPS of AIS31 te certificeren.

Of weet je er meer van dan ik? Geef dan aan waarom je denkt dat een PRNG niet goed genoeg is! Ik kan niet wachten om hier meer over te leren

[jp]

Een goede random number generator zal echter nooit in een "cycle" terecht komen en dezelfde (lange) reeks van getallen opnieuw produceren.

In echt random is dat natuurlijk op zich wel mogelijk. (Bij een dobbelsteen kan je ook 15x achter elkaar een 6 gooien, ook al is die kans niet zo groot )

[MSalters]

Nee, in het echt is zo'n cyclus niet mogelijk. De essentie van een cyclus is dat die zich oneindig herhaalt. Het is geen lokale herhaling (15 keer 6) maar een globale herhaling. Dat hoeven dus niet allemaal dezelfde waarden te zijn.

1551644221513 1551644221513 1551644221513 1551644221513 1551644221513 ... (oneindig) is bijvoorbeeld een cyclus. Binnen één cyclus zijn de dobbelsteen waardes nog wel random, maar de herhaling van de cyclus is het kenmerkvan een PRNG.

[dec0de]

Als jij van alle deeltjes in het heelal weet welke richting, massa en snelheid ze hebben, bestaat random niet. Maar we kunnen wel dichtbij komen, door zoveel mogelijk moelijk voorspelbare dingen in 1 groote pool te gooien en dan lekker te grabbelen

[Left]

Nope, zelfs dan bestaat random nog steeds. Sommige gebeurtenissen in de quantummechanica zijn puur random, bijvoorbeeld hoe lang het duurt voordat 1 specifiek radioactief atoom vervalt. Dat gaat in tegen je intuïtie, Einstein wilde het destijds zelfs niet accepteren, van hem kwam de beroemde quote "God dobbelt niet". Maar sinds die tijd is het uitgebreid getest en onderzocht en tegenwoordig is het door (bijna) alle fysici geaccepteerd dat randomness echt bestaat in de natuur.

[SinergyX]

'op dit moment', omdat simpelweg onze absolute kennis nog niet zover gaat. Nu we steeds een laag verder gaan, wordt er telkens een nieuwe formule gevonden om die laag te bepalen, te voorspelen en te berekenen.

https://en.wikipedia.org/wiki/Double_pendulum
Zelfs deze zijn we al bizar ver, waar nog steeds het laatste aspect wordt gezien als 'chaos' en niet zozeer 'random', maar zelfs binnen Chaos theorie komen ze steeds verder.
https://en.wikipedia.org/wiki/Chaos_theory

Zolang we tegen die grens aan huppelen is dat random 'random genoeg', we zullen er over 100 jaar misschien weer anders tegen aan kijken.

[.oisyn]

Dan ga je wel een beetje voorbij aan de implicaties van de kwantummechanica, hoor. Er zijn tal van experimenten geweest die aantonen dat het onzekerheidsprincipe weldegelijk een fundamenteel ding is, en dat lokale verborgen variabelen zo goed als zeker niet bestaan (zie de link naar de Bell test die ik hierboven gaf).

[MSalters]

Chaos theorie gaat niet over de oorzaken van randomness. Chaos theorie beschrijft hoe een kleine random verstoring een (bijna) onbeperkt groot gevolg kan hebben. Dat zegt niets over de oorzaak van die initiële verstoringen.

Het is in zoverre relevant dat quantummechanica een bron van randomness is, en chaostheorie zegt dus dat je niet kunt begrenzen wat de gevolgen van quantummechanische ruis zijn.

[ZpAz]

Just out of curiosity, hoe is vastgesteld dat dat echt random is in plaats van dat we de achterliggende “formule” gewoon nog niet begrijpen?

[Reactie gewijzigd door ZpAz op 23 juli 2024 06:32]

[.oisyn]

De Bell test bijvoorbeeld.

[blorf]

Volgens mij wijst het feit dat een universum dat uit een singulariteit is gekomen maar niet symmetrisch is daar ook op...

[uiltje]

Heisenberg. Je kan dat niet eens weten.

[Blokker_1999]

Die ken ik alleen maar van Star Trek

[Maurits van Baerle]

“How does the Heisenberg compensator work? - Very well, thank you.”

[leadpumper]

Wordt in de praktijk nogal lastig 😀 Je zou het waarschijnlijk oplossen met een computer (met véél geheugen). Maar laat die nu ook uit deeltjes bestaan... De computer zou dan moeten kunnen voorspellen wat de staat van alle deeltjes zou zijn, maar door dat te voorspellen verandert de staat van sommige deeltjes.

[Transportman]

Ze zijn gebaseerd op formules, maar de input van die formule moet er voor zorgen dat het random genoeg is. Input kan bijvoorbeeld systeemtijd zijn, of muisbewegingen van een gebruiker.

Daarmee wil ik niet zeggen dat Java die inputs gebruikt, maar het idee blijft hetzelfde.

[com2,1ghz]

We zijn zo tegen een paar bugs aan gelopen in een Docker container. Daar bleef de boel hangen en timeouten. Bleek dat binnen een container er niet genoeg random(SecureRandom) events te meten waren waardoor de thread ging hangen.

Was wel een leuk leermomentje

[leadpumper]

Ik neem aan dat je het al gefixt hebt, maar voor anderen die hier tegenaan lopen: kijk eens naar Haveged als quick-fix: https://issihosts.com/haveged/

Het euvel komt doordat er gebruik gemaakt wordt van /dev/random, en die blockt zodra er te weinig entropie is. Haveged zorgt voor meer entropie.

Overigens kun je volgens sommigen net zo goed /dev/urandom gebruiken: https://www.2uo.de/myths-about-urandom/ Ik weet er zelf niet genoeg van af om te oordelen wat juist is. (En daarnaast zou je dan de software in kwestie moeten gaan hercompileren, of een patch moeten insturen.)

[com2,1ghz]

We hebben ook /dev/urandom gebruikt daarna inderdaad. /dev/random was eigenlijk gebruikt vanwege hetzelfde reden er in het artikel staat.

[Yoshi]

grotendeels waar, maar je kan ook ruis gebruiken uit electronica om iets random te genereren. En dat is volgens mij ook wat het onderdeel doet van de cpu dat je kan aanspreken om een nummer te genereren (of mede te genereren).

[blorf]

Ik vraag me af hoe belangrijk dit is. Als je op een PC de systeemtijd neemt, uitgedrukt in kernel main-loop ronde's vanaf opstarten en je neemt van de 20 digits de rechtse 10 dan heb je al een reeks cijfers die volgens mij op geen manier voorspelbaar kan zijn.

[Mijzelf]

Hierbij is het juist vreselijk goed voorspelbaar. De enige variabele is hoe laat je de PC opstartte. Vanaf daar is het monotoon stijgend.

[blorf]

Met fysieke toegang kom je misschien een beetje in de buurt, maar dan kun je evengoed gewoon de output van de random-methode via de process space onderscheppen. Met een druk op het toetsenbord of via een communicatie-adapter lukt het niet om een deze "meting" op een extact tijdstip na opstarten te plaatsen. De cijfers ontstaan uit een minimale fractie van een seconde waardoor ze volledig random zullen zijn. Als een computer precies een minuut na aanzetten de meting doet zullen de resultaten van 1000 afzonderlijke keren allemaal totaal van elkaar verschillen.

Het is als een stopwatch die miloensten secondes weergeeft. Geen manier om een dergelijke uitkomstwaarde te voorspellen. De meet-methode zelf is daar altijd al te complex voor. Helemaal een probleem wordt het als je die teller op een vast staand moment wil onderscheppen, dus als kwaadwillende, bij het proces van een ander...

[Reactie gewijzigd door blorf op 23 juli 2024 06:32]

[MSalters]

"Vreselijk goed" is geen bruikbare uitspraak hier. De entropie in die 10 bits is gewoon meetbaar. Ik vermoed dat je er al gauw 2 of 3 random bits uit kunt halen. Ja, 7 of 8 bits voorspelbaarheid is aardig, maar dat was de vraag niet. Als je begint met 1000 bits en er zijn er 900 voorspelbaar, dan is dat nog veel beter voorspelbaar, en heb je tegelijkertijd nog veel meer random bits over.

[beerse]

En je pc draait als 1 van 10 virtuele systemeen op dezelfde host die met auto-start gelijk zijn opgestart, dan zijn ze voor jou onvoorspelbaar maar in theorie is de kans op onderling gelijk zijn serieus aanwezig.
Dus moet er nog iets systeem specifiek in, zoals bijvoorbeeld iets uit de mac-adressen van de machine.

[beerse]

Daar moest ik ook aan denken. De vraag is dan natuurlijk welke kleur ruis je gebruikt. Ideaal is witte ruis natuurlijk. Met rode of blauwe ruis krijg je toch een afwijking naar onder of boven.

Uiteindelijk zal er veel willekeurig signaal als seed in een routine gaan om een willekeurig getal te pakken.

[Argantonis]

Is random écht random?
Ik had altijd begrepen dat écht random niet bestond, aangezien alles gebaseerd is op formules.

Er is wel écht random op een computer (voor zover iets ooit echt random is maar dat is een natuurkunde-discussie) maar dat soort functies gebruiken dan externe input.

https://en.wikipedia.org/...e_random_number_generator

Because the outcome of quantum-mechanical events cannot be predicted even in principle, they are the ‘gold standard’ for random number generation. Some quantum phenomena used for random number generation include:

A nuclear decay radiation source, detected by a Geiger counter attached to a PC.

[Reactie gewijzigd door Argantonis op 23 juli 2024 06:32]

[uiltje]

Intel RDRAND wordt geseed door een "self-oscillating digital circuit with feedback". En die zit gewoon op je chip hoor. ARM heeft een vergelijkbare functie natuurlijk. Dat er geen random functie op je PC zit is ondertussen echt geschiedenis aan het worden.

[Argantonis]

Intel RDRAND wordt geseed door een "self-oscillating digital circuit with feedback". En die zit gewoon op je chip hoor. ARM heeft een vergelijkbare functie natuurlijk. Dat er geen random functie op je PC zit is ondertussen echt geschiedenis aan het worden.

Dat is nog steeds externe input uit een natuurkundig proces dan. De computer zelf bedenkt geen daadwerkelijke random waarde.

[.oisyn]

Dat is wel heel erg filosofisch. Een computer zelf "bedenkt" sowieso niets, het is gewoon een electrisch circuit. Dat circuit is sowieso al volledig afhankelijk van natuurkundige processen; zonder kwantummechanica kun je de werking van een transistor niet verklaren. Niets staat in de weg om in dat circuit gewoon een stukje te bouwen dat een willekeurige 0 of 1 produceert op basis van een kwantummechanisch proces. Het is nogal arbitrair om dan maar te zeggen dat dat niet bij de computer hoort.

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:32]

[Argantonis]

Misschien filosofisch maar wel vrij essentieel. Dat de technologie achter de computer ook van kwantummechanica afhangt zegt niet zoveel, alles wat een computer kan bedenken met die transistoren is alsnog pseudo-random, altijd met een of andere functie. Er zal dus input uit de buitenwereld moeten komen om échte randomheid te introduceren. Dat dat in een chip kan zitten, ja sure, maar wel zolang die chip een sensor heeft om iets uit de buitenwereld op te pakken.

[.oisyn]

Nee, je haalt wat dingen door elkaar. Algoritmes zijn (met opzet) deterministisch, een geintegreerd circuit is zo gemaakt om deze uit te kunnen voeren, want we hebben nou eenmaal niets aan een nondetermistische computer. Maar feitelijk staat niets in de weg om in dat geintegreerde circuit een component op te nemen dat weldegelijk nondeterministisch werkt. Dat kun je dan wel noemen "sensor van buitenaf", maar het is gewoon een stukje electronica dat random waardes produceert, net zoals we ook electronica hebben die bits kan onthouden, etc.

[MSalters]

Er komt geen sensor uit de buitenwereld. Het is een transistor op de chip zelf die random van state 0 naar state 1 wisselt. Elke transistor is van nature al quantum-mechanisch. Chipmakers doen doorgaans extreem veel moeite om random gedrag te voorkomen, maar dat kunnen ze ook voor een paar transistioren opzettelijk achterwege laten.

[Argantonis]

Kan je misschien beter RDSEED zelf noemen.

https://software.intel.co...en-rdrand-and-rdseed.html

[Reactie gewijzigd door Argantonis op 23 juli 2024 06:32]

[blorf]

Met een PC moet het thuis ook wel lukken. Ruis op je mic-ingang softwarematig versterken en daar een reeks cijfers uit halen...

[Argantonis]

Met een PC moet het thuis ook wel lukken. Ruis op je mic-ingang softwarematig versterken en daar een reeks cijfers uit halen...

Ja idd (met enig voorbehoud wat je precies met die data doet). Het was ook niet m’n bedoeling om te zeggen dat het uit een supercomplex apparaat moet komen, maar wel dat een computer het niet uit zichzelf kan genereren.

[blorf]

Het uitgangspunt lijkt me dat je het niet op een constante voorstelling wil baseren. Als dat geen probleem is kun je nog gewoon een constructie verzinnen die onvoorspelbare reeksen cijfers geeft. Als je bijvoorbeeld een op seed gebaseerde randomgenerator voert met zijn eigen gegenereerde waarden en dat tot in een aantal 'levels' moet het ook wel voldoende zijn. Knap systeem dat zoiets doorgrondt en er in een uitzonderlijk geval niet totaal naast zit bij een poging om iets te voorspellen.

[Dnomyar96]

Uiteindelijk zijn het allemaal algoritmes die de nummers maken, dus het zal nooit écht random zijn, maar voor de meeste implementaties is het wel random genoeg.

[uiltje]

Oh, hoe wordt RDRAND dan geseed volgens jou?

[Kwistnix]

Deze generatoren zijn inderdaad pseudo-random. Dat is ook waar de P in PRNG voor staat

[ChillinR]

Het is niet écht random nee. Dit wordt aangegeven door pseudo / de P in de afkorting PRNGs:

Daarin staat dat de makers een nieuwe interface en nieuwe implementaties willen voor pseudorandom number generators, of PRNGs

Voor toepassingen waarbij echte willekeur nodig is probeert random.org een oplossing te bieden, door ruis uit de atmosfeer te gebruiken als input voor de randomgenerator.

[Reactie gewijzigd door ChillinR op 23 juli 2024 06:32]

[Blokker_1999]

Er zijn nog leuke manieren om willekeur te bekomen. Cloudflare heeft bijvoorbeeld een kast vol lavalampen staan, daar een camera op gericht en die beelden worden verwerkt tot randomness omdat de flow van die lampen niet te voorspellen is.

[Verwijderd]

Wat grappig, nooit geweten.
Heb 't even opgezocht, is beste een flinke wall vol lampen

[Verwijderd]

Echt random kan wel degelijk: https://www.idquantique.com/shop/online-shop/
Er zijn ook websites die iets gelijkaardigs aanbieden (oa. https://www.random.org/ dat gebruik maakt van atmosferische ruis, wat in principe ook echt random is)

[ACM]

De titel van de JEP:

JEP 356: Enhanced Pseudo-Random Number Generators

dus dat lijkt me wel antwoord op je vraag te geven

[beerse]

Ooit op de HTS een programmeer opdracht gekregen: Maak een programma dat een willekeurig getal geeft.

Mijn oplossing : `echo 24`

Die 24 is een geheel willekeurig getal. Dat het elke keer het zelfde getal is doet daar niets aan af. Als er een nadere eis wordt gegeven door te zeggen dat na herhaald uitvragen een redelijk gelijke spreiding moet komen binnen de scope, dan is het daarmee dus geen willekeurige spreiding. Want uiteindelijk moeten alle getallen aan bod komen en als het getal 11 nog niet aan bod is geweest en het moet aan bod komen om de vulling goed te krijgen, is het dus niet meer willekeurig.

Maar dat is misschien wel een beetje filosofisch geneuzel.

[.oisyn]

Wel een beetje geleend van XKCD
Deze Dilbert is ook relevant.

[beerse]

Mooie invullingen van vergelijkbare inspiratie. Nu ben ik toevallig "The Hitchhiker's Guide to the Galaxy" aan het her-lezen. Verbeterde versie:

echo 42

[Sp3ci3s8472]

Het hangt ook weer veel af van de gebruikte generator. Je hebt goede en hele slechte.
https://www.pcg-random.org/index.html

[fastedje]

De pseudo random number generators leveren niet echt 100% willekeurige getallen op, hiervoor is op.een computersysteem echt random input nodig van bronnen die echt random getallen afleveren. Dit zijn over het algemeen bronnen van devices of zelfs hardware number generators die werken op basis van kwantumruis.

Op linux levert /dev/random alleen getallen die echt random zijn gebaseerd op die input van hardware. Zo kan het gebeuren dan een Java applicatie blijft hangen bij het opstarten omdat er niet genoeg echte random input is om degelijke random keys te genereren.

Als je linux hebt is het interessant om het volgende te testen: cat /dev/random

Als deze stopt kan je b.v. met de muis of toetsenbord meer entropie genereren waardoor je weer output van /dev/random ziet.

[naftebakje]

Je hebt 2 soorten random:
- puur rekenkundig pseudo-random maken, waarvan je weet dat het pseudo is (zelfde startcondities geeft telkens dezelfde reeks getallen).
- random op basis van natuurkundige willekeur: met ADC variaties op spanning inlezen, inlezen van thermische ruis van een diode, ... Op een of andere manier analoge variaties binnennemen (en liefst meerdere combineren) en die zo goed mogelijk randomiseren zodat je op geen enkele wijze op voorhand kan voorspellen welke reeks getallen er uit zal komen.

Op de laatste manier heb je een beperkte aanvoer van de reeks random data, dus als je sneller getallen wil maak je de combinatie: de "echte random" ga je gebruiken als input voor een "pseudo-random".
Op die manier kan je ook de spreiding vergroten, het is bijvoorbeeld perfect mogelijk dat je een hoop herhalingen ziet in een natuurkundige random reeks waar dat in je toepassing ongewenst is (cfr. Wat is de kans dat je na 10 keer 6 gooien na elkaar met een dobbelsteen weer 6 gooit? --> een zesde, maar het menselijk brein is daar niet mee akkoord, wil dat die kans dan kleiner is.); met een pseudo-random algoritme kan je dit bijsturen om er "gewenste random" van te maken.

[MikeN]

De legacy-systemen Random, ThreadLocalRandom en SplittableRandom worden toegevoegd aan JDK 17

Even voor de duidelijkheid, die worden dus niet toegevoegd, maar dat zijn juist implementaties die nu al aanwezig zijn.

[vinsterdamus]

Ze gaan de nieuwe interface implementeren als ik het bericht goed begrijp. Dus ze worden toegevoegd aan de lijst van implementerende classes

[jimshatt]

Precies, en de quote over veelvuldig gebruik in andere programmeertalen gaat juist over de nieuw toegevoegde algoritmes.

[Kwistnix]

Er wordt overigens niet gerept over SecureRandom, die lijkt mij ook niet onbelangrijk. Al is dat een afgeleide van Random net als ThreadLocalRandom, dus die zal allicht ook meeverhuizen.

[ACM]

In de JEP wordt die wel benoemd. Dat is een subclass van Random en gaat dus automatisch mee.

quote: https://openjdk.java.net/jeps/356

Note that because SecureRandom is a subclass of Random, all instances of SecureRandom also automatically support the RandomGenerator interface, with no need to recode the SecureRandom class or any of its associated implementation engines.

[Robkazoe]

Dit meme plaatje kan natuurlijk niet ontbreken bij dit nieuwsbericht: https://imgur.com/bwFWMqQ

[Eonfge]

Je kunt heel wat papers vullen met berekeningsmethodes over random, accuratie en deviatie. Super interessant/slaapverwekkend allemaal, maar gelukkig zijn er ook goede (cryptografische) libraries die dit werk je uit handen kunnen nemen. Bouncy Castle is een aanrader wat dat betreft.

Ook leuk om te zien, is hoe zo iets werkt in een game. Vaak wordt er gebruik gemaakt van goedkope PRNG tabellen zodat alle clients gelijk lopen, met allemaal exploiteerbare effecten. Speedrunners zijn daar super goed mee.

Hier de Doom uitleg:
https://www.youtube.com/watch?v=pq3x1Jy8pYM

[Reactie gewijzigd door Eonfge op 23 juli 2024 06:32]

[P1nGu1n]

Ter aanvulling, hier nog een van The Legend of Zelda: The Wind Waker:
https://www.youtube.com/watch?v=1hs451PfFzQ

[Standeman]

Dan mag xkcd ook niet ontbreken!

[darkfader]

https://www.royvanrijn.co...k-and-xkcd-random-number/

[Dark Angel 58]

Ik dacht dat Java ook gaat stoppen... net als Adobe Flash.

[MarnickS]

Die kans lijkt me heel klein. Heel veel software is afhankelijk van Java.

[Umbrah]

Niet alleen oude software hoor, ook veel nieuwe software heeft een basis in Java. Puur kijkend naar backend/applet niveau is het gewoon mega-flexibel en snel, en met OpenJDK's en JVM's zeker in Adopt wereld, gaan we er nog lang niet vanaf zijn.

Waar ik je wel punten moet geven is op frontend niveau: web applets zijn gestorven, en ook JavaFX is niet mega groot, maar daar staat dan weer tegenover dat je het op de gekste plekken tegen komt. 3DMark bijvoorbeeld heeft behoorlijk wat Java in zich verwerkt.

[jrswgtr]

Bijvoorbeeld Android SDK

[uiltje]

Alleen beweegt die niet zo snel mee, hoewel LTS releases vast extra aandacht krijgen. Voor zover het niet naar Kotlin op schuift natuurlijk, Google is maar wat graag los van Oracle waarschijnlijk.

[jrswgtr]

Het probleem wat je met Android SDK hebt is dat je continu moet denken aan backwards compatibility. Daardoor zit je constant met legacy code te werken, en met iedere nieuwe versie komt er weer een AppCompat library bij. Niet echt fijn om mee te werken.

[Wh4ck0]

Volgens mij zitten die niet vast aan Oracle, Google heeft hun eigen JVM voor Android gebouwd.

[uiltje]

Inderdaad, gebaseerd grotendeels op Java 8, maar onderdelen van Java 9 en 11 worden ondertussen ook ondersteund. Natuurlijk is het vanwege compatibiliteit met core libs wel zo handig om enigszins bij te blijven. Als je dat niet doet ga je een grote groep Java devs op den duur ook afschrikken. Het grootste probleem van Java is dat het nogal omslachtige taal is; juist de laatste versies pakken dit aan.

Dit is echter natuurlijk ook een belangrijke reden waarom Kotlin überhaupt bestaat, dus het is aan Google welke kant ze opgaan (en ze zijn groot genoeg om beide kanten tegelijk op te gaan).

[Reactie gewijzigd door uiltje op 23 juli 2024 06:32]

[vickypollard]

"3 Billion Devices Run Java"

[Argantonis]

Grappig. De halve serverwereld draait op Java. En weet je waarin Android apps geschreven zijn?

[Killemov]

En weet je waarin Android apps geschreven zijn?

Iets wat heel sterk lijkt op Java maar vanwege Oracle absoluut geen Java genoemd mag worden?

[Reactie gewijzigd door Killemov op 23 juli 2024 06:32]

[pbruins84]

In Kotlin?

[Standeman]

Wat gewoon weer java is met een ander sausje

[ACM]

Het is een andere taal op basis van dezelfde JVM. Dat is niet helemaal hetzelfde als een Java-dialect

[Standeman]

Ik heb hier nog een Groovy boek staan, ik vermoed dat het met Kotlin niet veel anders zal verlopen

[ACM]

Nouja, het is nu wel de de-factor taal voor Android geworden toch?

Dus het kan ook de kant van Scala op gaan, wat wel aardig populair is gebleken/gebleven.

[Standeman]

Het is al weer een tijdje geleden dat ik mezelf onder de android dev community heb begeven, dus daar zou je best gelijk in kunnen hebben.

Mijn punt is dat veel van dit soort bewegingen opkomen en weer neer gaan (zoals ook Scala), maar dat "plain old simple java" blijft bestaan en ze overleeft. Hoewel je qua Kotlin een goed punt hebt dat het een blijvertje is wanneer het dominant is bij android.

[ACM]

Ik ben sowieso met je eens dat Java nog lang niet is uitgespeeld in de wereld. Zelfs niet nu Oracle het langzaamaan steeds een beetje lastiger is gaan maken.

En dat is maar goed ook, want voor Tweakers krijgt Tomcat toch zo'n 500 requests per seconde...

[GoodspeeD]

Deels deel ik jouw vrees. Tegelijkertijd is Kotlin de standaard voor Android-ontwikkeling. Als je nu een Android project start in Android Studio, wordt je Kotlin voorgeschotend. En Kotlin wordt gesteund door Google en sterk doorontwikkeld door JetBrains. Dus in die zin geef ik het wel een enorme kans van slagen. Meer dan Groovy en Scala.

[Cyb]

Groovy bleef een beetje steken bij Grails en Gradle. Kotlin is verder dan dat, met Android, Spring en de invloedrijke rug van JetBrains. Vooral met Spring support zorg je er voor dat je meteen een hele lading enterprise developers meekrijgt, terwijl dat bij Groovy beperkt bleef tot een web framework en een CLI build tool. En dat laatste heeft nu overigens ook Kotlin support.

Het Spring team had ook wel interesse in Scala, maar de Scala community gaf er wat minder om. In de Scala wereld zijn ze wat meer bezig met de academische wereld en complexere problemen. Het lezen van Scala code geschreven door anderen, is dan vaak ook een stuk lastiger dan de gemiddelde Java code, omdat men meer geavanceerdere taal constructies heeft en gebruikt. Zo begint het bijv. al met SBT (Simple Build Tool), wat door veel mensen wordt gezien als alles behalve simpel, en operators in Scala-Z operators die er dusdanig raar uit zien, "<|*|>", dat ze maar worden genoemd naar waar het op lijkt: een spaceship.

Kotlin richt zich vooral op het maken van een Java met meer mogelijkheden, en zo veel mogelijk compatibiliteit met Java. In Scala bestaat ook Java compatibiliteit, maar is dat minder belangrijk. In Scala houden ze zich liever bezig met complexere problemen dan Java.

[com2,1ghz]

Web applets ja.

[Cobalt]

Dacht het niet. Heel veel software server side draait op Java. Het ging destijds alleen om de applet in de browser want daarmee kreeg je te veel toegang net als ActiveX.

[Reactie gewijzigd door Cobalt op 23 juli 2024 06:32]

[jrswgtr]

Heel veel software server site draait op Java

Bijvoorbeeld het Spring MVC framework dat breed wordt gebruikt.

[Standeman]

Java in de browser is inderdaad niet aan te raden en is altijd ruk geweest, net zoals Adobe Flash.

Echter als server/backend is Java niet weg te denken. Overheids, banken, verzekeraars, etc gebruiken Java als programmeertaal om hun software mee te bouwen. Dit artikel gaat over SDK en heeft niet zo gek veel te maken met de browser-plugin.

[Reactie gewijzigd door Standeman op 23 juli 2024 06:32]

[phYzar]

Ook voegen de makers vier nieuwe PRNGs toe aan die interface. Dat zijn SplittableRandomGenerator, JumpableRandomGenerator, LeapableRandomGenerator en .

Oef, wat een cliffhanger, ben benieuwd naar de 4e!

[Thomasvt]

Even wachten nog op het Premium artikel

[Herko_ter_Horst]

ArbitrarilyJumpableRandomGenerator waren ze even vergeten over te nemen uit de bron.

[RangedNeedles]

Java kennende zit er mogelijk ergens SimpleRandomAbstractContextServiceFactoryGeneratorProviderInterface in de naam

[Snake]

https://projects.haykranen.nl/java/ Zeer handig!

[RangedNeedles]

[xiphoid]

Ach, maak je niet zo druk. Je hoeft niet die premium spullen te lezen. Klagen mag je op het forum doen, mits het constructive feedback is natuurlijk.

[jimshatt]

Kan iemand mij uitleggen wat het nut is van jump en leap? Is dat om voorspelbaarheid te mitigeren?

[MSalters]

Jump en leap gaan beide over de mogelijkheid om een toekomstig random getal te genereren zonder alle tussenliggende getallen te genereren. Zo kun je bojvoorbeeld vragen om het duizendste getal gegeven een seed, of juist (nadat je al een onbekend aantal getallen hebt gegenereerd) om de volgende 99 getallen over te slaan.

Voor een échte RNG is dat overigens triviaal, daar kun je die operaties implementeren als een NOP.

[MneoreJ]

Ja, voor parallelisme. Wordt bijvoorbeeld hier besproken:

All generators, being based on linear recurrences, provide jump functions that make it possible to simulate any number of calls to the next-state function in constant time, once a suitable jump polynomial has been computed. We provide ready-made jump functions for a number of calls equal to the square root of the period, to make it easy generating non-overlapping sequences for parallel computations, and equal to the cube of the fourth root of the period, to make it possible to generate independent sequences on different parallel processors.

[RedPixel]

Random numbers should not be generated with a method chosen at random

-- Donald Knuth

[tinustate]

JEP 356: Enhanced Pseudo-Random Number Generators
Created 2017/12/07 19:09

Ik dacht al, het plan bestaat dus al een tijdje, zo'n nieuwe feature zal niet direct in een LTS komen, of het word gemarkeerd als "experimental".

[Danny the dog]

Ik moest java toevallig laatst opnieuw installeren en toen viel me op dat het niet goed samenwerkt met gangbare browsers. Firefox 64 bit, Edge en Chrome gaven allemaal een melding. Chrome was de enige waarbij ik het desondanks aan de praat kreeg.

Ik had het pakket nodig tbv een update van de Unifi Control center software voor mijn AP's. Daar had ik héél lang niks meer mee gedaan

[com2,1ghz]

Die update voor Unifi heeft niets met je browser te maken toch? Unifi controller software heeft java nodig om te draaien, maar het heeft geen Java Applet.
Dus het is prima dat je browser dit blokkeert aangezien Applets 10 jaar terug al dood had moeten zijn.

[Snow_King]

Java wordt in de serverwereld nog heel veel gebruikt. Veel grote applicaties draaien op de achtergrond in Java. De taal is verre van dood.

Enterprises, overheden, maar ook MKB draait (onbewust) veel op Java.

[novasurp]

Probeer Waterfox Classic of Basilisk.

[TWauters]

Interessant. Dat ze ook maar eens beginnen met het ondersteunen van meer dan 64 Threads op Windows.

[gimbal]

Het is onmogelijk om een probleem op te lossen wat niet bestaat.

[TWauters]

Dit probleem bestaat wel degelijk. Een Threadripper 3990X met 64cores/128threads op Windows kan in Java niet meer dan 64 Threads gebruiken. En ja er zijn wel degelijk workstation toepassingen waar dit nodig is.

[Tjidde]

Hoe groot is die userbase die dat gebruikt? Voor servers ga je dan al snel naar een VM of een docker systeem met iets van Microservices. Wat juist goed schaalt met veel threads/cores.
Desktop applicaties die dat nodig hebben zijn er niet veel? Vaak zit je dan al snel richting content creation of renderen, daarvoor kan je ook gewoon servers gebruiken om de final rendering te doen. Wat je ook weer kan ophaken in services.
Want waarom zou je nog een applicatie dat de threads/cores nodig heeft monolith maken?

[Reactie gewijzigd door Tjidde op 23 juli 2024 06:32]

[TWauters]

Deze userbase is klein, dat is waar, maar er zijn wel degelijk workstation toepassingen waar dit nodig is.
Een Threadripper 3990X met 64cores/128threads op Windows kan in Java niet meer dan 64 Threads gebruiken.

[BikkelZ]

Tenzij ik niet snap wat threads zijn in deze context wil je sowieso meer software threads dan cores / processor threads kunnen gebruiken.

[Reactie gewijzigd door BikkelZ op 23 juli 2024 06:32]