Er java et tregt språk?

[doloop]

Jeg misforstod ikke. Bankid har vist at Java sin plattformuavhengighet er rimelig skjelven. Så lenge du holder deg til windows går det gjerne greit. OSX, linux, solaris etc. har vært sjansespill, for ikke å snakke om de forskjellige nettleserne.

 

Jeg regner med du sikter til Java appleten som nordea blant annet benytter, ikke selve bankid løsningen fra BBS. Det å støtte java applets i en browser har lite med plattformuavhengihet, og mye med integrasjon mot spesifikke programmer. JREen kjører fint, men at browseren er integrert på en god måte er ikke sikkert. Vet ei heller hvem som står for integrasjonen der, om det er sun/oracle eller det er hver og en browser som gjør det selv.

 

Det sagt skal jeg gledelig innrømme at java applets er elendige; det har heller så å si ingen ting å si i dagens web. Faktisk er Nordeas bankid den eneste appleten jeg kan huske å ha kjørt de siste 5 årene. Du må gjerne kritsere Java applets, men jeg tror ikke du finner så mange som motsier deg.

 

 

Jeg har satt meg inn i det du sa. Statistikken du referer til kan ikke oversettes i linjer kode, og dette er gjort klart i lenken. Det som derimot er viktigere er at Java av forskjellige årsaker ofte ender opp som stand-alone prosjekt med lite kodedeling. For meg som foretrekker åpen utvikling er Java en katastrofe, hvilket betyr at alle sitter på hver sin haug og koder opp de samme snuttene om og om igjen. Dette er forsåvidt ikke språket sin feil i seg selv, men det betyr at du finner en rikere verdikjede hos C og C++. Du kan også observere hvilken positiv betydning dette har hatt for Perl og nå har for Python.

 

Antall linjer kode er et ganske dårlig tegn på populæriteten til et språk, men la gå.

 

http://www.ohloh.net/languages/compare?measure=loc_changed

 

Det å anklage java for å være fiendtlig mot open source er jo også en litt snodig anklage...

[Manuel]

Ja jeg er helt enig det kan unngås men det krever kunnskap om alle disse udefinerte oppførslene. i=i++;

 

er ikke veldig kryptisk kode...

Kryptisk betyr ikke nødvendigvis langt, men inkrementeringen du viser der burde få utvikleren til å lure på hva han/hun egentlig forventer at den skal gjøre. Med overlagring av operatorer - noe som mangler helt i Java - så er dette antakeligvis ikke engang overraskende.

 

Da vil jeg heller hevde at det er mer problematisk å skjønne hvordan kopiering av objekter utføres i forhold til tildelingsoperator, kopikonstruktør og med manuell minnehåndtering. Bland inn unntakshåndtering og pthreads, og man har en oppskrift på et tidkrevende mareritt i debuggeren dersom ikke alt er gjort riktig. Likevel så er atferden til disse veldefinert.

 

Er problemet at standard oppførsel er shallow copy? Jeg har ikke hørt argumentet at shallow copy fører til ytelsestap (logisk sett vil det jo føre til ytelesesøkning)? Det er også fint mulig å imlementere deep copy om du trenger dette, og du burde jo også kunne få IDEen til å genere disse for deg om det er noe du trenger mye av. Jeg har egentlig aldri støtt på problemer med dette, men kanskje det skyldes at jeg i hovedsak har kodet java og ikke har tenkt på det.

Ytelsesaspektet var ikke i tankene, men at "definert" atferd ikke er synonymt med kode som ikke stinker (i=i++) og er innlysende første gang en utvikler blir eksponert for problemet.

 

At java utnytter det at strings er immutable er vel strengt tatt ikke negativt, og kan faktisk la deg utføre (om kryptiske) ytelsesforbedringer =) Jeg ser dog poenget ditt at sammenligning av stringer kan forføre nybegynner til å mistforstå == operatoren, men dette er da i mye mindre grad enn c++ og dets høye terskel for å skrive god kode. Sannelig ikke noe jeg ville våge meg ut på, men jeg ser at muligheten er der.

 

