mboost-dp1

unknown

Suns udviklere synes Java er upraktisk

- Via The Inquirer -

Der har åbenbart i nogen tid hersket en heftig intern debat i SUN omkring anvendelsen af Java. Diskussionen drejer sig bl.a. om, hvorvidt Java er en acceptabel platform til at udvikle stabile applikationer med, til Solaris. Også når SUN udgiver nye versioner af Java, risikerer udviklerne, at deres eksisterende programmer pludselig ikke virker.





Gå til bund
Gravatar #1 - sKIDROw
5. feb. 2003 12:40
Hehhe
Minder mig om det lækkede MS dokument, hvor MS teknikerne roser FreeBSD og nogle gange på bekostning af deres egen Win2k server.. ;)
Gravatar #2 - Raenil
5. feb. 2003 12:52
Det viser vel bare, at de fleste teknikere og programmører ikke er så åndsvage, som deres egen marketingsafdeling gerne vil overbevise omverdenen om at de er. :-)
Gravatar #3 - vidofon
5. feb. 2003 12:53
whauuu
Gravatar #4 - knasknaz
5. feb. 2003 13:15
LOL
Gravatar #5 - 3njoy
5. feb. 2003 13:34
Jeg fatter hat :)

JEg er ligeglad :)

JEg bruger windows :)

Jeg Ka godt lide windows :)

Når det virker altså :)
Gravatar #6 - propan
5. feb. 2003 13:43
Well, Java og JIT-compileren er sgu da lame i forhold til kode som er lavet til den maskine det skal afvikles på! Det kan man da ikke sammenligne med BSD vs. Windows ???
Det handler jo om at Java-platformen er for langsom, og nogle gange virker den slet ikke!
Gravatar #7 - RhAzN
5. feb. 2003 14:08
At sige at JIT-compileren er "lame" i forhold til kode der er compiled direkte til en platform er imo (og for at bruge dit eget udtryk) "lame." JIT-compilerens job er netop at compile javakode direkte til bestemt platform i de tilfælde hvor det er nødvendigt.
Gravatar #8 - cas2
5. feb. 2003 14:30
Jooh. Men hvordan du end vender og drejer det compiler Java til bytecode der kører på en VM. Og det går altså langsommere end kode der er compilet til en bestemt processor arkitektur. Jeg ville ihvertfald ikke købe "...shelves full of shrink wrapped packages for Windows and Linux..." selvom det fandtes.
Gravatar #9 - Yasw
5. feb. 2003 15:08
Kan nu meget godt lide Java, men det egner sig nok ikke til alt for store programmer, da det jo som nævnt før ikke kører vanvittigt hurtigt.
Gravatar #10 - damp
5. feb. 2003 15:18
når jeg læser det får jeg det da ikke til at de brokker sig over det er langsomt men at den bruger for meget ram og at de skrifter deres packages konstant og derfor kan udviklerne opleve at deres software lige pludselig ikke virker med nye releases.
Gravatar #11 - seahawk
5. feb. 2003 15:42
Nu havde vi jo denne diskussion i en anden tråd forleden, og i 95% af de programmer i bruger vil i ikke kunne mærke forskel pga at det er bytecode med en jit-compiler!

Teoretisk set burde det være muligt at lave java programmer HURTIGERE end normale programmer, da jit-compileren vil kunne tage højde for den maskine den kører på netop nu - i modsætning til normale programmer som typisk er kompileret til laveste fællesnævner!

Og så er der et par af argumenterne jeg synes er lidt vage - eksempelvis: At der er flere bugs i java end f.eks. i c++!

Jeg formoder at de her snakker om antallet af bugs i STL kontra java class library, og det skulle da være underligt at der ikke var flere bugs i java når det nu er 10-50 ganges større end STL! :)
Gravatar #12 - Dreadnought
5. feb. 2003 17:21

Tja, som der er påpeget et eller fler gange før. Java er for stort, fejlfyldt og seriøst langsom på mindre maskiner. Det kan ikke bruges til særligt meget andet end små rådne internet applikationer.

word!
Gravatar #13 - charon
5. feb. 2003 18:03
Det er da ganske imponerende så ignorante folk er. Java er muligvis sløvt og stort til GUI-programmer, men til serverprogrammer er det faktis utroligt vellidt og benyttet - så meget så SAP har annonceret at ville lave en version af deres økonomisystem i Java, og det er alligevel en ret stor tillidserklæring.

