[java] annotations.. wie gebruikt het al?

[Alarmnummer]

Sinds Java 5 heeft java eindelijk beschikking over annotations/metadata/attributes (annotations is de naam die Sun gebruikt) en hierbij is het mogelijk om in java op een declaratieve manier te programmeren: je specificeert wat je wilt, maar niet hoe. Ik denk dat annotations daarom veruit de belangrijkste toevoeging zijn geweest in alle versies van java die tot zover zijn uitgebracht. Hierdoor kunnen constructies die voorheen niet beter te doen waren opgelost worden. En verder kan de nare ziekte, waar Java last van heeft, namelijk: "Ohh my god.. nog een xml configuratie bestand" bestreden worden.

Intussen is Java 5.0 al meer dan een jaar uit, en naar verloop van tijd zal Java 5 in steeds meer productie omgevingen terug te vinden zijn. Ik gebruik intussen Java 5 icm JBoss bij mijn thuis projecten en intussen ook op 1 project op mijn werk. Maar ik doe eigelijk nog niet zo veel met annotations.Waar ik het voornamelijk voor gebruik is voor transactionele metadata voor services.

Verder gaan we binnenkort een systeem opzetten waarbij de structuur van de data erg belangrijk is. De oude opzet van de structuur zou zijn door bepaalde interfaces te implementeren zodat een specifieke implementatie door een generiek systeem geanalyseerd kan worden. Maar ik zit er nu over te denken om niet een bepaalde interface te implementeren, maar door bepaalde metadata toe te voegen.

Het is wel gek dat ik al wel veel met andere taalfeatures (generics bv)/libraries van java 5 bezig ben geweest, en eigelijk nog maar weinig met annotations ( alhoewel java 5 al vrij lang uit is). Tot zover mijn ervaring met annotations... wat is jullie ervaring ermee? Mogen jullie het al gebruiken? Passen jullie het in projecten toe? Van welke annotations maak je gebruik? Acegi security? Hibernate? Tapestry? etc etc. Wat is jullie ervaring ermee? Gebruik je alleen metadata dat door anderen is ontwikkeld? Of heb je zelf al annotations ontwikkeld?

[ Voor 22% gewijzigd door Alarmnummer op 13-07-2005 10:31 ]

[Verwijderd]

Nadat we Java 5 ongeveer een jaar in de wijnkelder hebben laten rijpen zijn we sinds kort begonnen met het toepassen ervan.

Ik denk dat dus voor veel (corporate) java developpers het feit helemaal niet telt dat Java 5 al een jaar oud is. Voor de meeste van dergelijke developpers bestaan versies jonger dan +- 1 jaar gewoon niet, en bedrijfsmatig gezien is java 5 dus pas een paar weken uit.

Zelf ben ik dus net begonnen met generics in java. Als je C++ gewent bent mis je meteen de typedef constructie. Enums en varargs werken weer wil lekkerder, en de for each loopt werkt ook super.

On topic, annotations. Ook ik heb deze niet gebruikt. Ik zie er echter wel een simpele toepassing voor. Ik gebruik nu een soort van container plug-in classes die in een hashmap allemaal andere classes zetten die slechts 1 simpele functie hebben en geen state kennen. M.a.w. het zijn eigenlijk gewoon 'functie' objecten die via een (string) key aangeroepen kunnen worden. (deze aanpak komt een beetje uit mijn C++ achtergrond waar ik vaak maps van functie pointers had).

Met annotations kan ik nu elke functie in de classe die als "plug-in functie" gebruikt gaat worden markeren, en kan ik in de annotation de key opgeven die naar die functie mapped.

Ik had dit ook met een name convention icm reflection kunnen oplossen, maar dat is toch wel minder mooi.

[Verwijderd]

Ik gebruik Hibernate 3 + annotaties voor de herbouw van http://www.burgerweeshuis.nl, wat een hobby project is. Verder gaan we (Topicus) als alles meezit binnenkort met een project beginnen waarbij we met Hibernate 3 + annotaties gaan werken. Misschien dat we nog meer gebruik zien voor annotaties voor dat project, maar heb dat nog niet echt onderzocht. Ik zal met interesse EJB 3 blijven volgen, waarbij ik met name geinteresseerd ben in dependency injection zonder dat je daarvoor Spring nodig hebt. En als de ondersteuning voor EJB 3 op korte termijn goed wordt, willen we wellicht van de afhankelijkheid van Hibernate af.

Eelco

[Alarmnummer]

Verwijderd schreef op woensdag 13 juli 2005 @ 11:05:
Ik gebruik Hibernate 3 + annotaties voor de herbouw van http://www.burgerweeshuis.nl, wat een hobby project is. Verder gaan we (Topicus) als alles meezit binnenkort met een project beginnen waarbij we met Hibernate 3 + annotaties gaan werken.

