mboost-dp1
unknown
Den har også meget bedre gtk (look) understøttelse: http://elliotth.blogspot.com/2006/04/gtk-laf-in-ja...
#1 Hvilket i øvrigt skyldes, at de nu ikke emulerer widgetsne, men rent faktisk bruger dem. http://www.jroller.com/page/swingbling?entry=java_...
Vista look and feel lader dog til at sakke lidt bag ud: http://weblogs.java.net/blog/chet/archive/2006/10/...
Vista look and feel lader dog til at sakke lidt bag ud: http://weblogs.java.net/blog/chet/archive/2006/10/...
100% offtopic post, intet som helst nyhedsrelateret her!
Jeg glæder mig til der kommer en ny version af et produkt, og der står at det tager længere tid og er sværere at udvikle i.
Bare for at se det.
Jeg installerede forleden Windows 3.11 i en virtuel maskine, mest for sjov. Men det er altså også "Hurtigere og mere stabilt end nogensinde før" (eller hvordan det nu var formuleret).
Jeg glæder mig til der kommer en ny version af et produkt, og der står at det tager længere tid og er sværere at udvikle i.
Bare for at se det.
Jeg installerede forleden Windows 3.11 i en virtuel maskine, mest for sjov. Men det er altså også "Hurtigere og mere stabilt end nogensinde før" (eller hvordan det nu var formuleret).
Flottere look i Java? Det er da en af de bedste Java-nyheder længe. Så kan de være at man kan programmere det, uden konstant at skulle have en brækspand ved siden af sig.
Er det så også flottere look som default, eller skal man bruge nogle hemmelige, udokumenterede biblioteker som desuden kræver seperat installation af Gtk?
Hr. Ellioth skriver også at det godt ligner rimmelig godt, men at det er fyldt med bugs! WTF?????
Og hvad mon med koden til interface-programmeringen? Er den stadigvæk lige så ukonsistent som den altid har været?
Er det så også flottere look som default, eller skal man bruge nogle hemmelige, udokumenterede biblioteker som desuden kræver seperat installation af Gtk?
Hr. Ellioth skriver også at det godt ligner rimmelig godt, men at det er fyldt med bugs! WTF?????
Og hvad mon med koden til interface-programmeringen? Er den stadigvæk lige så ukonsistent som den altid har været?
illshar>>>Hvad mener du interface programmeringen fejler? At man ikke kan define constructors? eller statiske metoder?
For det er på ingen måde fejl, men bevidste og smarte design valg.
Dog savner jeg flerdobbelt nedarvning i java, men med cglib, er det faktisk muligt efter mixins princippet, hvilket imo er et genialt komprimis med farene og mulighederne med flerdobbelt nedarvning.
Til dem der ikke kender til mixins:
In object-oriented programming languages, a mixin is a class that provides a certain functionality to be inherited by a subclass, but is not meant to stand alone. Inheriting from a mixin is not a form of specialisation but is rather a means to collect functionality. A subclass may even choose to inherit most or all of its functionality by inheriting from one or more mixins through multiple inheritance.
For det er på ingen måde fejl, men bevidste og smarte design valg.
Dog savner jeg flerdobbelt nedarvning i java, men med cglib, er det faktisk muligt efter mixins princippet, hvilket imo er et genialt komprimis med farene og mulighederne med flerdobbelt nedarvning.
Til dem der ikke kender til mixins:
In object-oriented programming languages, a mixin is a class that provides a certain functionality to be inherited by a subclass, but is not meant to stand alone. Inheriting from a mixin is not a form of specialisation but is rather a means to collect functionality. A subclass may even choose to inherit most or all of its functionality by inheriting from one or more mixins through multiple inheritance.
#8 Jeg savner også en del ting; ordentlig implementering af generics, duck typing mm. men mest af alt håber jeg "nogen" *skuler til Google* vil tage og lave en ordentlig fork af Java og få ryddet op i de efterhånden 16.000 klasser hvor der er alt for meget depricated og oppustethed!
*Tager noget Samarin og så tilbage til arbejdet*
*Tager noget Samarin og så tilbage til arbejdet*
#11 Oppustethed (bloat?) er vel kun et problem hvis det går ud over performance? Depricated metoder bliver svjv fjernet efter et par releases, men det pointen med at beholde dem er jo at folk ikke skal omskrive al for meget gammel kode hver gang der kommer et nyt release. Det er der nok mange i industrien som er glade for...
Man kan sige meget om javas generics, men jeg kan ikke umiddelbart se at det kunne være lavet bedre uden at lave væsentligt om på så godt som alle specifikationer og klasser i class library. En præprocessor-løsning (som i C++) ville gå heftigt ud over størrelsen på den compilede kode...
Man kan sige meget om javas generics, men jeg kan ikke umiddelbart se at det kunne være lavet bedre uden at lave væsentligt om på så godt som alle specifikationer og klasser i class library. En præprocessor-løsning (som i C++) ville gå heftigt ud over størrelsen på den compilede kode...
#11
Der er sikkert mange som mener at der er meget overflødigt i Java
API, men jeg har bare en mistanke om at de ikke vil kunne blive
enige om hvad der er overflødigt. Forskellige brugere har
forskellige behov. Mange brugere => mange behov => mange
klasser.
.NET, Win32, SUS er heller ikke ligefrem små API'er.
Der er sikkert mange som mener at der er meget overflødigt i Java
API, men jeg har bare en mistanke om at de ikke vil kunne blive
enige om hvad der er overflødigt. Forskellige brugere har
forskellige behov. Mange brugere => mange behov => mange
klasser.
.NET, Win32, SUS er heller ikke ligefrem små API'er.
#5
Plejer selv at bruge det som nedenstående. Det sætter automatisk look and feal på alle platforme.
import javax.swing.UIManager;
UIManager.setLookAndFeel(
UIManager.getSystemLookAndFeelClassName());
main = new Main();
Er det så også flottere look som default, eller skal man bruge nogle hemmelige, udokumenterede biblioteker som desuden kræver seperat installation af Gtk?
Plejer selv at bruge det som nedenstående. Det sætter automatisk look and feal på alle platforme.
import javax.swing.UIManager;
UIManager.setLookAndFeel(
UIManager.getSystemLookAndFeelClassName());
main = new Main();
#15
Jo.
Der er ingen garanti for at folks fork kan klare de test, eller at den fork de laver kaldes for 'Javaa' osv.
Der er en overhængende chance for at sproget kan blive ødelagt af en fork.
F.eks. hvis folk synes der skal være multiple arv i det, men Sun ikke synes det, pludseligt kan det kun compiles med en speciel compiler som ikke er Sun Java, men en eller anden absurt afart.
Jo.
Der er ingen garanti for at folks fork kan klare de test, eller at den fork de laver kaldes for 'Javaa' osv.
Der er en overhængende chance for at sproget kan blive ødelagt af en fork.
F.eks. hvis folk synes der skal være multiple arv i det, men Sun ikke synes det, pludseligt kan det kun compiles med en speciel compiler som ikke er Sun Java, men en eller anden absurt afart.
#5, #16:
og det skal nævnes, at ønsker man at override, kan det gøres:
export _JAVA_OPTIONS="-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" :)
alt i alt vil jeg sige at java nu er blevet okay, 1.4 var virkelig skrammel, men 1.5 var ganske fin, og 1.6 er nu ret god.
#17:
det bliver sproget jo ikke ødelagt af..
alle kan da også implementere mærkelige version af c++, baseret på gcc, eller andre compilere (og faktisk er der nogle der har gjort det, det er bare meget lidt kendt), det har da ikke skadet c/c++.
og det skal nævnes, at ønsker man at override, kan det gøres:
export _JAVA_OPTIONS="-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel" :)
alt i alt vil jeg sige at java nu er blevet okay, 1.4 var virkelig skrammel, men 1.5 var ganske fin, og 1.6 er nu ret god.
#17:
det bliver sproget jo ikke ødelagt af..
alle kan da også implementere mærkelige version af c++, baseret på gcc, eller andre compilere (og faktisk er der nogle der har gjort det, det er bare meget lidt kendt), det har da ikke skadet c/c++.
#18
Der er dog den væsentlige forskel på c og java, at java bliver kompileret just in time, mens c kode kun skal kompileres en gang. Det betyder at et program der fungerer på en fork, kun ville kræve at en person kompilerer med den fork, for at programmet kan distributeres, hvis det er under c, mens alle brugere skal benytte forken under java. Det er for ikke at nævne, at begge dele er dårlig stil.
#11
Nu er der jo andre java distributioner i suns, det er bare suns der er den største og mest understøttede, men hvis du vil se på en der er mindre, er der rigeligt at vælge fra.
Der er dog den væsentlige forskel på c og java, at java bliver kompileret just in time, mens c kode kun skal kompileres en gang. Det betyder at et program der fungerer på en fork, kun ville kræve at en person kompilerer med den fork, for at programmet kan distributeres, hvis det er under c, mens alle brugere skal benytte forken under java. Det er for ikke at nævne, at begge dele er dårlig stil.
#11
Nu er der jo andre java distributioner i suns, det er bare suns der er den største og mest understøttede, men hvis du vil se på en der er mindre, er der rigeligt at vælge fra.
#17
En ikke kompatibel fork kaldet javaa er ikke java.
Kalder de den java kan de blive sagsøgt langt ind i helvede.
Der er faktisk en enkelt styk præcedens for at det koster 20
millioner dollar at kalde noget Java som ikke overholder Java
specs.
Jeg kan ikke umiddelbart komme i tanke om et sprog der er blevet
ødelagt af en ukomplet implementation der ikke overholder
standarden.
En ikke kompatibel fork kaldet javaa er ikke java.
Kalder de den java kan de blive sagsøgt langt ind i helvede.
Der er faktisk en enkelt styk præcedens for at det koster 20
millioner dollar at kalde noget Java som ikke overholder Java
specs.
Jeg kan ikke umiddelbart komme i tanke om et sprog der er blevet
ødelagt af en ukomplet implementation der ikke overholder
standarden.
#19 Jo, Microsoft ville i høj grad gerne have noget med Java at gøre. De lavede, som du skriver, deres egen JVM, men de lavede den en anelse inkompatibel (samme strategi som de brugte med HTML i kampen mod Netscape) med Sun's JVM og så begyndte de ellers i stor stil at bundle det med Windows for at presse Sun ud af markedet. Dette endte med en retssag hvor MS fik forbud mod at fortsætte og indvilligede i at stoppe udviklingen af deres JVM. Derefter startede de .NET som stort set er en videreudvikling af Java-ideen.
#24 Der er jo flere holdninger til det du siger. Spørger du Anders Hejlsberg, siger han at de forbedrede Java og jeg husker da studiekamerater der "vi skriver det i Java" mens de aldrig kunne drømme om at forlade Visual Studio til at gøre det i. Det ironiske er nu at en sådan fork er lovlig, men nu er de (Microsoft) bare ikke længere intereseret jvf. det noget mere modne og produktive C#.
#25 Hvis du har skrevet til begge API'er vil du vide hvad jeg mener.
Nej jeg er ikke MS fanboy (med C# snakker jeg primært om Mono), men arbejder med Java hver eneste dag og oplever dets stridigheder og mangler. C# har ikke en 10 år gammel hale at slæbe rundt på, så simpelt er det bare. Det er min mening og jeg kan sagtens bakke den op, men af risiko for at blive udnævnt som troll stopper jeg her.
Nej jeg er ikke MS fanboy (med C# snakker jeg primært om Mono), men arbejder med Java hver eneste dag og oplever dets stridigheder og mangler. C# har ikke en 10 år gammel hale at slæbe rundt på, så simpelt er det bare. Det er min mening og jeg kan sagtens bakke den op, men af risiko for at blive udnævnt som troll stopper jeg her.
#28
Jeg kan kun give dig ret, har selv i mange år været Java udvikler, og kunne ikke snuppe .net Frameworket.
Men efter .Net er blevet V2.0 og nu V3.0 er det i mine øjne et langt bedre framework at arbejde med. At Visual Studio så samtidigt er et virkeligt godt udviklingsmiljø skader bestemt heller ikke.
Mono synes jeg så ikke er brugbart endnu til .Net 2.0 for mange problemmer, sidst jeg prøvede.
Jeg kan kun give dig ret, har selv i mange år været Java udvikler, og kunne ikke snuppe .net Frameworket.
Men efter .Net er blevet V2.0 og nu V3.0 er det i mine øjne et langt bedre framework at arbejde med. At Visual Studio så samtidigt er et virkeligt godt udviklingsmiljø skader bestemt heller ikke.
Mono synes jeg så ikke er brugbart endnu til .Net 2.0 for mange problemmer, sidst jeg prøvede.
#25
Og der er ikke meget som har ændret sig med hensyn til at lave en
Java implementation.
Det har altid været legalt at lave en kompatibel java implementation.
Adskillige sådanne er også lavet.
Og overholder de specs er der ikke noget problem.
Det eneste som er nyt er at nu kan man hvis man kan leve med
GPL licens basere sit arbejde på SUN's implementation. Før
skulle man enten selv lave det hele eller betale SUN.
Og der er ikke meget som har ændret sig med hensyn til at lave en
Java implementation.
Det har altid været legalt at lave en kompatibel java implementation.
Adskillige sådanne er også lavet.
Og overholder de specs er der ikke noget problem.
Det eneste som er nyt er at nu kan man hvis man kan leve med
GPL licens basere sit arbejde på SUN's implementation. Før
skulle man enten selv lave det hele eller betale SUN.
Det er bestemt ikke den eneste forskel, nu tænker du en smule for snæversynet.
Forskellen er nu nemlig, at det ikke er en lukket kommision (JCP) der kan sidde og trække tingene i langdrag med deres lukkede JSR spec, advokater og kommercielle interesser. Nu er der brugerne (det er os) der bestemmer. Ligesom Python og Ruby, hvor et library først skal "vise sit værd" før at blive accepteret i kernen. I Java verdenen er der mange eksempler på problemerne med denne top-down kommision.
1) Læg mærke til at der absolut ingen spec findes for f.eks. swing.plaf.basic, en meget central del af JSE skulle jeg mene.
2) EJB2 blev aldrig nogen success, først da man kiggede på et community/buttom-up projekt (Hibernate) kommer kommisionen med et nyt udkast de nu kalder EJB3. Det samme er tilfældet med alle de LayoutMangers Sun har prøvet sig med de sidste 10 år, først da de kiggede på Visual Studio kom de på GroupLayout og har implementeret noget a la Visual Studio i NetBeans 5.0 (Matisse).
3) Tilbage i 1999 klagede brugere over at den meget anvendelige BASE64 encoding/decoding ligger i en skjult sun.misc pakke der bør gøres offentlig. Vi skriver nu næste n2007 og der er stadig ingen hos Sun der har reageret.
4) De bedste ting i Java er kommet fra brugerne og retter fejl/magler i Sun's klodsede API. Dette inkluderer Joda Time, Log4J, JUnit, JGoodies, Jakarta Commons osv.
Det problem Sun nu har er omkring forvaltningen. De vil gerne være populære pga. at Java nu er open source, men de vil også lige så godt bevare kontrollen så de ikke mister den - lige som de var ved da Microsoft pillede. Nogen er sågår gået i vrede over dette.
Forskellen er nu nemlig, at det ikke er en lukket kommision (JCP) der kan sidde og trække tingene i langdrag med deres lukkede JSR spec, advokater og kommercielle interesser. Nu er der brugerne (det er os) der bestemmer. Ligesom Python og Ruby, hvor et library først skal "vise sit værd" før at blive accepteret i kernen. I Java verdenen er der mange eksempler på problemerne med denne top-down kommision.
1) Læg mærke til at der absolut ingen spec findes for f.eks. swing.plaf.basic, en meget central del af JSE skulle jeg mene.
2) EJB2 blev aldrig nogen success, først da man kiggede på et community/buttom-up projekt (Hibernate) kommer kommisionen med et nyt udkast de nu kalder EJB3. Det samme er tilfældet med alle de LayoutMangers Sun har prøvet sig med de sidste 10 år, først da de kiggede på Visual Studio kom de på GroupLayout og har implementeret noget a la Visual Studio i NetBeans 5.0 (Matisse).
3) Tilbage i 1999 klagede brugere over at den meget anvendelige BASE64 encoding/decoding ligger i en skjult sun.misc pakke der bør gøres offentlig. Vi skriver nu næste n2007 og der er stadig ingen hos Sun der har reageret.
4) De bedste ting i Java er kommet fra brugerne og retter fejl/magler i Sun's klodsede API. Dette inkluderer Joda Time, Log4J, JUnit, JGoodies, Jakarta Commons osv.
Det problem Sun nu har er omkring forvaltningen. De vil gerne være populære pga. at Java nu er open source, men de vil også lige så godt bevare kontrollen så de ikke mister den - lige som de var ved da Microsoft pillede. Nogen er sågår gået i vrede over dette.
#32
Mig bekendt er der intet ændret ved rolle fordelingen. JCP
styrer stadigt hvad der er Java.
SUN har bare udgivet deres reference implementation som
open source under GPL.
Alle standardiserede sprog har en komite som styrer hvad
der kommer i sproget.
Det står enhver frit at lave ekstra libraries etc..
Det sker i stor stil for C++. Det sker i stor stil for Java. Det
har hverken ISO/ANSI C++ komiteen eller JCP noget imod.
Jeg tror ikke at der kommer en fork.
SUN scorer lidt PR og man får løst Java på Linux problemet en
gang for alle.
re 2)
EJB3 er ikke et udkast men en vedtaget standard.
Det er meget populært at sige at EJB har været en fiasko. Men
hvad er egentligt substansen af det. De mener som regel at
entity beans (1 ud af de 3 EJB typer) er et problem. Det
antager jeg at du også gør da du snakker om Hibernate som
løsning. Der er nogle issues med entity beans. Ikke mindst når folk
har brugt dem til noget som de ikke var beregnet til. Og tro mig
vi kommer også til at høre en del grimme historier om Hibernate
fremover, når den er blevet brugt til noget som den ikke egner
sig til. Hvis man sammenligner EJB med sine forgængere nemlig
CORBA og DCOM/COM+, så vil jeg uden at blink med øjnene sige
at EJB målt på udbredelse er en 20 gange så stor success som
forgængerne.
re 3)
Java har dokumenteret base64 support. Hvorfor syv pokker skulle
de duplikere den i java.util ?
re 1 & 3)
Jeg vil undlade at gøre mig klog på Swing.
Mig bekendt er der intet ændret ved rolle fordelingen. JCP
styrer stadigt hvad der er Java.
SUN har bare udgivet deres reference implementation som
open source under GPL.
Alle standardiserede sprog har en komite som styrer hvad
der kommer i sproget.
Det står enhver frit at lave ekstra libraries etc..
Det sker i stor stil for C++. Det sker i stor stil for Java. Det
har hverken ISO/ANSI C++ komiteen eller JCP noget imod.
Jeg tror ikke at der kommer en fork.
SUN scorer lidt PR og man får løst Java på Linux problemet en
gang for alle.
re 2)
EJB3 er ikke et udkast men en vedtaget standard.
Det er meget populært at sige at EJB har været en fiasko. Men
hvad er egentligt substansen af det. De mener som regel at
entity beans (1 ud af de 3 EJB typer) er et problem. Det
antager jeg at du også gør da du snakker om Hibernate som
løsning. Der er nogle issues med entity beans. Ikke mindst når folk
har brugt dem til noget som de ikke var beregnet til. Og tro mig
vi kommer også til at høre en del grimme historier om Hibernate
fremover, når den er blevet brugt til noget som den ikke egner
sig til. Hvis man sammenligner EJB med sine forgængere nemlig
CORBA og DCOM/COM+, så vil jeg uden at blink med øjnene sige
at EJB målt på udbredelse er en 20 gange så stor success som
forgængerne.
re 3)
Java har dokumenteret base64 support. Hvorfor syv pokker skulle
de duplikere den i java.util ?
re 1 & 3)
Jeg vil undlade at gøre mig klog på Swing.
#33
Hvad nytter det at alle kan lave deres egne libraries osv.
Lad os antage får JCP'en til 3d i mobil telefoner kom, at f.eks. Nokia lavede deres egen 3d API, kunne man så bruge deres spil på andre end nokia telefoner, nej netop fordi det IKKE var en del af java.
Så hjemmefuskede udvidelser er tit noget være hø, eftersom kun meget få kan anvende det.
Hvad nytter det at alle kan lave deres egne libraries osv.
Lad os antage får JCP'en til 3d i mobil telefoner kom, at f.eks. Nokia lavede deres egen 3d API, kunne man så bruge deres spil på andre end nokia telefoner, nej netop fordi det IKKE var en del af java.
Så hjemmefuskede udvidelser er tit noget være hø, eftersom kun meget få kan anvende det.
#35 Hvis det ikke kan overaske nogen, hvordan kan det så være Google på bare første side afslører masser af folk med dette behov der selv har implementeret den:
http://iharder.sourceforge.net/base64/
http://www.source-code.biz/snippets/java/2.htm
http://mindprod.com/jgloss/base64.html
http://www.planet-source-code.com/vb/scripts/ShowC...
Nej, der har aldrig været meget logik i Java mht. pakke organisation eller navne.
http://iharder.sourceforge.net/base64/
http://www.source-code.biz/snippets/java/2.htm
http://mindprod.com/jgloss/base64.html
http://www.planet-source-code.com/vb/scripts/ShowC...
Nej, der har aldrig været meget logik i Java mht. pakke organisation eller navne.
#41
Linux-brugere er vant til at nærmest alt er bundlet. Problemet er ikke større i Linux end i Windows, vi Linux-brugere er bare mere forvænte.
Vi forventer noget bedre end den besværlige og langsommelige process med at gå ind på hjemmesiden, grave et download frem, downloade (accepter betingelser blah blah), finde filen lokalt, starte installer, næste, næste, accepter, næste osv osv.
Min nuværende løsning i Linux fungerer stadig bedre end Windows-installeren, men det ville da være fint, hvis Java kunne installeres på samme måde som næsten alt andet software jeg bruger.
Linux-brugere er vant til at nærmest alt er bundlet. Problemet er ikke større i Linux end i Windows, vi Linux-brugere er bare mere forvænte.
Vi forventer noget bedre end den besværlige og langsommelige process med at gå ind på hjemmesiden, grave et download frem, downloade (accepter betingelser blah blah), finde filen lokalt, starte installer, næste, næste, accepter, næste osv osv.
Min nuværende løsning i Linux fungerer stadig bedre end Windows-installeren, men det ville da være fint, hvis Java kunne installeres på samme måde som næsten alt andet software jeg bruger.
#39 Base64 stammer fra MIME RFC'erne ja, men er i dag en standard måde at escape data for kontroltegn. Bliver brugt til at smide binære data over WebServices, PGP, Hibernate bruger den til at hashe unikke nøgler, Thunderbird til at hashe passwords osv. Når vi nu har java.util.logging, java.util.regex og java.util.zip hvorfor så ikke en java.util.codecs med alle disse konverteringer af data i?!
Al den redundans, deprikering og mangel på transparens gør det svært at være Java programmør og udføre sit daglige arbejde.
Man græmmes.
Al den redundans, deprikering og mangel på transparens gør det svært at være Java programmør og udføre sit daglige arbejde.
Man græmmes.
#44 Jeg var tilbøjelig til at være enig, men:
1) Hvis du følger tråden og læser min post 32 vil du se at jeg startede med at pointere hvorfor BASE64 konverteringen gemt i sun.misc pakken ikke gøres offentlig. Så at Sun har en BASE64 konvertering dér, i deres Mail.jar (nu Glassfish) og sikkert andre steder ER redundant.
2) Problemet er desværre bare at ja, ting bliver depricated, men aldrig fjernet. Dvs. du får en advarsel i IDE'en men koden virker jo stadig. Og så kan man jo nemt komme til at bruge dem. Tag f.eks. Date klassen (der i virkeligheden skulle hedde Time, men det er en anden snak) der er 95% deprikeret. Det har man så flyttet over i GregorianCalendar der skulle have været en utility klasse omkring Date, men hov, den har i virkeligheden udviklet sig til i sig selv at repræsentere et tidspunkt.
1) Hvis du følger tråden og læser min post 32 vil du se at jeg startede med at pointere hvorfor BASE64 konverteringen gemt i sun.misc pakken ikke gøres offentlig. Så at Sun har en BASE64 konvertering dér, i deres Mail.jar (nu Glassfish) og sikkert andre steder ER redundant.
2) Problemet er desværre bare at ja, ting bliver depricated, men aldrig fjernet. Dvs. du får en advarsel i IDE'en men koden virker jo stadig. Og så kan man jo nemt komme til at bruge dem. Tag f.eks. Date klassen (der i virkeligheden skulle hedde Time, men det er en anden snak) der er 95% deprikeret. Det har man så flyttet over i GregorianCalendar der skulle have været en utility klasse omkring Date, men hov, den har i virkeligheden udviklet sig til i sig selv at repræsentere et tidspunkt.
#45
Hvis vi ser bort fra dem som udvikler SUN Java, så kan en
udokumenteret og usupporteret klasse vel ikke kaldes
redundant. Det er ikke meningen at man skal bruge den.
Date klassen er ikke deprecated. Det er formentlig en af de
allermest brugt klasser i java.util. Alle de metoder som er
kalender specifikke er deprecated, således at Date kun har en
enkelt funktion - nemlig at opbevare tid. Der er faktisk
dem som finder en enkelt funktion af en klasse for godt design.
Hvis vi ser bort fra dem som udvikler SUN Java, så kan en
udokumenteret og usupporteret klasse vel ikke kaldes
redundant. Det er ikke meningen at man skal bruge den.
Date klassen er ikke deprecated. Det er formentlig en af de
allermest brugt klasser i java.util. Alle de metoder som er
kalender specifikke er deprecated, således at Date kun har en
enkelt funktion - nemlig at opbevare tid. Der er faktisk
dem som finder en enkelt funktion af en klasse for godt design.
#46 Men du mener altså man er dårlig programmør hvis man ikke kan regne sådanne ting ud? Den må stå for egen regning, men vil da lige påpege at Apache også selv lavede deres konverter i sin tid (org.apache.catalina.util.Base64) til Tomcat. sun.misc BASE64 versionen har været der siden 98'. Apache er ikke just et no-name inden for Java.
#47 Date er en fejl, det har intet med en dato at gøre og er bare en long (Unix tid) indkapslet som et objekt. I langt de fleste tilfælde (når man f.eks. arbejder med Oracle database) er det istedet java.sql.TimeStamp man bruger. Hvis du synes Date og Calendar/GregorianCalendar er godt design (MyCalendar.getTime().getTime() og andre grælle eksempler) så synes jeg det er ret sørgeligt. Jeg har på fornemmelsen du ikke vil acceptere mine argumenter, men du kan jo checke hvad Martin Fowler og Joshua Bloch mener om emnet. Førstnævnte f.eks. i denne video.
#48 Der er en JSR ude om at rydde op i det depricated, bl.a. fjerne noget gaaammelt AWT mm. men vi skal nok være heldige hvis det når at ske før Dolphin/Java 1.7.0
#49 Seriøst, hvor mange kender du der har 1.1 eller 1.2 kode kørende på en 1.5 eller 1.6? Ofte holder denne bagudkompatibilitet ikke alligevel, jeg har f.eks. lige måtte ændre i et Swing program fordi en liste markering opførte sig anderledes i 1.6 end 1.5. Folk der skal bruge en ældre kan da bare køre f.eks. en 1.3 (de er stadig tilgængelige fra 1.1 og op), der er jo intet i vejen med at have flere JRE'er kørende.
#47 Date er en fejl, det har intet med en dato at gøre og er bare en long (Unix tid) indkapslet som et objekt. I langt de fleste tilfælde (når man f.eks. arbejder med Oracle database) er det istedet java.sql.TimeStamp man bruger. Hvis du synes Date og Calendar/GregorianCalendar er godt design (MyCalendar.getTime().getTime() og andre grælle eksempler) så synes jeg det er ret sørgeligt. Jeg har på fornemmelsen du ikke vil acceptere mine argumenter, men du kan jo checke hvad Martin Fowler og Joshua Bloch mener om emnet. Førstnævnte f.eks. i denne video.
#48 Der er en JSR ude om at rydde op i det depricated, bl.a. fjerne noget gaaammelt AWT mm. men vi skal nok være heldige hvis det når at ske før Dolphin/Java 1.7.0
#49 Seriøst, hvor mange kender du der har 1.1 eller 1.2 kode kørende på en 1.5 eller 1.6? Ofte holder denne bagudkompatibilitet ikke alligevel, jeg har f.eks. lige måtte ændre i et Swing program fordi en liste markering opførte sig anderledes i 1.6 end 1.5. Folk der skal bruge en ældre kan da bare køre f.eks. en 1.3 (de er stadig tilgængelige fra 1.1 og op), der er jo intet i vejen med at have flere JRE'er kørende.
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