Jeg syntes også at huske Java kørende på min mobiltelefon, hvilke da må siges at være en ret beskeden computer. Og sidst jeg checkede havde aceshardware.com deres site kørende på Servlets (ie. Java) - de har sågar lavet en artikel om hvordan de fik lavet deres nye site så det kunne modstå det stigende load de oplevede.

Hvis jeg træder nogen over tæerne og de stadigvæk mener at Java er sløvt, at JIT er ubrugeligt, og i det hele taget gerne vil gøre dem selv mere til grin, opfordrer jeg hermed til at komme med saglige argumenter til hvorfor det skulle være så dårligt. Hvis ikke, case closed.
Gravatar #14 - Regus
5. feb. 2003 18:04
#11
nu er det sådan at 95% af de applikationer jeg bruger har en GUI...

"Teoretisk set (...)"
Ja <STRONG>Teoretisk</STRONG>

"Jeg formoder at de her snakker om antallet af bugs i STL kontra java class library, og det skulle da være underligt at der ikke var flere bugs i java når det nu er 10-50 ganges større end STL! :)"

Det han siger er vist nok at flere bugs bliver marked unfixable - hvilket er lidt noget andet end at de opdages...
Gravatar #15 - Regus
5. feb. 2003 18:07
#13
Det er simpelthen fantastisk så meget man skal beskyldes for fordi man siger at java er langsomt...
Gravatar #16 - s-leep
5. feb. 2003 18:15
Spørgsmålet er hvorfor jeg skriver her, men Sun har længe haft slowdown på accepten af Java. Det er ikke kun på Windows og Linux, som artiklen kommer ind på.

Er det overraskende, at Sun ikke supporterer Java tilfredsstillende, forstået på den måde, at det tager evigheder at få ting fixet, tilføjet i Java classes, og at basale ting i Java er i uorden, som der skrives om?

Jeg synes det er på tide, at Sun begynder at overveje, om de gaber over for meget. Det er tydeligt, at de har mindre og mindre gang i både servermarkedet, Solaris, Java..

Java har aldrig været cross platform, og det bliver det aldrig. Årsagen er, at Sun faktisk er bange for at miste deres greb om teknologien, dvs. deres produkt.

Det er en Microsoft om igen i mine øjne.

p.s. hvor manger af jer har læst artiklen? NÅH ok! :p
Gravatar #17 - Regus
5. feb. 2003 18:21
#13
og så noget sagligt...

Det afhænger så sandelig af hvad du sammenligner med og hvad dit program skal foretage sig...

f.eks. understøtter java som bekendt ikke pointerarithmetik og det gør java langsommere end C++ i situationer hvor man kunne få fordel af det...

Java benytter RTTI og det giver et overhead som C++ ikke har det gør igen java langsommere

Java har en garbage collector det gør memmory allocation mere kompliceret det gør java langsommere end C++

Alle metoder er virtuelle i java det gør metodekald langsommere end i C++

Java understøtter ikke funktionspointere og afviklingen af callbacks er derfor langsommere end i C++

Ikke dermed sagt at java ikke har sine fordele...
Det er bare ikke performance drejer sig om - nu er jeg selv C# og .Net tilhænger det er ikke nær så hurtigt som C++ men det har nogle andre store fordele som opvejer de performance problemer der... en ekstra CPU er del billigere end de ekstra timer jeg skulle bruge på at kode det i C++

og hvis vi endelig taler performance så er det i 99% af alle performance situationer ikke et spørgsmål om rå ydelse men intelligent implementering og det er folk lige ringe til hvad end sprog de skriver i
Gravatar #18 - charon
5. feb. 2003 18:43
#17

Pointeraritmetik er en af de ting Java eksplicit ikke understøtter, simpelthen fordi det er den største kilde af fejl i C/C++-programmer - ikke dermed sagt at det ikke har sin ret, men hvis man skal skrive programmer der er missionskritiske (bank- og økonomisystemer, som eksempel), så er det da rart at den fejlgruppe er væk.