Ik ben nu nog aan het twijfelen over het nut ervan. Persoonlijk vind ik het nog niet zo`n groot probleem om een apart mapping bestand per class te hebben aangezien de mapping in mijn filetree toch direct onder de class definitie staat. Mijn 'aarrghhh niet nog meer xml' irritatiemeter slaat hier nog niet uit

Misschien dat we nog meer gebruik zien voor annotaties voor dat project, maar heb dat nog niet echt onderzocht. Ik zal met interesse EJB 3 blijven volgen, waarbij ik met name geinteresseerd ben in dependency injection zonder dat je daarvoor Spring nodig hebt.

Offtopic: Ik heb je al een paar keer erg positief gehoord over EJB 3.0. Waarom EJB ipv Hibernate/Spring? Ik heb persoonlijk niet bepaald goeie ervaringen met EJB (2) en mijn algemene ervaring met Sun tools is: leuke bak met ingwikkelde specs.. en tools die een te hoge complexiteit/waarde verhouding hebben. Ik weet dat EJB 3.0 zwaar verbeterd is, maar tegen een POJO met metadata kan het volgens mij niet aanboxen.

En als de ondersteuning voor EJB 3 op korte termijn goed wordt, willen we wellicht van de afhankelijkheid van Hibernate af.

Ik heb begrepen dat de EJB 3.0 persistance specs zwaar zijn gebaseerd op het ontwerp van Hibernate. Waarom zou je hier van af willen?

Maar leuk om te zien dat steeds meer bedrijven serieuzer gaan kijken naar annotations en andere 5.0 features.

[Alarmnummer]

Verwijderd schreef op woensdag 13 juli 2005 @ 10:53:
Zelf ben ik dus net begonnen met generics in java. Als je C++ gewent bent mis je meteen de typedef constructie. Enums en varargs werken weer wil lekkerder, en de for each loopt werkt ook super.

Yep.. ik heb intussen al weer een jaar of 3/4 ervaring met generics in java (Pizza, GJ, beta releases van 1.5). Maar vind het soms nog wel eens lastig om precies te bepalen wat er geparametriseerd moet gaan worden binnen een class. Soms zijn er meerdere oplossingen mogelijk en ga ik meestal voor de simpele, maar krijg daarbij toch verlies van parametriseerbaarheid.

On topic, annotations. Ook ik heb deze niet gebruikt. Ik zie er echter wel een simpele toepassing voor. Ik gebruik nu een soort van container plug-in classes die in een hashmap allemaal andere classes zetten die slechts 1 simpele functie hebben en geen state kennen. M.a.w. het zijn eigenlijk gewoon 'functie' objecten die via een (string) key aangeroepen kunnen worden. (deze aanpak komt een beetje uit mijn C++ achtergrond waar ik vaak maps van functie pointers had).

Zou je daar niet veel eenvoudiger een strategy voor kunnen gebruiken?

Met annotations kan ik nu elke functie in de classe die als "plug-in functie" gebruikt gaat worden markeren, en kan ik in de annotation de key opgeven die naar die functie mapped.

Het probleem is hoe die functie dan aangeroepen moet gaan worden lijkt mij. Met een strategy is dat erg duidelijk.

[ronaldmathies]

Ik gebruik annotations ivm hibernate 3 (EJB3). Daarnaast heb ik een eigen validatie framework gemaakt waarmee je heel gemakkelijk validatie aan objecten kan toevoegen:

code:

public class Test  {
  
  @Required(key="name.required")
  @MaxLength(value=255, key="name.max.length")
  private String name;

  ...
}

Zo heb ik al een redelijke hoeveelheid aan validatie annotations.
Dit kan je vervolgens valideren door de validator aan te roepen met het betreffende object:

code:

try {
  Validator.validate(test);
} catch (ValidationException validationException) {
  throw new EJBException(validationException);
}

Er zijn opzich zat toepassingen voor Annotations. Je moet er alleen even op komen.

[ronaldmathies]

Alarmnummer schreef op woensdag 13 juli 2005 @ 11:13:

Offtopic: Ik heb je al een paar keer erg positief gehoord over EJB 3.0. Waarom EJB ipv Hibernate/Spring? Ik heb persoonlijk niet bepaald goeie ervaringen met EJB (2) en mijn algemene ervaring met Sun tools is: leuke bak met ingwikkelde specs.. en tools die een te hoge complexiteit/waarde verhouding hebben. Ik weet dat EJB 3.0 zwaar verbeterd is, maar tegen een POJO met metadata kan het volgens mij niet aanboxen.

EJB 3 en EJB 2 is niet te vergelijken. Het hele EJB3 model is gewoon Hibernate, het is daarom ook mogelijk om je classe die je voor EJB3 gemaakt hebt gewoon in een stand alone applicatie te gebruiken. (Client -> MySQL bijvoorbeeld.)

EJB3 zijn trouwens gewoon POJO's met metadata.

Ik heb begrepen dat de EJB 3.0 persistance specs zwaar zijn gebaseerd op het ontwerp van Hibernate. Waarom zou je hier van af willen?

Maar leuk om te zien dat steeds meer bedrijven serieuzer gaan kijken naar annotations en andere 5.0 features.

De afwijkingen zijn meer toevoegingen dan dat er echt werkelijk iets is veranderd.

Ik snap dit ook niet helemaal. Het is en blijft hibernate, alleen zit hibernate in dit geval in de EJB container verwikkeld.

[ Voor 6% gewijzigd door ronaldmathies op 13-07-2005 11:47 ]

[Verwijderd]

Alarmnummer schreef op woensdag 13 juli 2005 @ 11:32:
[...]
Zou je daar niet veel eenvoudiger een strategy voor kunnen gebruiken?

Volgens mij niet. De toepassing is in een eigen XML dialectje, de waarde van sommige attributes staat voor een dynamische mapping. Bv iets in de zin van <mytag atr="CURRENT_USER_NAME" /> De string "CURRENT_USER_NAME" staat dan gemapped naar een functie in mijn plug-in container. Elke functie is nu een hele simpele class met alleen een String map(); functie erin.

[Alarmnummer]

ronaldmathies schreef op woensdag 13 juli 2005 @ 11:43:
[...]


EJB 3 en EJB 2 is niet te vergelijken. Het hele EJB3 model is gewoon Hibernate.

Ik snap je niet helemaal. Ik weet dat jij weet dat EJB3 meer is dan alleen een OR-mapper, dus ik kan deze opmerking niet plaatsen.

, het is daarom ook mogelijk om je classe die je voor EJB3 gemaakt hebt gewoon in een stand alone applicatie te gebruiken. (Client -> MySQL bijvoorbeeld.)

Hmm tja.. Er zal een manier moeten zijn om een invulling te geven aan de metadata die in de objecten is opgenomen. Bv het aanleveren van transacties en het rollbacken/committen op basis van transactionele metadata.

Dit is bij mij een taak van Spring en als ik zonder Spring zou werken zou ik het met de handmoeten doen (en dat wil je denk ik niet). Ik neem aan dat een soortgelijke vergelijking ook opgaat voor EJB 3.0.

Ik denk dat het verder onrealistisch om te zeggen dat een object zonder zijn container kan leven. De vraag is alleen hoe complex die container moet zijn (met Spring is het allemaal erg eenvoudig). Trouwens onhankelijk van een container is imho net zo`n fabel als onafhankelijkheid van je or mapper..