Misforstå meg ikke, jeg nekter ikke for at en glimrende c++ utvikler(som det ikke er altfor mange av!) kan lage algoritmer som knuser de fleste andre språk på samme problem, men den faktiske nytten av dette er diskutabel. Det er ikke mange programmer som trenger slik ytelse til den kostnaden. I hovedsak vil slike programmer som krever denne typen ytelse være programmer som JVMen? Ikke akkurat noe de fleste selskaper trenge å bry seg om.

Jeg har litt problemer med å bli altfor engasjert i diskusjonen rundt ytelse ved programkjøring, siden dette sjelden er et problem på moderne maskinvare. Det finnes unntak, men jeg håper og tror at bruken av "managed" kode vil øke med de fordelene dette gir i forhold til pålitelighet - uavhengig av selve språket. Likevel så vil det alltid finnes bruksområder der man ønsker kontroll over når deallokering utføres, når man ønsker å betale for dynamisk dispatch, ønsker adgang til datatypene til faktiske representasjon og ha et begrep om hvordan koden kan "mappes" til maskinen sitt instruksjonssett.

Endret 31. oktober 2010 av Manuel

[doloop]

Kryptisk betyr ikke nødvendigvis langt, men inkrementeringen du viser der burde få utvikleren til å lure på hva han/hun egentlig forventer at den skal gjøre. Med overlagring av operatorer - noe som mangler helt i Java - så er dette antakeligvis ikke engang overraskende.

 

Dette har lite med operatoroverstyring, og er en diskusjon jeg ikke ønsker å ta opp siden det finnes like mange meninger som mennesker. Det er uansett frivillig å benytte. Mitt poeng er at kode som har funket i 3 år kan plutselig slutte å gjøre det du forventer.

 

Når du leser kode er det ikke lett å se slike ting som

 

i=i++; på linje 412 inne i en loop

 

Orginalforfatter av koden kan være long gone, eller det kan ha vært deg selv før du visste bedre, det er irrelevant. Problemet oppstår i at feilen kan oppstå lenge etter koden ble skrevet. Det blir vanskelig å finne årsaken til slike feil i ettertid, uavhengig av om orginalforfatter skulle visst bedre. Det naturlige når et program går i stykker er å sjekke de siste endringene.

 

Da vil jeg heller hevde at det er mer problematisk å skjønne hvordan kopiering av objekter utføres i forhold til tildelingsoperator, kopikonstruktør og med manuell minnehåndtering. Bland inn unntakshåndtering og pthreads, og man har en oppskrift på et tidkrevende mareritt i debuggeren dersom ikke alt er gjort riktig. Likevel så er atferden til disse veldefinert.

 

Å kopiere objekter i java krever at du forstår hva en referanse er, ikke noe mer. Det burde du forstå før du skriver kode andre skal bruke =)

Endret 1. november 2010 av doloop

[x871kx6167ss7]

Vil først si at jeg egentlig synes diskusjonen er litt «teit». Deler man opp alle implementasjoner som "rask" og "treg"? Er det sånn at alt som er like rask eller raskere enn C++ er raskt og alt annet er tregt? Dere setter vel ikke Java og Ruby i samme bås? Føler det blir et veldig sort/hvit diskusjon her, noe som ikke er særlig givende.

 

Jeg antar at når dere snakker om hastigheten til java, da tenker dere på hvor fort kompilert javakode ("bytecode") kjører på sun sin JVM. Og når dere snakker om hvor rask C++ er, da snakker dere om et GCC kompilert program som kjører på den fysiske CPUen?

 

Neida, jeg er kjent med både det og JIT, men jeg ser vel mer på det som et plaster på elendig ytelse enn noe som drar ifra kompilert kode.

Man har jo f.eks. gcj som kompilerer Java- og bytekode til maskinkode. Men dersom du søker litt rundt på nettet ser du fort at det ikke nødvendig vis gir noen ytelseforbedringe, snarer tvert i mot. Informasjonen som man har under kjøringen gir en reell mulighet for optimaliseringer som JIT-VMer benytter seg av.

 

