Snydt igen: Java får alligevel ikke closures med havelåger

Java-udviklerne bliver snydt for closures og modularisering i den næste udgave af sproget. Ellers bliver Java 7 ikke færdig til 2011. Det er skuffende, synes dansk udvikler, der ser muligheder for konkurrenterne.

Hvis den mytologiske Java 7 nogensinde skal blive færdig, må der skæres i pakken. Det er konklusionen for Mark Reinhold, som er Oracles chefarkitekt for Java.

Med alle de påtænkte funktioner ville version syv tidligst blive færdig i 2012. Den tidsramme er ikke acceptabel for den allerede slemt forsinkede udgave, og derfor sættes ambitionerne ned for at nå en udsendelsesdato, der hedder sommeren 2011.

Det betyder et foreløbigt farvel til closures, som ellers endeligt var kommet med på vognen efter megen tovtrækkeri. Det samme gælder Jigzaw, som dækker over modularisering på pakkeniveau samt visse dele af Project Coin, der stræber efter små forandringer i sproget, der kan gøre programmørens hverdag lettere.

Alle de nævnte faciliteter kommer dog med i den efterfølgende Java 8, som er foreløbigt sat til 2012.

**LÆS OGSÅ **Java får closures med havelåger

»Vi er jo mange der er tvunget til at bruge Java i hverdagen, og jeg må indrømme at jeg er helt vildt skuffet, og det tror jeg også der er mange andre udviklere, der er« siger Ole Friis Østergaard, som udvikler i Trifork.

»Det er en våd klud i hovedet. Man kunne have håbet, at nu hvor Oracle brugte store ord på Javaone, at der også var noget mere hold i det.«

Mange enterpriseudviklere programmerer til applikationsservere, som ikke nødvendigvis benytter den nyeste udgave af Java, og bliver på den måde ikke direkte berørt af forsinkelsen. Men Ole Friis Østergaard tror alligevel at det giver mere medvind til de konkurrerende miljøer.

»Jeg tror at det er vind i sejlene for .Net. Der sker væsentlig flere ting, og det er Microsoft der styrer med hård hånd. Der kommer mange spændende nye ting hele tiden.«

Det kan også give et skub bagi til de andre sprog på Java-platformen. Det gælder specielt Scala, mener Ole Friis Østergaard.

»Det er jo sådan en form for Java++. Man har taget udgangspunkt i Java og udvidet det i den retning, som man nok ellers ville have udviklet Java i.«

Det er svært at svare på om Scala vil gøre indhug i skaren af Java-udviklere, siger Ole Friis Østergaard. Det virker som om at Scala-miljøet har tabt pusten lidt på det seneste. Men det kan også blot være et udtryk for, at Scala er nået til det punkt på hype-kurven hvor folk anvender sproget i stedet for kun at snakke om det.

Blandt det, der rent faktisk kommer med i Java 7, er JVM-instruktionen invokedynamic, som giver bedre muligheder for dynamiske sprog på platformen, nio.2 med asynkron i/o og bedre fil- og mappeunderstøttelse, parallel classloading, binære konstanter i stil med "0b10," bedre læsbare heltalskonstanter, hvor "123456" kan skrives "123_456," mulighed for at bruge strenge som case-argument i switch-sætninger, samt udvidelser til concurrency-pakken.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lasse Lindgård

Det er faktisk kun dovenskab og konservatisme, der forhindrer at nye java projekter bliver skrevet i Scala, i stedet for java.

Skift sprog - uden at skifte platform. Det burde være en nobrainer. Alle venter på at alle andre har afprøvet det.

  • 0
  • 0
Uffe Seerup

Scala i den seneste opdatering indeholdt flere ændringer som knækkede bagudkompatibiliteten. Et sprog er nødt til at vise stabilitet (læs: fravær af knækkende ændringer) i et stykke tid før der er opbygget tillid. Scala er ikke helt dér endnu...

Hele Javas klassebibliotek og alle robuste 3. parts biblioteker er skrevet med Java for øje. Designet (brug af patterns) er altid med Javas begrænsninger og muligheder in mente. Scala ser godt ud når du kan bygge fra grunden med Scala. Og ja, Scala kan "konsumere" Java klassebiblioteker. Men pludselig bliver koden underligt kompliceret. Det nytter ikke noget at kode Java i Scala.

Hele Java økosystemet er Java centreret. Dokumentation, kodeeksempler etc. er altsammen rettet mod Java.

Virksomheders egne softwareporteføljer er i Java og er designet derefter. Du smider ikke bare mange års investeringer ud. Hvad når du vil modernisere et eksisterende produkt? Koder du det hele forfra i Scala? Det er en noget mere omfattende ændring end at løfte produktet til en ny Java version som er garanteret bagudkompatibel, hvorefter du kan begynde at benytte de nye faciliteter.

Hvad med uddannelse? Scala er et meget mere avanceret sprog end Java. Der er mange Java udviklere som skal lære nye discipliner som funktionsprogrammering etc.

Hvad med modenhed? Java er måske ét af de mest modne software økosystemer overhovedet, men stærke konventioner for kodning, navngivning, dokumentation, test etc. Mange af disse discipliner skal modificeres for at være optimale med Scala. Det er en erkendelsesproces som også tager tid.

Ved at dømme dem som overvejer disse aspekter for "dovne" overser du de mange ikke-tekniske problemer ved et skifte. Ikke-tekniske problemer har oftest ikke tekniske løsninger.

  • 0
  • 0
Lasse Lindgård