[ Voor 25% gewijzigd door Alarmnummer op 13-07-2005 13:14 ]

[Verwijderd]

EJB 3 en EJB 2 is niet te vergelijken. Het hele EJB3 model is gewoon Hibernate, het is daarom ook mogelijk om je classe die je voor EJB3 gemaakt hebt gewoon in een stand alone applicatie te gebruiken. (Client -> MySQL bijvoorbeeld.)

Da's wat te gesimplificeerd. EJB3 != Hibernate. Hibernate heeft een grote rol gehad doordat Gavin King in de spec commissie zat, maar er zaten ook diverse mensen van JDO in de spec commissie, en natuurlijk de gebruikelijke partijen zoals Oracle etc, die nog wel grotere invloed hebben gehad. Aan de oppervlakte vallen de Hibernate achtige constructie het meest op ja, maar dat heeft ook met het feit te maken dat Hibernate3 bewust naar EJB3 is aangepast. Uiteindelijk is het de bedoeling dat Hibernate een EJB3 implementatie is, maar dat je deze implementatie kan vervangen door anderen.

EJB3 zijn trouwens gewoon POJO's met metadata.

Ja, eindelijk van dat active record pattern af. Overigens wordt specificeren in XML ipv met annotaties voorlopig gewoon ondersteund.

De afwijkingen zijn meer toevoegingen dan dat er echt werkelijk iets is veranderd.

Nou ja, noem het kunnen gebruiken van pojo's ipv van die bende interfaces met remote afhandeling etc, de introductie van application managed persistence managers en het kunnen gebruiken van EJB's buiten een J2EE container (dus in de gewone SDK) maar geen veranderingen!

[Eelke Spaak]

Ik las laatst een artikel waarin benadrukt werd dat EJB3 heel erg gebaseerd is op 'programming by exception': als je iets weglaat dan krijgt het meestal wel de juiste defaultwaarde.

Dit zorgt ervoor dat je een Hibernate-achtige manier van interacteren met de container hebt (EJBQL3 is bv. eigenlijk gewoon HQL) zonder dat je moeilijk hoeft te doen met nog weer een extra abstractielaag.

