mboost-dp1
unknown
IBM lavede jo engang en open source Java-compiler - Jikes - som så vidt jeg husker døde pga. manglende interesse, tilbage i 2004.
Selvfølgelig ville en Java runtime-engine, der ikke brugte 60 MB RAM til et "hello world" program på Windows være dejligt - og måske endda ligefrem få mig til at installere Java, hvilket jeg kategorisk nægter nu... men jeg tvivler nu på der er nok interesse for det, til ligefrem at begynde på et så stort projekt.
Der sker nok ikke så meget ved det.
Selvfølgelig ville en Java runtime-engine, der ikke brugte 60 MB RAM til et "hello world" program på Windows være dejligt - og måske endda ligefrem få mig til at installere Java, hvilket jeg kategorisk nægter nu... men jeg tvivler nu på der er nok interesse for det, til ligefrem at begynde på et så stort projekt.
Der sker nok ikke så meget ved det.
#2 Man kunne vel forestille sig, at brugeren måske ville gøre brug af sin computer til at køre andre programmer end "hello world". Men det er selvfølgelig bare ren teori.
#1 Jeg tvivler stærk på at helloworld bruger 60MB, hvor har Du det tal fra? Du har vel ikke lyttede til for meget FUD fra MS? Når man nu kan kører java på alt fra pc'er, telefoner til smartcard, så er et lille hukommelse forbrug jo en fordel. Envidere har jeg ingen problemer med at kører 10 samtidige JVM, på min gl. maskine, som kun har en 512 MB ram.
Selvfølgelig ville en Java runtime-engine, der ikke brugte 60 MB RAM til et "hello world" program på Windows være dejligtJava er en virtuel maskine og den reserverer 32 MB hukommelse til heapen og tilsvarende til stakken.
Det ser ud som om fra Windows at hukommelsen er "brugt", men det er altså ikke tilfældet. OS'et giver et niveau af paging som gør at de 64 MB ikke optager plads i den fysiske RAM.
Denne opførsel er helt uafhængig af om du kører et hello world program eller en applikationsserver og det er såmænd ganske glimrende, hvis man vil have Java programmer til at performe godt (og det vil man jo gerne).
men jeg tvivler nu på der er nok interesse for det, til ligefrem at begynde på et så stort projekt.Du kan på command line vælge hvor meget virtuel hukommelse som skal reserveres ved opstart. Hvis du sætter det lavt så vil java kun bruge få MB hukommelse, men det vil gå ud over performance. Default størrelsen er en afvejning som Sun har lavet....
#1
60 MB RAM? Nu må du stramme op. På mit system er der et reelt overhead på 3 MB, hvilket egentlig ikke er så slemt. Derudover er der 4,2 MB shared, så i værst tænkelige fald 7,2 MB.
Hvis der vitterligt står 60 MB, så skyldes det måden hvorpå hukommelsen opregnes (virtuel hukommelse og hvad ved jeg. EDIT: tak til mathiass. Jeg mente dog stakken var noget mindre).
Til sammenligning bruger python 1 MB plus 1,4 MB shared, hvilket jo stadig er betydeligt mere end hvad der kræves for at køre et hello world program. Er du også stærk modstander af python?
Testprogrammet er i begge tilfælde en enkelt linje der læser fra standard input.
60 MB RAM? Nu må du stramme op. På mit system er der et reelt overhead på 3 MB, hvilket egentlig ikke er så slemt. Derudover er der 4,2 MB shared, så i værst tænkelige fald 7,2 MB.
Hvis der vitterligt står 60 MB, så skyldes det måden hvorpå hukommelsen opregnes (virtuel hukommelse og hvad ved jeg. EDIT: tak til mathiass. Jeg mente dog stakken var noget mindre).
Til sammenligning bruger python 1 MB plus 1,4 MB shared, hvilket jo stadig er betydeligt mere end hvad der kræves for at køre et hello world program. Er du også stærk modstander af python?
Testprogrammet er i begge tilfælde en enkelt linje der læser fra standard input.
#1 Du kan læse på java man-page hvordan du kan sætte initial heap size:
http://www.hmug.org/man/1/java.php
(bladr ned til -Xmsn). Det ville dog være fjollet at sætte den meget lavt med det eneste formål at få mængden af reserveret virtuel hukommelse sat ned. Det eneste du kan få ud af det er ringe performance for dine java-programmer, men det giver dig måske lidt en forklaring på hvad de 60 MB egentlig betyder, når nu det ikke er forbrug af fysisk hukommelse...
http://www.hmug.org/man/1/java.php
(bladr ned til -Xmsn). Det ville dog være fjollet at sætte den meget lavt med det eneste formål at få mængden af reserveret virtuel hukommelse sat ned. Det eneste du kan få ud af det er ringe performance for dine java-programmer, men det giver dig måske lidt en forklaring på hvad de 60 MB egentlig betyder, når nu det ikke er forbrug af fysisk hukommelse...
Det største problem med Java er kompleksiteten, lag på lag på lag i 12-13 år nu, med 18.000 klasser, SE/EE/ME opdeling der lige så godt kunne være 3 forskellige sprog og en konstant skiftende fokus (appletter, enterprise og nu endelig desktop).
Der er ingen tvivl om, at livet for en Java programmør er noget mere komplekst end livet for en Microsoft programmør hvor en masse valg er taget på forhånd (Hvilken IDE, hvilket build værktøj, hvilket web framework, hvilket UI library osv.).
Sun har dog endelig forståelse for at der skal stærke standard værktøjer og de-facto teknologier til (NetBeans, Matisse, GlassFish, JPA, JSF...) for ikke at udviklerne drukner.
Jeg er bare bange for at det er for sent for Java, det er heller ikke for ingen ting der er så meget fokus på Groovy, Scala og lignende sprog i VM'en fordi Java i sig selv er for komplekst.
Der er ingen tvivl om, at livet for en Java programmør er noget mere komplekst end livet for en Microsoft programmør hvor en masse valg er taget på forhånd (Hvilken IDE, hvilket build værktøj, hvilket web framework, hvilket UI library osv.).
Sun har dog endelig forståelse for at der skal stærke standard værktøjer og de-facto teknologier til (NetBeans, Matisse, GlassFish, JPA, JSF...) for ikke at udviklerne drukner.
Jeg er bare bange for at det er for sent for Java, det er heller ikke for ingen ting der er så meget fokus på Groovy, Scala og lignende sprog i VM'en fordi Java i sig selv er for komplekst.
med 18.000 klasser, SE/EE/ME opdeling der lige så godt kunne være 3 forskellige sprogSprog? Der er da nøjagtig det samme sprog, kun API'erne er forskellige, og det er ikke meningen at man sætter sig ind i hele EE, kun i de dele som man har behov for...
Der er ingen tvivl om, at livet for en Java programmør er noget mere komplekst end livet for en Microsoft programmør hvor en masse valg er taget på forhånd (Hvilken IDE, hvilket build værktøj, hvilket web framework, hvilket UI library osv.).Er det nødvendigvis godt? Konkurrencen på Java IDE'er har givet nogle utroligt stærke og gode IDE'er som IMHO er lysår foran hvad Visual Studio kan præstere. Build værktøjet (ant) og UI library (Swing) ligger nu rimlig fast...
Jeg er bare bange for at det er for sent for JavaJava er mig bekendt den største platform til enterprise udvikling for tiden.
Sprog? Der er da nøjagtig det samme sprog, kun API'erne er forskellige, og det er ikke meningen at man sætter sig ind i hele EE, kun i de dele som man har behov for...
Har du nogensinde set hvad der sker hvis du forsøger at bruge et singleton i noget SE kode og deployer det til en app server? Har du nogensinde set hvor mange fiksfakserier (f.eks. preprocessors) der skal bruges til ME kode?
Er det nødvendigvis godt? Konkurrencen på Java IDE'er har givet nogle utroligt stærke og gode IDE'er som IMHO er lysår foran hvad Visual Studio kan præstere. Build værktøjet (ant) og UI library (Swing) ligger nu rimlig fast...
Du joker ik? Da jeg startede på Java i 96 var der INGEN IDE'er men så kom MS (Anders Hejlsberg) med J++. I dag kan man sågar sætte en breakpoint i Visual Studio og så steppe tilbage i koden. Der går nok et par år før Java IDE'er/debuggers kan det. Og Swing med dets emulering holder altså bare ikke, man kan føle at det ikke er nativt hvorfor også IBM startede på SWT. Hvis Sun havde valgt en native peer teknologi som SWT fra start af havde verden set helt anderledes ud og så skulle de måske heller ikke have brugt 10 år på af finde en layout manager der rent faktisk virker (GroupLayout).
Java er mig bekendt den største platform til enterprise udvikling for tiden.
Og større er bedre eller hvad? For ja, så er Java da bedst! lol
#12 "I dag kan man sågar sætte en breakpoint i Visual Studio og så steppe tilbage i koden. Der går nok et par år før Java IDE'er/debuggers kan det"
Du joker ik?
Det fungerer da fint med breakpoints i Eclipse debuggeren og jeg ville være meget overrasket hvis NetBeans etc. ikke kan det samme.
Du joker ik?
Det fungerer da fint med breakpoints i Eclipse debuggeren og jeg ville være meget overrasket hvis NetBeans etc. ikke kan det samme.
#12
Jeg tror du mangler et fortegn. Java debuggere er i dag meget avancerede. I Eclipse kan du f.eks. sætte den til at debugge, hvis programmet kaster en exception, så kan du tage et par steps tilbage, redigere lidt i koden og køre videre.
I dag kan man sågar sætte en breakpoint i Visual Studio og så steppe tilbage i koden. Der går nok et par år før Java IDE'er/debuggers kan det
Jeg tror du mangler et fortegn. Java debuggere er i dag meget avancerede. I Eclipse kan du f.eks. sætte den til at debugge, hvis programmet kaster en exception, så kan du tage et par steps tilbage, redigere lidt i koden og køre videre.
Og større er bedre eller hvad? For ja, så er Java da bedst! lolDer står da ingen steder noget om ordet "bedre". Du skrev at det er for sent for Java som om at Java har misset sin chance for at gøre sig gældende og det må jeg sige at jeg jeg er fuldstændig uenig i. Vi kan godt blive enige om at API har en masse klasser og funktioner som ikke ville være der, hvis man satte sig og lavede det forfra, men selve Java-sproget synes jeg nu er ganske smukt, især i forhold til sprog som C++ eller C# som har vanvittigt mange features som er unødvendige og som skyldes gammel arv...
Har du nogensinde set hvad der sker hvis du forsøger at bruge et singleton i noget SE kode og deployer det til en app server?Jeps, den tror jeg at vi alle sammen har haft fornøjelsen af på et tidspunkt. De fleste regner nu også en stateful singleton for et antipattern.
I dag kan man sågar sætte en breakpoint i Visual Studio og så steppe tilbage i koden. Der går nok et par år før Java IDE'er/debuggers kan det.Der tager du ganske fejl. Du kan ovenikøbet i eksempelvis Idea injecte vilkårlig kode, mens VM'en er suspenderet, således at du kan teste hurtige fixes mens systemet kører.
Og Swing med dets emulering holder altså bare ikke, man kan føle at det ikke er nativt hvorfor også IBM startede på SWT.Jeg mener at SWT er ret problematisk da det ikke kan porteres som resten og jeg synes nu efterhånden at Swings look and feel ligner native programmer stort set på en prik (selvom det er kommet til inden for de sidste par releases...).
#9
Ca. 3300 public top level classes i JSE 1.6.
Det er ikke så slemt.
.NET 2.0 har dobbelt så mange (men dækker så selvfølgelig også noget af JEE).
Men indrømmet - det er meget mere omfattende end VB6. Men vi kan
ikke skrue tiden 15 år tilbage.
Hvis du mener at det er stressende at have valg muligheder med hensyn
til IDE, andre tools, frameworks og libraries, så er Java absolut
ikke noget for dig.
Men der er altså mange som er glade for de muligheder.
Du skal ikke regne med at NetBeans og Glassfish bliver
de facto standarder. De er ikke specielt udbredte.
Groovy har jo adgang til hele Java biblioteket, så der er jo ikke
mindre at skulle sætte sig ind i der.
Jeg synes heller ikke at Groovy sproget som sådan er nemmere
end Java.
Men det er et anderledes sprog. Og hvis det er den type sprog
man vil have (og interessen for pythin og ruby antyder at der
er efterspørgsel efter den type sprog), så kan groovy da
godt gå hen og tage en pæn slice af JVM sprog markedet. Men
indtil videre er det mere interesse end production usage.
Det største problem med Java er kompleksiteten, lag på lag på lag i 12-13 år nu, med 18.000 klasser,
Ca. 3300 public top level classes i JSE 1.6.
Det er ikke så slemt.
.NET 2.0 har dobbelt så mange (men dækker så selvfølgelig også noget af JEE).
Men indrømmet - det er meget mere omfattende end VB6. Men vi kan
ikke skrue tiden 15 år tilbage.
Der er ingen tvivl om, at livet for en Java programmør er noget mere komplekst end livet for en Microsoft programmør hvor en masse valg er taget på forhånd (Hvilken IDE, hvilket build værktøj, hvilket web framework, hvilket UI library osv.).
Hvis du mener at det er stressende at have valg muligheder med hensyn
til IDE, andre tools, frameworks og libraries, så er Java absolut
ikke noget for dig.
Men der er altså mange som er glade for de muligheder.
Sun har dog endelig forståelse for at der skal stærke standard værktøjer og de-facto teknologier til (NetBeans, Matisse, GlassFish, JPA, JSF...) for ikke at udviklerne drukner.
Du skal ikke regne med at NetBeans og Glassfish bliver
de facto standarder. De er ikke specielt udbredte.
Jeg er bare bange for at det er for sent for Java, det er heller ikke for ingen ting der er så meget fokus på Groovy, Scala og lignende sprog i VM'en fordi Java i sig selv er for komplekst.
Groovy har jo adgang til hele Java biblioteket, så der er jo ikke
mindre at skulle sætte sig ind i der.
Jeg synes heller ikke at Groovy sproget som sådan er nemmere
end Java.
Men det er et anderledes sprog. Og hvis det er den type sprog
man vil have (og interessen for pythin og ruby antyder at der
er efterspørgsel efter den type sprog), så kan groovy da
godt gå hen og tage en pæn slice af JVM sprog markedet. Men
indtil videre er det mere interesse end production usage.
C# som har vanvittigt mange features som er unødvendige og som skyldes gammel arv...
C# er i de flestes øjne "Java done right", fordi du har tilpas med funktionalitet til at lade sproget udvikle sig (operator overloading, properties & events, type inference etc.).
Det opfører sig vil som man forventer at det skal - nemlig at forskellige apps er uafhængige af hinanden.
Øhh, jeg tror du får dig en overaskelse hvis du prøver det.
Hvis du mener at det er stressende at have valg muligheder med hensyn til IDE, andre tools, frameworks og libraries, så er Java absolut ikke noget for dig.
Det er stressende fordi man ender med at bruge mere tid på teknologi og research af samme, end på at løse den egentlige opgave man er sat til.
Du skal ikke regne med at NetBeans og Glassfish bliver
de facto standarder. De er ikke specielt udbredte.
Ah det ved jeg nu ikke, men du kan jo tage med til JavaOne i næste uge og se selv hvor meget der handler omkring NetBeans/GlassFish sammenlignet med Eclipse/Orion/WebSphere. ;)
Jeg synes heller ikke at Groovy sproget som sådan er nemmere end Java.
Man kan noget mere, så'n som at bruge closures... men ok det kommer også til Java når de kan blive enige i JCP'en.
C# er i de flestes øjne "Java done right"Ja, med fare for at starte en religionskrig her, så kan jeg stadig ikke forstå at man ikke skaffede sig af med pointere og structs, og hvorfor man ikke forenklede nedarvningssystemet til altid at være virtuelt som i Java. Manglen på operator overloading i Java mener jeg så absolut tjener til Javas ære, men det er jo nok et smagsspørgsmål...
Ah det ved jeg nu ikke, men du kan jo tage med til JavaOne i næste uge og se selv hvor meget der handler omkring NetBeans/GlassFish sammenlignet med Eclipse/Orion/WebSphere. ;)
I lyset af at det er Sun der udvilker Netbeans & Glassfish OG arrangerer JavaOne, ville det sq da være underligt at de ikke har en del om selv samme!
mrmorris, du fremstår som en meget pro c# frem for java, ved at slå på tromme for lige nøjagtigt de features du synes er relevant, samt at ignorerer samtlige andre features som klart er en force for java. Jeg vil ikke gå i detaljer, men kommentarer som c# is java done right lyder uhyggeligt farvet.
Ville du i øvrigt bruge c# hvis det kørte på en jvm?
mrmorris, du fremstår som en meget pro c# frem for java, ved at slå på tromme for lige nøjagtigt de features du synes er relevant
Ja det ville være mærkeligt hvis jeg "slog på trumme" overfor ting jeg ikke synes er relevant ville det ikke? Der er i forvejen alt for store skyggeklapper på udviklere i Java verdenen, så jeg synes godt man kan tillade sig at fokusere på de negative sider. C# har også negative sider, f.eks. at det kun er pseudo multi-platform.
Jeg vil ikke gå i detaljer, men kommentarer som c# is java done right lyder uhyggeligt farvet.
Jeg synes du skal gå i detaljer, det er dét man har debatfora til og det er altså mere objektivt end at kalde et synspunkt for "farvet".
De fleste af de problemer Java har, tog Anders Hejlsberg hånd om i C# og det er i dag Java der forsøger at hænge på C#'s innovation. Hvis du har godt modargumenter imod dette så lad mig høre.
Det klart største problem med Java er at der ikke er en stærk leder, alt skal forhandles og specificeret i lukkede JSR komiteer hvor Oracle, BEA, Sun, IBM, RedHat, HP, Intel, Google osv. alle skal have noget indført således at API'erne bliver overengeneered eller fejlagtigt.
Og således har vi nu, for 3 gang, et nyt dato-API på vej (JSR 310). For 3 gang et nyt IO-API på vej (JSR 203), ca. 15 officielle layout managers, og så er der jo EJB3 som igen er 3 forsøg - men stadig ikke så innovativt eller nemt at bruge som Microsoft's Linq.
Bare af nysgerrighed, hvilke er det ?Prøv at læse post #20 og #21 med modsat fortegn. Så er der i hvert fald et udmærket bud. Dertil kommer at koden umiddelbart kan flyttes mellem OS'er. Jeg arbejder selv på en mac, folk jeg arbejder sammen med bruger Windows og i sidste ende kører softwaren ofte på en Linux-server, og det giver ikke anledning til nogen problemer...
Skulle jeg hive ting frem som er bedre i C# end i Java vil jeg først og fremmest pege på lambda funktioner.
De fleste af de problemer Java har, tog Anders Hejlsberg hånd om i C#Men samtidig svingede pendulet tilbage i den gamle C++ rille med alt alt for mange besynderlige sprog-features der som nævnt dækker pointere men også skelnen mellem pass by reference og pass by value og lignende. C# er et meget omfattende og komplekst sprog, synes jeg. Måske er det fordi jeg mest koder i Java...
Prøv lige at tjekke disse to gæste talere på javaone:
url=http://www.dk.capgemini.com/nyheder/capgemini_danmark_i_front_p_open_source/
samt
url=http://www.dk.capgemini.com/nyheder/capgemini_skal_levere_open_source_lsning_til_det_offentlige/
url=http://www.dk.capgemini.com/nyheder/capgemini_danmark_i_front_p_open_source/
samt
url=http://www.dk.capgemini.com/nyheder/capgemini_skal_levere_open_source_lsning_til_det_offentlige/
...skelnen mellem pass by reference og pass by value og lignende. C# er et meget omfattende og komplekst sprog, synes jeg. Måske er det fordi jeg mest koder i Java...
Men i C# har man trods alt fuld styr på det via in/out semantik. I Java skal man vide at alt er pass-by-value af pointere med undtagelsen af arrays. Dvs. følgende kode stump virker IKKE som mange ville forvente:
public void swap(int a, int b)
{
int tmp = a;
a = b;
b = a;
}
...for at gøre det mere klart er man så begyndt at bruge "final" på argumenterne men det er stadig kun i Java Language Spec'en man kan få forklaringen på disse ting.
Jeg er også Java programmør og det er da en fantastisk platform fra mange synspunkter, især nu det er open source. Men jeg mener bare vi kunne få det endnu bedre ved at slå en streg i sandet og for en gang skyld siger "Java 7 er IKKE binær kompatibel med tidliere" og så få rettet alle de legacy ting det vil tage for lang tid at opremse så som at lave Date immutable, BigDecimal som nativ type og droppe type erasure til generics osv. osv.
og droppe type erasure til generics osv. osv.Ja, det var et tåbeligt valg, men så vidt jeg ved så er det et punkt på dagsordenen for java 7 og det kræver på ingen måde et brud med ideen om binær kompatibilitet, det kræver ikke ret meget mere end lidt desguaring og pilleri som man fint kan bruge det apparat, man lavede til indre klasser, for at implementere (jeg kunne forestille mig noget med et synthetic field til at holde et class object og så lidt syntax til at aflæse det...)
#27
Arrays i Java er ogsaa pass by value af reference. Ingen forskel
fra andre objekter.
Lad os ignorere den lille b=tmp detalje - vi ved hvad du mener.
Den kode virker fuldstændigt ens i C, C++, Java og C#. Eller
virker ikke hvis man foretrækker det.
C++ og C# har mulighed for explicit at ændre fra call by value
til call by reference. C# lidt pænere end C++.
For min skyld kunne man godt tilføjde det til Java.
Men det er ret sjældent at det er en pæn løsning.
I Java skal man vide at alt er pass-by-value af pointere med undtagelsen af arrays.
Arrays i Java er ogsaa pass by value af reference. Ingen forskel
fra andre objekter.
Dvs. følgende kode stump virker IKKE som mange ville forvente:
public void swap(int a, int b)
{
int tmp = a;
a = b;
b = a;
}
Lad os ignorere den lille b=tmp detalje - vi ved hvad du mener.
Den kode virker fuldstændigt ens i C, C++, Java og C#. Eller
virker ikke hvis man foretrækker det.
C++ og C# har mulighed for explicit at ændre fra call by value
til call by reference. C# lidt pænere end C++.
For min skyld kunne man godt tilføjde det til Java.
Men det er ret sjældent at det er en pæn løsning.
#19
Hvad snakker du om.
Det er da helt elementær Java viden at class names er implicit
prefixed med classloader.
Jeg har en helt klar forventning om at default for en app server
er en classloader per ear.
Og saa virker det som det skal.
NB: bruger man JBoss skal man angive det eksplicit, fordi de
har valgt at bruge en classloader default. Det har de også
fået mange klø for.
Det er iøvrigt præcis det samme med ASP.NET - den sørger via
brug af appdomains for at apps er uafhængige af hinanden.
Næppe overraskende at et SUN arrangement snakker om SUN produkter
og ikke om IBM eller Oracle produkter.
Hvis det var et IBM arrangement så ville der nok blive snakket
meget WAS og Eclipse.
"Det opfører sig vil som man forventer at det skal - nemlig at forskellige apps er uafhængige af hinanden."
Øhh, jeg tror du får dig en overaskelse hvis du prøver det.
Hvad snakker du om.
Det er da helt elementær Java viden at class names er implicit
prefixed med classloader.
Jeg har en helt klar forventning om at default for en app server
er en classloader per ear.
Og saa virker det som det skal.
NB: bruger man JBoss skal man angive det eksplicit, fordi de
har valgt at bruge en classloader default. Det har de også
fået mange klø for.
Det er iøvrigt præcis det samme med ASP.NET - den sørger via
brug af appdomains for at apps er uafhængige af hinanden.
Ah det ved jeg nu ikke, men du kan jo tage med til JavaOne i næste uge og se selv hvor meget der handler omkring NetBeans/GlassFish sammenlignet med Eclipse/Orion/WebSphere. ;)
Næppe overraskende at et SUN arrangement snakker om SUN produkter
og ikke om IBM eller Oracle produkter.
Hvis det var et IBM arrangement så ville der nok blive snakket
meget WAS og Eclipse.
#19
Det er iøvrigt nemt at undersøge hvilke skills der efterspørges
på job markedet.
En søgning på dice.com siger:
WAS - 2470 (WebSphere er andet end app server og giver 4299 hits)
WebLogic - 2655
JBoss - 1059
Glassfish - 4
Eclipse - 1185
JBuilder - 124
IntelliJ - 62
NetBeans - 47
Det er iøvrigt nemt at undersøge hvilke skills der efterspørges
på job markedet.
En søgning på dice.com siger:
WAS - 2470 (WebSphere er andet end app server og giver 4299 hits)
WebLogic - 2655
JBoss - 1059
Glassfish - 4
Eclipse - 1185
JBuilder - 124
IntelliJ - 62
NetBeans - 47
#19
Der er ingen tvivl om at C# bygger ovenpå Java og sproget har
en del forbedringer.
Personligt er jeg meget glad for unsigned data typer,
decimal data type og dllimport - mens jeg ikke kan lide
properties og struct - og er rimelig neutral overfor operator
overloading (det er ufatteligt sjældent at man har brug for det,
men har man brug for det så gør det godt nok koden meget kønnere).
Men spørg 12 programmører om det samme og du får 13 forskellige
svar.
Der er ingen tvivl om at C# bygger ovenpå Java og sproget har
en del forbedringer.
Personligt er jeg meget glad for unsigned data typer,
decimal data type og dllimport - mens jeg ikke kan lide
properties og struct - og er rimelig neutral overfor operator
overloading (det er ufatteligt sjældent at man har brug for det,
men har man brug for det så gør det godt nok koden meget kønnere).
Men spørg 12 programmører om det samme og du får 13 forskellige
svar.
Min pointe er at der er kolosal forvirring omkring Java bruger pass-by-value, pass-by-reference eller diverse hybrider - og der har man total frihed i C#.
Aarhus universitet brillierer f.eks. med diaset "Simple typer = handly by value, klasse typer = handle by reference", når sandheden er at ALT er references og bliver passed by value:
http://javadude.com/articles/passbyvalue.htm
Problemet er igen at man tvinges til at lave DTO'er/beans for blot at kunne sende mere end ét resultat tilbage. Det betyder også at det er umuligt at skrive en swap(...) funktion i Java - pudsigt for der findes både Java byte kode og x86 assembler instruktion til netop dette formål.
Forkert. JPA er et persistens framework der typisk bruger TopLink i sit ORM lag. Og Linq er først og fremmest til at query DBMS'er men er bare så generelt (og i kraft af at det er trukket ind i selve C# sproget) at det også kan bruges til reflection, registreringsdatabasen, XML, filsystem osv.
Aarhus universitet brillierer f.eks. med diaset "Simple typer = handly by value, klasse typer = handle by reference", når sandheden er at ALT er references og bliver passed by value:
http://javadude.com/articles/passbyvalue.htm
Problemet er igen at man tvinges til at lave DTO'er/beans for blot at kunne sende mere end ét resultat tilbage. Det betyder også at det er umuligt at skrive en swap(...) funktion i Java - pudsigt for der findes både Java byte kode og x86 assembler instruktion til netop dette formål.
EJB 3 er et objekt persisterings framework. LINQ er til queries i in-memory data strukturer.
Forkert. JPA er et persistens framework der typisk bruger TopLink i sit ORM lag. Og Linq er først og fremmest til at query DBMS'er men er bare så generelt (og i kraft af at det er trukket ind i selve C# sproget) at det også kan bruges til reflection, registreringsdatabasen, XML, filsystem osv.
Min pointe er at der er kolosal forvirring omkring Java bruger pass-by-value, pass-by-referenceDet kan jeg ikke helt forstå at du siger. Det er fuldstændig veldefineret hvad der sker i java. Du kan altid opfatte en formel parameter som en lokal variabel når du koder, så er den ikke længere...
pudsigt for der findes både Java byte kode og x86 assembler instruktion til netop dette formål.Det er ikke korrekt! Javas swap bytecode swapper de to øverste elementer på stakken, hvilket er noget ganske andet, men det er nyttigt til implementationer af eksempelvis ++ og -- statements...
sandheden er at ALT er referencesDet er ikke korrekt. Specifikt er primitive typer ikke references...
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.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund