mboost-dp1
Flickr - Johnnie W@lker
Windcape (33) skrev:
Der er også flere grunde end hvad du kan forestille dig. Moderne arbejdsgange gør det hurtigere for nye medarbejdere at tilpasse sig, og være produktive.
Og som det er i dag, tager det over et år før at nye medarbejdere kan være produktive i bankernes regi. Det kan sagtens forbedres.
Tænk dig om. Grunden til at bankerne hyrer os i første omgang, er for at vi kan komme med input og viden til forbedringer af arbejdsgangene. Ikke for at vi bare spiller underdanig, og acceptere alting uden kritik.
Så du har faktisk et medansvar for at få indført mere moderne arbejdsgange på din arbejdsplads.
En stor bank har folk som er fuldtidsansat til at kigge på arbejdsprocesser og optimere dem.
Forhåbentligt lytter de til Cobol/Java/C#/whatever udvikleren hvis han har en god ide.
Men sandsynligheden for at eksperterne indenfor området allerede har overvejet ideen er jo nok stor.
Hvis der står en business architect/business developer og kigger dig over skulderen og foreslår dig at bruge en while løkke i.s.f. en for løkke vil du vel også lytte til ham, men sandsynligheden for at du vil give ham ret er nok lav.
Windcape (50) skrev:Den warning opstår på samtlige Java klasser, ligegyldig om det er meningen de skal serialiseres eller ej!
Ikke korrekt.
Den warning opstår kun i klasser som implementerer Serializable (direkte eller inddirekte).
En klasse som implementerer Serializable men som man ikke mener skal serialiseres er absolut en warning værd.
Windcape (50) skrev:Java har også andet idioti (typisk i forbindelse med deres elendige implementering af generics), så jeg har svært ved at se hvordan et stort projekt kan være warning fri.
Det kan det godt.
Ved brug af genrics skal man nogen gange tænke sig lidt om.
Der er enkelte tilfælde hvor det er nødvendigt at lave en unsafe cast, men så kan man suppresse warning på den assignment (og endelig ikke på mere).
myplacedk (35) skrev:Windcape (33) skrev:Performance, færre fejl, bedre concurrency, og mere moderne arbejdsgange?
Performance kan vi forbedre på langt bedre måde, end at opgradere Java. Færre fejl, ja, men dælme ikke mange. Jeg tror jeg er stødt på under 1 fejl om året, som ville have været løst nemmere eller undgået helt med en nyere Java. (Og jeg hjælper mange med at løse besværlige fejl.) Concurrency? Nej. Mere moderne arbejdsgange? Nej.
Performance af JVM vil blive forbedret mærkbart ved 1.4.2->1.5 for både SUN, IBM og BEA JVM. Og det er en forbedring uafhængig af andre forbedringer, så man kan både lave de andre forbedringer og få hurtigere JVM.
Der er generelt meget få fejl i Java. Og jeg mener ikke at nyere versioner generelt er mere fejlfri end ældre versioner.
I den typiske Java EE app sørger container og frameworks for det meste concurrency håndtering. Men skriver man multithreaded Java SE apps, så er der mange godbidder i java.util.concurrency pakken.
En opgardering af Java har åbenlyst ingen effekt på arbejdsgangene.
#54
????
Hvis der er nogen arbejdsgange som kan forbedres, så skal de forbedres.
Men at opgradere Java resulteter ikke i nogen ændrede arbejdsgange.
Og jeg er skeptisk overfor om forskellene mellem versionerne vil gøre en speciel stor forskel med hensyn til implementering af nye arbejdsgange.
????
Hvis der er nogen arbejdsgange som kan forbedres, så skal de forbedres.
Men at opgradere Java resulteter ikke i nogen ændrede arbejdsgange.
Og jeg er skeptisk overfor om forskellene mellem versionerne vil gøre en speciel stor forskel med hensyn til implementering af nye arbejdsgange.
#57
Ja, men siden vi skal vælge teknologi ud fra et forretnings-perspektiv, så giver det jo aldrig mening at opgradere en version af Java, hvis der er ikke er penge i det.
Så hvis ens medarbejdere ikke bliver mere effektive af en ny version af Java, må denne nye version jo netop være fuldstændig nyttesløs, ikke?
Der er ligesom argumentet for at blive ved med at bruge COBOL. Chefen kan ikke se pointen in at skifte teknologien ud, så længe man bare kan videreuddanne folk.
Ja, men siden vi skal vælge teknologi ud fra et forretnings-perspektiv, så giver det jo aldrig mening at opgradere en version af Java, hvis der er ikke er penge i det.
Så hvis ens medarbejdere ikke bliver mere effektive af en ny version af Java, må denne nye version jo netop være fuldstændig nyttesløs, ikke?
Der er ligesom argumentet for at blive ved med at bruge COBOL. Chefen kan ikke se pointen in at skifte teknologien ud, så længe man bare kan videreuddanne folk.
Windcape (58) skrev:Så hvis ens medarbejdere ikke bliver mere effektive af en ny version af Java, må denne nye version jo netop være fuldstændig nyttesløs, ikke?
Der er ligesom argumentet for at blive ved med at bruge COBOL. Chefen kan ikke se pointen in at skifte teknologien ud, så længe man bare kan videreuddanne folk.
Vi har en stor flok ganske dygtige/professionelle mennesker til at overveje den slags. Nogle gange får en overvejelse projekt-status, og der bliver brugt en del mandemåneder på det, måske laves der en proof-of-concept (eller det forsøges).
Konklusionen er klar: Vi holder os til COBOL, og opgraderingen er Java fra 1.4 haster ikke.
Det eneste der mangler er, at du enten indser at sådan er det, eller accepterer at nogen med bedre forstand på det end dig har indset det, og forstår det.
arne_v (41) skrev:Men givet at:
- det meste af Cobol udvikling sker i firmaer som har kørt Cobol i mange år
- Cobol udviklere har en relativ høj gennemsnitsalder og skifter mindre job end mange andre kategorier
så er det rimeligt at antage at andelen af Cobol udviklere er markant større end andelen af Cobol jobopslag.
På den anden side er der ret få COBOL-udviklere, hvilket gør det modsatte lige så rimeligt at antage.
Jeg har ingen tal på det, jeg har kun ét fact: Vi ansatte alle dem vi kunne finde, og det var ikke nok.
arne_v (42) skrev:1.4.2 til 1.5 kan godt give lidt arbejde, hvis det skal gøres ordentligt.
Vores største arbejde er at rette byggesystemet til, lave standarder for hvordan de nye features skal bruges og at uddanne udviklerne.
Hvad vi gør mht. warnings ved collections ved jeg ikke endnu. Jeg skal ikke udelukke at vi simpelt hen slår dem fra i første omgang.
Windcape (43) skrev:Hvor tit vil man det? Java har så mange latterlige krav for at der ikke er warnings.
Grundlæggende kræver det bare at man koder ordentligt. En udtalelse som din bekymrer mig meget, hvis det kommer fra nogen som udvikler hos os.
Skulle der være nogle warnings som ikke er relevante i dit projekt, så slå dem fra. Hvis en selvudnævnt ekspert som dig ikke har overvejet at det er en mulighed, så siger det mere om dig end om Java.
Windcape (50) skrev:Den warning opstår på samtlige Java klasser, ligegyldig om det er meningen de skal serialiseres eller ej!
Nej.
Windcape (50) skrev:Det er fjollet og unødvendigt, og burde håndteres af kompileren.
Det sker også, hvis man ikke selv angiver ID'en. Men man kan lave et bedre system ved at styre det manuelt. Spørgsmålet er kun, om det er relevant. Hvis ikke, slår man den warning fra.
Windcape (50) skrev:Java har også andet idioti
Overvej lige om det ikke er din holdning til at hvad du ikke forstår. Den slags er designet af grupper af folk som er langt klogere end end dig, så der er gode chancer for at der er en god grund.
I øvrigt har alle systemer sine ulemper, også dem du er fan af.
Jeg er virkeligt forbløffet over hvordan man kan hade java så meget, og elske c# så meget.
De er 90% ens, og jeg tænker simpelthen ikke over om jeg arbejder i det ene eller det andet.
De er 90% ens, og jeg tænker simpelthen ikke over om jeg arbejder i det ene eller det andet.
Java's generics er ikke særlig velimplementeret, det burde du vide.myplacedk (65) skrev:Den slags er designet af grupper af folk som er langt klogere end end dig, så der er gode chancer for at der er en god grund.
Problemet er vel bare at du ikke selv undersøger andre teknologier, og derfor ikke ved bedre.
Du skulle overveje at læse C#, det ville give dig et rigtig fornuftig perspektiv på Java. Samt et funktionelt sprog mens du er i gang.
Windcape (67) skrev:Java's generics er ikke særlig velimplementeret, det burde du vide.
Det var en kommentar til Java generelt, ikke generics. Og liiige bagefter fortæller jeg dig så, at jeg er opmærksom på at det ikke betyder Java er perfekt.
Jeg HAR skam overvejet at lære om .net og c#. Konklusionen er at selv om det kunne give fordele, er der andre måder jeg kan blive klogere på området på, som vil give mere i forhold til tidsforbruget på.
Lige præcist c# og .net kan jeg ikke se nogen grund til at studere, hvis jeg ikke skal bruge det. Og det skal jeg ikke, og jeg har ikke lyst til det.
Men da generics alligevel ikke er bagudkompatible, hvorfor så ikke implementere dem ligesom i C#?arne_v (69) skrev:Givet tidslinien, så var der ikke fornuftige alternativer.
SUN har valgt den lette genvej, frem for at udbygge sproget ordenligt. Type Erasures vil aldrig stoppe med at være et problem i Java.
Og hvis de også ville fjerne checked exceptions, nu hvor vi er i gang. Magen til hovedepine...
Windcape (70) skrev:Men da generics alligevel ikke er bagudkompatible, hvorfor så ikke implementere dem ligesom i C#?
Fordi Java fik generics efter 8 år og der var skrevet så meget kode der brugte collections at nogle nye klasser ikke ville være blevet brugt ret meget i mange mange år.
C# fik generics efter 3 år og havde ikke nær så meget eksistende kode. De kunne meget bedre sige til folk at de skulle skifte klasser.
Windcape (70) skrev:Og hvis de også ville fjerne checked exceptions, nu hvor vi er i gang. Magen til hovedepine...
Hvis man er ligeglad med robusthed i din kode, så er Java ikke et godt valg.
Hvis man er glad for robusthed, så er man også glad for at Java sproget giver mulighed for at tvinge kalder af et library til at tage stilling til exceptions.
Men er det virkelig en undskyldning for ikke at gøre det ordenligt?arne_v (71) skrev:Fordi Java fik generics efter 8 år og der var skrevet så meget kode der brugte collections at nogle nye klasser ikke ville være blevet brugt ret meget i mange mange år.
Generics var en del af deres roadmap fra starten af. Jeg ved ikke helt med .NET 1.1, det virkede altid som en "beta" version på mig. Jeg var ikke særlig imponeret. Først da .NET 2.0 udkom synes jeg det var værd at kigge på.arne_v (71) skrev:C# fik generics efter 3 år og havde ikke nær så meget eksistende kode. De kunne meget bedre sige til folk at de skulle skifte klasser.
Hejlsberg har også sagt at generics var tænkt ind fra starten af, men de nåede det bare ikke til 1.1
Problemet er bare at robusthed ikke altid er en god ting. I forbindelse med webudvikling skader det mere end det gavner.arne_v (72) skrev:Hvis man er ligeglad med robusthed i din kode, så er Java ikke et godt valg.
Hvis man er glad for robusthed, så er man også glad for at Java sproget giver mulighed for at tvinge kalder af et library til at tage stilling til exceptions.
J2EE er dybt præget af problemerne med checked exceptions, og det fjerner alt alt for meget af den fleksibilitet man ellers ville have.
Derudover hele problematikken ved exceptions i andre threads. Det er nok her man ser flest catch(Exception e) {}.
Windcape (73) skrev:Men er det virkelig en undskyldning for ikke at gøre det ordenligt?
De valgte at gøre det ordentligt.
Når man har en stor eksisterende kode base er det bedre at få 90% af fordelene på en kompatibel måde der gør at det bliver brugt end at få 100% af fordelene på en ikke-kompatibel måde der gør gør at det ikke bliver brugt.
Windcape (73) skrev:Problemet er bare at robusthed ikke altid er en god ting. I forbindelse med webudvikling skader det mere end det gavner.
Jeg tror altså at de fleste der laver web udvikling i Java sætter stor pris på robusthed.
Windcape (73) skrev:J2EE er dybt præget af problemerne med checked exceptions, og det fjerner alt alt for meget af den fleksibilitet man ellers ville have.
Det forstår jeg så ikke helt.
Det giver da absolut mening at C håndterer exceptions i M i web delen.
Og exception håndtering er helt essentiel i EJB's.
Windcape (73) skrev:Derudover hele problematikken ved exceptions i andre threads. Det er nok her man ser flest catch(Exception e) {}.
Det er forhåbentligt en konstruktion som du aldrig ser.
Windcape (70) skrev:Og hvis de også ville fjerne checked exceptions, nu hvor vi er i gang. Magen til hovedepine...
Wow. Jeg er virkelig chokeret...
myplacedk (64) skrev:Ja, for eksempel den. I vores tilfælde giver det mere bøvl at holde styr på den, end hvad det giver ikke at bruge den. Slå den warning fra, problem løst.
Serialization skal altså ikke tages for nemt.
Joshua Bloch valgte at bruge et helt kapitel på dette emne i hans kendte bog.
Men mange af os os der har arbejdet med mange af de andre teknologier, sætter højere pris på fleksibilitet.arne_v (75) skrev:Jeg tror altså at de fleste der laver web udvikling i Java sætter stor pris på robusthed.
Hvis det giver mening, så kan programmøren håndtere det selv. Det fungere fint i alle andre sprog end Java.arne_v (75) skrev:Det giver da absolut mening at C håndterer exceptions i M i web delen.
Jeg vil hellere have at f.eks. Exceptions i JEE blev chainet helt op til applikations serveren, og håndteret / filteret af den, frem for at det skal klares på applikationsniveau.
@Test
public void myUnitTestMethod() {
try {
folder.open(Folder.READ_ONLY);
...
}
catch (Exception e) {
Assert.fail("An exception was caught: " + e.getMessage());
}
finally {
try {
if (folder != null && folder.isOpen()) {
folder.close(false);
}
} catch(Exception e) {
// checked exceptions sucks
}
}
}
Alternativet er at man kan ændre signaturen til
public void myUnitTestMethod() throws Exception {Men resultatet er det samme som hvis der ikke var checked exceptions, bare med et latterligt overload af unødvendig kode.
Robut? Ikke mere end alt andet. Det er kun et spørgsmål om at tvinge programmøren til at skrive træls kode. Med alt ikke test kode ender man alligevel med at logge sine exceptions, fordi man ikke kan komme pænt af med dem.
Ufleksibelt og tungt design. Og utrolig træls at arbejde med.
Windcape (78) skrev:Hvis det giver mening, så kan programmøren håndtere det selv. Det fungere fint i alle andre sprog end Java.
Det fungerer.
Jeg ved ikke om man kan sige fungerer fint.
Det er vist et ret almindeligt problem ikke at vide hvilke exceptions der kan opstå i en given situation, fordi dokumentationen af dem mangler.
Jeg er stadigvæk ikke enig i at checked-exceptions er lig med robusthed.arne_v (80) skrev:Hvad man ikke prioriterer robusthed, så er Java næppe det rette valg.
Vil du mene at brugen af "var" i C# gør sproget mindre robust?
Det handler om hvor man vil ligge ansvaret. Hvis man ønsker et mere ansvarsfuldt sprog så er Java måske et muligt valg.
Men hvis man ønsker alle mulige andre ting, så er Java nok et dårlig valg. (Rent sprogmæssigt, frameworks og platform-support er en anden diskussion)
Der er sikkert heller ikke mange som vil mene at PHP er robust, men alligevel bruges det til at drive nogle af de største sider i verden, med større succes end deres tilsvarende i Java EE.
void myMethod() throws Exception;arne_v (81) skrev:Det er vist et ret almindeligt problem ikke at vide hvilke exceptions der kan opstå i en given situation, fordi dokumentationen af dem mangler.
Jeps... Hvor meget ved vi så nu? ;)
Windcape (78) skrev:Jeg vil hellere have at f.eks. Exceptions i JEE blev chainet helt op til applikations serveren, og håndteret / filteret af den, frem for at det skal klares på applikationsniveau.
Windcape (79) skrev:Robut? Ikke mere end alt andet. Det er kun et spørgsmål om at tvinge programmøren til at skrive træls kode. Med alt ikke test kode ender man alligevel med at logge sine exceptions, fordi man ikke kan komme pænt af med dem.
Hvis man altid aborterer applikation eller request behandling i tilfælde af en exception, så har man ikke meget at bruge checked exceptions til.
Men det er nu forholdsvis almindeligt at gøre mere end det.
Windcape (79) skrev:
...
try {
...
}
catch (Exception e) {
...
}
Windcape (79) skrev:public void myUnitTestMethod() throws Exception {
Windcape (82) skrev:void myMethod() throws Exception;
Jeps... Hvor meget ved vi så nu? ;)
At du ikke har lært at bruge Java exceptions korrekt.
Man hverken throw, throws eller catch Exception i normal Java kode.
Det er faktisk rent normalt i GWT, da alle Exceptions i ens RPC services skal rekastes.arne_v (84) skrev:Man hverken throw, throws eller catch Exception i normal Java kode.
private T myMethod()
throws SerializationException {
try {
...
} catch (Exception e) {
throw new SerializationException(e);
}
}
At have checke for mere end een type for samme handling virker meningsløst. (Om det så er recast eller asserts)
At man typisk ikke vil lave "throws Exception" er jeg enig med dig i, og ikke kode jeg personligt ville skrive. Men sproget begrænser dig ikke i at være doven! Derfor er hele pointen med at tvinge folk jo nyttesløst i første omgang.
P.S. Vi har faktisk ikke lært at bruge exceptions "korrekt". Jeg kender de første 7-8 stykker fra mit hold som nemt kunne finde på "throws Exception".
Windcape (82) skrev:Jeg er stadigvæk ikke enig i at checked-exceptions er lig med robusthed.
Det tvinger kalder til at tage stilling til exceptions. Det er godt for robustheden.
Windcape (82) skrev:Vil du mene at brugen af "var" i C# gør sproget mindre robust?
Nej.
dynamic gør sproget mindre robust.
var har ikke nogen betydning for robustheden (det kan dog gøre det lidt sværere at læse koden).
Windcape (82) skrev:Det handler om hvor man vil ligge ansvaret. Hvis man ønsker et mere ansvarsfuldt sprog så er Java måske et muligt valg.
På godt og på ondt er Java meget præget af erfaringerne med C++.
Det er et meget bevidst valg at sproget ikke skulle give programmøren de samme muligheder for at skyde sig selv i foden som C++.
Eller nemmere ;)arne_v (86) skrev:det kan dog gøre det lidt sværere at læse koden
XmlLoadResultReader<ListLoadResult<ModelData>> reader
= new XmlLoadResultReader<ListLoadResult<ModelData>>(type);
var reader = new XmlLoadResultReader<ListLoadResult<ModelData>>(type);
Er/var problemet med C++ ikke nærmere at folk slet ikke brugte exceptions i den grad de burde. Jeg ser ihvertfald utrolig lidt C++ kode som faktisk bruger OO kode, og tilhørende exceptions.arne_v (86) skrev:Det er et meget bevidst valg at sproget ikke skulle give programmøren de samme muligheder for at skyde sig selv i foden som C++.
Jeg kan godt lide en balance, C# rammer den ret godt.
Og netop dynamics er jo tiltænkt der hvor man skal arbejde sammen med loosely typed sprog. Hvilket jeg synes det passer rigtig godt til.
Måske skal jeg ikke kunne skyde mig selv i foden, men vil jeg have lov at sigte på den! Og ikke som Java, tvunget til kun at holde pistolen i een retning.
Windcape (82) skrev:Der er sikkert heller ikke mange som vil mene at PHP er robust, men alligevel bruges det til at drive nogle af de største sider i verden, med større succes end deres tilsvarende i Java EE.
PHP bruges af rigtigt mange store web sites.
Det har en kombination af lav pris, hurtig udvikling, masser af udviklere som er attraktiv.
Men stor trafik volumen er ikke det samme som høje krav til robusthed.
FaceBook har vel 10000 gange så meget trafik som myplacedk's banker. Men der bliver nok alligevel mere ballade hvis der går kage i en penge overførsel i en af hans banker end at en FB profil ender op halvt opdateret.
Windcape (85) skrev:Det er faktisk rent normalt i GWT, da alle Exceptions i ens RPC services skal rekastes.arne_v (84) skrev:Man hverken throw, throws eller catch Exception i normal Java kode.
private T myMethod()
throws SerializationException {
try {
...
} catch (Exception e) {
throw new SerializationException(e);
}
}
At have checke for mere end een type for samme handling virker meningsløst. (Om det så er recast eller asserts)
Jeg synes ikke, at det der er god kode.
Det er helt normalt at catche og rethrowe en API specific exception. Det er en nødvendigt for at lave god encapsulation af implementationen.
Men det er stadigvæk ikke godt at catche alle Exception. Catch de checked exceptions du ved kan komme. Og catch unchecked exceptions du har brug for at gøre noget ved (ofte: ingen).
Windcape (85) skrev:P.S. Vi har faktisk ikke lært at bruge exceptions "korrekt". Jeg kender de første 7-8 stykker fra mit hold som nemt kunne finde på "throws Exception".
En god policy for brug af exceptions er faktisk ikke nemt. Det er hundesvært.
Men det er også vigtigt for robusthed og vedligeholde af applikationen.
Selv dem på dit hold vil sikkert efter en 5-10 års erfaring med Java have dannet sig nogle meninger om hvordan exceptions bør håndteres.
Windcape (87) skrev:Eller nemmere ;)XmlLoadResultReader<ListLoadResult<ModelData>> reader
= new XmlLoadResultReader<ListLoadResult<ModelData>>(type);var reader = new XmlLoadResultReader<ListLoadResult<ModelData>>(type);
I det eksempel gør det ikke nogen forskel for læsbarheden.
Det er værre med:
XmlLoadResultReader<ListLoadResult<ModelData>> reader
= Foobar();
var reader = Foobar;
Hvor det er svært at læse hvad reader er.
Windcape (89) skrev:Det er vist et dårlig argument når størstedelen af pengene i Danmark håndteres af PL/1 og COBOL.
Det er normalt PL/I eller Cobol som kører de natlige jobs i bankerne.
Men det betyder altså ikke at det er ligegyldigt om eventuelle Java frontends (eller frontends i .NET eller en hvilket som helst anden teknologi) er robuste eller ej.
Hvis ikke de rigtige data er blevet gemt så bliver de natlige jobs til GIGO.
Ah, men lige netop exceptions skal man ikke bruge til at kontrollere ens flow med.arne_v (93) skrev:Men det betyder altså ikke at det er ligegyldigt om eventuelle Java frontends
Checked exceptions hjælper til at sikre at exceptions bliver håndteret, ikke at de bliver håndteret korrekt.
Og i min erfaring er det ikke nødvendigvis positivt. Nærmere det modsatte. (*Specielt* når kode kaster unødvendige exceptions, halvdelen af tiden.)
Windcape (94) skrev:Ah, men lige netop exceptions skal man ikke bruge til at kontrollere ens flow med.
Nej. Men derfor kan de godt bridrage til robusthed.
Windcape (94) skrev:Checked exceptions hjælper til at sikre at exceptions bliver håndteret, ikke at de bliver håndteret korrekt.
Helt korrekt.
Checked exceptions er ikke nogen mirakel løsning.
Men de kan være en et lille skub i den rigtige retning.
Windcape (94) skrev:Og i min erfaring er det ikke nødvendigvis positivt. Nærmere det modsatte.
Der er en del som ikke er glade for checked exceptions.
Windcape (87) skrev:Er/var problemet med C++ ikke nærmere at folk slet ikke brugte exceptions i den grad de burde. Jeg ser ihvertfald utrolig lidt C++ kode som faktisk bruger OO kode, og tilhørende exceptions.
Exceptions kom først til i C++ ca. 15 år efter at sproget blev opfundet.
Derfor er der en del ældre C++ kode og en del C++ programmører som ikke bruger exceptions.
Windcape (87) skrev:
Jeg kan godt lide en balance, C# rammer den ret godt.
Og netop dynamics er jo tiltænkt der hvor man skal arbejde sammen med loosely typed sprog. Hvilket jeg synes det passer rigtig godt til.
Måske skal jeg ikke kunne skyde mig selv i foden, men vil jeg have lov at sigte på den! Og ikke som Java, tvunget til kun at holde pistolen i een retning.
C# har nogle features som unsafe blokke med pointers og dynamic som giver mulighed for henholdsvis pointer fræs og duck typing.
Men C# har en lidt anden baggrund end Java. C# er udover C++ også præget af Delphi og Java.
Nogen ting blev designet anderledes.
Skal man arbejde meget med COM er man nok ret glad for dynamic.
+ optional parameters. Og glad er en underdrivelse!-)arne_v (97) skrev:Skal man arbejde meget med COM er man nok ret glad for dynamic.
Formålet er nok anderledes, men P/Invoke som erstatning for JNI er nu også *rart*
Jeg har arbejdet min del med JNI, it ain't pretty.
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