Op het eerste (nouja, eigenlijk tweede) gezicht is EJB3 volgens mij onder de motorkap krachtiger en meer uitbreidbaar dan Hibernate, terwijl je in de praktijk net zo werkt als met Hibernate (1 POJO levert op de container 1 entitybean, zonder extra interfaces of wat dan ook; deze worden als je ze niet opgeeft automatisch gemaakt door de container). Ik denk er sterk over om voor mijn volgende project EJB3 te gaan gebruiken in plaats van Hibernate 2.

[Alarmnummer]

Eelke Spaak schreef op woensdag 13 juli 2005 @ 14:57:
Ik las laatst een artikel waarin benadrukt werd dat EJB3 heel erg gebaseerd is op 'programming by exception': als je iets weglaat dan krijgt het meestal wel de juiste defaultwaarde.

Dit zorgt ervoor dat je een Hibernate-achtige manier van interacteren met de container hebt

Ik zou bij god niet weten wat ik me hierbij moet voorstellen. En ik ben thuis in Hibernate. Ik zie verder ook niet waarom de nadruk van zo op Hibernate gelegd moet worden bij EJB 3.0 aangezien EJB veel verder gaat dan Hibernate.

(EJBQL3 is bv. eigenlijk gewoon HQL) zonder dat je moeilijk hoeft te doen met nog weer een extra abstractielaag.

Als ik direct met Hibernate werkt, dan werk ik helemaal zonder 'extra' abstractie laag.

Op het eerste (nouja, eigenlijk tweede) gezicht is EJB3 volgens mij onder de motorkap krachtiger en meer uitbreidbaar dan Hibernate

EJB 3.0 vergelijken met Hibernate is het zelfde als een auto vergelijken met een paar banden. EJB gaat veel verder dan alleen wat OR-mappen. EJB zorgt voor een bepaald concurrency model, een bepaald transactie model, een bepaald threading model en nog veel meer. Dit doet Hibernate (gelukkig) niet.

, terwijl je in de praktijk net zo werkt als met Hibernate (1 POJO levert op de container 1 entitybean, zonder extra interfaces of wat dan ook; deze worden als je ze niet opgeeft automatisch gemaakt door de container). Ik denk er sterk over om voor mijn volgende project EJB3 te gaan gebruiken in plaats van Hibernate 2.

Tja.. persoonlijk vind ik het een vreemde argumentatie. Ik wil graag een auto gebruiken ipv een paar banden terwijl je misschien alleen een paar banden nodig bent. Als je zegt dat je EJB 3.0 wilt gebruiken ipv Spring, of Hibernate ipv IBatis, dan kan ik iets met je verhaal. Maar hier kan ik niets mee.

[ Voor 8% gewijzigd door Alarmnummer op 13-07-2005 15:12 ]

[Verwijderd]

Verwijderd schreef op woensdag 13 juli 2005 @ 10:53:
Enums en varargs werken weer wil lekkerder, en de for each loopt werkt ook super.

Kan je mij vertellen waar de grote kracht van varargs zit? Ik heb zelf namelijk nog nooit een goede concrete toepassing gevonden (en dus ook neit de noodzaak gehad om het te gebruiken).

[Alarmnummer]

Verwijderd schreef op woensdag 13 juli 2005 @ 15:14:
[...]

Kan je mij vertellen waar de grote kracht van varargs zit? Ik heb zelf namelijk nog nooit een goede concrete toepassing gevonden (en dus ook neit de noodzaak gehad om het te gebruiken).

Het kan zooooo fijn zijn alhoewel ik het niet zo vaak gebruik. Soms heb je functies waarbij je een bewerking wilt uitvoeren op een variabel aantal argumenten. Je zou dan een lijst kunnen maken, de argumenten daarin stoppen en die aan de functie meegeven. Maar dat is veel werk. Ter plekke een array aanmaken is al iets minder pijnlijk.

vb:
int max = max(new int[]{a,b,c});

Maar met varargs kan je het volgende schrijven:

int max = max(1,2,3);

In sommige situaties vind ik het echt extreem prettig werken.. Maar ik ben het nog niet zo vaak nodig geweest. Verder vind ik het geen theoretisch en praktisch interessante taalfeature, in tegenstelling tot generics en annotations. Static imports.. who cares.. and forloop... ach.. die is wel fijn... niet zo bijzonder.. oja.. en last but.... least? autoboxing.. valt ook in de categorie:boeie.

[Verwijderd]

precies dat heb ik dus ook, alleen ben ik dus de situatie nog niet tegengekomen dat ik het kon gebruiken. Ik heb niet zo vaak (nooit) dat ik een variabel aantal argumenten nodig heb. Juist op dat moment is het een collection dat ergens uit, wat voor tier dan ook, komt...

[Verwijderd]

Verwijderd schreef op woensdag 13 juli 2005 @ 15:14:
[...]