Men man kan jo selfølgelig påstå at semantikken til java uansett gjør at programmer skrevet i Java er tregere enn de skrevet i C++.

 

Alt det høres jo fint ut, men profilering av kode er fullt mulig i C/C++/Fortran, hvor du gir inn typiske datasett og kompilatoren gjør optimaliseringer knyttet til det. Derfra har vi også et godt erfaringsgrunnlag for å se nøyaktig hvor effektiv denne metodikken er sammenlignet med å kompilere uten profilering. Gevinsten er ofte liten, gjerne knyttet til lokalitet av minne og grenpredikering.

Må du huske at det er utfordringer knyttet til optimalisering av C/C++ på grunn av svært stor frihet mtp pekere o.l.

 

In any case. Poenget mitt er at jeg mener at man ikke kan si at et språk er kjappere enn et annet, hvis det er hovedsakelig skrevet i språket man sammenlikner det med. Hvordan kan Java være kjappere enn C++, hvis Java er avhengig av å ha størsteparten av sine egne funksjoner skrevet i C++ for å bli kjapt?

Ingen funksjoner "i java" er skrevet i C++.

 

Når det kommer til JVMen, så er vel ingen i tvil om at en ren tolking av javas bytekode vil være tregt. Men ved hjelp av JIT blir (implementasjonen til) språket JVM er skrevet i irrelevant etter som tiden går, og andre faktorer vil spille en større rolle (f.eks. optimalisering basert på profiling av det kjørende programmet).

 

Synes den generelle påstanden blir et veldig naivt og forenklet syn på verden. F.eks. kompilerer stalin schemekode til C-kode, og kan ofte match/overgå vanlige C-kompilatorer som kompilerer et tilsvarende C-program.

 

Eh, saken er at nettopp en copying collector kan være raskere enn eksplisitt allokering/deallokering. Hvorvidt det vil være tilfellet avhenger av allokeringsmønsteret til programmet. Så GC fører definitivt ikke til "treghet" uten forbehold.

Copying collectors er vel (nesten?) alltid compacting også, noe som er fordelaktig mtp. caching.

 

 

[Eksempler på at rekkefølge argumenter o.l. blir evaluert i er udefinert]

Synes ikke dette er noe bra argument. Kan vel sammenlignes med det å sammenligne stringobjekter som allerede er nevnt. Uten at jeg har lest begrunnelsen til dette valget i C++, så var det tidligere vanligere å ikke spesifisere rekkefølgen argumentene blir evaluert i for å gi kompilatorer spillerom for optimalisering, og det taler vel ikke i ditt favør.

[Manuel]

Å kopiere objekter i java krever at du forstår hva en referanse er, ikke noe mer. Det burde du forstå før du skriver kode andre skal bruke =)

Eksempelet var rettet mot C++ - ikke Java.

[Del]

Jeg regner med du sikter til Java appleten som nordea blant annet benytter, ikke selve bankid løsningen fra BBS.

For bankid løsningen fra BBS som alle banker bruker ble Java valgt, antagelig blant annet fordi noen hørte på en som deg og faktisk trodde at det var så enkelt. Dessverre har det vist seg at det er langt fra så enkelt. Dette er en høyst overkommelig og svært liten Java kodesnutt som har vist seg svært lite plattformuavhengig, og den brukes av hele Norges voksne befolkning. Sun hadde alltid problemer med å ta skrittet helt ut i forhold til åpning av Java-plattformen, og med søksmålet Oracle nå fremmer mot Google er det lite som tyder på at det punktet blir bedre. Språk som C og C++ er derimot svært uavhengige av de store selskapene, selv om VS har vist svak evne til å følge standard innimellom, og stor evne til å putte sine egen bibliotek og utvidelser i miksen.

Det å støtte java applets i en browser har lite med plattformuavhengihet, og mye med integrasjon mot spesifikke programmer.

Det blir svært slitsomt når du forsøker å kverulere deg ut av en så enkel observasjon. Java ble valgt som løsning for bankid, og det nettopp på Java sin hjemmebane, nemlig web-løsninger. Det funker elendig, og er i praksis på ingen måte plattformuavhengig. Det bør du være i stand til å absorbere. Selv nå flere år etter er det 50/50 om bankid funker med åpen java i form av icedtea. Selv med Sun sin egen implementering har jeg (og stort sett hele den norske befolkning som bruker annet en windows) opplevd store problemer.

Jeg har satt meg inn i det du sa. Statistikken du referer til kan ikke oversettes i linjer kode, og dette er gjort klart i lenken. Det som derimot er viktigere er at Java av forskjellige årsaker ofte ender opp som stand-alone prosjekt med lite kodedeling. For meg som foretrekker åpen utvikling er Java en katastrofe, hvilket betyr at alle sitter på hver sin haug og koder opp de samme snuttene om og om igjen. Dette er forsåvidt ikke språket sin feil i seg selv, men det betyr at du finner en rikere verdikjede hos C og C++. Du kan også observere hvilken positiv betydning dette har hatt for Perl og nå har for Python.

 

Antall linjer kode er et ganske dårlig tegn på populæriteten til et språk, men la gå.

 

http://www.ohloh.net/languages/compare?measure=loc_changed

 

Det å anklage java for å være fiendtlig mot open source er jo også en litt snodig anklage...

Takk for ohloh-lenken, godt kjent med nettstedet, men jeg visste ikke at man kunne dra ut kodelinjer etter språk. Synes det virker merkelig at antall linjer har falt dramatisk det siste året, hva skyldes det? Uansett, du demonstrerer at det produseres mye åpen Java-kode, men det endrer ikke at den åpne utviklingsmodellen sin viktigste styrke, nemlig deling av kode, er en katastrofe for Java.

[doloop]

Sun hadde alltid problemer med å ta skrittet helt ut i forhold til åpning av Java-plattformen, og med søksmålet Oracle nå fremmer mot Google er det lite som tyder på at det punktet blir bedre. Språk som C og C++ er derimot svært uavhengige av de store selskapene, selv om VS har vist svak evne til å følge standard innimellom, og stor evne til å putte sine egen bibliotek og utvidelser i miksen.

For det første.

 

1) Sun har gjordt java apiene opensource, dere applikajsonsserver opensource, deres IDE er opensource, deres database... du ser hvor dette går.

 

2) Oracle saksøker ikke google for bruk av opensource, de saksøker google fordi de mener Google selger programvare de har gjordt opensource. De ønsker en royalty på googles virtual machine siden de hevder google har kopiert mye av deres VM kildekode. Ikke at jeg er enig i søksmålet, men det er ganske vanlig at man ikke aksepterer at andre selger ditt opensource prosjekt. Dette er heller ei en et angrep på åpen kildekode. Jeg kan dog legge til at oracle og sun er ganske forskjellige selskaper, og at oracles holdning til opensource etter oppkjøpet gjenstår å se.

 

Det blir svært slitsomt når du forsøker å kverulere deg ut av en så enkel observasjon. Java ble valgt som løsning for bankid, og det nettopp på Java sin hjemmebane, nemlig web-løsninger. Det funker elendig, og er i praksis på ingen måte plattformuavhengig. Det bør du være i stand til å absorbere. Selv nå flere år etter er det 50/50 om bankid funker med åpen java i form av icedtea. Selv med Sun sin egen implementering har jeg (og stort sett hele den norske befolkning som bruker annet en windows) opplevd store problemer.

 

Mitt poeng er simpelt at vi må skille serverside fra klientside her. Klientside er ikke java veldig god på(og alle er enig i at java applets ikke er noe spesielt bra, dog du finner noen bra her også. Feks NASAs World Wind opengl applet), og bruker som de fleste andre språk vanligvis HTML + javascript for presentasjon. Det er også serverside som er viktig siden HTML +css i dag brukes så å si av alle uavhengig av om det er java, php eller ruby (på .net finner du jo litt silverlight)

