mboost-dp1
unknown
Eneste jeg kan se det vil hjælpe mig: Vil det blive hurtigtere end det er nu ? Fordi java SUCKS normalt, det ved alle ! Ingen kan lide at have med java apps at gøre.
#1: Java 'SUCKS' på ingen måde. Java-applets er kun et lille hjørne af hvad Java kan, og vi kan blive helt enige om at opstartstiden på appletter er for lang til at bruge det til ret meget i web-verdenen. Det Java i meget høj grad bruges til i dag er serversoftware rundtomkring, og her et det en rigtig god og højtydende platform.
J2EE er ikke den virtuelle maskine, som du kører på din computer derhjemme, men en lang række frameworks som bruges i den professionelle verden.
J2EE er ikke den virtuelle maskine, som du kører på din computer derhjemme, men en lang række frameworks som bruges i den professionelle verden.
decon>>>Really? Jeg er da usædvanligt glad for IntelliJ IDEA, det starter og opfører sig umiddelbart ligeså hurtigt som et program lavet i c++/visual basic/c#/delphi/whatever.
Iøvrigt er denne nyhed angående EE Enterprise Edition og ikke SE Standard Edition. Og siden du ikke kender forskel på det kan jeg garantere dig at du aldrigt har kørt en enterprise bean, så just move along :)
Personligt håber jeg at det bliver simplere at gå i gang med enterprise development(ala .net), men det tyder det jo også på ifølge http://www.computerworld.dk/art/33815?a=block&...
Iøvrigt er denne nyhed angående EE Enterprise Edition og ikke SE Standard Edition. Og siden du ikke kender forskel på det kan jeg garantere dig at du aldrigt har kørt en enterprise bean, så just move along :)
Personligt håber jeg at det bliver simplere at gå i gang med enterprise development(ala .net), men det tyder det jo også på ifølge http://www.computerworld.dk/art/33815?a=block&...
#1 det er helt fint, sig det til en jobsamtale hos et firma som udvikle enterprise/ERP systemer, og du kan være sikker på at få en "døren er der" kommentar.
[ontopic]
Lyder absolut positivt, EE versionerne har altid været en tand mere professionelle en normalt (som alt andet der er designet til enterprise). Må kigge nærmere på de nye licencsvilkår , da dette måske er en forbedring mange har ventet på.
Personligt har jeg kun brugt Enterprise versionen sammen med Tomcat, men kunne være man skulle kigge liiidt mere på den nye udgave, ved at være et stykke tid siden sidst. ;)
[ontopic]
Lyder absolut positivt, EE versionerne har altid været en tand mere professionelle en normalt (som alt andet der er designet til enterprise). Må kigge nærmere på de nye licencsvilkår , da dette måske er en forbedring mange har ventet på.
Personligt har jeg kun brugt Enterprise versionen sammen med Tomcat, men kunne være man skulle kigge liiidt mere på den nye udgave, ved at være et stykke tid siden sidst. ;)
#1 Java er et exelent sprog. Det er dog ikke så brugt på desktoppen, da guien normalt ikke er helt identisk med resten af platformens programmer, hvad er grimt.
Dette er dog også ved at blive rettet op, så nu er enste forhindring licensen.
Der er en del diskussioner internt i Sun, om hvorvidt man vil opensource java. Personligt håber jeg meget at det sker, f.eks. ved version 6.0. Det vil give mulighed for meget kraftigere brug af java i opensource verdenen.
Dette er dog også ved at blive rettet op, så nu er enste forhindring licensen.
Der er en del diskussioner internt i Sun, om hvorvidt man vil opensource java. Personligt håber jeg meget at det sker, f.eks. ved version 6.0. Det vil give mulighed for meget kraftigere brug af java i opensource verdenen.
Sun burde lave Java og tilhørende teknologier til en åben standard, ligesom MS var smarte nok til at gøre med .NET. Det vil gavne open source verdenen utrolig meget, og Sun behøver ikke selv at lave deres implementation open source hvis de ikke vil det. Det er bare min holdning til det. Lige nu er Java en "standard", som Sun kontrollerer 100%, og det er ikke det hele som er dokumenteret. Jeg ser frem til den dag, hvor det at vælge en open source Java er lige så godt som at vælge Suns.
#1 Java er meget nem at komme til at hade, primært på grund af:
Politikken om altid at være bagudkompatibel
---------------------------------------------------
Store dele af API'et bærer præg af at være 10 år gammelt og nu enten depricated eller blot seriøst inkonsistent. Man mister simpelthen muligheden for at sige "Hmm, dette var vist ikke så godt, lad os rydde op her..." modsat f.eks. hvad Microsoft gør med deres CLR VM.
Eks: Date er 90% depricated med bruges stadig og BigInteger klassen skulle være ændret til en nativ type (eller Java skulle have operator overloading), hvem fa'en gider skive ourBigInt = myBigInt.add(yourBigInt)?
SUN's manglende fokus
---------------------------
Og så er der SUN's svingende tendenser, i starten blev Swing udråbt til at være VB6's afløser men fra år 2000 til 2005 er der intet lavet på Swing API'et, selv om man ved gud ofte savner f.eks. en dato-vælger, statusbar eller andre basale komponenter. Efter 5 år ser det ud til at de nu flytter fokus tilbage fra EE til SE efter pres fra .NET og SWT.
Eks: De utallige layout managere, manglende komponenter, SWT/Eclipse der er gået deres egen vej.
Manglende værktøjer
------------------------
Først for et par år siden kom der IDE'er på niveau med Visual Studio mht. debugging og on-the-fly hjælp. De kører dog noget langsommere og med flere crashes, men værre, de er sjældent kompatible med hinanden.
Eks. Nogen bruger Ant, andre Maven, andre proproritært format. Nogen bruger deres egne deployment filer (ear, war og variationer heraf). Nogen bruger deres egen Layout Managers (GroupLayout i NetBeans, FormLayout i JDeveloper).
#6 Azerus er teknisk set ikke lavet i Java, fordi SWT er en samling C kode samlet i en .dll/.so fil. Det er således kun programflow og meget generelle ting så som collections der er egentlig Java.
Politikken om altid at være bagudkompatibel
---------------------------------------------------
Store dele af API'et bærer præg af at være 10 år gammelt og nu enten depricated eller blot seriøst inkonsistent. Man mister simpelthen muligheden for at sige "Hmm, dette var vist ikke så godt, lad os rydde op her..." modsat f.eks. hvad Microsoft gør med deres CLR VM.
Eks: Date er 90% depricated med bruges stadig og BigInteger klassen skulle være ændret til en nativ type (eller Java skulle have operator overloading), hvem fa'en gider skive ourBigInt = myBigInt.add(yourBigInt)?
SUN's manglende fokus
---------------------------
Og så er der SUN's svingende tendenser, i starten blev Swing udråbt til at være VB6's afløser men fra år 2000 til 2005 er der intet lavet på Swing API'et, selv om man ved gud ofte savner f.eks. en dato-vælger, statusbar eller andre basale komponenter. Efter 5 år ser det ud til at de nu flytter fokus tilbage fra EE til SE efter pres fra .NET og SWT.
Eks: De utallige layout managere, manglende komponenter, SWT/Eclipse der er gået deres egen vej.
Manglende værktøjer
------------------------
Først for et par år siden kom der IDE'er på niveau med Visual Studio mht. debugging og on-the-fly hjælp. De kører dog noget langsommere og med flere crashes, men værre, de er sjældent kompatible med hinanden.
Eks. Nogen bruger Ant, andre Maven, andre proproritært format. Nogen bruger deres egne deployment filer (ear, war og variationer heraf). Nogen bruger deres egen Layout Managers (GroupLayout i NetBeans, FormLayout i JDeveloper).
#6 Azerus er teknisk set ikke lavet i Java, fordi SWT er en samling C kode samlet i en .dll/.so fil. Det er således kun programflow og meget generelle ting så som collections der er egentlig Java.
#9 du lyder ikke for intelligent - du har slet ikke styr på hvad du siger!
bagfra:
så er der jo ingen java applikationer med gui der er lavet i Java - ej heller Visual Basic applikationer eller .NET - de bruger jo alle sammen c/c++ dll's fra Microsoft/X/Quartz (hvilke man er *nødt* til). Alle VM's fra Sun bruger JNI for at interface med OS'et - ligeledes gør AWT (som så at sige er en lightweight udgave af SWT (AWT var det første (officielle) grafiske bibliotek til Java). Swing er baseret på AWT.
Så visual studio er kompatibelt med make, codeblocks, dev-cpp - nej vel, tror jeg heller ikke. Folk bruger forskellige ting fordi det giver mening. Og at sige at ant ikke er kompatibelt med maven siger lidt om dit kendskab til det du skriver!
At du ikke har applikationer der kører java her efter 10 år er fint for dig - men vi andre er mere end almindeligt glad for bagudkompatibilitet.
Det sammer er Windows, hvorfor store dele af deres API også er bagudkompatibelt. Bare vent til .NET er 13 år gammelt, så kan du se hvad der er sket.
bagfra:
#6 Azerus er teknisk set ikke lavet i Java, fordi SWT er en samling C kode samlet i en .dll/.so fil.
så er der jo ingen java applikationer med gui der er lavet i Java - ej heller Visual Basic applikationer eller .NET - de bruger jo alle sammen c/c++ dll's fra Microsoft/X/Quartz (hvilke man er *nødt* til). Alle VM's fra Sun bruger JNI for at interface med OS'et - ligeledes gør AWT (som så at sige er en lightweight udgave af SWT (AWT var det første (officielle) grafiske bibliotek til Java). Swing er baseret på AWT.
men værre, de er sjældent kompatible med hinanden.
Så visual studio er kompatibelt med make, codeblocks, dev-cpp - nej vel, tror jeg heller ikke. Folk bruger forskellige ting fordi det giver mening. Og at sige at ant ikke er kompatibelt med maven siger lidt om dit kendskab til det du skriver!
Store dele af API'et bærer præg af at være 10 år gammelt og nu enten depricated eller blot seriøst inkonsistent. Man mister simpelthen muligheden for at sige "Hmm, dette var vist ikke så godt, lad os rydde op her..." modsat f.eks. hvad Microsoft gør med deres CLR VM.
At du ikke har applikationer der kører java her efter 10 år er fint for dig - men vi andre er mere end almindeligt glad for bagudkompatibilitet.
Det sammer er Windows, hvorfor store dele af deres API også er bagudkompatibelt. Bare vent til .NET er 13 år gammelt, så kan du se hvad der er sket.
#10 true! Men det ændrer ikke ved #9's indvending om GUI'er. Java GUI'er er langsomme, grimme og mangelfulde. Det er naturligivs enormt subjektivt, men jeg savner ikke at kode java, primært pga. Swing.
#1 Java og .net applikationer lider alle under at være lidt sløve at starte op (første gang i hvertfald) fordi de ikke er kompilede til "0'er og 1'er" , men til så kaldte "Intermediate languages", der bliver fortolket, delvist ved opstart og delvist på kørselstidspunktet. Det koster lidt oversættelse når de bliver startet, men det er prisen for memory management, ultimativ portabilitet (i hvertfald for java) etc. Java har ikke den mulighed som .net har, med at cache den oversatte kode, da det skal kunne køre på andet end PC'er.
Java er blevet meget hurtigere med alderen, og jeg syntes ikke din kritik er særlig relevant længere... Du kan køre den samme app på din PC og din mobiltelefon, og det er en mulighed der ikke er gratis, men dyr er den heller ikke imo.
#1 Java og .net applikationer lider alle under at være lidt sløve at starte op (første gang i hvertfald) fordi de ikke er kompilede til "0'er og 1'er" , men til så kaldte "Intermediate languages", der bliver fortolket, delvist ved opstart og delvist på kørselstidspunktet. Det koster lidt oversættelse når de bliver startet, men det er prisen for memory management, ultimativ portabilitet (i hvertfald for java) etc. Java har ikke den mulighed som .net har, med at cache den oversatte kode, da det skal kunne køre på andet end PC'er.
Java er blevet meget hurtigere med alderen, og jeg syntes ikke din kritik er særlig relevant længere... Du kan køre den samme app på din PC og din mobiltelefon, og det er en mulighed der ikke er gratis, men dyr er den heller ikke imo.
#11 iluka
Hvordan mener du at Java applikationer er hurtigere til at starte op efter første gang, hvis de ikke kan cache den oversatte kode?
Ja, hvis app'en er skrevet til J2ME?
Java og .net applikationer lider alle under at være lidt sløve at starte op (første gang i hvertfald)
...
Java har ikke den mulighed som .net har, med at cache den oversatte kode, da det skal kunne køre på andet end PC'er.
Hvordan mener du at Java applikationer er hurtigere til at starte op efter første gang, hvis de ikke kan cache den oversatte kode?
Du kan køre den samme app på din PC og din mobiltelefon, og det er en mulighed der ikke er gratis, men dyr er den heller ikke imo.
Ja, hvis app'en er skrevet til J2ME?
Hva' kan vi ikke holde os til sund debat frem for personlige angreb?
AWT og SWT bruger JNI, men Swing enumerer ALT helt ned til laveste niveau og kalder kun OS'et med paint beskeder for den "nederste" container (typisk JFrame). Swing er absolut ikke baseret på AWT, ud over at det kører i samme tråd (event-dispatchen) og implementerer sværvægtskomponenter ovenpå disse AWT letvækskomponenter. Swing er baseret på en komplekst MVC arkitektur som er ren Java og hvor det er JVM'en der for at rendere. Det er jo derfor man har konceptet L&F og årsagen til hvorfor Swing er langsommere end AWT/SWT!
Faktum er, at man ikke bare hopper fra en IDE til en anden uden at bruge enorm tid på denne migration. Jovist man får valgmulighed, problemet er at de fleste er ligeglad med valgmulighed hvis de kan få ensartethed og høj kvalitet og bruge tiden på kundens artifakt frem for værktøjer og paraplyaktiviteter.
Tja det viser hvor meget du ved. I .NET skriver man til en specifik CLR. Så når .NET er 13 år gammelt og vi er nået til CLR 6.0 eller lignende (mon Java stadig hedder Java 2) har folk der kører .NET 3.0 software sjovt nok et CLR 3.0 runtime mens spritny 6.0 kode kører på et CLR 6.0 runtime.
Dét er grunden til at C# har rigtig innovation (Generics, extension methods, delegates, enums, lambda functions) mens Java forsøger at følge med, desværre primært via syntaks-sukker (Java pseudo-generics) og .NET efterligninger (GroupLayout).
Alle VM's fra Sun bruger JNI for at interface med OS'et - ligeledes gør AWT (som så at sige er en lightweight udgave af SWT (AWT var det første (officielle) grafiske bibliotek til Java). Swing er baseret på AWT.
AWT og SWT bruger JNI, men Swing enumerer ALT helt ned til laveste niveau og kalder kun OS'et med paint beskeder for den "nederste" container (typisk JFrame). Swing er absolut ikke baseret på AWT, ud over at det kører i samme tråd (event-dispatchen) og implementerer sværvægtskomponenter ovenpå disse AWT letvækskomponenter. Swing er baseret på en komplekst MVC arkitektur som er ren Java og hvor det er JVM'en der for at rendere. Det er jo derfor man har konceptet L&F og årsagen til hvorfor Swing er langsommere end AWT/SWT!
Og at sige at ant ikke er kompatibelt med maven siger lidt om dit kendskab til det du skriver!
Faktum er, at man ikke bare hopper fra en IDE til en anden uden at bruge enorm tid på denne migration. Jovist man får valgmulighed, problemet er at de fleste er ligeglad med valgmulighed hvis de kan få ensartethed og høj kvalitet og bruge tiden på kundens artifakt frem for værktøjer og paraplyaktiviteter.
At du ikke har applikationer der kører java her efter 10 år er fint for dig - men vi andre er mere end almindeligt glad for bagudkompatibilitet.
Det sammer er Windows, hvorfor store dele af deres API også er bagudkompatibelt. Bare vent til .NET er 13 år gammelt, så kan du se hvad der er sket.
Tja det viser hvor meget du ved. I .NET skriver man til en specifik CLR. Så når .NET er 13 år gammelt og vi er nået til CLR 6.0 eller lignende (mon Java stadig hedder Java 2) har folk der kører .NET 3.0 software sjovt nok et CLR 3.0 runtime mens spritny 6.0 kode kører på et CLR 6.0 runtime.
Dét er grunden til at C# har rigtig innovation (Generics, extension methods, delegates, enums, lambda functions) mens Java forsøger at følge med, desværre primært via syntaks-sukker (Java pseudo-generics) og .NET efterligninger (GroupLayout).
Java GUI'er er langsomme, grimme og mangelfulde. Det er naturligivs enormt subjektivt, men jeg savner ikke at kode java, primært pga. Swing.
jeg synes at java 1.5 er væsenligt pænere - specielt under xp da den bruger native theme (gtk halter vidst ret meget).
mht. hastighed så straffes alle VM basered programmer i en eller anden grad - en ting, som afhængig af programmet er mere eller mindre irriterende. Men jeg tror at en stor del af programmer i fremtiden kører under en eller anden form for VM da sikkerheds modellen simpelthen er uendeligt meget bedre. Og da alle ikke er perfekte kodere - langt fra - er det bedre at placerer folk i sandkasser.
Men jeg synes at der er gjort alvorlige indhug i diverse performance issues i Java 6 (mustang - som desværre ikke får escape analysis - helt (lock elimination og stack allocation) - med i første omgang :(). Så prøv den (er stadig kun i beta: http://mustang.dev.java.net)
Tja det viser hvor meget du ved. I .NET skriver man til en specifik CLR. Så når .NET er 13 år gammelt og vi er nået til CLR 6.0 eller lignende (mon Java stadig hedder Java 2) har folk der kører .NET 3.0 software sjovt nok et CLR 3.0 runtime mens spritny 6.0 kode kører på et CLR 6.0 runtime.
øhh - det er slet ikke korrekt det du siger. Man kan sagtens have kode der er lavet til .net 1.0 som også kan køre på .net 2.0.
Og hvis man ikke kunne det ville man blive idiot - så kunne man jo ikke opgraderer til nyest VM's med nyeste sikkerheds opdateringer uden at rekompilere. Der var en del folk der brokede sig over at 2.0 breakede en del kode. Og hvis folk lavede kode til en specifik version var der vel heller ikke brug for:
http://msdn.microsoft.com/netframework/programming...
?
Faktum er, at man ikke bare hopper fra en IDE til en anden uden at bruge enorm tid på denne migration.
og det er anderledes hvordan med .net? - nøjagtig samme problem stilling. Alle bruger ikke visual studio (thank god!)
AWT og SWT bruger JNI, men Swing enumerer ALT helt ned til laveste niveau og kalder kun OS'et med paint beskeder for den "nederste" container (typisk JPanel).
Swing er absolut ikke baseret på AWT
alle Swing komponenter arver fra jcomponent, som arver fra java.awt.Container - så alt swing er særdeles baseret på awt. Uden awt, ingen swing.
Det har netop den store fordel at swing tegner og opfører sig ens på alle platforme (+/- et par % ;)) - hvilket desværre ikke er det samme som man kan sige om swt & awt - eller winforms for den sags skyld.
Swing er baseret på en komplekst MVC arkitektur som er ren Java og hvor det er JVM'en der for at rendere.
Siden hvornår er MVC pattern blevet komplekst? - det er en del af GoF's introduktions kapitel!
Sidst men ikke mindst har en JVM aldrig renderet en dyt - den kalder andre eksterne libraries (gdi, ogl osv.) til at tegne.
Det er jo derfor man har konceptet L&F og årsagen til hvorfor Swing er langsommere end AWT/SWT!
Nu er fleksibilitet jo trodsalt typisk langsommere end begrænsede løsninger som AWT. (Kan ikke helt vurdere swt's fleksibilitet vs. swing - har jo jfaces og sådan noget). Men mange siger faktisk at swing er hurtigere end SWT under linux - så kan man jo tænke hvad man vil.
Jeg har ikke ret gode erfaringer med det. Der er kommet en del forbedringer i 2005 - men har kun prøvet express som er kastreret.
men i flæng kan man da nævne mangel på refactoring og integreret cvs eller svn (source safe har jeg kun prøvet for et stykke tid siden - og jeg svor aldrig at røre den gang makværk af et program!!!! - godt nok en torn i øjet på mange af microsofts ellers udemærkede værktøjer), ordenlig gui designer (sammenlignet med matisse), profiling osv.
men i flæng kan man da nævne mangel på refactoring og integreret cvs eller svn (source safe har jeg kun prøvet for et stykke tid siden - og jeg svor aldrig at røre den gang makværk af et program!!!! - godt nok en torn i øjet på mange af microsofts ellers udemærkede værktøjer), ordenlig gui designer (sammenlignet med matisse), profiling osv.
øhh - det er slet ikke korrekt det du siger. Man kan sagtens have kode der er lavet til .net 1.0 som også kan køre på .net 2.0.
Du misser pointen. Prøv at lav en søgning på dine drev og se hvor mange VM'er du har installeret. Og svar så på spørgsmålet, hvorfor så mange hvis de er bagudkompatible? Med .NET ved du hvorfor du skal bruge en ver 1.0, 2.0 eller 3.0.
alle Swing komponenter arver fra jcomponent, som arver fra java.awt.Container
Container er bare en abstrakt klasse der arver fra Component. Hvorfor tror du Component.java er fyldt med tests for om en peer er en instans af en LightweightPeer? Fordi der delegeres forskellige afhængig af om det er LightWeight (AWT) eller HeavyWeight (Swing).
siden hvornår er MVC pattern blevet komplekst? - det er en del af GoF's introduktions kapitel!
Sidst men ikke mindst har en JVM aldrig renderet en dyt - den kalder andre eksterne libraries (gdi, ogl osv.) til at tegne.
MVC er pr. definition kompleks, fordi der indgår flere andre patterns (Strategy, Composite og Observer). Du kan jo så tilføje Command, Abstract factory, Adaptor mf. og så begynder det at blive tydeligt hvor svært det er at gennemskue og bruge Swing korrekt for alm. dødelige programmører.
Kan vi i det mindste blive enige om at det ville have været rart og mere konsistent hvis SUN havde implementeret SWT istedet for Swing og distribuerede den med deres VM? Hvem er alligevel intereseret i at glo på Metal på deres Windowsboks eller Motif på deres Mac?
Sun burde lave Java og tilhørende teknologier til en åben standard, ligesom MS var smarte nok til at gøre med .NET. Det vil gavne open source verdenen utrolig meget, og Sun behøver ikke selv at lave deres implementation open source hvis de ikke vil det.Det er den da allerede. Der findes indtil flere forsøg på at lave en åben implementation af Java. I flæng nævner jeg GNU Classpath og Apache Harmony. Ingen af dem er færdige, men Harmony gør så vidt jeg ved en del fremskridt. Det er korrekt at Suns egen JVM ikke er åben, men det er jo det samme med MS's .NET-ting. Meget tyder på at Sun på et tidspunkt vil udgive koden under en fri licens, men det er altså ikke sket endnu.
Derudover findes flere lukkede implementationer lavet af eksempelvis IBM og der var også engang en Microsoft JVM, som de stoppede med at udvikle på da Sun forbød dem at lave den inkompatibel med de andre. Det var anledningen til at de gik igang med .NET.
Du misser pointen. Prøv at lav en søgning på dine drev og se hvor mange VM'er du har installeret.
jeg har 2: Java 5 som er current stable, og Java 6 som er beta ...
ligeledes har jeg .net 2 installeret - som fint kører 1.0 og 1.1 kode - fordi de alle er bagud kompatible!
Container er bare en abstrakt klasse der arver fra Component. Hvorfor tror du Component.java er fyldt med tests for om en peer er en instans af en LightweightPeer? Fordi der delegeres forskellige afhængig af om det er LightWeight (AWT) eller HeavyWeight (Swing).
det ændrer da stadigt ikke på at swing er baseret på awt - du kan ikke have swing uden en awt del - det er rent arv.
Kan vi i det mindste blive enige om at det ville have været rart og mere konsistent hvis SUN havde implementeret SWT istedet for Swing og distribuerede den med deres VM?nope. SWT er infleksibelt, underlig og samme problem som swing - 1 thread access. Jeg har en forkærlighed til AWT som er dejlig simpelt :) - alternativt opengl
Hvem er alligevel intereseret i at glo på Metal på deres Windowsboks eller Motif på deres Mac?Det vil dem der har enterprise applikationer der skal supporteres på mange computere hvor et fælles look er kritisk. Det klarer man ikke uden theming - på den ene eller anden måde.
EDIT - swt er ikke direkte infleksibelt, men knap så fleksibelt som swing. Jeg er personligt ikke vild med API'et - men det virker bedre designet backend wise.
Det vil dem der har enterprise applikationer der skal supporteres på mange computere hvor et fælles look er kritisk. Det klarer man ikke uden theming - på den ene eller anden måde.
Nu er de fleste EE applikationer med interaktionsbehov ikke bygget op omkring tunge Swing klienter, men web-præsentationslag i form af UIX, MyFaces, JSF, Tapestry osv.
Jeg har en forkærlighed til AWT som er dejlig simpelt :) - alternativt opengl
Mustang vil få 2D renderingen sat kraftigt i vejret på både OpenGL og DirectX siden. Java 5 (og dermed Swing) bruger jo kun Direct3D til at tegne diagonale linier og firkanter, hvilket er for ringe i disse tider hvor GPU'er har mere regnekraft end CPU'er!
#17
Sorry to say, men jeg tror ikke helt du har sat dig ind i VS. :-)
Refactoring er et plugin du bare kan downloade (ja den er ikke oppe på IntelliJ niveau men absolut brugbar)
Et CVS er ikke noget der hører hjemme i et IDE. Der kan være et interface til et CVS hvilket der også er i VS.
F.eks. til Microsoft Sourcesafe (ja man kan mene hvad man vil).
Til Perforce er der f.eks. også et plugin.
Jeg bruger selv TortoiseSVN til at check ind/ud i SVN med, og bruger Visual Studio som udviklingsværktøj. Det fungere upåklageligt.
Jeg havde også en gang noget imod VS, da jeg startede på ingeniør studiet i 1995, der var det noget hø. Men i dag er det et særdeles godt IDE, selv i den gratis Express udgave. Højest lidt irriterende der er forskellige versioner alt efter om du vil lave applikationer eller kode til web.
Men integrationen til f.eks. MsSQL er rigtig dejlig, så man kan tilgå Stored Procedures direkte, få lavet typed dataset osv.
Men selvfølgelig er det smag og behag. :) (jeg hadede det selv i starten på arbejdet. Indtil jeg lige fik sat mig ind i tingene og vendet mig til det ikke var IntelliJ jeg arbejdede med.)
Sorry to say, men jeg tror ikke helt du har sat dig ind i VS. :-)
Refactoring er et plugin du bare kan downloade (ja den er ikke oppe på IntelliJ niveau men absolut brugbar)
Et CVS er ikke noget der hører hjemme i et IDE. Der kan være et interface til et CVS hvilket der også er i VS.
F.eks. til Microsoft Sourcesafe (ja man kan mene hvad man vil).
Til Perforce er der f.eks. også et plugin.
Jeg bruger selv TortoiseSVN til at check ind/ud i SVN med, og bruger Visual Studio som udviklingsværktøj. Det fungere upåklageligt.
Jeg havde også en gang noget imod VS, da jeg startede på ingeniør studiet i 1995, der var det noget hø. Men i dag er det et særdeles godt IDE, selv i den gratis Express udgave. Højest lidt irriterende der er forskellige versioner alt efter om du vil lave applikationer eller kode til web.
Men integrationen til f.eks. MsSQL er rigtig dejlig, så man kan tilgå Stored Procedures direkte, få lavet typed dataset osv.
Men selvfølgelig er det smag og behag. :) (jeg hadede det selv i starten på arbejdet. Indtil jeg lige fik sat mig ind i tingene og vendet mig til det ikke var IntelliJ jeg arbejdede med.)
#16
Sammen grund som ikke at bruge eclipse, f.eks. at være på en platform som ikke understøtter dit farvoridt IDE... hovsa, rigtigt.. .NET er wind0ws only.
Personligt foretrækker jeg stadig min text-editor med commandline compile til non-gui applications. Derudover har de gui-applications jeg f.eks. har udviklet i java slet ikke være understøttet af en "WYSIWYG" editor, da vi snakker om at skrive extendede gui spots, som ikke kan renderes af et "WYSIWYG" og derfor fucker kode op. (Ja, sidstnævnte er i java).
Derudover til jeg påpege at Java Enterprice f.eks. er noget du kan arbejde med på maskiner som AS/400, hvor du typisk ikke vil benyttet eclipse som første udviklingsværktøj ;)
Hvis I bliver ved med at tro at programmering er noget som handler on windows/linux til en brugerplatform, så bør i snart tage og lære noget andet. Synes dette kendetegnerne programmørne på newz.dk , de tror alting er 1) med GUI 2) til win/*nix only.
Og mht. java og bagudkompatibelthed, så er det da skrottet for længest, der er en del i 1.5 som ikke er 1.4 compat :) ved så ikke om det også gælder for enterprise versionen, men ville jeg nu tro.
Sammen grund som ikke at bruge eclipse, f.eks. at være på en platform som ikke understøtter dit farvoridt IDE... hovsa, rigtigt.. .NET er wind0ws only.
Personligt foretrækker jeg stadig min text-editor med commandline compile til non-gui applications. Derudover har de gui-applications jeg f.eks. har udviklet i java slet ikke være understøttet af en "WYSIWYG" editor, da vi snakker om at skrive extendede gui spots, som ikke kan renderes af et "WYSIWYG" og derfor fucker kode op. (Ja, sidstnævnte er i java).
Derudover til jeg påpege at Java Enterprice f.eks. er noget du kan arbejde med på maskiner som AS/400, hvor du typisk ikke vil benyttet eclipse som første udviklingsværktøj ;)
Hvis I bliver ved med at tro at programmering er noget som handler on windows/linux til en brugerplatform, så bør i snart tage og lære noget andet. Synes dette kendetegnerne programmørne på newz.dk , de tror alting er 1) med GUI 2) til win/*nix only.
Og mht. java og bagudkompatibelthed, så er det da skrottet for længest, der er en del i 1.5 som ikke er 1.4 compat :) ved så ikke om det også gælder for enterprise versionen, men ville jeg nu tro.
Sorry to say, men jeg tror ikke helt du har sat dig ind i VS. :-)njo - bruger det da ret tit, men det er til c/c++ - ikke .net development. Men det burde også være lige meget. Problemt er - udover at jeg skal ud og finde en masse plugins til at får IDE'et til at virke "ordenligt" - at express ikke tillader plugins!!!
men ja - jeg mente selvf. at versionering skulle kunne installeres som plugin - ikke med direkte integreret klient.
igen antager du at alle koder op mod noget nyt. Java+swing har eksisteret siden 97 - der er stadig 1.1 kode derude (swing har virket siden 1.1, og kom officielt med under 1.2 (aka java 2))
Nu er de fleste EE applikationer med interaktionsbehov ikke bygget op omkring tunge Swing klienter, men web-præsentationslag i form af UIX, MyFaces, JSF, Tapestry osv.
#24
Det var da en seriøs arrogant holdning du har, og meget dømmende af os udviklere.
Der er INTET der forhindrer dig i at sidde i dit favorit OS med din favorit editor/ide og udvikle software til AS/400.
Jeg har selv været med til at udvikle Java til en mobil telefon, udviklingen foregik på windows, jeg brugte Forte de andre JBuilder, vi simulerede på windows, compilede til target på HP servere, og smid i telefonerne derefter. Så du kan godt se tingene kan sagtens kombineres.
Det jeg var med til at lave var ikke GUI applikationer, men selve GUI'en :)
Det skal du velkommen til, jeg har dog valgt at bruge et IDE da det for mit vedkommende gør at jeg kan udvikle meget hurtigere, end i en alm. editor. Og bøvlet med command line compiling og opsætning af Make/Ant/osv scripts gider jeg ærligt talt ikke spilde min tid på. Jeg vil hellere lave arkitektur og design software og senere koden den, eller sætte andre til det.
Ja i VS kan du lave dine egne GUI elementer som også virker i GUI editoren. :-) Så det må havde været det IDE du har brugte der ikke var helt så smart :)
Hvis I bliver ved med at tro at programmering er noget som handler on windows/linux til en brugerplatform, så bør i snart tage og lære noget andet. Synes dette kendetegnerne programmørne på newz.dk , de tror alting er 1) med GUI 2) til win/*nix only.
Det var da en seriøs arrogant holdning du har, og meget dømmende af os udviklere.
Derudover til jeg påpege at Java Enterprice f.eks. er noget du kan arbejde med på maskiner som AS/400, hvor du typisk ikke vil benyttet eclipse som første udviklingsværktøj ;)
Der er INTET der forhindrer dig i at sidde i dit favorit OS med din favorit editor/ide og udvikle software til AS/400.
Jeg har selv været med til at udvikle Java til en mobil telefon, udviklingen foregik på windows, jeg brugte Forte de andre JBuilder, vi simulerede på windows, compilede til target på HP servere, og smid i telefonerne derefter. Så du kan godt se tingene kan sagtens kombineres.
Det jeg var med til at lave var ikke GUI applikationer, men selve GUI'en :)
Personligt foretrækker jeg stadig min text-editor med commandline compile til non-gui applications.
Det skal du velkommen til, jeg har dog valgt at bruge et IDE da det for mit vedkommende gør at jeg kan udvikle meget hurtigere, end i en alm. editor. Og bøvlet med command line compiling og opsætning af Make/Ant/osv scripts gider jeg ærligt talt ikke spilde min tid på. Jeg vil hellere lave arkitektur og design software og senere koden den, eller sætte andre til det.
da vi snakker om at skrive extendede gui spots, som ikke kan renderes af et "WYSIWYG" og derfor fucker kode op. (Ja, sidstnævnte er i java).
Ja i VS kan du lave dine egne GUI elementer som også virker i GUI editoren. :-) Så det må havde været det IDE du har brugte der ikke var helt så smart :)
Personligt foretrækker jeg stadig min text-editor med commandline compile til non-gui applications.
De dage er over hvor en sådan holdning får dig til at lyde cool. jeg kan slet ikke forestille mig at skulle skrive ADF og UIX kode med bindingslag og metadata i hånden, det ville tage flere år.
Hvor mange her bruger så rent faktisk J(2|5)EE til seriøs udvikling? Og med seriøs mener jeg i arbejdsøjemed. Det virker ikke som om det er ret mange, siden I har skiftet fokus fuldstændigt over på stereotypiske udtalelser og personlige holdninger til GUI, IDE'er og alt muligt andet nærmest irrelevant =)
Java er for mig en eksponent for OO programmering taget til det ekstreme. Alt skal i klasser. Man kan snart ikke have en enkelt bit i fred længere når man programmerer java. I mine øjne er det ikke en fordel i sig selv at have et vanvittigt stort antal klasser, så hellere have en lidt slankere struktur man kan overskue... Jeg synes java falder lidt ned i accidental complexity faldgruben: http://en.wikipedia.org/wiki/Accidental_complexity
Hvad betyder det? Kæmpe overhead pga. infrastruktur i programmerne, bunker af garbage som skal ryddes op af VM => ramforbrug, og tja, at have en VM i sig selv er også et kæmpe overhead. Jeg ved godt at JIT compilere og lign. kan forbedre performance, men det er stadigt et stort maskineri der liige skal op i omdrejninger før det spiller.
Når jeg hyggehacker, må jeg nok erkende at jeg stadig hælder til VB6 den dag i dag. Man kan lave GUI sindsygt hurtigt og en fin lille OO struktur til data+logik, og det bedste er at ens executable fylder ingenting og bruger meget få ressourcer.
#9 Derfor blev java+swing ikke den nye VB6 for mig :)
Hvad betyder det? Kæmpe overhead pga. infrastruktur i programmerne, bunker af garbage som skal ryddes op af VM => ramforbrug, og tja, at have en VM i sig selv er også et kæmpe overhead. Jeg ved godt at JIT compilere og lign. kan forbedre performance, men det er stadigt et stort maskineri der liige skal op i omdrejninger før det spiller.
Når jeg hyggehacker, må jeg nok erkende at jeg stadig hælder til VB6 den dag i dag. Man kan lave GUI sindsygt hurtigt og en fin lille OO struktur til data+logik, og det bedste er at ens executable fylder ingenting og bruger meget få ressourcer.
#9 Derfor blev java+swing ikke den nye VB6 for mig :)
#30 Nu slipper du heller ikke billigere i C#/Vb.net/C++.net ... det er faktisk nemmere at udvikle programmer når man har et "real-world picture" af et domæne model. Det er faktisk muligt at implementere små dele i sit program, og holde de enkelte klasser adskilt, så hvis du fucker up i én ting, ryger de andre ikke.
Jeg er ikke selv vild med Java. Mest pga. den dovenskab Sun har udvist med at holde class-bibliotekerne opdaterede. Deres dovenskab kommer til fulde med deres Java API side, som virkelig er afskyelig grim og utiltalende. Jeg holder mig altid til den implementation der er bedst supported på den givne platform. I dette tilfælde .NET på Windows. (sproget er jo heldigvis ligegyldigt).
Sun prøver helt klart at få Java til at blive det populære udviklingsalternativ på Linux m.m. for at vippe GTK+, Qt m.m. af pinden.
Selvom Ram og harddiskplads, er peanuts at betale for et stort firma, er der stadigvæk nogen der vil presse hver eneste bit ud af citronen for at udnytte processor-kraft og ram og ikke vil spilde den på at køre et framework i baggrunden.
Jeg er ikke selv vild med Java. Mest pga. den dovenskab Sun har udvist med at holde class-bibliotekerne opdaterede. Deres dovenskab kommer til fulde med deres Java API side, som virkelig er afskyelig grim og utiltalende. Jeg holder mig altid til den implementation der er bedst supported på den givne platform. I dette tilfælde .NET på Windows. (sproget er jo heldigvis ligegyldigt).
Sun prøver helt klart at få Java til at blive det populære udviklingsalternativ på Linux m.m. for at vippe GTK+, Qt m.m. af pinden.
Selvom Ram og harddiskplads, er peanuts at betale for et stort firma, er der stadigvæk nogen der vil presse hver eneste bit ud af citronen for at udnytte processor-kraft og ram og ikke vil spilde den på at køre et framework i baggrunden.
#31 Det' sandt, .net er ikke et hak bedre end java mht. resourceforbrug. Men samtidigt er det så utroligt let at programmere C# må jeg medgive. Men det kan gøre een nervøs - når man sidder med en linje kode og tænker, den må godt nok blive til nogle millioner/milliarder opcodes at eksekvere...
Jeg hører hjemme under den "nogen" :). Men det skyldes nok at jeg primært koder til embedded (microcontroller), her tæller alle bits og bytes (som regel)
Selvom Ram og harddiskplads, er peanuts at betale for et stort firma, er der stadigvæk nogen der vil presse hver eneste bit ud af citronen for at udnytte processor-kraft og ram og ikke vil spilde den på at køre et framework i baggrunden.
Jeg hører hjemme under den "nogen" :). Men det skyldes nok at jeg primært koder til embedded (microcontroller), her tæller alle bits og bytes (som regel)
#32
Hvilket er tilfældet i alle compilerede sprog, om man så compiler/linker direkte til assembler, eller først til et intermidiate sprog, og derfra videre til assembler er irrelevant.
Men generelt betyder det ikke så meget når man tænker på hvor gode compilerne er idag.
Men udvikleren skal dog stadigvæk tænke sig om.
når man sidder med en linje kode og tænker, den må godt nok blive til nogle millioner/milliarder opcodes at eksekvere...
Hvilket er tilfældet i alle compilerede sprog, om man så compiler/linker direkte til assembler, eller først til et intermidiate sprog, og derfra videre til assembler er irrelevant.
Men generelt betyder det ikke så meget når man tænker på hvor gode compilerne er idag.
Men udvikleren skal dog stadigvæk tænke sig om.
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