Kan je mij vertellen waar de grote kracht van varargs zit? Ik heb zelf namelijk nog nooit een goede concrete toepassing gevonden (en dus ook neit de noodzaak gehad om het te gebruiken).

Eigenlijk zijn varargs (IMO) voornamelijk geintroduceerd voor 1 ding: printf, maar andere formatting classes profiteren er ook van.

Je zou zonder varargs je argumenten altijd in aan array of iets anders moeten wrappen. Bijvoorbeeld:

Java:

formatter.format( msg.getString("my_key"), new Object[]{ arg1, arg2, arg3});

// vs

formatter.format( msg.getString("my_key"), arg1, arg2, arg3 );

In Java wordt dit op de achtergrond door vervangen met een OO oplossing. In C++ heb je een vieze macro waarmee je de stack direct benaderd en deze afloopt. (dit is een erfenis uit C).

Het voordeel overal is dat je die nare wrapper niet hoeft te gebruiken; je code ziet er veel cleaner uit.

[Verwijderd]

Ik vind persoonlijk dan ook printf erg lelijk en zwaar anti OO. Waarom vonden ze het nodig om die ouderwetse c programmeurs een plezier te doen?

Formatting zou er zo uit moeten zien imho:

formatter.addRule ( rule1 );
formatter.addRule ( rule2 );
formatter.addRule ( rule3 );
formatter.format( "bla" );

[ Voor 40% gewijzigd door Verwijderd op 13-07-2005 17:10 ]

[Alarmnummer]

Verwijderd schreef op woensdag 13 juli 2005 @ 17:07:
Ik vind persoonlijk dan ook printf erg lelijk en zwaar anti OO.

1) ik zie niet aan wat er anti oo aan is.
2) ook al was het anti oo, dan is het van een mug een olifant maken.

Het heeft geen gevolgen voor de rest van Java, dus consequenties van deze aanpak zijn er niet. Het is puur een syntaxtisch suiker..

Waarom vonden ze het nodig om die ouderwetse c programmeurs een plezier te doen?

Formatting zou er zo uit moeten zien imho:

formatter.addRule ( rule1 );
formatter.addRule ( rule2 );
formatter.addRule ( rule3 );
formatter.format( "bla" );

Sommige mensen die houden ook wel van makkelijk programmeren. Uiteraard kan iedereen bv werken met een lange kut syntax bij de forloop

code:

for(Iterator<Persoon> it = persoonlist.iterator();it.hasNext();){
      Persoon p = it.next();
      ...
}

of

code:

for(Persoon p: persoonList){
...
}

Ik weet wel wat ik lekkerder vind werken. Soms kunnen kleine verbeteringen in een taal een hoop irritatie/geklungel wegnemen.. En dat soort dingen zijn ook belangrijk. Uiteindelijk zal in een taal ontwikkeld moeten worden.

[edit]

En ik vind:

formatter.format( "bla" ,rule1,rule2,rule3);

toch echt wel 1000 keer fijner dan:

formatter.addRule ( rule1 );
formatter.addRule ( rule2 );
formatter.addRule ( rule3 );
formatter.format( "bla");

Ik hou van zo weinig mogelijk niets zeggende ruis in mijn code...

[ Voor 17% gewijzigd door Alarmnummer op 13-07-2005 17:50 ]

[Verwijderd]

Soms kunnen kleine verbeteringen in een taal een hoop irritatie/geklungel wegnemen.. En dat soort dingen zijn ook belangrijk.

He zeg, Alarmnummer, was jij niet diegene die Wicket niet voldoende vond toevoegen ten opzichte van Tapestry? Slechts een paar irritante dingentjes beter deed?

[ Voor 3% gewijzigd door Verwijderd op 13-07-2005 20:17 ]

[Alarmnummer]

Verwijderd schreef op woensdag 13 juli 2005 @ 20:16:
[...]
He zeg, Alarmnummer, was jij niet diegene die Wicket niet voldoende vond toevoegen ten opzichte van Tapestry? Slechts een paar irritante dingentjes beter deed?

Uhhh... ik zeg wel vaker iets Maar verder komt me dit niet zo bekend voor aangezien Tapestry bij ons erg op de tocht staat (dat was ook mijn eerste reply waarop je hebt gereageerd), en dus niet bij voorbaat een lichtere versie van Tapestry afkeur.

[ Voor 7% gewijzigd door Alarmnummer op 13-07-2005 20:49 ]

[Verwijderd]

Over de forEach zul je me ook niet horen, die vind ik heel fijn. Maar om even terug te komen op het formatting voorbeeld, ik weet eigelijk negen van de tien keer niet welke Rules ik ga gebruiken in compile time, dat zoek ik wel in runtime uit met bijvoorbeeld een config bestandje...

[Verwijderd]

