Novell vil putte .Net på Android-telefoner

Novell vil gøre det muligt at afvikle open source-udgaven af .Net, Mono, på Android-enheder. Det frister dog ikke dansk .Net-mobiludvikler, som hellere vil bruge Java, hvis det skulle være.

I forbindelse med Microsoft Mix-konferencen, der afholdes i disse dage i Las Vegas, har Novell annonceret, at firmaet vil udsende en udgave af Mono til Android-styresystemet. Mono er en open source-udgave af Microsofts .Net-miljø. Det skriver SDTimes.

Mobiludvikler Martin Bahn Hansen fra Commentor, som udvikler mobilapplikationer på Microsofts platform, føler sig dog ikke umiddelbart tiltrukket af muligheden for at portere applikationerne til Novells Android-kørselsmiljø.

»For så vidt kan det være spændende, men Mono-projektet er rimeligt langt bag efter .Net i versionsnumre, som det ser ud lige nu. Android kører hovedsageligt Java med Eclipse som udviklingsværktøj, så i mobiløjemed tror jeg ikke det bliver interessant. Spørgsmålet er, om udviklere vil skifte fra Java til .Net, især nu, hvor Mono ikke er så langt fremme, men jo mere konkurrence, der kommer, jo bedre er det, så det er i hvert fald spændende, at de har meldt det ud.«

Heller ikke udsigten til nemmere at kunne portere .Net-baserede løsninger til Android gør det store indtryk.

»Jeg vil hellere skrive applikationen forfra i Java, fordi der er ikke den store forskel mellem C# og Java. Jeg vil hellere gå efter et native sprog, for typisk har du bedre support og kan typisk mange flere ting. Hvis jeg skulle hoppe over på Android, ville jeg gå over til Java.«

Det er Novells strategi at stille .Net i Mono-aftapning til rådighed på alle de platforme, som udviklerne ønsker, siger firmaets Mono-chef Joseph Hill. Udover Android stiller Novell også Mono til rådighed på iPhone, ved at konvertere .Net-applikationer til Objective-C, som er det eneste Apple tillader på platformen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (34)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anders Sørensen

Mono på iPhone, ved at konvertere .Net-applikationer til Objective-C

Tror flere vil se frem til ovenstående. Personligt synes jeg at det er ret kranglet at kode til iphonen.

  • 0
  • 0
Casper Bang

Enig med Jesper. Da jeg spurgte Miguel de Icaza om emnet for nogle måneder siden, var svaret at de havde noget i støbeskeen men intet at annoncere endnu.

Ang. Martin Bahn Hansen's kommentarer:

"Mono-projektet er rimeligt langt bag efter .Net i versionsnumre"

Lyder ikke til at han er bekendt med at Mono IKKE følger .NET's versionsnr. Mono er næsten 100% kompatibel med .NET 3.5.

"Android kører hovedsageligt Java med Eclipse som udviklingsværktøj, så i mobiløjemed tror jeg ikke det bliver interessant"

What? Det er ikke interesant at .NET programmører kan installere en plugin i Visual Studio og skrive programmer til Android uden at skulle installere og sætte sig ind i Eclipse og Java?

  • 0
  • 0
Martin Bahn Hansen

Lyder ikke til at han er bekendt med at Mono IKKE følger .NET's versionsnr.

Man kan altid blive citeret forkert. Jeg ved godt at versionsnumrene på ingen måde er ens. Det jeg mente var funktionaliteten.

Mono er næsten 100% kompatibel med .NET 3.5.

Og så ikke helt alligevel. Jeg vil give dig ret i at C# 1.0-3.0 er næsten 100% implementeret, men WinFX pakken er ikke eksisterende i Mono.

What? Det er ikke interesant at .NET programmører kan installere en plugin i Visual Studio og skrive programmer til Android uden at skulle installere og sætte sig ind i Eclipse og Java?

Jeg synes ikke det er interessant -kun, hvis native API'erne bliver tilgængelige. Hvis man sidder som mobil udvikler, så bruger man tit native metoder for at få det hele til at køre bedre samt få mere funktionalitet.

