mboost-dp1

Mono
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Det var også på tide. Det bliver da lækkert at kunne udvikle et stykke software som virker på mere end bare Windows platformen, uden at skulle genskrives til den specifikke platform først.
At det så kun er fællesmængden af .NET funktionalitet man kan bruge, det er et ærgeligt men et nødvendigt onde.
At det så kun er fællesmængden af .NET funktionalitet man kan bruge, det er et ærgeligt men et nødvendigt onde.
Jeg kunne godt bruge Java, men så ville jeg skulle til at sætte mig ind i endnu et programmeringssprog, som jeg kun ville benytte privat og ikke ville benytte til Windows programmering, da der findes produkter som er bedre egnet til Windows.
Altså ville jeg skulle lære Java for at bruge det på ikke-Windows systemer, hvilket sænker motivationen for det gevaldigt, da alle mine nuværende systemer er Windows systemer - både på i forbindelse med arbejdet og hjemme.
Derudover så er Java, så vidt jeg kan se, heller ikke bare Java. Java som kører i min webbrowser er forskelligt fra den Java som kører på min mobiltelefon, hvilket igen betyder at der er forskel på den kode der skal skrives, alt efter hvor den skal bruges.
Altså ville jeg skulle lære Java for at bruge det på ikke-Windows systemer, hvilket sænker motivationen for det gevaldigt, da alle mine nuværende systemer er Windows systemer - både på i forbindelse med arbejdet og hjemme.
Derudover så er Java, så vidt jeg kan se, heller ikke bare Java. Java som kører i min webbrowser er forskelligt fra den Java som kører på min mobiltelefon, hvilket igen betyder at der er forskel på den kode der skal skrives, alt efter hvor den skal bruges.
Personligt har jeg brugt mange år i linux, og det er ikke mit indtryk at java er specielt portabelt.
Ja deres VM kører ganske vist men da dem der udvikler programmer ret ofte lige hardcoder en sti som %PROGRAMFILES%\xyz\ ind i programmet virker det sjovt nok ikke.
De kører så fint igennem wine, men det er så ikke java der kommer og redder dagen der, for der kører programmer i c eller c++ lige så godt :P
Ja deres VM kører ganske vist men da dem der udvikler programmer ret ofte lige hardcoder en sti som %PROGRAMFILES%\xyz\ ind i programmet virker det sjovt nok ikke.
De kører så fint igennem wine, men det er så ikke java der kommer og redder dagen der, for der kører programmer i c eller c++ lige så godt :P
Yo dawg, I heard you like programming across platforms, so I added cross-platform libraries to a cross-platform framework, so you can code cross-platform while you code cross-platform.
#6 -
12. maj 2011 08:04
[sarkasme]
Yiiir J2ME CDC/CLDC ftw!!!!!!
[/sarkasme]
Har aldrig oplevet noget så elendigt at arbejde med, som J2ME CDC/CLDC... Håber det er blevet lagt i graven for længst...
Yiiir J2ME CDC/CLDC ftw!!!!!!
[/sarkasme]
Har aldrig oplevet noget så elendigt at arbejde med, som J2ME CDC/CLDC... Håber det er blevet lagt i graven for længst...
#4 med en hardcodet sti som %PROGRAMFILES%\xyz\ er det jo tydeligt at kodehovedet ikke har overvejet at programmet skal køre på andet end Windows.
På java siden kan jeg tilføje at på mit tidligere arbejde porterede vi vores client/server management system til Solaris i 2003 og senere til Linux i 2008.
Solaris porteringen var 1 mand i ca 3 måneder. Det meste af tiden gik med at lave installations skripts til server og klient delene + test.
Vi brugte relative stier men der skulle lige ændres fra "\" til "/" en håndfuld steder.
Alt virkede men det viste sig at det var gået lidt for nemt. GUIen var lidt skæv rundt omkring. Der var åbenlyse ting som standard dialoger som havde anden funktionalitet på Solaris.
Fik fortalt at standard fonten på Solaris er 1 pixel højere end på Windows. Så der begyndte at dukke ekstra kode op i visse dele af klienterne
if windows
.....
else if solaris
....
I virkeligheden var det ikke det helt store problem da de af kunderne der kørte Solaris på server siden selvfølgelig kørte klienterne på Windows; så efter det værste var håndteret lod vi resten være som det var.
og i 2008 blev der tilføjet lidt
else if linux
I øvrigt var der i 2003 andre udfordringer; performance mæssigt var SUNs JVM til Windows et stykke foran sine lunix brødre. På andre UNIX platforme kunne man få en alternativ JVM fra HP eller IBM, men på Solaris hang man på SUNs JVM.
Forskellen blev stort udjævnet med 1.4.2 som heldigvis kom da vi tilføjede Solaris som platform
På java siden kan jeg tilføje at på mit tidligere arbejde porterede vi vores client/server management system til Solaris i 2003 og senere til Linux i 2008.
Solaris porteringen var 1 mand i ca 3 måneder. Det meste af tiden gik med at lave installations skripts til server og klient delene + test.
Vi brugte relative stier men der skulle lige ændres fra "\" til "/" en håndfuld steder.
Alt virkede men det viste sig at det var gået lidt for nemt. GUIen var lidt skæv rundt omkring. Der var åbenlyse ting som standard dialoger som havde anden funktionalitet på Solaris.
Fik fortalt at standard fonten på Solaris er 1 pixel højere end på Windows. Så der begyndte at dukke ekstra kode op i visse dele af klienterne
if windows
.....
else if solaris
....
I virkeligheden var det ikke det helt store problem da de af kunderne der kørte Solaris på server siden selvfølgelig kørte klienterne på Windows; så efter det værste var håndteret lod vi resten være som det var.
og i 2008 blev der tilføjet lidt
else if linux
I øvrigt var der i 2003 andre udfordringer; performance mæssigt var SUNs JVM til Windows et stykke foran sine lunix brødre. På andre UNIX platforme kunne man få en alternativ JVM fra HP eller IBM, men på Solaris hang man på SUNs JVM.
Forskellen blev stort udjævnet med 1.4.2 som heldigvis kom da vi tilføjede Solaris som platform
mht. java og cross platform, så er der en hel del ting som er "hardcoded" i deres GUI biblioteker. Mange grafiske javaprogrammer virker ikke i visse window managers på linux.
EDIT: Man kan så mene at det ikke er så stort da det kun er få lidt obskure WMs hvor det ikke virker, og det er i forvejen ikke let at lave crossplatform gui.
EDIT: Man kan så mene at det ikke er så stort da det kun er få lidt obskure WMs hvor det ikke virker, og det er i forvejen ikke let at lave crossplatform gui.
Ideen om at vi så kan sikre os, at når vi udvikler standardbiblioteker der skal supportere en bred række af consumer produkter, så kan sikre os at det faktisk virker er jo også rigtig god.
F.eks. til spil der skal fungere på Xbox/PC/WP7. Men også ideen om at man f.eks. kan lave data providers, og parsers, som kan bruges på både iOS og Xbox, er lovende.
Man kan jo skrive ret meget kode, bare med BCL. Ligeledes kan ViewModels også nemt genbruges til en del UI udvikling.
F.eks. til spil der skal fungere på Xbox/PC/WP7. Men også ideen om at man f.eks. kan lave data providers, og parsers, som kan bruges på både iOS og Xbox, er lovende.
Man kan jo skrive ret meget kode, bare med BCL. Ligeledes kan ViewModels også nemt genbruges til en del UI udvikling.
albatros (4) skrev:Personligt har jeg brugt mange år i linux, og det er ikke mit indtryk at java er specielt portabelt.
Mystisk.
Siden der sidder millioner af udviklere og skriver og unit tester Java på Windows som deployes på *nix.
albatros (4) skrev:Ja deres VM kører ganske vist men da dem der udvikler programmer ret ofte lige hardcoder en sti som %PROGRAMFILES%\xyz\ ind i programmet virker det sjovt nok ikke.
Endnu mere mystisk.
Hvorfor skulle det gøre det? Det virker nemlig heller ikke under Windows!
Mort (3) skrev:Derudover så er Java, så vidt jeg kan se, heller ikke bare Java. Java som kører i min webbrowser er forskelligt fra den Java som kører på min mobiltelefon, hvilket igen betyder at der er forskel på den kode der skal skrives, alt efter hvor den skal bruges.
Der findes forskellige Java udgaver, konfigurationer og profiler:
Java ME - CLDC - MIDP
Java ME - CLDC - IMP
Java ME - CDC - Foundation
Java ME - CDC - Personal
Java SE
Java EE - Web
Java EE - Full
Det er lidt givet grundet de meget forskellige typer af platforme.
Det Java giver dig er at den samme app vil køre på forskellige platforme indenfor samme type af platform (medmindre man skyder sig selv i foden).
Det sikres via TCK, en certificerings process og advokater.
Scorp-D (6) skrev:Har aldrig oplevet noget så elendigt at arbejde med, som J2ME CDC/CLDC... Håber det er blevet lagt i graven for længst...
Det er det ikke.
Men enten burde det lægges i graven eller have en større opdatering.
CLDC minimums HW krav : 192 KB RAM
CDC minimums HW krav : 2 MB RAM
er jo ikke ligefrem HW anno 2011.
Personligt mener jeg at de burde gøre en dyd af nødvendigheden og gøre Android SDK til Java ME SCDC.
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.