Endret 1. november 2010 av doloop

[Del]

For det første.

 

1) Sun har gjordt java apiene opensource, dere applikajsonsserver opensource, deres IDE er opensource, deres database... du ser hvor dette går.

 

2) Oracle saksøker ikke google for bruk av opensource, de saksøker google fordi de mener Google selger programvare de har gjordt opensource. De ønsker en royalty på googles virtual machine siden de hevder google har kopiert mye av deres VM kildekode. Ikke at jeg er enig i søksmålet, men det er ganske vanlig at man ikke aksepterer at andre selger ditt opensource prosjekt. Dette er heller ei en et angrep på åpen kildekode. Jeg kan dog legge til at oracle og sun er ganske forskjellige selskaper, og at oracles holdning til opensource etter oppkjøpet gjenstår å se.

Nå må du lese hva jeg skriver. Jeg er svært godt kjent med Sun sin håndtering av åpen utvikling. I Java sitt tilfelle må jeg fortsatt legge inn pakkebrønn for proprietær programvare, og godta en proprietær lisens, for å kunne få Java plugin til min nettleser slik at jeg kan logge inn på min bankkonto.

 

Når det gjelder MySQL har det vært mye støy og usikkerhet knyttet til den nettopp fordi Sun ikke har villet slippe den helt løs. På Openoffice har det vært mye støy rundt copyright transfer og byråkratisk overstyre fra Sun som har bidratt til levedyktige forker av prosjektet over periode på flere år. Java er patentert i hue og rævva, og det er derfor Google kan saksøkes over Dalvik. Den eneste grunnen til at Sun valgte å bli rimelig åpen på Java var trusselen fra Silverlight. Det er mer enn litt trist. Når det gjelder hele Solaris er CDDL en åpen provokasjon mot hele det åpne miljøet. Jeg gjentar, Sun har aldri klart å ta den åpne modellen helt ut, og du trenger ikke være noe geni for å se det. Når det er sagt er jeg svært glad for at Sun innså at de var best tjent med åpne lisenser, og at de har bidratt med store mengder viktig kode til åpne prosjekter.

[jossy]

Så lenge du ikke skal programmere sanntidssystemer, nei.

[GeirGrusom]

Så lenge du ikke skal programmere sanntidssystemer, nei.

Det gjelder å velge riktig verktøy til jobben.

 

Generelt så er kryssplattformutvikling en utfordring. Dette er på ingen måte noe enklere i C eller C++ enn det er i Java. Nøye planlegging må til uansett språk.

[quantum]

Den eneste grunnen til at Sun valgte å bli rimelig åpen på Java var trusselen fra Silverlight.

Hvordan skulle Silverlight være en trussel? Kan ikke se at det er overlapp i markedssegmentene i det heletatt?

[Del]

Silverlight er siste skudd fra MS for å fremme .net. Å kreve en plug-in er en effektiv lock-in mekanisme, og som en fin bonus flyttes den regnetunge biten fra server til klient for nettbaserte tjenester. Ser du det nå?

[quantum]

Silverlight er siste skudd fra MS for å fremme .net. Å kreve en plug-in er en effektiv lock-in mekanisme, og som en fin bonus flyttes den regnetunge biten fra server til klient for nettbaserte tjenester. Ser du det nå?

 

Ikke i det heletatt. I det markedet Java befinner seg er det ingen som er interessert i å flytte noe som helst regnetungt og forretningskritisk over på klienten. Mulig Adobe skjelver i buksene, men åpenbart ikke nok til å åpne Flash'en sin. Og *hvis* det er noe som har fått Sun til å skjelve i buksene (edit: når det gjelder klientteknologi), så er det Flash og ikke Sliverlight.

 

Java har veldig lite å tape på klientsiden, muligens med unntak av Id-applet'en til nettbankene, men den tror jeg neppe vi får se på Silverlightplattform. Edit: Og .Net har seff. vært et ekstremt kraftig og berettiget spark i Java-ræva generelt, noe Java EE utvilsomt har hatt godt av.