Derfor vil jeg hellere bruge Eclipse med Java, men vil da helt klart savne Visual Studio.

  • 0
  • 0
Casper Bang

"WinFX pakken er ikke eksisterende i Mono."

Det får du nok heller ikke lige brug for på en mobil. Selv Windows Mobile 7 når den kommer senere på året, vil blive baseret på Silverlight - og altså et væsentligt mindre subset end f.eks. Mono.

-kun, hvis native API'erne bliver tilgængelige. Hvis man sidder som mobil udvikler, så bruger man tit native metoder for at få det hele til at køre bedre samt få mere funktionalitet.

Nu er det jo så heldigvis 10 gange nemmere at interface til den native platform i .NET (DllImport) end f.eks. Java (JNI). Og Java SDK'et samt runtime på Android er jo i sig selv blot en fortolker, til native ting leverer Google et NDK.

Det virkelig interesante ved Mono på Android er faktisk at, modsat MonoTouch, så vil MonoDroid ikke være begrænset til static cross-compilation men de vil være i stand til at placere et standard Mono runtime komplet med AOT/JIT, compacting GC osv.

Det betyder samtidig også at der er åbnet op for at skrive i alle mulige andre sprog så som Python, Ruby, Boo etc.

Derfor vil jeg hellere bruge Eclipse med Java, men vil da helt klart savne Visual Studio.

Så er nyheden her med andre ord uinteresant for dig. Jeg ville klart foretrække C#, som jo i alle henseende er et superset af Java. Ved standard Android udvikling har du ingen properties, ingen events, ingen enums, ingen decimal literals, ingen delegates/closures/lambdas, ingen LINQ, ingen extension methods, begrænset type inference, begrænset generics, begrænset dynamic dispatch osv.

  • 0
  • 0
Martin Bahn Hansen

Nej, WinFx er ikke tilgængelig på Windows Mobile, men omvendt vil jeg så heller ikke bruge Mono til udvikling hertil.
MonoTouch og MonoDroid ser interessante ud og vil være en god hjælp til at komme igang på en platform. Jeg vil dog stadigvæk bruge de tools der hører til platformen -men det er vist et religionsspørgsmål :-)

Om det er nemmere at interface til en native platform i .NET kontra Java er jo kun en udfordring for udvikleren. Jeg går efter den bedste oplevelse for brugeren, og ikke hvad der er nemmest for mig.

  • 0
  • 0
Kasper Sørensen

Med frygt for at påbegynde den evigt vedvarende religionskrig vedr. mit sprog vs. dit sprog vil jeg gerne knytte et par kommentarer til:

C#, som jo i alle henseende er et superset af Java.

Det er dels ikke sandt generelt, dels er det også usandt for enums, som du nævner. Enums er faktisk langt stærkere i Java end i C# (man kunne fristes til at sige at der ikke findes ægte enums i C#).

Kig evt. på denne udmærkede rapport om de forskellige sprog: http://www.25hoursaday.com/CsharpVsJava.html ... Der er også en liste over ting som findes i Java, der ikke findes i C#...

  • 0
  • 0
Kasper Sørensen

Ah ja det kan sagtens være at jeg tager fejl angående Android SDK'et, da jeg ikke kender det særligt dybdegående. Men hvis en .NET/C# runtime skulle findes på Android ville den garanteret være ligeledes begrænset.

Dét som anslår min skeptisme er dit brug af ordet "superset" som ganske entydigt siger at alt hvad der findes i Java også findes i C#, og det er ikke tilfældet. Mange af tingene kan garanteret undværes fordi man har et andet sæt af best practices at arbejde ud fra i C#.