Hej Uffe. Jeg besvarer dig punkt for punkt herunder:

I følge Odersky, så skulle scala 2.8 have heddet 3.0. De brugte denne version til at få de sidste store grundlæggende ting på plads, så sproget netop kan holdes stabilt fremover. I øvrigt, så mener jeg at en af javas største svagheder har været det ekstreme fokus på bagudkompatibilitet. Prisen viser sig nu i form af legacy.

Scala har et pattern som hedder "pimp my library", som netop går ud på at lave en tynd, tynd skal om et java bibliotek som gør det mere scala venligt.
F.eks. er det gjort med swing:
http://www.cs.helsinki.fi/u/wikla/OTS/Sisalto/examples/html/ch33.html

Hvis ikke man "pimper" det, er scala stadig mere clean, som f.eks. JPA
http://wiki.liftweb.net/index.php?title=Lift_and_JPA_(javax.persistence)...

Alle de eksempler jeg har set hvor man kalder java kode fra scala, er koden blevet enklere end hvis man havde kaldt den fra java.

Mht. dokumentation og kodeeksempler, så er det korrekt at det p.t. er rettet mod java. Det er dog ikke noget problem, da det er så ens.

Scala IDE til eclipse er bygget oven på eclipse's java integration, sådan at samme projekt kan indeholde både java og scala klasser. Så man kan i princippet bare beslutte sig for at alle nye klasser er lavet i scala.

Du har ret mht. uddannelse, men man kan ikke holde et bedre alternativ tilbage bare med den undskyldning at man ikke gider at lære noget nyt. Hvis det er en valid grund ville vi stadig skrive COBOL dagen lang.

Du har også ret med hensyn til kodestandarder. Her ser jeg det største problem. Fordi udviklerene kan lave vildere ting end i java, så ville det være rart med nogle konventioner for hvornår man griber dybt i værktøjskassen og hvornår det er bedre at koden er enklere men længere. Her savnes der stadig meget, men hvis man holder sig til KISS og udpeger en dygtig 'smagsdommer' i virksomheden/projektet kan man komme langt.

  • 0
  • 0
Søren Berg Glasius

Som Javaudvikler, så ser jeg ingen grund til at skifte til et helt nyt sprog, når man kan "nøjes med" at skifte til Groovy.
Groovy har siden sin fødslen i 2005 haft Closures, indlæringskurven for Groovy er meget nem, og det meste Java kode kan oversættes direkte af Groovy's compiler.
Groovy har et meget aktivt miljø, og hvis man er web-udvikler findes Grails framework'et, som bestemt også er værd at kikke på.

Jeg kan kun opfordre til at læse mere på Groovy's hjemmeside: http://groovy.codehaus.org

Groovy er Java på steoider!

  • 0
  • 0
Lasse Lindgård

Groovy's skaber siger:
"Though my tip though for the long term replacement of javac is Scala. I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."

http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for....

  • 0
  • 0
Søren Berg Glasius

mit argument var heller ikke: "Hold dig væk fra Scala - brug Groovy", men nærmere: Hvis du er java-udvikler og gerne vil flytte dig lidt, uden at skulle lære et helt nyt sprog, så er Groovy et oplagt valg.
Alle har jo lov til at ændre mening, så hvis Groovy's skaber synes Scala er den bedste erstatning for Java, så er det jo en tilladt holdning at have.
Personligt har jeg det rigtig godt med, at kunne udnytte min Java viden, når jeg udvikler i Groovy, og jeg behøver ikke at lære en helt ny syntaks.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Java er ikke særlig statisk typet, det er for det meste fyldt med casts for at flytte rundt, og alt ar bare Objects. Det er en illusion.
Generics er en fejl! Det sværter koden til med alt for mange tegn som fylder alt for meget i kildeteksten der bare er forvirrende for læseren. Fordelen ved både Groovy og Scala er, at der skal kun det kode til som man skal bruge for at "forklare" hvordan man vil have sit problem løst. Java har typisk 4 gange ekstra kode i form at casts, exception handling mm. Java er designet i 1995 og ikke ændret siden, hvilket i sig selv fortæller at det er legacy. Det er et enormt umoderne sprog.
Vi skal da stadig bruge de libraries der er lavet i Java, men skift nu sprog rent udviklingsmæssigt til et moderne sprog. Hvis folk ikke vil følge med, må det naturligvis være af rent idelogiske grunde, og ikke grunde baseret i rationel fornuft.

Igen, jo færre kodelinier vi skal skrive jo færre fejl får vi introduceret.
Groovy er fint som alternativ til Scala, desværre er der flere ting som ikke er særlig smart i Groovy i forhold til Scala. F.eks. er alt ikke et expression (switch statement er en af de store fejl designs i Groovy), dog kan jeg personligt godt lide den dynamiske natur i Groovy, men Ruby (JRuby) er efter min mening dog pænere.
Jeg kunne dog godt tænke mig et sprog der er mere en hybrid mellem Groovy, Scala og Ruby - men det må vel bare stå på ønske listen.
Alle 3 sprog har i hvert flad temmelig vidt forskellige måder ideologisk at løse de samme problemer på.

Jeg synes personligt ikke der er nogen grund til at blive hængende i Java, og når jeg ser præsentationer (som f.eks. på netop overståede JavaOne), hvor de viser Java kode, får jeg næsten ondt i hovedet over hvor meget koden fylder (altså ikke koden der løser problemet, men al den plumbing der er rundt om).

  • 0
  • 0
Log ind eller Opret konto for at kommentere