Funktionspointere og callbacks kan implementeres ved at bruge Java's Reflection-API, hvor du kan kaste et Method-objekt eller et Class-objekt af sted, eller lægge et i et array. Samme boldgade, anden implementering. Selvfølgelig er det langsommere end at have en direkte funktionspointer, men så er vi tilbage til at bruge pointere igen, hvilket er en fejlgruppe der gerne skulle undgås.

Men som du selv skriver, så er det sjældent performance der er problemet, men mere implementeringen. Hvis man skal bruge et engangsbeløb på kr. 100.000,- for at få nok ydelse til at køre et mere CPU-intensivt program, hvor udviklingstiden så til gengæld er 20% mindre, og hvor der er 10% færre fejl, så er det for store værdier af x måske besparende i længden.

Desuden er jeg blevet ganske glad for J2EE - der er mange ting der generer mig, men der er også mange ting jeg er glad for, og så er det ellers at opveje fordele mod ulemper. Prøv at kigge på de features der er i JBoss, og så spørg dig selv hvor lang tid det ville tage at implementere i C eller C++, og hvor mange sjove små hukommelsesfejl der ville krybe ind.

Angående fejl i Java og dets class library, så undlader jeg at kommentere på det punkt - jeg er en selvbestaltet fri software nørd, og undlader derfor at klage for meget over fejl i proprietær software - man kan jo bare gøre det bedre selv, og det har jeg ikke formået endnu :-)
Gravatar #19 - Regus
5. feb. 2003 18:49
#18
Nu tager jeg slet ikke stilling til hvorvidt pointere er en <STRONG>god</STRONG> ting jeg siger bare det er en <STRONG>hurtig</STRONG> ting...
Gravatar #20 - propan
5. feb. 2003 19:29
#11: fuck nu det! Skriv lige Macromedia Flash, Photoshop, diverse mediaplayers (.mpg, .avi, osv), winamp, ms office, og lignende i Java, og se om din maskine ikke mister RAM så det basker?
Java er FINT til utilities og små tools som kun skal klare MEGET små opgaver og derefter smutter igen (hej hej)
Java skal holde sig fra RAM krævende processer generelt! Det halter!
Gravatar #21 - ns
5. feb. 2003 19:41
:)
Gravatar #22 - xbeeps
5. feb. 2003 19:47
Java kan som alle andre sprog også kompileres til maskinkode.

Gang på gang bliver Java/C#/C++ diskussionen forplumret af at folk blander fortolker, oversætter og hybriden JIT sammen. Man kan ikke diskutere begge ting på én gang!

Sprogene er ca. lige gode

Java er (næsten altid) implementeret til at køre på en virtuel maskine, evt. en der benytter JIT kompilering, men det kan også oversættes til maskinkode.

C++ er (næsten altid) implementeret således at det skal oversættes, men der er intet i vejen for at bygge en virtuel maskine der fortolker koden.

C# er (kun) implementeret til en virtuel maskine (fortolker) der benytter en JIT compiler.

Forstå dog at forskellene mellem sprogene er næsten ligegyldige, det er implementationerne der giver de store forskelle. Og husk så at alle kendte implementationer kan benyttes til et vilkårligt af de sprog i udkæmper en religionskrig for.
Gravatar #23 - cas2
5. feb. 2003 20:07
Prev: Jeg ved da ikke om der er tale om en religionskrig.

Inden for de vante rammer (Suns VM) er Java bare ikke super hurtigt. Fx. til aritmetiske operationer. Men til dets nuværende web "niche" fungerer det jo fint. Jeg har også godt set forsøg på at lave "ægte" compilere til Java, men det har altid været med stort BETA. Am i wrong?
Gravatar #24 - Regus
5. feb. 2003 22:43
#22
nu er der bare det at ordet java dækker over lidt mere end et sprog - VM'en er en del af pakken java som også indeholder et sprog tilfældigvis af samme navn...
Der er ikke meget java tilbage i java hvis man dropper vm'en og det er i praksis så sjældent at det højest kan blive en hypoteteisk debat...

Og det kan vel være lidt lige meget hvad der kan lade sig gøre hvis det intet har med praktisk anvendelse at gøre du kan givetvis også compile VB til at køre på Solaris eller skrive et operativsystem i Windows classen i COBOL, men der er ikke nogen der har gjort det og næppe nogen der vil gøre det så hvilken relevans har det?
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login