Hvis jeg skal nævne en ting som jeg personligt tror bliver en væsentlig ting for Java i de næste par år, så kunne jeg nævne meta-annotationer (dvs. annotationer på annotationer). Java EE 6 indeholder således mange nye features hvor man kan lave sine egne annotationer (med meta-annotationer) og benytte dem til at generalisere og kvalificere ifht. interception, dependency injection, objekt-valideringsregler, observer/observable markering (dvs. et ægte løst koblet event system, uden det bøvl som ellers altid findes, både i C# og "old school" Java) og mere.

Du har helt ret i at enums i Java også har begrænsninger, men sammenlignet med enums i C# må man da sige at de kan meget. Som Java-udvikler er det primært kun LINQ som jeg virkelig misunder C#-udviklerne. Omvendt ser det ud til at JPA 2 har en fornuftig løsning på type-stærke queries baseret på metamodel-klasser genereret netop ud fra annotationer.

  • 0
  • 0
Carsten Sonne

Uanset hvad Martin Bahn Hansen mener, så er det da opløftende at .Net nu også rammer Android telefonerne (og platformen). Man kan kun tage hatten af for at Novell gør det som egentlig burde være Microsofts mission. Endnu et eksempel på hvordan et monopol kan få en aktør til at handle.

Mon ikke .Net applikationer får en noget større udbredelse end Martin Bahn Hansen holdning ligger op til.

  • 0
  • 0
Casper Bang

Kasper, jeg skriver i mange forskellige sprog og er som sådan glad for både Java og C#. Men min holdning er at sprog der giver programmøren bedre værktøjer til at løse opgaver er fordelagtige, f.eks. en simpel C# delegate frem for selv at skulle implementere Observer pattern manuelt via interfaces og anonyme klasser i Java. Så objektivt set ud fra grammatikken ER C# altså et superset af Java... håber ikke du vil bestride dette.

Ang. enums, så synes jeg du skulle tage og downloade SDK'et hvor du hurtigt vil finde ud af at syntaksen måske ligner Java, men det ER altså ikke Java (kan ikke bestå Sun's TCK) da der f.eks. netop ikke kan bruges enum's! På denne baggrund, er du helt sikker på du ikke er ude efter en religiøs debat?

Enum's i Java er en af mine absolut favoritter i sproget (bare synd det skulle tage over 10 år før vi fik den). Men de er dog heller ikke perfekte, man kan f.eks. ikke lave en state machine hvor en enum værdi skal forward-reference en anden værdi (som jeg beskriver her: http://coffeecokeandcode.blogspot.com/2008/07/enum-is-perfect-well-almos... og her: http://coffeecokeandcode.blogspot.com/2008/12/java-enum-relational-model...)

  • 0
  • 0
Casper Bang

"Men hvis en .NET/C# runtime skulle findes på Android ville den garanteret være ligeledes begrænset."

Nej, ikke hvis vi snakker sprog og syntax. Modsat Java, så er C# standardiseret under ISO og ECMA, dén spec som Mono implementerer og som kan findes her: http://standards.iso.org/ittf/licence.html.

"Dét som anslår min skeptisme er dit brug af ordet "superset" som ganske entydigt siger at alt hvad der findes i Java også findes i C#, og det er ikke tilfældet."

Hvordan du tolker superset må naturligvis stå for egen regning, faktum er at syntaksmæssigt så kan du enormt nemt portere et Java program til C#, hvorimod det omvendte ikke er tilfældet. Kan du ikke komme med et eksempel på en konstruktion i Java sproget der ikke umiddelbart er lige til at bruge i C# også, bortset fra Enum som jo altså ikke er relevant på Android - som denne artikel handler om.

Jeg håber du har ret i dit håb for Java, jeg synes Sun de seneste år har været forvirret og uambitiøs, og er bange for at Oracle ikke har motivationen og evnerne til at puste nyt liv i Java. Dette er sagt som programmør der har arbejdet med ADF og andre af Oracle's diverse komplekse enterprise stakke.

Nææ KISS og state-of-the-art tak... men vi kan i alt fald godt blive enige om at LINQ er genialt. :) JPA med dets type-usikre DSL queries embedded i strenge i annotations, i et sprog der ikke engang har multi-line strings, er et mareridt til sammenligning.

Hmm hvad sker der med v2's placering af indlæggene i denne tråd? Jeg skrev et svar, se evt. ovenfor :)

Jeg rettede en stavefejl i mit indlæg, så det vil jeg næsten kalde en bug i Version2's indlægsystem. :)

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Casper,

Modsat Java, så er C# standardiseret under ISO og ECMA, dén spec som Mono implementerer

Det er kun "basisbibliotekerne" i C#, der er standardiserede af ECMA/ISO.

Fra http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29#Criticism:

"Although the C# language definition and the CLI are standardized under ISO and Ecma standards which provide reasonable and non-discriminatory licensing protection from patent claims, Microsoft uses C# and the CLI in its Base Class Library (BCL) which is the foundation of its proprietary .NET framework, [b]and which provides a variety of non-standardized classes (extended I/O, GUI, web services, etc)[/b]"

(min fremhævning)

  • 0
  • 0
Casper Bang

Hej Jesper,

Du har helt ret. Men jeg snakker heller ikke på noget tidspunkt om API'er, men om sprog (syntaks og grammatik). Et programmeringssprog er oftest en tretrinsraket bestående af compiler, et sprog og et library.

Jer der giver negative stemmer, kunne i ikke modargumentere fagligt istedet? Er der fordi jeg er så "fræk" at kalde C#'s syntaks et superset af Javas?

  • 0
  • 0
Martin Bahn Hansen

Uanset hvad Martin Bahn Hansen mener, så er det da opløftende at .Net nu også rammer Android telefonerne (og platformen).

Ikke at misforstå, jeg synes det er rigtig fedt det Mono har gang i, og synes det er lækkert at man kan skrive .NET til Android/iPhone.

Man kan kun tage hatten af for at Novell gør det som egentlig burde være Microsofts mission. Endnu et eksempel på hvordan et monopol kan få en aktør til at handle.

Jeg tror det er vigtigt at det ikke er MS der driver værket for ligesom at få flere med på vognen. Forstået således at MS-hadere ikke indtager holdningen at MS prøver at pakke .NET platformen ned over de andre mobile platforme.
Jeg synes det er super fedt initiativ Novell har gang i. Det er kun at vente og se hvad det ender med.

Mon ikke .Net applikationer får en noget større udbredelse end Martin Bahn Hansen holdning ligger op til.

Man kan da altid håbe, for Visual Studio er da helt klart et fedt udviklingsværktøj.
Tiltrods for at Mono har gjort et fantastisk job, så tror jeg nu alligevel ikke at .NET bliver så udbredt medmindre alle native API'er bliver gjort tilgængeligt.

Jeg fokuser meget på native API'er -jeg ved det. Men at skrive en 'Hello World' app til mobilen er ikke det der sælger.
Idag er der rimelige store krav til app'en samt hardwaren, så hvis det skal kunne fungere ordentligt så bliver man nød til at tage et par smutveje. F.eks. er der nogle ting man bare ikke kan out-of-the-box i .NET. F.eks. har jeg lavet et managed/unmanaged interface til GPS'en fordi det ikke eksisterede i Windows Mobile. Eller tilgå en masse device specifikke ting, som heller ikke er tilgængelig.
Så alt i alt, hvis man vil lave en app, der ikke har den vilde funktionalitet, så kan man helt klart begå sig med standard .NET CF ellers bliver man nød til at kigge nærmere på API'erne.

  • 0
  • 0
Kasper Sørensen

Er der fordi jeg er så "fræk" at kalde C#'s syntaks et superset af Javas?

Tjah, det er jo bare ikke sandt. Du har nok ret i at der er flere syntaktiske konstruktioner i C# end i Java, men der er jo eksempler på både ting der findes i Javas syntax, som ikke findes i C#'s og omvendt, så udsagnet er ikke sandt.

Derudover synes jeg tit at det er tilgangen til bibliotekerne der er mere interessante end syntaksen. Langt de fleste af de ting som findes som syntax i C# findes jo som API'er i Java.

  • 0
  • 0
Casper Bang

Du har ret i at API også er vigtig, men det har stadig ikke noget med syntaksen at gøre.

Hvor Java altid har sagt "we do this with an API" siger C# ofte "we make it a first class construct". Med andre ord, hvad man ofte skal bikse med selv i Java er bagt ind i C# fordi man anerkender at hvis det er blevet til et brugt pattern, så bør det også være support for det så folk der ikke nødvendigvis har læst GOF bogen, stadig kan være produktiv og skrive korrekte programmer.

Jeg kunne pege på rigtig mange konkrete eksempler for at pointere hvad jeg mener, men jeg tror de fleste der har brugt C# Using statement, properties, events, decimal type osv. er af samme overbevisning. Desværre har Sun ikke holdt sproget ved lige og de sidste 4 år har de brugt alle kræfter på JavaFX. Du vil finde lignende tilkendegivelser fra Sun folk, hvis du f.eks. følger med på Coin mailinglisten. Og for et års tid siden, skred Neal Gafter (der var javac maintainer) over til Microsoft af samme årsager.

At implementationer igennem et API er fordelagtige, er indiskutabelt. Men det kræver en tilpas fleksibel grammatik - denne fleksibilitet har C#, hvorfor du også ser LINQ providers både til LDAP, Oracle, Filesystem, XML osv. LINQ er ganske enkelt en umulighed at implementere i Java fordi du ikke har type-inference, extension methods, properties og closures. Det tætteste vi har i dag til Java, er Hibernates Criteria API (https://www.hibernate.org/hib_docs/v3/api/org/hibernate/Criteria.html) men det er ikke type-sikkert og det henvender sig kun til ORM.

  • 0
  • 0
Carsten Sonne

Hej Martin,

Jeg er helt med på din anke. Jeg ser bare tiltaget i et lidt større perspektiv og over en længere tidshorisont.

I øvrigt har du en ganske god i pointe i, at det er en fordel bagmændene bag Mono ikke er Microsoft.

Mvh
Carsten Sonne Larsen

  • 0
  • 0
Kasper Sørensen