Om het topic nog wat meer te laten gaan richting algemene java language features:

Ik mis ook nog steeds de [] notatie voor Collection classes.

bijvoorbeeld:

Java:

HashMap<String,String> myMap = new HashMap<String,String>();

myMap[ "test" ] = "entry";
String mystr = myMap[ "test" ];

Eigenlijk weer zo'n heel klein syntax dingetje wat de leesbaarheid toch wel vergroot.

[ Voor 47% gewijzigd door Verwijderd op 14-07-2005 15:29 ]

[Verwijderd]

en daar ben ik het natuurlijk weer is lekker recalsitrant niet mee eens

Moet je die dan zelf gaan specificeren middels operator overriding of ga je er vanuit dat elke Collection klasse een [] operator heeft? "get" is toch leesbaar genoeg? Sterker nog, het is leesbaarder...

[ Voor 9% gewijzigd door Verwijderd op 14-07-2005 15:49 ]

[Verwijderd]

Verwijderd schreef op donderdag 14 juli 2005 @ 15:48:
en daar ben ik het natuurlijk weer is lekker recalsitrant niet mee eens

Moet je die dan zelf gaan specificeren middels operator overriding of ga je er vanuit dat elke Collection klasse een [] operator heeft? "get" is toch leesbaar genoeg? Sterker nog, het is leesbaarder...

Ik twijfel aan zelf specificeren. In feite is het cleaner, maar het kan tot abuse lijden. Aan de andere kant, static imports kunnen dat ook. De build-in array van java gebruikt wel de [] notatie, en dit is feitelijk ook een Class waarop zowel "generics" als [] vanaf het begin werkzaam zijn.

Door het feit dat je raw arrays eigenlijk nooit meer gebruikt, vervalt dus eigenlijk het hele [] gebruik in java. Dat is eigenlijk zonde. Bekijk het eens van de andere kant, wat is er niet leesbaar aan []?

In de allersimpelste, minst intrusive implementation, zou [] voorbehouden zijn aan interface Collection.

Aan de left-side van een assignment zou het dan automatisch een put worden:

code:

objX[ objY ] = objZ;   --->  objX.put( objY, objZ);

Aan de right-side van een assignment en in een expressie zou het dan automatisch een get worden:

code:

objZ = objX[ objY ];  ---> objZ = objX.get( objY );

[Verwijderd]

Los van het feit dat er geen onderscheidt meer moet worden gemaakt tussen put en get ( immers Object bar = objects[1] = new String("foo") ; ), zie ik het grote voordeel niet. Het brengt ook wat eigenaardigheden met zeg mee, bijvoorbeeld de length property van een Array. Die is natuurlijk constant maar je kunt er voor een Collection klasse geen property van maken aangezien een Collection klasse mutable is. Dus je kunt ze sowieso niet generiek behandelen.

Het zijn in weze dus twee verschillende types dus behandel ze ook verschillend

[Verwijderd]

Verwijderd schreef op donderdag 14 juli 2005 @ 16:15:
Het brengt ook wat eigenaardigheden met zeg mee, bijvoorbeeld de length property van een Array. Die is natuurlijk constant maar je kunt er voor een Collection klasse geen property van maken aangezien een Collection klasse mutable is. Dus je kunt ze sowieso niet generiek behandelen.

Het is natuurlijk niet noodzakelijk dat een Collection alles van een array moet overnemen. Integendeel zelfs. Een raw array mag best zijn impliciete public length field houden, zonder dat een Collection deze hoeft te hebben. Eventueel zou een raw array wel wat meer van Collection mogen overnemen, maar dat is eigenlijk een ander verhaal. (je ziet nu al dat de raw array ook 'opeens' de Iterable interface impliciet heeft toegedeeld gekregen).

Waar het eigenlijk alleen maar om gaat is de C talen een syntax hebben voor get en set. Dmv de enorme liguistische kracht van C++ is het in die taal mogelijk gebleken om deze syntax in de OO wereld toe te passen. In C++ is namelijk hetzelfde process als in Java gaande: primitive types zoals de raw array worden steeds minder en minder gebruikt.

Het zijn in weze dus twee verschillende types dus behandel ze ook verschillend

Mhoah... als raw arrays nog echt VEEL gebruikt zouden worden, zou dat mischien een punt zijn. Maar raw arrays zijn dino's in Java. Niemand die ze meer gebruikt. Je maakt alleen af en toe een raw array aan als er een oude legacy lib function is die dat type wil hebben.

Hierdoor verdwijnt [] gewoon uit Java, en iniedergeval ik vind dat zonde.
Dingen als Array en ArrayList komen -direct- in de plaats van de raw array, echter de [] ben je kwijt.

[Verwijderd]

Maar mag je dan ook in jou ogen dingen doen als:
Collection c = new ArrayList(){ arg0, arg1, arg2 };

