»Nu bliver Java langt om længe et moderne sprog«

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.

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.

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).

Ja sproget er meget bedaget. Runtime/Platform er dog slet ikke.

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.

Ø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.

...på server siden er 10 års bagud kompatibilitet et kæmpe plus for rigtig mange firmaer.

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".

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".

Men du må jo heller ikke bruge Date :-)

Men du må jo heller ikke bruge Date :-)

1) 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.

2) Selve formaterne eksponeres via java.util.DateFormat, når man skal parse (input) eller formattere (output).

3) Selv med JDK8, der får nyt Date/Calendar API via JSR310/JEP150, bliver Date AFAIK ikke deprecated.

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.

2) Selve formaterne eksponeres via java.util.DateFormat, når man skal parse (input) eller formattere (output).

Korrekt.

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.

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.

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

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.

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.

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.

@Pelle Så .NET 1.0 kan ikke?

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.

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.

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.

Jeps!

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.

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.