Endret 1. desember 2010 av quantum

[Del]

I det markedet Java befinner seg er det ingen som er interessert i å flytte noe som helst regnetungt og forretningskritisk over på klienten.

Når du betegner markedet Java befinner seg i som noe ensartet, så kan det være veldig nyttig at du forteller akkurat hva du mener dette markedet er. Det vil gjøre videre diskusjon uendelig mer meningsfylt.

Mulig Adobe skjelver i buksene,

Naturligvis gjør de det, Silverlight går rett i strupen på flash, men det er ikke temaet her.

men åpenbart ikke nok til å åpne Flash'en sin.

Tja, du bør følge med bedre. Adobe åpnet opp litt av hvert som en reaksjon, sjekk ut Open Screen Project. Riktignok åpnet de ikke plugin utviklingen.

Java har veldig lite å tape på klientsiden, muligens med unntak av Id-applet'en til nettbankene, men den tror jeg neppe vi får se på Silverlightplattform. Edit: Og .Net har seff. vært et ekstremt kraftig og berettiget spark i Java-ræva generelt, noe Java EE utvilsomt har hatt godt av.

Jeg tror du bør løfte blikket litt. Skillet mellom server og klient er ikke det vesentlige.Du ser ut til å være klar over at .net er en trussel, da er ikke veien lang til å se at utbredt silverlight vil bidra sterkt til å favorisere .net plattformen.

[quantum]

Riktignok åpnet de ikke plugin utviklingen.

det var vel nøyaktig det jeg skrev også?

Jeg tror du bør løfte blikket litt. Skillet mellom server og klient er ikke det vesentlige.Du ser ut til å være klar over at .net er en trussel, da er ikke veien lang til å se at utbredt silverlight vil bidra sterkt til å favorisere .net plattformen.

nei, skillet mellom server og klient er vesentlig. javamarkedets hovedsegment (men ikke eneste segment) er forretningskritisk transaksjonsprosessering, hvor silverlight aldri kommer til å sette sine labber.

[GeirGrusom]

nei, skillet mellom server og klient er vesentlig. javamarkedets hovedsegment (men ikke eneste segment) er forretningskritisk transaksjonsprosessering, hvor silverlight aldri kommer til å sette sine labber.

Men som er et sted hvor .NET Framework har satt sine labber, og fått ihvertfall littegranne. Skal vi bruke jobbutlysninger etter utviklere kan en anta at de har klort til seg ganske mye ifra Java på dette området.

 

Men Silverlight != .NET ettersom Silverlight kjører på et Subset av .NET Framework (derfor Silverlight er tilgjengelig på Mac OS X, men .NET er ikke det) men det er bare pirk.

[Del]

nei, skillet mellom server og klient er vesentlig. javamarkedets hovedsegment (men ikke eneste segment) er forretningskritisk transaksjonsprosessering, hvor silverlight aldri kommer til å sette sine labber.

Snakker du om verdensmarkedet her? Isåfall hadde det vært fint med noe dokumentasjon, for her ser det ut til at du snakker om ting du ikke har peiling på.

[quantum]

nei, skillet mellom server og klient er vesentlig. javamarkedets hovedsegment (men ikke eneste segment) er forretningskritisk transaksjonsprosessering, hvor silverlight aldri kommer til å sette sine labber.

Snakker du om verdensmarkedet her? Isåfall hadde det vært fint med noe dokumentasjon, for her ser det ut til at du snakker om ting du ikke har peiling på.

jepp, Java spiller en viktig rolle innen f.eks. bank/finans og telecom også utenfor Norge. men hvis du ønsker å tro at Oracle kjøpte Sun primært for å bli dominerende i Norge skal ikke jeg hindre deg.

[Del]

Dokumentasjon, er det for mye å be om?

[quantum]

Dokumentasjon, er det for mye å be om?

Altfor mye, vi kan la det være opp til de som måtte gidde å lese dette å avgjøre hva de ønsker å tro. Men du bør kanskje vurdere å varsle Oracle om at de har kjøpt katta i sekken...