Oftewel hoe ver wil je gaan.
------------------------------------------
Overigens denk ik dat bij reflectie die varargs wel handig zouden kunnen zijn in tegenstellig tot wat ik eerder had te melden.

[Verwijderd]

Verwijderd schreef op donderdag 14 juli 2005 @ 16:57:
Maar mag je dan ook in jou ogen dingen doen als:
Collection c = new ArrayList(){ arg0, arg1, arg2 };

Dat is inderdaad een goede waar ik nog niet aan had gedacht. De 1D versie kun je nog makkelijk oplossen met varargs:

new ArrayList<String>( "aap", "noot", "mies" );

Maar 2D wordt lastiger met varargs. Voor collections waar de index geen nummer is zou je zelfs een andere syntax moeten verzinnen. Dat lijkt me niet de bedoeling. Voor numbered collections kan het wel. Via de template params kun je ook de types afleiden:

new ArrayList<Arraylist<String>>() { {a,b}, {c,d} };

Het zou kunnen ja, maar persoonlijk zie ik liever alleen de [] terug in objecten. Makkelijk, duidelijk, bij iedereen bekend (beetje elke bekende taal gebruikt het wel, alleen java niet omdat het zich zo perse wil afzetten tegen C++ ).

Oh, en nu we toch bezig zijn:

De rekenkundige operators voor alle java.lang.Number's

[ Voor 23% gewijzigd door Verwijderd op 14-07-2005 17:35 ]

[Verwijderd]

ja, laat Java op C++ gaan lijken. 1000 manieren om hetzelfde te bereiken. Lekker nog meer discussies over code standards. Van mij hoeft het niet.

[Verwijderd]

Verwijderd schreef op donderdag 14 juli 2005 @ 17:46:
ja, laat Java op C++ gaan lijken. 1000 manieren om hetzelfde te bereiken. Lekker nog meer discussies over code standards. Van mij hoeft het niet.

Tsja, aan de ene kant heb je wel gelijk, maar waarom heeft java dan bijvoorbeeld wel de while loop syntax precies van C++ (indirect C) overgenomen? De statement syntax? De declaratie syntax?

