Java rejser til Valhal, hvor værdityperne gror

Java rejser til Valhal, hvor værdityperne gror
Illustration: Flickr-bruger Smudge9000.
Værdityper og projekt Valhalla skal modernisere Java med bedre ydelse i hukommelsen til følge. Og det er sværere, end det lyder – nærmest som »seks sammenfiltrede ph.d-afhandlinger,« mener sprogets opfinder.
26. januar kl. 03:45
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Java har ikke længere samme dominans inden for programmering som tidligere. Især Python og Javascript har snuppet tronen på flere målinger for sprogs popularitet.

Men sproget er stadig det foretrukne valg til forretningsprogrammering i mange industrier, og bedømt på det store antal aftapninger af open source-udgaven Openjdk, er der ikke tegn på, at Java er på vej ud af døren lige foreløbig.

Oracle, der ejer Java som varemærke og står i spidsen for udviklingen af sproget, har i mange år været bekymret for, at sproget fremstår som støvet sammenlignet med nyere moderne sprog. Det har tidligere resulteret i strategien ‘Java first’, som handler om, at sproget skal moderniseres og være konkurrencedygtigt i forhold til ydelse og udviklerproduktivitet.

Værdityper gør kål på langsom hukommelse

Oracles top-udvikler ved Java, Brian Goetz, har igennem flere år stået i spidsen for projektet Valhalla, der blandt andre tiltag skal indføre værdityper i Java. Det er ikke så svært på sprogsiden, men kompliceret på kørselssiden. For nylig har Brian Goetz og kolleger løftet sløret en smule for de kommende forbedringer.

Log ind og få adgang
Du kan læse indholdet ved at logge ind eller oprette dig som ny bruger.
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
11
29. januar kl. 16:32

Ved et usundt typesystem forstås, at man kan komme i en situation, hvor et udtryk på kørselstidspunktet viser sig at have en anden type, end typesystemet indikerede ved oversættelsestidspunktet. Dette kan i C# ske ved at erklære et array af giraffer , gemme en reference til det i en variabel af typen “array af dyr” og herefter indsætte et objekt af typen tiger i array vha. denne variabel.

Jeg er helt enig i, at det sjældent giver praktiske udfordringer ved brug af C#. Samme kovariante opførsel for arrays er tilladt i Java.

9
28. januar kl. 09:47

Især Python og Javascript har snuppet tronen på flere målinger for sprogs popularitet.

Nu skal man altså tage "popularitets" målinger med et vist gran salt.

At der er søgt meget på et sprog, eller det er det mest adspurgte på Stackoverflow, er ikke nødvendigvis fordi det er populært, men fordi der er mange der (er tvungne til) bruger det.

Således tror jeg ikke Javascript er specielt populært, tværtom (elendig typing og bizar casing), men det er nu engang en nødvendighed for at lave funktionalitet på et website - men hvis det i stedet havde været Brainfuck der var nødvendigt, så ville det jo også ryge til tops på Stackoverflow.

Man kan vel egentlig vende den om og sige, des mere besværligt et sprog er, des flere spørgsmål på Stackoverflow.

8
28. januar kl. 08:41

Array-varians i C# er usundt. Endnu en dårligdom man kopierede fra Java for lettere at kunne køre Java kode på CLR.

12
27. april kl. 17:24

Array-varians i C# er usundt. Endnu en dårligdom man kopierede fra Java for lettere at kunne køre Java kode på CLR.

Tja, men Javas valg giver rigtig god mening. Java er lavet ud fra en inspiration af C (og C++) og ikke noget som helst andet. Det er imperativt og objektorienteret med funktionelle muligheder. C (og C++) var trods alt de mest udbredte sprog overhovedet i 1995. Specielt til emerging embedded var C kongen (nogen der husker Echelon?). Så med det target der var oprindeligt for Java, er det ikke så underligt.

At der så senere (snart 30 år after the fact) sidder nogen og beklager sig over at Java ikke ligner Standard ML det er helt skudt ved siden af. Det kunne man godt. Man kunne godt have lavet et sprog der lignede et andet sprog som ingen benytter, men var det så blevet en success? Næppe.

Java er (ligesom JacaScript) en kæmpe success i industrien, og Standard ML er det nok i undervisningen. Men det er sådan set ligegyldigt. Det er super fedt at der udvikles på sproget og at der tilføjes nye features som gør programmerne "bedre" (for hvad er bedre egentlig?, det er altid et trade off, noget andet bliver så ringere).

For dem med hang til det funtionelle kan man benytte Frege på JVM, det er der absolut intet i vejen for.

PS: Jeg er ikke helt med på hvad du har imod Javas arrays?

7
27. januar kl. 23:49

og C# for den sags skyld

Hvad er der usundt ved typesystemet i C#? Jeg er med på at det ikke helt så avanceret som hvad man ser andre steder, men usundt? Type systemet i Java blev en skandale da de lavede generics men C# / .Net er helt anderledes.

6
27. januar kl. 09:58

selvom ML ramte rigtigt på mange punkter så fejlede man da sproget blev (stort set) pure functional.

Jeg vil ikke kalde SML ret "pure". Der er mutable arrays, imperativ i/o, exceptions, osv., der ikke passer med en ren funktionel tilgang. Den primære begrænsning er, at variable ikke er mutable. Men en variabel kan være en (immutable) reference til en mutable celle, der kan opdateres. Det tillader kopiering af variable i closures i stedet for at skulle tilgå dem via referencer. Altså værdiidentitet i stedet for adresseidentitet.

SML er ikke fejlfrit -- der er dele af syntaksen, der ikke er så pæn, og der mangler understøttelse af tråde (der er varianter af SML, f.eks. Concurrent ML, der gør) og Unicode. Og standardbibliotekerne er ikke super store. Men grundstrukturen er pæn og kan implementeres effektivt fordi man ikke skal tage hensyn til snavns såsom adresseidentitet og virtuelle metodekald. Og så er typesystemet sundt til forskel fra det i Java (og C# for den sags skyld).

5
26. januar kl. 18:11

Jeg vil tro, at compleren sørger for at aligne valuetypede objekter på cachelinjegrænser, så hele objektet ligger i samme cachelinje (hvis det ikke fylder for meget). Dermed bliver hele objektet hentet ind i cachen så snart et felt hentes.

I lang tid var guidance på C# fronten at en valuetype (struct) skulle være max 16 bytes. Men den guidance var baseret på .NET's barndom. For 10 år siden fandt jeg at man fint kunne få god performance ud af 128 byte structs hvis man bare er omhyggelig. .NET Jit compileren er faktisk ret god til at optimere skidtet når den får muligheden. Med omhyggelig kodning fik man en performance der kun lå 10-15% under C++. Men der kræves at man ved hvad man laver.

Den nye form for identitet for værdityper...

Valhalla kunne have sparet rigtigt meget tid hvis Gosling ikke havde fucket op fra start. Identity, hashvalue og synchronization er ikke nyttige attributter for de fleste "objekter". Men Gosling valgte at en reference var det samme som identity og derfor kom det ud alle steder. Hans brug af == operatoren til at sammenligne identity var idiotisk. C# kopierede de tåbelige ting.

Da man opdagede fejlen skulle man have indført "light classes". Klasser uden ovennævnte attributter. Det havde gjort introduktion af value types meget nemmere og havde krævet minimale omskrivninger af koden.

"Over time every language evolves to look more and more like Standard ML".

Men hverken C# eller Java er på vej til at bliver pure functional. Og det bliver de aldrig. Så selvom ML ramte rigtigt på mange punkter så fejlede man da sproget blev (stort set) pure functional. Der problemer der løses bedst med functional programming og andre problemer der løses bedst med imperative programming.

4
26. januar kl. 10:15

Den nye form for identitet for værdityper minder meget om den, der ses i funktionelle sprog såsom Standard ML: To objekter er ens, hvis deres felter er ens, selv om de ligger på forskellige adresser. I ML er det envidere transparent, om felterne ligger samlet i lageret eller ej, så det er op til compileren at beslutte det. For små felter giver det mening at have dem samlet, men store felter kan med fordel lægges et andet sted end resten af objektet, og hvis der er tale om en rekursiv type, så skal rekursive felter ligge et andet sted for at undgå eksplosion af størrelsen og for at tillade deling.

Jeg vil som sædvanlig, når der snakkes om udvidelser af Java eller C#, citere Bob Harper: "Over time every language evolves to look more and more like Standard ML".

3
26. januar kl. 10:08

Jeg vil tro, at compleren sørger for at aligne valuetypede objekter på cachelinjegrænser, så hele objektet ligger i samme cachelinje (hvis det ikke fylder for meget). Dermed bliver hele objektet hentet ind i cachen så snart et felt hentes.

1
26. januar kl. 05:25

Derfor er moderne CPU’er udstyret med deres egen hukommelse, L1-, L2- og L3-cache, så afviklingsmiljøet kan hente en ordentlig klump data fra heapspace i et hug, i stedet for at fordele byrden over mange små langsomme indlæsninger.

Vil man lave en "prefetch"-mekanisme? Den liniære PF er nornalt god, men begynder man at kunne cache explicit åbner man potentielt for trashing, som kan have uheldig følger.

Men lad os håbe, det hjælpe Java med IKKE at være 40% langsommere end fx compileret C++!

Hidtil har det oversete "emulator paradoks" (=lille VM) hjulpet lidt.