»Nu bliver Java langt om længe et moderne sprog«
Java har været det sikre og bagudkompatible valg, men altid et skridt efter de mere sexede nyheder. Men det bliver der lavet om på nu, fortæller Kresten Krab Thorup, teknisk direktør hos it-firmaet Trifork, og en af arrangørerne af udviklerkonferencen GOTO i Aarhus til oktober.
»Jeg er overrasket over, hvad der er sket med Java i den nye Java 8. Nu er Java langt om længe blevet et moderne sprog,« siger han til Version2.
Blandt hovedtalerne på konferencen er nemlig Brian Goetz, der er chefarkitekt for Java hos Oracle, og som kan fortælle om alt det nye i sproget, der er blandt verdens mest brugte.
»Java har altid været noget, der var lidt bagud og blev udviklet lidt langsomt, men som altid var bagudkompatibelt. Imens har C# altid har været foran med nye sprogfeatures. Men nu er der altså virkeligt kommet skub i Java. Der er sket ret store ændringer. For eksempel er der redesignet en del på standardbibliotekerne, så de fungerer bedre med de nye sprogfeatures,« fortæller Kresten Krab Thorup, der har set Brian Goetz’ oplæg på en af de andre GOTO-konferencer.
Og det er ikke bare en tør gennemgang af nye funktioner i Java, lover han.
»Vi får hele historien om, hvordan Java 8 blev til. Noget af det skete ud af nød. Det er spændende at følge sådan en evolution inden for programmeringssprog, som stadig skal være bagudkompatible,« siger han.
Javas hidtil lidt langsomme udviklingstempo har fået mange til at kigge i andre retninger, især mod Scala, som har en del færre år på bagen. Men det er der ikke samme grund til nu, vurderer Kresten Krab Thorup.
»Der har været meget snak om at flytte over til Scala i stedet, men med Java 8 er Java kommet 80 procent af vejen til Scala,« siger han.
GOTO i Aarhus ligger i år fra 30. september til 2. oktober. Version2 er mediepartner på konferencen, som du kan læse mere om og tilmelde dig her..
- emailE-mail
- linkKopier link

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Java bliver aldrig et moderne sprog. Der sker utrolig meget på området, og Java halter bagefter. Meget. For at være et moderne sprog kræver det, i min optik, at man er innovativ, og ikke bare tilføjer features som andre sprog har haft i evigheder.
Som Java-udvikler bør man nok nøjes med at glæde sig over at der trods alt sker NOGET, men personligt synes jeg det er mere interessant at kigge på andre JVM-sprog.
- more_vert
- insert_linkKopier link
- more_vert
- insert_linkKopier link
Ja, JVM'en er værd at bruge sammen med et er de andre JVM sprog. Scala er faktisk rigtig godt, omend læringskurven er lidt stejl.
- more_vert
- insert_linkKopier link
Korrekt.2) Selve formaterne eksponeres via java.util.DateFormat, når man skal parse (input) eller formattere (output).
Far fetched argumentation dog. Det var jo en bug som du selv siger, og ikke tilsigtet.
En helt anden betragtning på problemet er, at man, i min bog, aldrig må forlade sig på defaults. Man angiver eksplicit encodings osv.
- more_vert
- insert_linkKopier link
Java er absolut ikke døende. Hvor har du det fra? Tag et kig på TIOBE indekset over populære programmeringssprog.
Når det kommer til applikationsserver software eller blot en almindelig desktop applikation, så er der bare ikke mange gode alternativer til Java (eller rettere JRE'en). Desuden er Java (som sprog) stadig let at forstå og gå til i forhold til f.eks. Scala.
Og ja... Java Applets i en browser ER døende. Og her er der trods alt nogle gode alternativer.
- more_vert
- insert_linkKopier link
Jeg skal bestemt se/høre Brian Goetz, men jeg er bange for dét løb er kørt. Der er ikke mange Java guruer tilbage, langt de fleste er (forståligt nok) skredet til mere moderne sprog (C#, Clojure, Scala etc.) og/eller platforme (Dalvik, CLR).
Selve JRE'en er også døende takket være Oracle's fatale måde at markedsføre den på via toolbars og eksponerede sikkerhedshuller.
Sun/Oracle kunne have trukket en streg i sandet, og lavet en Java.Next, istedet for at fokusere på 15 års bagudkompatibilitet, som alt andet lige kun kan ende med at være en bulldozer der skal skubbe en masse lort foran sig.
- more_vert
- insert_linkKopier link
Ja sproget er meget bedaget. Runtime/Platform er dog slet ikke.Jeg skal bestemt se/høre Brian Goetz, men jeg er bange for dét løb er kørt. Der er ikke mange Java guruer tilbage, langt de fleste er (forståligt nok) skredet til mere moderne sprog (C#, Clojure, Scala etc.) og/eller platforme (Dalvik, CLR).
- more_vert
- insert_linkKopier link
Man må skeldne mellem klient side java og server side java. Klient siden er kørt for længe siden. Men på server siden er 10 års bagud kompatibilitet et kæmpe plus for rigtig mange firmaer.
Hvilke andre miljøer vil kunne køre din kode også om 10 år.
- more_vert
- insert_linkKopier link
Det er rigtigt nok... i teorien. I praksis, fugnerer det bare ikke sådan. Skal man være helt sikker er man nødt til at køre med en gammel JVM. Der er talrige eksempler på dette, f.eks. måtte jeg rejse denne bug hos Sun da de skiftede default dansk dato-format fra de-facto standarden "dd/mm/yyyy" til ISO standarden "yyyy/mm/dd"....på server siden er 10 års bagud kompatibilitet et kæmpe plus for rigtig mange firmaer.
- more_vert
- insert_linkKopier link
Jeg har været med til flytte en kodebase fra Java 1.3 til Java 6 og det var ikke noget større problem. Selvfølgelig er der et par forskelle, med de er lette er genkende og erstatte i koden. Siden da at koden flyttet til Java 7, hvilket var en no brainer. Her snakket vi om et projekt med et fem-cifret antal klasser.
Jeg har i øvrigt intet imod at de har skiftet dd/mm/yyyy til yyyy-mm-dd. Det er ikke sværer for brugerne. Det er dog klart at knækker noget kode, og det er sjældent rart at være tvunget til noget. Vi brugte anledningen til at lave vores egen parser til at genkende datoer i dato felter og rette det til yyyy-mm-dd. Denne skrev vi i JavaScript og ikke i Java, og anvender den alle steder.
Jeg har hørt fra andre, at det at flytte kode fra 1.1 til 2.0 i C# ikke er særlig let, og at frameworks sjældent prioriterer bagudkompatibilitet til tidligere versioner i .Net.
- more_vert
- insert_linkKopier link
Jeg ser frem til lambda expressions og et ordentligt Date/Time framework. Dato håndtering i Java er så broken at man skulle tro det var amatører der havde implementeret det og .NET verdenen er LANGT foran på dette punkt. Det er især kritisk fordi Java bruges så meget i enterprise verdenen hvor datobehandlinger og tidszoner ofte er meget centrale elementer.
Og ja, der findes joda-time, som i høj grad løser problemet, men det er ikke altid hensigtsmæssigt med et 3. parts framework så det bliver rart at se dette implementeret ordentligt i Java 8. (Det er btw. gutten bag joda-time der står for den opgave)
Java har stadig stor berettigelse, specielt til enterprise udvikling der skal kunne afvikles i *nix verdenen er det stadig et af de mest produktive miljøer. Kan man derimod leve med at afvikle løsningen på en Windows Server eller tilnøds under Mono, så slår C# og .NET dog Java med flere længder imo. Simpelthen fordi .NET frameworket er designet bedre fra bunden og op (self. med god inspiration fra Java og vurdering af hvilke fejltagelser man her har gjort sig). C# er også langt mere pragmatisk anlagt og fokuserer på at levere features der øger produktiviteten istedetfor at være helt så akademisk anlagt som Java er tilbøjelig til at være designet, det har selvfølgelig fordele og ulemper, men jeg må indrømme jeg foretrækker C#'s tilgang hvor man kan skaffe sig adgang til en pistol hvis man får lyst til at skyde sig i foden istedetfor mother-java hvor man som et andet lille barn skal pakkes ind i vat og beskyttes fra det onde :-)
Angående .NET og bagudkompatibilitet så er det altså også noget .NET verdenen er kendt for at prioritere højt og jeg kan ikke mindes at jeg nogensinde (jeg har lavet .NET løsninger fra starten) har været nød til at foretage deciderede tilrettelser i kodebasen for at kunne compile og afvikle løsningen ved opgraderinger til nyere udgaver, men det er klart at der kan være ting du benytter som er blevet markeret deprecated som vil kræve tilrettelser før eller siden.
- more_vert
- insert_linkKopier link
Joe: Følgende er fra MSDN:
"The .NET Framework 4.5 is backward-compatible with applications that were built with the .NET Framework versions 1.1, 2.0, 3.0, 3.5, and 4. In other words, applications and components built with previous versions of the .NET Framework will work on the .NET Framework 4.5"
Og det er også min oplevelse at det i praksis er tilfældet, så det er bestemt en prioritet for Microsoft også - og reelt har Microsoft altid været kendt for at fokusere (nogle gange lidt for meget) på bagudkompatibilitet, så det er reelt ikke den store overraskelse.
- more_vert
- insert_linkKopier link
Så .NET 1.0 kan ikke?
Ved faktisk ikke hvad problemet er her, men noget kunne tyde på det har krævet lidt kode-tilrettelser.
Det er dog ikke mit indtryk at .NET 1.0 blev brugt til ret mange seriøse projekter, for mig handlede det mere om at lege med denne nye platform - det blev først for alvor seriøst med .NET 1.1 som kom året efter.
- more_vert
- insert_linkKopier link
Rigtigt, men .NET afvikles ikke lige på System Z, ARM, SPARC osv. Det kan afvikles på Mono på nogle arkitekturer som ikke er Windows+x86, men ikke altid.Java har stadig stor berettigelse, specielt til enterprise udvikling der skal kunne afvikles i *nix verdenen er det stadig et af de mest produktive miljøer.
Kan man derimod leve med at afvikle løsningen på en Windows Server eller tilnøds under Mono, så slår C# og .NET dog Java med flere længder imo.
Simpelthen fordi .NET frameworket er designet bedre fra bunden og op (self. med god inspiration fra Java og vurdering af hvilke fejltagelser man her har gjort sig).
C# er også langt mere pragmatisk anlagt og fokuserer på at levere features der øger produktiviteten istedetfor at være helt så akademisk anlagt som Java er tilbøjelig til at være designet, det har selvfølgelig fordele og ulemper, men jeg må indrømme jeg foretrækker C#'s tilgang hvor man kan skaffe sig adgang til en pistol hvis man får lyst til at skyde sig i foden istedetfor mother-java hvor man som et andet lille barn skal pakkes ind i vat og beskyttes fra det onde
Desuden er der et miljø omkring Java med rigtigt mange leverandører af diverse rammeværk, application servere mm. også Open Source. Så man kan undgå vendor lock-in, når man skal skabe sine løsninger. Dette er meget vigtigt på den lange bane.
- more_vert
- insert_linkKopier link
Nikolaj: Helt enig og det er da også derfor jeg på inden måde betragter Java som værende død indenfor Enterprise udvikling - det er stadig klart det bedste cross-platform framework og det er Javas helt store styrke.
Derudover er der et stort øko-miljø omkring Java indenfor Enterprise udvikling og stærke open source traditioner, samtidig med at Java nyder godt af at det er det foretrukne akademiske sprog, så alle lærer Java på uddannelserne.
Kan man i højere grad leve med Vendor-lockin (omend Mono forsøger at bryde dette lidt, men jeg betragter det endnu ikke som modent nok til Enterprise-udvikling) så er .NET/C# en mere moden platform - simpelthen fordi det grundlæggende er en rewrite af Java from scratch hvor man har lært af fejltagelserne og ikke slæber rundt på nær så meget legacy bagage og så er hele tankegangen mere pragmatisk og fokuseret på erhvervslivet og ikke universitetsmiljøet.
- more_vert
- insert_linkKopier link
Men du må jo heller ikke bruge Date :-)
Visse konstruktører af java.util.Date blev rigtig nok deprecated i Java 1.1, da java.util.Calendar kom til, men Date er ikke deprecated.
Selve formaterne eksponeres via java.util.DateFormat, når man skal parse (input) eller formattere (output).
Selv med JDK8, der får nyt Date/Calendar API via JSR310/JEP150, bliver Date AFAIK ikke deprecated.
- more_vert
- insert_linkKopier link
Øh, jeg har et .Net 1.1 projekt der lever i bedste velgående. Det må vel være 13-14 år gammelt. Så .Net er et godt bud.
- more_vert
- insert_linkKopier link