Dat Java een aantal dingen niet heeft overgenomen komt omdat het notaire moeilijke/gevaarklijke punten in C++ waren. Pointer arithmetic is 1 zo'n ding. MI is een andere. De wijze waarop C++ -echt- generic programming ondersteund is mischien ook zo'n punt. (Zie bv template meta programming, of de boost lambda functions. Krachtig, maar ultiem verwarrend). Globale functies en parameters, headers (.h) includes (met het gare #ifndef etc), macro's, etc zijn nog veel meer C++ dingen die echt niemand in Java wil hebben.

Maar wat is er ERG aan bijvoorbeeld default parameters voor methods? Wat is er erg aan operators voor classes? De raw array heeft toch ook gewoon de [] operator? En voor String heb je toch ook de +?

[ Voor 4% gewijzigd door Verwijderd op 14-07-2005 18:16 ]

[Alarmnummer]

Verwijderd schreef op donderdag 14 juli 2005 @ 17:46:
ja, laat Java op C++ gaan lijken. 1000 manieren om hetzelfde te bereiken. Lekker nog meer discussies over code standards. Van mij hoeft het niet.

In sommige gevallen heb ik er niet zoveel problemen mee. Ik zou er bv geen problemen mee als je een operator voor sommige types overload.

Matrix a = b.multiply(c);

of

Matrix a = b * c;

Operatoren waarover geen onduidelijkheid kan ontstaan... Maar je moet bv niet gaan knoeien met de . of de new operator.

Op taalconstructie nivo zijn er imho niet veel praktische discussies te voeren (imho zijn het meestal taalpuristen en andere totaal onpraktische mensen die zoveel stennis lopen te schoppen). Het zijn meer standaarden op het gebied van frameworks, die me zorgen baren. Vooral dat je vaak qua compiletime veiligheid zoveel moet inleveren (iedereen loopt maar met strings te prutsen en vind dit de normaalste zaak van de wereld).

[ Voor 40% gewijzigd door Alarmnummer op 14-07-2005 18:27 ]

[Cuball]

de rekenkundige operaties overloaden zou inderdaad handig zijn...

annotations... voorlopig gebruiken wij die nog niet, ik zie er het extra voordeel nog niet van in...

Wat soms vergeten wordt is dat niet iedereen zo snel alles onder die knie krijgt en tegenwoordig zijn er zoveel frameworks, nieuwe technieken dat je niet meer weet wat eerst te bekijken, laat staan gebruiken...

Voorlopg voel ik me goed met de combinatie Spring, Hibernate, Struts... dit alles op 1.4

[Verwijderd]

Ja al kun je ze overloaden kun je ze ook te makkelijk misbruiken. Ontwikkelen zou niet moeten beteken dat je voor elk stukje third-party software dik de docs in moet duiken om uit te vissen hoe alles overloaded is.

[Alarmnummer]

Verwijderd schreef op vrijdag 15 juli 2005 @ 07:54:
Ja al kun je ze overloaden kun je ze ook te makkelijk misbruiken. Ontwikkelen zou niet moeten beteken dat je voor elk stukje third-party software dik de docs in moet duiken om uit te vissen hoe alles overloaded is.

Ik denk dat dat wel meevalt. Als je nu een methode aanroep zit, of je zit een operator. De een zijn syntax is een stuk prettiger dan de ander. Je weet gewoon als het andere types zijn, dan moet het wel overloaded zijn. Dus operatoroverloading zou ik geen problemen mee hebben.

Trouwens.. alles kan misbruikt worden. Kan ook wel een api maken die bij de 1e add jouw hele pron collectie van je schijf haalt

[misfire]

Annotations gebruik ik zelf al in Java 5 voor het @Override, @Deprecated en dat soort dingen. Ik ken het metadata principe al uit .NET en het is een geweldig krachtig principe, en is met stip de belangrijkste toevoeging aan Java 5. De crux zit hem echter in het feit dat metadata op zich zelf niks doet: er zullen eerst standaarden, frameworks en tools moeten komen die gebruik maken van annotations.

De taal Java is afhankelijk van frameworks die features op een correcte manier benutten. In Beehive worden annotations bijvoorbeeld erg uitgebreid ingezet, maar dienen ze vaak wel als een soort declaratie van gedrag, niet als metadata. Dat is een erg goed voorbeeld van metadata als hype-factor ipv als toegevoegde waarde te gebruiken. Hopelijk zullen andere frameworks minder snel vallen voor de verleiding van de coole en hippe annotations, anders zal over 4 jaar iedereen annotations ook de neus uitkomen, net zoals men nu vaak een hekel heeft aan XML configuratiebestanden (terwijl die ook nuttig kunnen zijn).

[Verwijderd]

@Override is zoooo goed. Wat had me dat een hoop bug hunting gescheeld in het verleden!

[Verwijderd]

Verwijderd schreef op vrijdag 15 juli 2005 @ 23:11:
@Override is zoooo goed. Wat had me dat een hoop bug hunting gescheeld in het verleden!

Praktijk voorbeeldje?

[Verwijderd]

Praktijk voorbeeldje?

Stel, je bouwt voort op een api, waarin overridable methode 'foo' zit. Je hebt zelf foo overschreven met je eigen implementatie, en verwacht dat deze methode als onderdeel van de api waarop je voortborduurt wordt aangeroepen. Stel dat de api een refactoring doorvoert, waardoor foo nu 'bar' heet. Als je de api nu update, is foo betekenisloos geworden, terwijl je daar waarschijnlijk pas runtime achterkomt. Nu de truuc: als je bij 'foo' de annotatie @Override had gezet, wordt compile time gechecked of foo inderdaad wel een methode override. Is dit niet het geval, compileert het niet, en is direct duidelijk dat je iets te fixen hebt.

Ik heb zelf vrij regelmatig bugs gehad doordat het onderliggende framework dergelijke refactorings had. En dan kan het best even duren voordat je doorhebt dat er uberhaupt iets aan de hand is.

[Verwijderd]

Verwijderd schreef op maandag 18 juli 2005 @ 13:38:
[...]
Stel dat de api een refactoring doorvoert, waardoor foo nu 'bar' heet. Als je de api nu update, is foo betekenisloos geworden, terwijl je daar waarschijnlijk pas runtime achterkomt.

Ik snap het ja, en in die situatie is het handig. Bedankt voor de uitleg. Wel heb ik er nog een beetje mijn bedenkingen over. Namelijk, als foo naar bar wordt gerenamed, en jij geeft jouw type door aan aan het framework, dan gaat het dus fout als jij heel toevallig al een method bar had met dezelfde signature. Dat is wel een *groot* toeval, maar -als- het gebeurd heb je idd een moeilijk te vinden bug ja...

[misfire]

@Override is een erg goed voorbeeld van metadata. In andere talen is er vaak een keyword voor, maar de meeste keywords zijn in principe ook een vorm van metadata. Met @Override kun je ook zien dat een methode iets override terwijl het niet de bedoeling is, door bijv. Eclipse een warning te laten geven voor iedere override methode zonder @Override annotation.

Een goed stukje metadata is zelfbeschrijvend en eenvoudig, maar het opent hele nieuwe deuren voor het schrijven van code. In de nieuwste versie van AspectJ kan bijvoorbeeld ipv de AspectJ syntax ook met annotations advices geschreven worden, waardoor je met standaard Java kunt werken zonder dat dit heel veel aan uitdrukkingskracht verliest.