---

Hej gruppe

Ja, så er det jo snart, og det var måske på tide at mærke stemningen
omkring Java 1.5, også kaldet "Tiger". Nedenfor følger mine
umiddelbare reaktioner på følgende skala:

GRRRR!!: Herligt, nøj hvor bliver det feed (blødt "d").
GRR: Ok, men ikke uproblematisk
Miauv: Det må vi så leve med, det går nok alligevel alt sammen..
Vuf: Nu stopper de faneme, de klaptorske

Jeg har koncentreret mig om "core" delen af 1.5 udvidelserne,
og ikke kommenteret API ændringer/tilføjelser og nye værktøjer
- disse giver jeg næsten altid et GRRRR!!, hvis de ellers bare
er nogenlunde.. En stor API har altid været en af Javas forcer.
Bedre performance, som de påstår opstår, er jo selvfølgelig
også bare GRRRR!!

Nederst er en lille litteraturliste, som nogenlunde
svarer til aktivering af "I feel lucky" på søgeordene
Java Tiger 1.5 - der er sikkert bedre artikler derude,
men hvor?

*****************************************************************
Disclaimer
*****************************************************************

Allerførst, må jeg indrømme at mit eget udgangspunkt er
stor skepsis. En af de gode sider ved Java i forhold til
C++ og (specielt) C#, er at det er et forholdsvist "lille
sprog" (C# har 77 nøgleord imod Javas 52, ifølge denne
liste: <http://www.javacamp.org/javavscsharp/keyword.html>
og C++ 73 nøgleord, ifølge denne oversigt:
<http://cs.stmarys.ca/~porter/csc/ref/java_cpp_keywords.html>).

Et lille sprog producerer mange programmører, som er
nogenlunde enige om måden at gøre tingene på, da der ikke
er noget valg at tage (det sidste ofte meget bekosteligt
i tid), og enige programmører kan nemt udveksle kode.

Et lille sprog er nemmere at lære, og derfor nemmere at
udbrede og derfor nemmere at finde hjælp til, og derfor
nemmere at skrive kvalitetsprogrammer i.

Vedligeholdelse af præ-1.5 programmer vil næsten nødvendigvis
medføre at præ-1.5 kode blandes med 1.5 kode, og gøre koden
mere kompleks.

etc. etc. bla, bla, bla.

Hermed min umiddelbare vurdering af de enkelte nye
(væsentlige) features:

*****************************************************************
Vurderinger:
Udgangspunktet er i stor udstrækning artiklen
"J2SE 1.5 in a Nutshell",
som findes her:
<http://java.sun.com/developer/technicalArticles/releases/j2se15/>
*****************************************************************

Generics: GRR

Typesikkerhed er en god ting, men da det er
den eneste fordel (kompakt kode er i mit hoved
ikke nødvendigvis godt men ofte bare mere
komplekst og ineffektivt) trækker det noget
ned at indføre en så omfattende tilføjelse.
Jeg havde håbet på et performance boost også,
men det kommer åbenbart ikke, pga. bagudkombatibilitet.

Boxing/Unboxing: Miauv

Igen, kompakthed er ikke nødvendigvis et gode.
Nu får vi nogle "gamle" Java folk, som ikke
bruger "boxing" og "nye" som skal vedligeholde
koden, bruger boxing/unboxing. Begejstringen er
til at overse.

(sjovt eksempel i artiklen "J2SE 1.5 in a Nutshell"
i øvrigt - med automatisk boxing tøver jeg lige et
øjeblik, da list.add(0,42) lige så godt kunne betyde
"tilføj 0 på plads 42" - se fx
java.util.Vector.insertElementAt(Object,int) i
forhold til java.util.List.add(int,Object), som
java.util.Vector også implementerer).

Enum type: GRR

Ikke absolut nødvendigt, men fint nok at undgå
faldgruberne i "enum pattern" automatisk.
Her er lidt om "enum pattern":
<http://www.javaworld.com/javaworld/javatips/jw-javatip122.html>

Static import: Vuf

Uha, hvor er det hårdt at skrive på et tastatur -
næh, hellere sætte læseren til at dereferere sig til
den egentlige betydning.. Jeg tvivler stærkt på
at jeg nogensinde selv vil bruge denne, med mindre
kodestandarden foreskriver det. En dårlig idé.

Enhanced for loop: Miauv

Dette er IMHO absolut unødvendigt og jeg vil sikkert
bruge timer på at blive enig med mig selv om jeg skal
bruge den ene eller den anden konstruktion. Java er
ikke VB, men konstruktionen ser dog ud til at have
begrænset negativ effekt.

Varargs: Vuf

Hmm, "jeg må hellere sørge for at denne metode
nemt kan udvides, så jeg smækker lige en '...'
på".. Dårlig idé, som jeg har svært ved at se
hvad skal bruges til - vi har allerede arrays.

Metadata: Vuf uden loppehalsbånd

Så fik vi også en slags makrosprog, så vi ikke behøver
at kode Java mere? Derudover får Microsoft så endelig
lov til at tilføje en masse nye "nøgleord", som de har
gjort med C++, og vil vel derfor lave et nyt forsøg
med MS Java. Hvis jeg var død, ville jeg vende mig
i min grav.

*****************************************************************
Konklusion:
*****************************************************************

"We have already got C++. We don't need another one thanks."
Citat:
<http://forum.java.sun.com/thread.jsp?thread=488882&forum=4&message=2295776>