Det tætteste vi har i dag til Java, er Hibernates Criteria API (https://www.hibernate.org/hib_docs/...) men det er ikke type-sikkert og det henvender sig kun til ORM.

Tag og kig på JPA 2's criteria API. Det benytter annotation processing til at generere metamodel-klasser, så du kan lave typestærke queries, ala:

EntityManager em = ...
CriteriaQuery q = em.getCriteriaBuilder().createQuery();
q.from(Person.class);
q.select(Person_.name);
List<Person> personList = em.executeQuery(q);

På denne måde tilbydes alle features fra JPQL via et typestærkt API i stedet for en String. Det er et rigtigt godt eksempel på hvordan Java har løst et problem vha. biblioteker i stedet for syntax (netop som du også understreger). Jeg hører dit argument om at syntax er med til at standardisere løsninger på kendte problemer. Problemet med syntax er dog at man typisk finder forskellige løsninger på problemerne over tid, efterhånden som nye best practices udvikler sig. Se eksempelvis bare på hvilken udvikling der har været inden for dependency injection, observer-pattern osv. Derfor mener jeg at en API-løsning ofte er bedre, da API'er lettere kan udskiftes, refaktoreres mm., end sproglige konstruktioner kan. Derudover er der selvfølgelig dét, at når man først har lært Javas sprog-konstruktioner, så kan man meget lettere konsumere nye API'er. Hvis man skal lære et nyt keyword er der et helt nyt koncept som skal læres, hvorimod et nyt API vil benytte velkendte principper.

  • 0
  • 0
Casper Bang

Men JPA2's criteria API er jo netop IKKE en generel løsning på query (projectering/mapning) problemet, det er kun tiltænkt som ORM - og vil formeentlig hurtigt blive irrelevant eftersom mange er på vej over til NoSQL løsninger. Så hvor man kan se LINQ som en form for super-JDBC API der kan sende et AST igennem, så bliver man meget nemt låst fast ved at bruge et library som JPA2 der kun spytter SQL ud.

Ved at incl. konceptet i sproget kan udviklere drage fordel af dette i alle andre henseende - både imod et DBMS, Cassandra, LDAP osv. Let's face it, det meste af det vi laver til daglig, er at læse data, transformere det, og gemme det igen. Dertil kommer, at vi er NØD til at kunne forklare vores intensioner til compileren (skrive mere deklerativt), hvis den skal have nogen chance for at optimere/paralellisere de opgaver vi giver den.

Du har ret omkring fordelen ved API, at man skal naturligvis tænke sig gevaldigt om før man putter noget ned i sproget. Men vi bliver nok aldrig enige omkring dét at have et rigt nok sprog. Om man skal lære et nyt keyword eller nyt API kan gå ud på et. I Java verdenen har man det så bare på den måde, at man hele tiden skal lære et nye framework fordi der i mindre grad eksisterer standard eller de-facto løsninger.

Om det er en fordel eller ulempe kommer så nok bare an på hvem man spørger. Men lad mig høfligt minde om, at for 15-20 år siden før OO, skrev folk selv deres polymorfism i C (administrerede VTABLE pointere manuelt) men dette er sidenhen blevet includeret som syntaks i moderne sprog som Java og C#. Det tror jeg ikke der er nogen der har noget imod :)

  • 0
  • 0
Nikolaj Brinch Jørgensen

Hvis jeg skal nævne en ting som jeg personligt tror bliver en væsentlig ting for Java i de næste par år, så kunne jeg nævne meta-annotationer (dvs. annotationer på annotationer). Java EE 6 indeholder således mange nye features hvor man kan lave sine egne annotationer (med meta-annotationer) og benytte dem til at generalisere og kvalificere ifht. interception, dependency injection, objekt-valideringsregler, observer/observable markering (dvs. et ægte løst koblet event system, uden det bøvl som ellers altid findes, både i C# og "old school" Java) og mere.

Det er forkert at sammenligne sprogene Java/C# med Enterprise platformen JEE. Java var fint, og det inspirerede også Microsoft til at lave C#. Men verdenen går mod Groovy, Ruby, Python og Scala. Lad os få disse sprog på de mobile enheder - og lad firmaerne udvikle nogle gode runtimes.

PS: Syret med Windows Mobile 7, ad udvikle noget som bliver til en parentes det øjeblik den rammer gaden.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Tag og kig på JPA 2's criteria API. Det benytter annotation processing til at generere metamodel-klasser, så du kan lave typestærke queries, ala:

EntityManager em = ...
CriteriaQuery q = em.getCriteriaBuilder().createQuery();
q.from(Person.class);
q.select(Person_.name);
List<Person> personList = em.executeQuery(q);

Alt dette selvfølgelig ud fra den præmis, at type safe queries er sagen....

  • 0
  • 0
Casper Bang

"Alt dette selvfølgelig ud fra den præmis, at type safe queries er sagen"

Men at man omvendt er ligeglad med semantisk code completion i sit IDE. Som altid med annotations, så foregår al verifikation på køretid.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Men at man omvendt er ligeglad med semantisk code completion i sit IDE. Som altid med annotations, så foregår al verifikation på køretid.

For at kunne lave queries som er typestærke og hvor du får type fejl i IDE, kræver konstant adgang til din DB for at du kan holde din kode om mod skemadefinitionerne.
Skemadefinitionerne er som oftest forskellige mellem de forskellige miljøer - hvilket yderligere komplicere problemstillingen.
Iøvrigt kan man sagtens have code completion af dynamiske sprog (af mig lige nu defineret ved sprog som ikke er type stærke), f.eks. findes det til JS, Ruby og Groovy.

Som Kasper er inde på er Meta annotations vejen frem, og her er de dynamiske sprog allerede foran med deres meget avancerede meta programmerings features.

  • 0
  • 0
Casper Bang

"Iøvrigt kan man sagtens have code completion af dynamiske sprog (af mig lige nu defineret ved sprog som ikke er type stærke), f.eks. findes det til JS, Ruby og Groovy."

Klart, men det er og bliver en heuristisk affære (gætteri). Især med sprog baseret på Prototype nedarvning som f.eks. JavaScript. Her kan du på runtime tilføje og fjerne egenskaber på objekter og så kommer IDE'er altså hurtigt ude og svømme.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Klart, men det er og bliver en heuristisk affære (gætteri). Især med sprog baseret på Prototype nedarvning som f.eks. JavaScript. Her kan du på runtime tilføje og fjerne egenskaber på objekter og så kommer IDE'er altså hurtigt ude og svømme.

Sandt.
jeg ser sådan på det, at code completion selvfølge er produktivitetsforbedrende, men det er også produktivitetsforbedrende at holde sig væk fra Java (boilerplate/clutter code), der er enormt verbose. Java er en stærk platform, især overfor .NET - af den grund at den kan afvikles på stort set enhver platform, og de nye sprog der afvikles herpå er meget mere produktivitetsfremmende end Java (ikke alle af disse er dynamiske - Scala f.eks.).

Det er så en vægtning af den produktivitetsforbedring code completion giver dig i f.eks. Java vs. den produktivitetsforbedring du får ved at benytte f.eks. Groovy.

Ved brug af Groovy har du ikke brug for så megen code completion, da du jo slet ikke skal skrive så meget. Desuden er koden lettere forståelig, da du jo ikke skal fylde den med alt muligt unødvendigt som f.eks. kontrolstrukturer for gennemløb af collections mm. (det er blevet en lille smule bedre med foreach konstruktionen - men så er det ikke bedre).

Min overbevisning er at verden går væk fra disse legacy sprog som Java og hen i mod de mere dynamiske sprog med en langt højere produktivitet og mere unit testing (Scala og andre funtionelle sprog er også inklulderet i fremtidige sprog selvom de ikke er dynamiske, men de opfylder præmissen for sprog med højere produktivitet).
Vi kan selvfølgelig ikke afskaffe Java og der vil blive ved med at være systemer der bliver udviklet heri, men nye systemer vil være baseret på især Groovy og Scala.

  • 0
  • 0
Kasper Sørensen

Jeg indrømmer igen, at jeg gad godt at der var noget tilsvarende LINQ i Java, da det kan meget mere end eks. JPA 2's criteria query. Når det er sagt synes jeg at criteria queries dækker det primære behov, nemlig at lave typestærke queries.

Alt dette selvfølgelig ud fra den præmis, at type safe queries er sagen....

Det ER sagen, da type-stærkheden jo ikke kun giver os produktivitetes-forbedring i form af code completion muligheder, men også fejlsikrings muligheder på compile-time. Således gøres queries meget lettere at refaktorere (og stavefejl og lign. sikres selvf. også).

Som altid med annotations, så foregår al verifikation på køretid.

Forkert. Med annotation processing kan du arbejde med annotationer på compile time. Det er på den baggrund at JPA 2 definerer metamodeller eller project lombok kan generere getters/setters, toString og equals metoder etc.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Det ER sagen, da type-stærkheden jo ikke kun giver os produktivitetes-forbedring i form af code completion muligheder, men også fejlsikrings muligheder på compile-time. Således gøres queries meget lettere at refaktorere (og stavefejl og lign. sikres selvf. også).

Det er da ikke nogen garanti. Det bygger på en tese om at type stærke sprog er bedre og mere produktive at udvikle i end dynamiske sprog - det er da en urimelig og ikke underbygget påstand.

Iøvrigt er produktivitetsforbedringen jo relativ til hvor megen kode du skal skrive (i Java skal du skrive vældig megen kode - en del overflødigt) for at opnå det du vil. Hvis du skal skrive forholdsvis lidt kode, er code completion jo forholdsvis overflødig, eller i hvert fald ikke så nødvendigt et redskab.

Vi kan stadig ikke garantere at vores queries er type stærke i forhold til basens skema, så det hele bygger på at det "næsten" er type stærkt - og hvad hjælper det.

Det er på den baggrund at JPA 2 definerer metamodeller eller project lombok kan generere getters/setters

Getter og setters er overflødige (det har C#, Groovy, Ruby m.fl. da også fundet ud af - dog har Java ikke set lyset endnu), desuden ikke objekt orienterede. http://bit.ly/PruI

  • 0
  • 0
Casper Bang

Forkert. Med annotation processing kan du arbejde med annotationer på compile time. Det er på den baggrund at JPA 2 definerer metamodeller eller project lombok kan generere getters/setters, toString og equals metoder etc.

Nej det er skam ikke forkert, nu har jeg selv arbejdet lidt med Reinier omkring Lombok (konkret, fjernelse af checked exceptions jvf. mit hack http://bit.ly/java-hack), og den måde det fungerer på er som hook EFTER lexeren og parseren, hvorfor du SKAL have et syntaktisk gyldigt AST for at kunne lave noget som helst. De bruger så en Java agent til deres Eclipse del, men det er og bliver et hack. Reinier har tit været oppe og toppes med Joe Darcy og Alex Buckley fra Sun. Check f.eks. Coin maillinglisten hvis det har interesse.

Svar mig på dette, i dit criteria eksempel, hvon' vil du få din IDE til at checke at Person.class overhovedet giver mening? Ud fra Java's type system, er det bare en class literal - der kunne ligesågodt have stået Monkey.class.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Svar mig på dette, i dit criteria eksempel, hvon' vil du få din IDE til at checke at Person.class overhovedet giver mening? Ud fra Java's type system, er det bare en class literal - der kunne ligesågodt have stået Monkey.class.

Nemlig!

Der er ingen type stærk beskyttelse her overhovedet!

  • 0
  • 0
Nikolaj Brinch Jørgensen

Flere af Project Lomboks annotations er hacks som kun er nødvendige på baggrund af manglende modernitet i sproget Java.
I Groovy er getters/setters implicit, da det benytter en property model a la C#, Ruby m.fl.
At man så i lombok kan skrive en masse annotationskode i stedet for at skrive getters/setters (declarativ i stedet for imperativ) er da fint, men det ændrer ikke ved at det helt skal undgåes at man skal skrive noget som bør være automatisk.
Kode-generering er symptom på mangler i værktøjet, og Java har i sin tid forudsat store mængder af kode-generering (XDoclet mm.)

  • 0
  • 0
Casper Bang

"At man så i lombok kan skrive en masse annotationskode i stedet for at skrive getters/setters (declarativ i stedet for imperativ) er da fint, men det ændrer ikke ved at det helt skal undgåes at man skal skrive noget som bør være automatisk."

Helt enig. Og det bliver meget hurtigt et problem, fordi man jo bliver afh. af et IDE. Derudover skal der ikke meget til at forestille sig indbyrdes konflikter kode-genereringer imellem.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Helt enig. Og det bliver meget hurtigt et problem, fordi man jo bliver afh. af et IDE. Derudover skal der ikke meget til at forestille sig indbyrdes konflikter kode-genereringer imellem.

Det er dejligt som IT verdenen fungere. Når vi finder en fejl, så i stedet for at rette root cause så den ikke kan opstår igen, så sætter vi en lap på.

Projekt lombok er et godt eksempel på noget som ikke skulle være opstået (ligesom Ivy til Ant).
I stedet for at fixe de problemer der er i Java (som egentlig er udtryk for at vi er blevet klogere og har udviklet os), så laver vi sådan noget som lombok, der får os til at tro vi har udviklet os, ved at vi nu bruger det.
I stedet bør vi fixe Java så vi i fremtiden ikke sidder og koder getters og setters. Der er jo altså versioner på Java udgivelserne, så det skulle være muligt at forbedre platformen fremadrettet.

Det ville være fedt, hvis Sun/Oracles næste JEE udgave byggede på Groovy (eller Scala), og ikke Java, eller det var komplet valgfrit mellem de forskellige sprog og der bare var support for det (JSP scriptlets i JRuby f.eks.)

  • 0
  • 0
Log ind eller Opret konto for at kommentere