Closures og Extension Methods i Java 7

Nahilas (8) skrev:

Så længe Javas VM er så forfærdeligt langsom som den er,

Windcape (11) skrev:

JVM er langsom i forhold til .NETs CLR,

Det er der ikke meget belæg for.

Det er så tæt performance mæssigt at hvad der er hurtigst afhænger af konteksten CPU, VM version, switches brugt, indhold af benchmark.

Windcape (11) skrev:

og derfor er JVM ret elendig til at køre andre sprog som f.eks. Scala, i forhold til IronPython/IronRuby i .NET, og med forbedringer i C# 4.0 (forventet omkring Marts 2010), så er JVM er altså LANGT bagud.

1) Scala kan ikke sammenlignes med IronPython/IronRuby. Du kan evt. sammenligne det med F#.

2) Det kan godt være at du mener at JVM er langt bag efter CLR for dynamisk sprog. Men JRuby og Jython er altså langt mere udbredte end IronRuby og IronPython.

arne_v (50) skrev:

MS mente ikke at brugerne skulle have RMI og JNI.

Microsoft forbedrede JNI, til hvad der er P/Invoke i .NET, hvilket også var grunden til at Microsofts Java var hurtigere.

arne_v (52) skrev:

1) Scala kan ikke sammenlignes med IronPython/IronRuby. Du kan evt. sammenligne det med F#.

2) Det kan godt være at du mener at JVM er langt bag efter CLR for dynamisk sprog. Men JRuby og Jython er altså langt mere udbredte end IronRuby og IronPython.

Java er også mere udbredt end C#.

Men forskellen ligger i at JVM ikke er lavet til andet end Java, hvor CLR er netop er optimeret til flere sprog. Og .NETs CLR udvikles uafhænging af C#.

Mads Torgersen gjorde netop opmærksom på det på .NET User Group mødet på JAOO i år.

SUN kunne sagtens oppe sig en hel dem mht. at forbedre performance af JVM i forhold til dynamiske sprog.

Windcape (53) skrev:

Microsoft forbedrede JNI, til hvad der er P/Invoke i .NET

Min pointe var at SUN ikke har forhindret MS i at lave nogle forbedrede features - SUN har kun forhindret MS i at fjerne features.

Og det er almindelig praksis at hvis der er en standard X, så er det i orden at tilføje sine egne forbedringer, men man skal implementere alle de features der er defineret i standarden.

Og din antagelse om hvad der baserer sig på hvad er lidt forsimplet.

Det hænger sådan sammen at:

Java         MS "Java"      .NET
API for simple tilfælde   mangler    J/Direct         P/Invoke
API som kan alt            JNI           RNI              mixed mode C++

(code brugt for at forsøge at få det til at stå ordentligt)

J/Direct og P/Invoke er typisk MS på godt og ondt:
- det er nemt at komme igang med
- man render først ind i begrænsningerne senere

Og man render ind i problemer med P/Invoke. Der er altid masser af spørgsmål omkring det i diverse fora fordi folk ikke kan få det til at gøre lige det som har behov for.

Hvorfor SUN valgte ikke at lave noget tilsvarende skyldes formentligt at:
1) i Java verdenen er prioriteringen af "nemt" under "rigtigt" - man vil hellere lave en løsning som kan løse alle problemer end to forskellige til henholdsvis de simple og de komplekse problemer
2) brug af den feature gør programmerne platform specifikke og det er så i skarp modstrid med hele intentionen med Java

Windcape (53) skrev:

hvilket også var grunden til at Microsofts Java var hurtigere.

Den påstand er set før.

Men det er noget sludder.

Hvis du opdeler CPU forbrug i en app i:
A) JVM/managed kode
B) glue kode
C) native/unmanaged kode
så må B/(A+B+C) være så lille at effektiviteten af glue arkitekturen ikke kan påvirke deb samlede performance for real world applikationer.

Windcape (53) skrev:

Men forskellen ligger i at JVM ikke er lavet til andet end Java, hvor CLR er netop er optimeret til flere sprog.

Der er maasser af sprog til JVM og mange af dem er ældre end CLR.

Windcape (53) skrev:

Og .NETs CLR udvikles uafhænging af C#.

MS har et team som udvikler CLR og et team som udvikler C# compileren. Og produkterne releases bundtet sammen i .NET version N.

SUN/IBM/Oracle/Apache/<insert Java vendor her> har et team som udvikler JVM og et team som udvikler Java compileren. Og produkterne releases bundtet sammen i JDK version N.

Ikke nogen stor forskel.

Windcape (53) skrev:

SUN kunne sagtens oppe sig en hel dem mht. at forbedre performance af JVM i forhold til dynamiske sprog.

Ja.

Der arbejdes på dette emne i JSR 292.

Men selvom man mener at Java kan forbedres på dette område, så er der altså allerede mange som bruger dynamiske sprog for JVM.

Windcape (38) skrev:

Prøv f.eks. at kode en server<->client client i C++. Det er noget mere besværligt, og du skal ud og arbejde med libraries, som skal linkes ind og meget andet.

Java, C# etc. bruger jo også libraries for at lave client server.

Eneste problem jeg ser er at det mest udbredte API for netværks programmering i C/C++ (BSD socket) er et low level API.

Windcape (38) skrev:

Derudover tillader en virtuel maskine at du kan få just-in-time debugging. Vil klart anbefale at du læser op på debugging og brug af exceptions.

????

JIT debugging og exceptions kræver ikke en VM.

Exceptions er standard i C++.

Og muligheden for at starte en debugger midt i en kørsel kan sagtens laves i native kode. Jeg kan huske at have lavet den slags sidst i 1980'erne.

Windcape (38) skrev:

Java er faktisk ret svagt på det punkt, da Java 6 ikke har versions-styring af JARs. (Der er værktøjer til det, men de er ikke standard).

Ikke korrekt.

Java har haft mulighed for at styre forskellige versioner af samme jar fil ihvertfald siden 1.2 fra 1998 (sandsynligvis siden 1.0 fra 1996, men jeg ved ikke ret meget om præ-1.2 versionerne).

Det Java ikke har er mulighed for at styre det via versions numre. Java styrer det via URL'er.

Hvis man vil have versions styring på jar filer via deres versions nummer, så skal man selv skrive lidt kode. En lille bitte smule kode.

Windcape (39) skrev:

Til jer som arbejde med Java, og ikke er så bekendt med C#, så har Ole Friis Østergaard fra Trifork har givet lidt input på version2:

http://www.version2.dk/artikel/13072-julegave-til-...

Jeg er ret enig med ham.

Påstanden om at Java er død er en EB overskrift.

Men han har fuldstændigt ret i at JCP processen tager lang tid.

Windcape (39) skrev:

Og Trifork har mig bekendt flere resourcer i Java end .NET.

Det er uden tvivl rigtigt.

Trifork har vel udviklet sig til et generelt konsulent hus.

Men de startede jo med at være et software hus som solgte deres egen Java EE applikations server.

Windcape (41) skrev:

C# 4 er allerede tilgængelig in Community Technology Preview (CTP), og er i anden beta-udgave.

Jeg kender flere som allerede benytter det til intern produktion, eller forberedelse.

Naturligvis er der mange som er startet på at kigge på 4.0, men jeg tillade mig at spå, at .NET nu bliver ramt af det fænomen som alle modne teknologier lider under - det er forbandet svært at få alle til at opdatere.

1.0->1.1 var ikke noget problem fordi 1.0 var mest eksperimentel.

1.1->2.0 gik nogenlunde fordi der ikke var så meget 1.1 kode.

2.0->3.5 har vist sig at være lidt sej, fordi der er faktisk en del 2.0 brugere som er på "If it ainøt broke then don't fix it" vognen.

3.5->4.0 kommer til at tage lang tid.

#60

I det mindste virker det generelle community bag .NET til at være bedre til at opdatere end Java/PHP/C/C++ udviklere.

Der er også mindre produktionsmæssige problemer ved at opdatere, da nye version af .NET er så godt integeret med den platform kunderne benytter (Læs: Windows).

SUN har endnu ikke formået at lave en JVM installer som ikke er irreterende, kræver diverse UAC promts ude af trit med MSs UX anbefalinger, og har reklamer og andet gøgl plasterede over det hele. En IT-admins værste mareridt må være at opdatere Java.

Derudover er der bedre backwards compability, samt .NET jo har benyttet versioning i assemblies fra dag 1, så får ikke problemer når man opdatere sin IIS6 til IIS7 med .NET 2 til 3.5/4.

Jeg kan ikke sige det samme for Java eller PHP.

#61

Ang. PHP er det primært dovne webhosts (læs: shared hosting), som er langsomme. PHP4 tog sin tid at komme af med, og der er endda stadig nogle, som kører med det. Nu er problemet bare 5.3.

Windcape (61) skrev:

I det mindste virker det generelle community bag .NET til at være bedre til at opdatere end Java/PHP/C/C++ udviklere.

Indtil videre ja.

Men Java brugerne opdaterede også ret hurtigt de første 5 år.

Det er nemt at opdatere så længe man ikke har alle de frosne "det virker - rør det ikke" systemer.

Når man begynder at få dem, så begynder det at gå langsommere med at opdatere.

.NET vil begynde at lide under samme problem.

Alle andre har problemet. Java, C++, Delphi etc.. Formentligt også PHP.

Windcape (61) skrev:

Der er også mindre produktionsmæssige problemer ved at opdatere, da nye version af .NET er så godt integeret med den platform kunderne benytter (Læs: Windows).

Vi ved godt at .NET på trods af Mono stort set kun bruges på Windows.

Man Java produktion kører altså på mange forskellige platforme: z/OS, AIX, Solaris, RHEL, SLES og Windows.

Skønsmæssigt vil jeg tror at Windows (2000, 2003 og 2008) må udgøre omkring 40%.

Windcape (61) skrev:

SUN har endnu ikke formået at lave en JVM installer som ikke er irreterende, kræver diverse UAC promts ude af trit med MSs UX anbefalinger, og har reklamer og andet gøgl plasterede over det hele. En IT-admins værste mareridt må være at opdatere Java.

Java er langt nemmer at installere end .NET.

Du kan xcopy'e en Java installation på en maskine.

SUN's installer futter rundt og sætter Java op til browsere og andet gøgl, men det har man ikke brug for til servere.

Og det er altså serverne som typisk kører de gamle versioner. Desktop bliver opdateret på trods af UAC prompter.