Er jeg for negativ?
Overser jeg nogle gode sider ved nogle af udvidelserne?
Har jeg overset nogle nye væsentlige udvidelser?
Har jeg helt misforstået meningen med nogle af udvidelserne?

For at slutte lidt positivt, må jeg lige råbe hurra for
indførelsen af Thread.getStackTrace() og JVMTI, så: HURRA! Bedre
debug værktøjer er altid velkomne

*****************************************************************
Litteratur (tilføj gerne flere):
*****************************************************************

New Language Features for Ease of Development in
the Java 2 Platform, Standard Edition 1.5: A Conversation
with Joshua Bloch:
<http://java.sun.com/features/2003/05/bloch_qa.html>

J2SE 1.5 - Effective Java Programming with Tiger:
<http://www.developer.com/java/other/article.php/3112301>

J2SE 1.5 in a Nutshell:
<http://java.sun.com/developer/technicalArticles/releases/j2se15/>

Beta version af 1.5:
<http://java.sun.com/j2se/1.5.0/download.jsp>

Ulrik Magnusson

---

Ulrik Magnusson uttered:
> Varargs: Vuf
>
> Hmm, "jeg må hellere sørge for at denne metode
> nemt kan udvides, så jeg smækker lige en '...'
> på".. Dårlig idé, som jeg har svært ved at se
> hvad skal bruges til - vi har allerede arrays.

Ydermere - giver det her ikke problemer ift. method overloading? Hvis
jeg har foo(int) og foo(int, int) er det fint, men foo(int), foo(int,
int) og foo(int ...) giver jo et problem.

\\kristian
--
What I hate most of all are M & M's because they're so hard to peel.

---

Kristian Thy wrote:

> Ulrik Magnusson uttered:
> > Varargs: Vuf
> >
> > Hmm, "jeg må hellere sørge for at denne metode
> > nemt kan udvides, så jeg smækker lige en '...'
> > på".. Dårlig idé, som jeg har svært ved at se
> > hvad skal bruges til - vi har allerede arrays.
>
> Ydermere - giver det her ikke problemer ift. method overloading? Hvis
> jeg har foo(int) og foo(int, int) er det fint, men foo(int), foo(int,
> int) og foo(int ...) giver jo et problem.

Jeg formoder at det vil give en "compile-time" fejl, men jeg har ikke
undersøgt det nærmere.

Jeg fandt i øvrigt et citat, som jeg må erklære mig som udelt tilhænger
af:

> A development environment, including the language used, should
> strive to help make the development process as efficient as
possible.

You are assuming that more time is spent in developing than in
maintaining. This is reportedly false, I believe several studies have

shown that the VAST majority of effort and expense is in maintenance
- not development.

I would argue that making code easy (in terms of effort and cost) to
maintain should be the highest goal of a language and environment;
and that making development efficient would be important, but
secondary.

Kilde:
<http://forum.java.sun.com/thread.jsp?forum=4&thread=471178&start=45&range=15&hilite=false&q=>

Ulrik Magnusson

---

On Wed, 11 Feb 2004 00:19:12 +0100
Ulrik Magnusson <ulrikm@yahoo.com> wrote:

>
> Hej gruppe
>
> Ja, så er det jo snart, og det var måske på tide at mærke stemningen
> omkring Java 1.5, også kaldet "Tiger". Nedenfor følger mine
> umiddelbare reaktioner på følgende skala:
>
> GRRRR!!: Herligt, nøj hvor bliver det feed (blødt "d").
> GRR: Ok, men ikke uproblematisk
> Miauv: Det må vi så leve med, det går nok alligevel alt sammen..
> Vuf: Nu stopper de faneme, de klaptorske
>
> Jeg har koncentreret mig om "core" delen af 1.5 udvidelserne,
> og ikke kommenteret API ændringer/tilføjelser og nye værktøjer
> - disse giver jeg næsten altid et GRRRR!!, hvis de ellers bare
> er nogenlunde.. En stor API har altid været en af Javas forcer.
> Bedre performance, som de påstår opstår, er jo selvfølgelig
> også bare GRRRR!!
>

Godt indlæg.

Jeg har ikke selv nået at sætte mig helt ind i alt det nye, men efter hvad jeg har set/hørt, så har mine indtryk været stort set magen til dine. Eller med andre ord 'Hvorfor nu det? Det er bare ekstra og det er kun med til at forvirre, og gavner ikke særlig'; men OK, sun får vel lukket munden på de værste kritikere, selv om disse er tumber.

vh. Lars Dam

p.s. Nu kan vi vel bare vente på en preprocessor og operator overloading :(

---

Lars Dam wrote:

> On Wed, 11 Feb 2004 00:19:12 +0100
> Ulrik Magnusson <ulrikm@yahoo.com> wrote:

> Godt indlæg.

Tak, tak, håber folk kunne bruge det til noget (samtidig med
at jeg kunne ride mine kæpheste..)

> Jeg har ikke selv nået at sætte mig helt ind i alt det nye, men efter hvad jeg har set/hørt, så har mine indtryk været stort set magen til dine. Eller med andre ord 'Hvorfor nu det? Det er bare ekstra og det er kun med til at forvirre, og gavner ikke særlig'; men OK, sun får vel lukket munden på de værste kritikere, selv om disse er tumber.

Så kommer der bare nye - man kan åbenbart ikke være
venner med alle. Hvis de bare havde stoppet ved enum og
generics, havde de nok været mere på den sikre side.

> p.s. Nu kan vi vel bare vente på en preprocessor og operator overloading :(

Shhh! Sæt, der er nogen, der hører det og ukritisk tvinger
det igennem!

Ulrik Magnusson

---

Lars Dam wrote:
> p.s. Nu kan vi vel bare vente på en preprocessor og operator overloading :(
øhh, hvad er der nu galt med gcc som preprocessor?

mht operator overloading, så skal de holde det lort LANGT væk fra java -
så hellere unsafe pointers!
google for hvorfor operator overloading er bad - gider ikke liste dem
alle ;)

/matzon

---

On 2004-02-10, Ulrik Magnusson <ulrikm@yahoo.com> wrote:
>
> Allerførst, må jeg indrømme at mit eget udgangspunkt er
> stor skepsis. En af de gode sider ved Java i forhold til

Denne note behoevede du slet ikke skrive, det fremgaar RET
tydeligt af din mening om de nye features!

> Vedligeholdelse af præ-1.5 programmer vil næsten nødvendigvis
> medføre at præ-1.5 kode blandes med 1.5 kode, og gøre koden
> mere kompleks.

Men det skal vel ikke vaere en undskyldning for at saette udviklingen
af et sprog helt i staa, hvis det er muligt langsomt at lave forbedringer?

> Typesikkerhed er en god ting, men da det er
> den eneste fordel (kompakt kode er i mit hoved
> ikke nødvendigvis godt men ofte bare mere

Jeg synes Generics er en rigtig laekker tilfoejelse.

- Man kan pludselig se, hvad en List indeholder blot ved at kigge paa
erklaeringen af den.
- Man er sikker paa at der ved et uheld ikke kommer forkerte typer i
en List
- Man er fri for at caste naar man henter ting ud af en List (Det goer
da koden noget mere laesbar synes jeg)


> Igen, kompakthed er ikke nødvendigvis et gode.
> Nu får vi nogle "gamle" Java folk, som ikke
> bruger "boxing" og "nye" som skal vedligeholde
> koden, bruger boxing/unboxing. Begejstringen er
> til at overse.

Du synes slet ikke det er pres at skulle konvertere mellem primitiver
og deres wrapperklasser? Det maa jeg indroemme er noget af det jeg
fandt mest underligt da jeg begyndte at kode java.

> Static import: Vuf

[klip]

> at jeg nogensinde selv vil bruge denne, med mindre
> kodestandarden foreskriver det. En dårlig idé.

Her er jeg til gengaeld enig...

> Enhanced for loop: Miauv
>
> Dette er IMHO absolut unødvendigt og jeg vil sikkert
> bruge timer på at blive enig med mig selv om jeg skal

Det er da klart nemmere at overskue i forhold til naar man
bruger en Iterator. Hvis man har skrevet meget perl bliver man
rigtig glad for det nye for loop...

> Varargs: Vuf

[klip]

> på".. Dårlig idé, som jeg har svært ved at se
> hvad skal bruges til - vi har allerede arrays.

Enig, heller ikke noget jeg ville benytte mig af.

> Metadata: Vuf uden loppehalsbånd
>
> Så fik vi også en slags makrosprog, så vi ikke behøver
> at kode Java mere? Derudover får Microsoft så endelig

Enig, som jeg ser det goer det kun koden mere uforstaaelig. Men
mange udviklingsvaerktoejer vil nok udnytte det til at undgaa en
masse kodegenerering, hvilket vel ogsaa er ok.

> Har jeg overset nogle nye væsentlige udvidelser?

Du har set at man bliver fri for rmic naar man koder RMI ting?

http://java.sun.com/j2se/1.5.0/docs/guide/rmi/relnotes.html

Men der gaar nok lige lidt tid foer man kan komme til at bruge de
nye ting i produktion rundt omkring...

/Michael

---

Michael Legart wrote:

> On 2004-02-10, Ulrik Magnusson <ulrikm@yahoo.com> wrote:
> > Allerførst, må jeg indrømme at mit eget udgangspunkt er
> > stor skepsis. En af de gode sider ved Java i forhold til
> Denne note behoevede du slet ikke skrive, det fremgaar RET
> tydeligt af din mening om de nye features!

Da jeg startede, regnede jeg faktisk med at der var nogle ting, som
jeg ville give GRRRR!! men det så bare sortere og sortere ud, og
visse "features" gjorde mig i direkte dårligt humør

> > Vedligeholdelse af præ-1.5 programmer vil næsten nødvendigvis
> > medføre at præ-1.5 kode blandes med 1.5 kode, og gøre koden
> > mere kompleks.
> Men det skal vel ikke vaere en undskyldning for at saette udviklingen
> af et sprog helt i staa, hvis det er muligt langsomt at lave forbedringer?

Pointen er nok, at det skal være faktiske _forbedringer_, og generics
er fx glimrende pga typesikkerheden, som jeg har set frem til, og som
du også påpeger, men da jeg hørte at det bare skulle implementeres
ved usynlige konverteringer, som stadig er lige dyre og som udelukker
type-inspektion via reflection, blev jeg da lidt skuffet. Når jeg så
derudover kom til at tænke på "gammel" kode, som skal vedligeholdes,
og dermed den mulige (næsten garanterede) sammenblanding af nye
og gamle konstruktioner i større systemer, kunne jeg ikke se den
nydelige kode for mig, som der ellers bliver slået meget på.
Generics får dog heller ikke bundkarakter, og det er klart den bedste
tilføjelse - jeg synes bare ikke, den når helt i mål.

> > Igen, kompakthed er ikke nødvendigvis et gode.
> > Nu får vi nogle "gamle" Java folk, som ikke
> > bruger "boxing" og "nye" som skal vedligeholde
> > koden, bruger boxing/unboxing. Begejstringen er
> > til at overse.
> Du synes slet ikke det er pres at skulle konvertere mellem primitiver
> og deres wrapperklasser? Det maa jeg indroemme er noget af det jeg
> fandt mest underligt da jeg begyndte at kode java.

Jo, men der ændrer bare ikke ved at primitive typer eksisterer - nu
har de bare endnu et feature (som er valgfrit at bruge). Hvis Sun ellers
leverede et værktøj til at detektere "grim kode" - som de åbenbart
synes eksisterer, så kunne man måske overveje at omskrive eksisterende
kode (og sikre at ny kode er "pæn" eller i hvert fald konsistent), men så
vidt jeg ved, ligger den slags ikke i planerne, og det ville nok heller
ikke være et godt signal at sende: "Java er næsten altid grimt, så brug
dette værktøj til at gøre det pænere"?

> > Enhanced for loop: Miauv
> > Dette er IMHO absolut unødvendigt og jeg vil sikkert
> > bruge timer på at blive enig med mig selv om jeg skal
> Det er da klart nemmere at overskue i forhold til naar man
> bruger en Iterator. Hvis man har skrevet meget perl bliver man
> rigtig glad for det nye for loop...

Det er muligvis et feature som jeg bare må sluge, og sikkert kan vænne
mig til - men i fremtiden stopper jeg sikkert lige op når jeg læser "for(..".

> > Metadata: Vuf uden loppehalsbånd
> > Så fik vi også en slags makrosprog, så vi ikke behøver
> > at kode Java mere? Derudover får Microsoft så endelig
> Enig, som jeg ser det goer det kun koden mere uforstaaelig. Men
> mange udviklingsvaerktoejer vil nok udnytte det til at undgaa en
> masse kodegenerering, hvilket vel ogsaa er ok.

"kodegenerering" - gys!

> > Har jeg overset nogle nye væsentlige udvidelser?
> Du har set at man bliver fri for rmic naar man koder RMI ting?

Det er faktisk smart, indrømmet - jeg har udeladt den, da det
er en udvidelse af en bestemt API. Det kunne være at jeg skulle
lave en liste over API og værktøjsudvidelser, når jeg engang får
tid.. (men i den henseende er jeg generelt meget positivt stemt -
det har vist næsten altid kun været godt nyt med alle nye versioner
af Java).

Ulrik Magnusson

---

On 2004-02-11, Ulrik Magnusson <ulrikm@yahoo.com> wrote:
>
> ved usynlige konverteringer, som stadig er lige dyre og som udelukker
> type-inspektion via reflection, blev jeg da lidt skuffet. Når jeg så

Det kan jeg saa godt forstaa. Man skulle jo tro det kunne give hurtigere
kode, men noget tyder paa at det faktisk bliver langsommere af det - det
er jo lidt aergeligt.

> derudover kom til at tænke på "gammel" kode, som skal vedligeholdes,
> og dermed den mulige (næsten garanterede) sammenblanding af nye
> og gamle konstruktioner i større systemer, kunne jeg ikke se den

Klart nok. Det er noget jeg lige saa stille (efter beta) vil begynde
at bruge i nogle nye projekter tror jeg. Storre projekter vil man
jo nok ikke begynde at koere paa 1.5 lige med det samme, og gammel
kode skal jo heller ikke aendres bare for at aendre det.

> Jo, men der ændrer bare ikke ved at primitive typer eksisterer - nu
> har de bare endnu et feature (som er valgfrit at bruge). Hvis Sun ellers

Men som jeg ser det er det oplagte og nemmeste at bruge denne feature,
og jeg tror nu folk rimelig hurtigt vaenner sig til det.

> "kodegenerering" - gys!

Netop! Og det kan man tit komme udenom ved at bruge metadata.


/Michael - der glaeder sig over at der for en gangs skyld ikke diskuteres
hvilken gruppe javascript hoerer til i

--
hestdesign.info - we put the hest in .com

---

Michael Legart wrote:

> On 2004-02-11, Ulrik Magnusson <ulrikm@yahoo.com> wrote:
> > derudover kom til at tænke på "gammel" kode, som skal vedligeholdes,
> > og dermed den mulige (næsten garanterede) sammenblanding af nye
> > og gamle konstruktioner i større systemer, kunne jeg ikke se den
> Klart nok. Det er noget jeg lige saa stille (efter beta) vil begynde
> at bruge i nogle nye projekter tror jeg. Storre projekter vil man
> jo nok ikke begynde at koere paa 1.5 lige med det samme, og gammel
> kode skal jo heller ikke aendres bare for at aendre det.

Jeg har siddet i de sidste 2 1/2 år og vedligeholdt og udvidet kode, som
blev skrevet tilbage i 95 (tror jeg nok), og vi har da et andet system,
som har 20 år på bagen, som stadigvæk vedligeholdes. Mange institutioner
har jo ikke råd til at skifte system hvert andet år, så kode har et noget
længere liv, end man lige regner med (deraf Y2K). Derfor regner jeg
med at der eksisterer store kodebaser derude, som ikke lige skrives
helt om, men alligevel skal vedligeholdes mange år frem.

> > Jo, men der ændrer bare ikke ved at primitive typer eksisterer - nu
> > har de bare endnu et feature (som er valgfrit at bruge). Hvis Sun ellers
> Men som jeg ser det er det oplagte og nemmeste at bruge denne feature,
> og jeg tror nu folk rimelig hurtigt vaenner sig til det.

Det er nok fint nok for nye Java-folk - men kun lige indtil de konfronteres
med "gammel" kode..
Hvad sker der i øvrigt med:

public void set( int i, Object o )
{
//...
}

i forhold til

public void set( Integer i, Object o )
{
//...
}

i samme klasse (eller nedarvet)?? javac fejl? Der må da vist være noget
kode, som skal skrives om på dén konto..

> > "kodegenerering" - gys!
> Netop! Og det kan man tit komme udenom ved at bruge metadata.

Jeg mener nu "kodegenerering" som alt kode, jeg ikke kan se og modificere
direkte - det bliver aldrig min kop te, men nok bare et fact of life..

> /Michael - der glaeder sig over at der for en gangs skyld ikke diskuteres
> hvilken gruppe javascript hoerer til i

LOL - ja, jeg synes der efterhånden var blevet lidt stille i gruppen.

Ulrik Magnusson

---

NB! subject ændret.

Denne deltråd kan bruges til at tilføje relevant 1.5 litteratur
(og evt. fjerne mindre gode artikler, efterhånden som de
bedre dukker op).

JSR-000176 J2SETM 1.5 (Tiger) Release Contents:
<http://jcp.org/aboutJava/communityprocess/review/jsr176/index.html>

JSR-000133 JavaTM Memory Model and Thread Specification Revision
<http://jcp.org/aboutJava/communityprocess/review/jsr133/index.html>

New Language Features for Ease of Development in
the Java 2 Platform, Standard Edition 1.5: A Conversation
with Joshua Bloch:
<http://java.sun.com/features/2003/05/bloch_qa.html>

J2SE 1.5 - Effective Java Programming with Tiger:
<http://www.developer.com/java/other/article.php/3112301>

J2SE 1.5 in a Nutshell:
<http://java.sun.com/developer/technicalArticles/releases/j2se15/>

Beta version af 1.5:
<http://java.sun.com/j2se/1.5.0/download.jsp>

Ulrik Magnusson

---

Ulrik Magnusson wrote:
> Generics: GRR
Uenig, er en MAX dejlig feature! - slipper for 432589235 typecasts!

> Boxing/Unboxing: Miauv
nja, tror nok jeg bliver glad - men har ikke rigtigt været noget større
problem endnu...

> Enum type: GRR
Pas, har aldrig haft brug for andet end Public static final int's - har
fungeret fint i de sidste mange år. Men der kan nok være nogle
konstruktioner som bliver væsenligt bedre - specielt i forhold til type
safe enums.

> Static import: Vuf
JUUUUBIII på tide!
Omend det kan give problemer omkring hvor en metode hører til, så har
det fantastisk mange fordele i static miljøer. Her tænker jeg specielt
på OpenGL/OpenAL bindingen i LWJGL (http://www.lwjgl.org). Som er
forberedt på static import. Dermed bliver et typisk kald:

GL11.glBegin(GL11.GL_QUADS); {
GL11.glVertex2i(-50, -50);
GL11.glVertex2i(50, -50);
GL11.glVertex2i(50, 50);
GL11.glVertex2i(-50, 50);
}
GL11.glEnd();

væsenligt mere læse venlige (og eksisterende c kode kan genbruges i
mange tilfælde):

glBegin(GL_QUADS); {
glVertex2i(-50, -50);
glVertex2i(50, -50);
glVertex2i(50, 50);
glVertex2i(-50, 50);
}
glEnd();

> Enhanced for loop: Miauv
tja, jeg er nu fint tilfreds med det nuværende - men kan da godt se
fordele i den nye syntaks.

> Varargs: Vuf
Yeah baby!
kan i sige System.out.format("Kiss my shiny %s %d times!", "ass", 3);
w00t :)

At bruge Object[] virker, men er totalt overdrevent sygt at lave og se på:
System.out.format("Kiss my shiny %s %d times!", new Object[]{"ass", new
Integer(3)});

Jeg er generelt ret glad for 1.5 - men ja, der var da ting der kunne
laves bedre :)

hov, og til sidst - de to *aller* vigtigste features EVER, som kommer
til at spare mig RIGTIG fucking mange timer i fremtiden:

public StackTraceElement[] getStackTrace()

Returns an array of stack trace elements representing the stack dump of
this thread. This method will return a zero-length array if this thread
has not started or has terminated. If the returned array is of non-zero
length then the first element of the array represents the top of the
stack, which is the most recent method invocation in the sequence. The
last element of the array represents the bottom of the stack, which is
the least recent method invocation in the sequence.

public static Map getAllStackTraces()

Returns a map of stack traces for all live threads. The map keys are
threads and each map value is an array of StackTraceElement that
represents the stack dump of the corresponding Thread. The returned
stack traces are in the format specified for the getStackTrace method.
The threads may be executing while this method is called. The stack
trace of each thread only represents a snapshot and each stack trace may
be obtained at different time. A zero-length array will be returned in
the map value if the virtual machine has no stack trace information
about a thread.

/matzon

---

Brian Matzon wrote:

> Ulrik Magnusson wrote:
> > Generics: GRR
> Uenig, er en MAX dejlig feature! - slipper for 432589235 typecasts!

Så negativ er jeg nu heller ikke - fint feature, som jeg vil bruge meget, men
det kunne bare have været lidt bedre alligevel (derfor ikke nogen
topkarakter).

> > Static import: Vuf
> JUUUUBIII på tide!
> Omend det kan give problemer omkring hvor en metode hører til, så har
> det fantastisk mange fordele i static miljøer. Her tænker jeg specielt
> på OpenGL/OpenAL bindingen i LWJGL (http://www.lwjgl.org). Som er
> forberedt på static import. Dermed bliver et typisk kald:
>
> GL11.glBegin(GL11.GL_QUADS); {
> GL11.glVertex2i(-50, -50);
> GL11.glVertex2i(50, -50);
> GL11.glVertex2i(50, 50);
> GL11.glVertex2i(-50, 50);
> }
> GL11.glEnd();
>
> væsenligt mere læse venlige (og eksisterende c kode kan genbruges i
> mange tilfælde):
>
> glBegin(GL_QUADS); {
> glVertex2i(-50, -50);
> glVertex2i(50, -50);
> glVertex2i(50, 50);
> glVertex2i(-50, 50);
> }
> glEnd();

Ja, nu bliver jeg nok rullet i tjære og fjer.., men jeg plejer nu gerne
helt at undgå imports, med mindre den eksisterende kode selv bruger
det. Dette skyldes følgende:

* At pakkenavne har betydning i forhold til hvad en klasse er for
en fisk: java.awt.List, java.nio.channels.Selector,
java.rmi.activation.Activatable, etc. Dette gør IMHO koden mere læselig,
da man umiddelbart kan se, hvilken slags funktion koden har og man er fri
for at hoppe frem og tilbage mellem import sektionen og den aktuelle sektion.
* Når man poster (og læser) snippets rundt omkring, er koden fuldt ud
forståelig, uden at man uformelt eller formelt skal gøre (gøres)
opmærksom på, hvilke pakker der faktisk er tale om.
* Man lærer pakkerne bedre at kende, når man er tvunget til at skrive
dem fuldt ud (kan måske diskuteres).
* At man alligevel ikke kan undgå det ved navneoverlap (java.util.List
og java.awt.List er et eksempel - min 1.1 kode fungerede pludselig
ikke med en 1.2 javac..)
* Læsevenlighed går IMHO på præcision, mere end på kortfattethed - men
der er vi vist fundamentalt uenige (jeg har mere mod tynde bøger, der er
propfyldt med pegere på sig selv (se side "bla", se eksempel "skod"..)
end mod tykke bøger, der gentager sig selv).

Det har selvfølgelig også bagdele:

* Andre udviklere vil finde stilen underlig, og derfor mindre læselig.
* Mange konstruktioner deles over flere linier (Swing).
* Man skal skrive mere (men det bør altså ikke være et problem, imho)
* At folk finder koden mere intimiderende end klar (nyt punkt - er dette
et problem?)
* For folk som er meget velbevandrede i den aktuelle API, kan det
sikkert virke belastende, da de allerede ved, hvad det handler om, når
der snakkes om GL_QUADS (ok, dårligt eksempel, da navngivningen
er meget sigende i sig selv..)
* Andre?

En løsning kunne være at finde et program, der automatisk kan konvertere
mellem import og ikke-import stilarterne - findes et sådant? (specielt til
Eclipse -
har søgt, men intet fundet - man skulle måske lave et selv.. de eksisterende
formateringsprogrammer ser ikke ud til at understøtte det (bruger p.t. jacobe:

<http://www.tiobe.com/jacobe.htm>, som er det bedste freeware, jeg er stødt
på).

[Nedenstående er kopieret ind fra ovenstående blok, men skal kommenteres
isoleret:]
> (og eksisterende c kode kan genbruges i mange tilfælde):

Er dette et stort problem, altså at portere kode fra andre sprog til Java,
og er det noget, som gøres i stor stil? Man kunne måske forestille sig
at Sun forsøger at hijacke C/C++/C# udviklere ved at indføre nogle
af de nye features, ligesom de valgte C-syntaks til at starte med. Det
er vel fint nok, og vil vel bare gøre Java bedre, jo flere der kommer til.

> > Varargs: Vuf
> Yeah baby!
> kan i sige System.out.format("Kiss my shiny %s %d times!", "ass", 3);
> w00t :)
>
> At bruge Object[] virker, men er totalt overdrevent sygt at lave og se på:
> System.out.format("Kiss my shiny %s %d times!", new Object[]{"ass", new
> Integer(3)});

Jeg har nu svært ved at se andre steder, det vil være godt at bruge (end i
en javaprintf), og i ovenstående er det jo ikke absolut uundværligt og derfor
knapt et argument for at indføre det generelt.

> Jeg er generelt ret glad for 1.5 - men ja, der var da ting der kunne
> laves bedre :)

Jeg tænkte jo nok, at vi var enige

> hov, og til sidst - de to *aller* vigtigste features EVER, som kommer
> til at spare mig RIGTIG fucking mange timer i fremtiden:
>
> public StackTraceElement[] getStackTrace()

[snip]

> public static Map getAllStackTraces()

Jep, det er for fedt (ingen ironi). Eller skulle man sige, på tide?

Ulrik Magnusson

---

Brian Matzon wrote:
> hov, og til sidst - de to *aller* vigtigste features EVER, som kommer
> til at spare mig RIGTIG fucking mange timer i fremtiden:
>
> public StackTraceElement[] getStackTrace()

Denne har skam været mulig i lang tid, omend på en lidt hackish måde.

StackTraceElement[] ste = null;
try {
new Exception();
} catch (Exception expected) {
ste = expected.getStackTrace();
}

Hvorfor er disse features så vigtige for dig? Har du i en given metode behov
for at se hvem der har kaldt dig?

--
Jonas Kongslund

---

Jonas Kongslund wrote:

> Brian Matzon wrote:
> > hov, og til sidst - de to *aller* vigtigste features EVER, som kommer
> > til at spare mig RIGTIG fucking mange timer i fremtiden:
> >
> > public StackTraceElement[] getStackTrace()
>
> Denne har skam været mulig i lang tid, omend på en lidt hackish måde.
>
> StackTraceElement[] ste = null;
> try {
> new Exception();
> } catch (Exception expected) {
> ste = expected.getStackTrace();
> }

Jep, men kun for den aktuelle tråd - den nye giver mulighed for
at inspicere andre tråde (og se, hvad f.. ens program egentlig
foretager sig..)

>
> Hvorfor er disse features så vigtige for dig? Har du i en given metode behov
> for at se hvem der har kaldt dig?

Både det, samt mulighed for at inspicere andre kørende tråde.

Ulrik Magnusson

---

Ulrik Magnusson wrote:

> Jonas Kongslund wrote:
>
> > Brian Matzon wrote:
> > > hov, og til sidst - de to *aller* vigtigste features EVER, som kommer
> > > til at spare mig RIGTIG fucking mange timer i fremtiden:
> > >
> > > public StackTraceElement[] getStackTrace()
> >
> > Denne har skam været mulig i lang tid, omend på en lidt hackish måde.
> >
> > StackTraceElement[] ste = null;
> > try {
> > new Exception();
> > } catch (Exception expected) {
> > ste = expected.getStackTrace();
> > }
>
> Jep, men kun for den aktuelle tråd - den nye giver mulighed for
> at inspicere andre tråde (og se, hvad f.. ens program egentlig
> foretager sig..)

og et link:
<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getStackTrace()>

Ulrik Magnusson

---

On Wed, 11 Feb 2004 19:48:34 +0100
Brian Matzon <brian@matzon.dk> wrote:

> Lars Dam wrote:
> > p.s. Nu kan vi vel bare vente på en preprocessor og operator overloading :(
> øhh, hvad er der nu galt med gcc som preprocessor?

Ikke noget... Hvis man ikke har noget imod at bruge ekstra meget tid på debugging.

Min personlige mening omkring dette emner er 'keep it simple' - at have en PP er med til at gøre eens kode mindre gennemskuelig.

Jeg kan godt lide det eksempel jeg så engang omkring C#, hvor følgende kode blev brugt som eksempel:

x[y]+=a.b;

Ovennævnte kode, kunne med de 'features' der er i C#, dække over hele 10 (TI!) forskellige metode kald i dette ene statement - snak om kode som man ikke aner eksisterer, uden at man skal bruge mængder af tid på at lede efter det. Nej, så hellere have et sprog hvor ting er simple og mere direkte.

PP er for mig blot endnu en ting som vil være med til at 'obfuscate code'.. Og med de ting der kommer med i 1.5 som vil gøre det nemmere at skrive kode, vil _samtidigt_ gøre det sværere at læse koden. Og koden blive kun skrevet een gang, men læst mange gange, og dermed kommer disse 'forbedringer' til at bevirke en nedgang i netto produktiviteten og kommer til at gå direkte ud over kvaliteten af det arbejde man laver.

Hvis jeg kommer til at skrive java kodestandarder, så vil der helt klart være ting som bliver bandlyst; og i kan selv regne jer ud til hvad ;)

vh. ld

---

On Wed, 11 Feb 2004 23:13:31 +0100
"Mads Andersen" <madsie@vip.cybercity.dk> wrote:

> > Og med de ting der kommer med i 1.5 som vil g_re det nemmere at skrive
> > kode, vil _samtidigt_ g_re det sv_rere at l_se koden.
>
> Jeg er ikke enig her. Hvis vi fx tager generics, s_ vil en metode som f_r
> var:

Ja. Jeg tænkte mere på autoboxing, og de potentielle andre ting der kunne komme senere.

Jeg er dog stadig lidt bange for generics, men af andre årsager. Nemlig at når folk lærer hvad det er, så begynder de at bruge teknikken ukritisk. F.eks. ligesom når man ser en nybegynder bruge arv konstant uden egentlig at gøre sig klart om det faktisk er nødvendigt i den aktuelle situation - så frygter jeg også at der kommer en masse kode som bruger generics hvor det bliver misbrugt fordi man ikke kan finde ud af at begrænse sig. Resultatet vil igen være 'obfuscated source code' ;)

Men hvis generics bliver brugt med respekt, så vil det være en god ting.

vh. ld

---

Hej
I får lige mit besyv med.

Ulrik Magnusson wrote:
> GRRRR!!: Herligt, nøj hvor bliver det feed (blødt "d").
> GRR: Ok, men ikke uproblematisk
> Miauv: Det må vi så leve med, det går nok alligevel alt sammen..
> Vuf: Nu stopper de faneme, de klaptorske

> Generics: GRR

Enig. En god ting. Måske vil jeg endda sige GRRRR.
Det er en af de ting, jeg synes JAVA har manglet.
Jeg kan godt lide, at man kan se, hvad listen e.l.
indeholder.

> Boxing/Unboxing: Miauv

Her vil jeg sige GRR

> Igen, kompakthed er ikke nødvendigvis et gode.
> Nu får vi nogle "gamle" Java folk, som ikke
> bruger "boxing" og "nye" som skal vedligeholde
> koden, bruger boxing/unboxing. Begejstringen er
> til at overse.

Jeg kan godt se, at det kan være et problem, med sådan er
det jo, når man tilføjer nye features. Så må man prøve
med nogle kodestandarter, men de bliver måske alligevel
ikke overholdt (især ikke hvis noget kode overtages fra
andre). Jeg tror problemet forsvinder hurtigt, når man
først er blevet vant til at bruge det.

> Enum type: GRR

Jeg synes heller ikke, det er absolut nødvendigt, men
jeg vil mene, at det kan øge kvaliteten af koden. Så
det er fint med mig.

> Static import: Vuf
>
> Uha, hvor er det hårdt at skrive på et tastatur -
> næh, hellere sætte læseren til at dereferere sig til
> den egentlige betydning.. Jeg tvivler stærkt på
> at jeg nogensinde selv vil bruge denne, med mindre
> kodestandarden foreskriver det. En dårlig idé.

Enig. Helt unødvendigt.
Jeg vil næsten sige, at det bør ikke bruges.
Jeg synes bare, det mindsker overskueligheden og når man
læser andres kode, kan man godt blive i tvivl om, hvilken
klasse en konstant hører til i. Og så meget tid sparer
det heller ikke. Det kan måske være en fordel i nogle
situationer, men stadig mener jeg, at det er noget pjat.

> Enhanced for loop: Miauv

Det er da absolut unødvendigt. Heller holde sproget
lille og klart. Skulle man tilføje noget nyt på det
område, så skulle man da istedet indføre noget ala
foreach i PHP (som er fedt i PHP, men som jeg stadig
mener ikke hører hjemme i JAVA).

> Varargs: Vuf

Enig. Det har vi ikke brug for.
Lad være med at lefle for C/C++ programmører
og hold sproget lille og klart.

> Metadata: Vuf uden loppehalsbånd

Det har jeg ikke lige nogen mening om.


Jeg synes, der er nogle få dårlige ting, men også flere
rigtig dejlige. Og så synes jeg, det er fint, at de nu
har tilføjet Semaphorer til standard klasserne.

Jeg synes ikke så godt om tendensen til at gøre sproget
mere lig C/C++ eller script-sprog-agtigt.


--
Mvh.
Martin Møller Bæk
www.yavi.dk

---

> Allerførst, må jeg indrømme at mit eget udgangspunkt er
> stor skepsis.

Da C++ i sin tid blev udgivet var det et forholdsvis "færdigt" sprog.. Java
derimod er et sprog som udvikles på konstant.. Dette har selvfølgelig sine
fordele og ulemper, men at det løbende udvikles er man nødt til at have i
baghovedet hvis man vil programmere i java.. at sproget er lille gør det
nemt at bruge.. men det giver også visse brgrænsinger.. derfor er det
naturligt at java med tiden bliver større og større for at tilpasse alles
behov.. det kan man så mene om som man vil.. men at det syntax mæssigt
kommer til at ligne C/C++ mere og mere er bare noget man må lære at leve
med.. men java vil altid være anderledes på nøgleområderne og det bliver der
nok ikke lavet om på.

Generelt må jeg sige at jeg er positiv over for de nye features.. hvis det
kan lette kodningen er jeg generelt positiv over for.. at sproget bliver
sværre at læse er beklageligt. Jeg kan rigtig godt lide java fordi det er
nemt og simpelt at gå til.. men jeg er da heller ikke helt ubekymret over
for den udvikling java er i. Om java dør pga. af denne udvikling kan man kun
gisne om.. men pt. holder jeg mig til java.

Det med at java kommer til at tillade scripting er dog lidt underligt.. men
det har sikkert en eller anden fordel.. men nok ikke noget jeg vil benytte
mig af..

---

Ulrik Magnusson wrote:
> Metadata: Vuf uden loppehalsbånd

Java-programmer består i forvejen af en række ad hoc programannoteringer
såsom nøgleordet transient, der bruges af serialiseringsystemet, eller
@deprected tagget som bruges af compileren til at give advarsler hvis det
annoterede programelement anvendes. Den nye metadatafacilitet er blot en
mere gennemført måde at gøre tingene på. Der er mange anvendelsesmuligheder
og da nogen af dem ligefrem er fornuftige så synes jeg et vuf er i
underkanten.

--
Jonas Kongslund

---

Ulrik Magnusson wrote:
> Ja, så er det jo snart, og det var måske på tide at mærke stemningen
> omkring Java 1.5, også kaldet "Tiger".
[...]

Her er en række kodeeksempler til dem der måtte være interesseret:
<http://zamples.com/JspExplorer/samples/samplesJDK1_5.html>

--
Jonas Kongslund

---

Jonas Kongslund wrote:
> Her er en række kodeeksempler til dem der måtte være interesseret:
> <http://zamples.com/JspExplorer/samples/samplesJDK1_5.html>

Efter at have læst nogle af eksemplerne fra ovenstående link,
tror jeg nok, at jeg på et eller andet tidspunkt, når jeg har
brugt 1.5 et lille stykke tid, kommer til at kunne lide "Enhanced
for loop". Men det tager nok lige lidt tid, før ens konservatisme
bliver overvundet .

Til gengæld synes jeg (stadig) ikke om printf.

--
Mvh.
Martin Møller Bæk
www.yavi.dk