[Java] J2SE 1.5 Beta 2 is uit!

[Stephan Oudmaijer]

Jawel, te downloaden bij Sun: http://java.sun.com/j2se/1.5.0/

Ben even aan het spelen geweest met nieuwe language features als Generics. Let wel op dat je specifiek tegen je compiler verteld dat je 1.5 specifieke features wilt gebruiken, dit doe je bijv zo:

javac -source 1.5 MyClass.java

Leuk nieuwe dingen:

Generic Types

Oude situatie:

ArrayList list = new ArrayList();
list.add(0, new Integer(42));
list.add(1, "fout");

Je kan allerlei verschillende Objecten in een ArrayList stoppen. Dit kan dus ook fout gaan. Stel je verwachten een lijst met alleen Integers, dan zou je hier net zo goed een String of ieder ander type aan toe kunnen voegen omdat de compiler dit prima vind.

Met generics:

ArrayList<Integer> list = new ArrayList<Integer>();
list.add(0, new Integer(42));
list.add(1, "fout");

De compiler vind dit niet goed omdat de typen niet matchen, omdat dit een Integer ArrayList is. De compiler checked of de juiste waarden aan je lijst worden toegevoegd.

Autoboxing and Auto-unboxing of Primitive Types

int i = new Integer(1);

Met JDK 1.4 mocht dit niet, omdat je een object aan een primitieve toekent.
Met 1.5 wordt automatisch de juiste wrapper functie aangeroepen (intValue()).

Metadata

The Metadata feature in J2SE 1.5 provides the ability to associate additional data alongside Java classes, interfaces, methods, and fields. This additional data, or annotation, can be read by the javac compiler or other tools, and depending on configuration can also be stored in the class file and can be discovered at runtime using the Java reflection API.

One of the primary reasons for adding metadata to the Java platform is to enable development and runtime tools to have a common infrastructure and so reduce the effort required for programming and deployment. A tool could use the Metadata information to generate additional source code or provide additional information when debugging.

Opstart tijden:

Opstarttijd van Swing applicaties is aanzienlijk verbeterd. Ze hebben ook aan de memory footprint gewerkt maar ik vind dit persoonlijk nog tegenvallen.

Nog meer leuke dingen zijn via de volgende links te vinden:

- http://java.sun.com/devel...Articles/releases/j2se15/
- http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html

[ Voor 34% gewijzigd door Stephan Oudmaijer op 05-02-2004 15:18 ]

[Alarmnummer]

En wat dacht je verder van metadata zoals c# dat ook heeft Ik moet me echt gaan verdiepen in de mogelijkheden ervan, maar ik denk dat dit de meeste krachtige feature is die in de afgelopen nieuwe jdk`s erbij is gekomen.

En natuurlijk die nieuwe forlus:

code:

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

en nu:

code:

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

En nog een hele lading andere leuks zoals de varargs, static imports en de leuke concurrency goodies van doug lea. Maar ik neem dat andere posters hier wel iets over willen vertellen.

Oja.. De javadoc is nu ook beschikbaar voor 1.5 en deze is ook meteen voorzien van generics.

[ Voor 61% gewijzigd door Alarmnummer op 05-02-2004 15:22 ]

[Stephan Oudmaijer]

Alarmnummer schreef op 05 februari 2004 @ 15:15:
En nog een hele lading andere leuks zoals de varargs, static imports en de leuke concurrency goodies van doug lea. Maar ik neem dat andere posters hier wel iets over willen vertellen.

steek jij eens van wal

[Alarmnummer]

CK schreef op 05 februari 2004 @ 15:23:
[...]


steek jij eens van wal

Op javahova zijn al zoveel discussies hierover geweest en verder zijn ze ook terug te vinden in J2SE 1.5 in a Nutshell. Ik ga het daarom niet nog een keer herhalen.

Maar ik zou iets lezen over wat er allemaal mogelijk is met metadata/attributen. Dit is echt een ongelovelijk krachtige toevoeging waar we nog heel veel van gaan horen.

[Tmr]

CK schreef op 05 februari 2004 @ 15:12:
Leuk nieuwe dingen:

Generic Types

<snip>

Hmm dat lijkt erg veel op het gebruik van templates in C++

Handig!

Het nadeel was altijd dat je bij een ArrayList (zoals in het voorbeeld) altijd zelf maar een beetje moest bepalen welk object er in zat en bij list.get() oid dan ook nog eens een cast moest doen. Compile time controleren lijkt mij in dit geval dus handiger en iets minder gevoelig voor fouten.

Swing sneller opstarten? Ja graag!

Die andere dingen zoals jij ze beschreef zoals de nieuwe for-loop enz vat ik nog niet helemaal maar ik zal er eens uitgebreid naar kijken.

[Donderwolk]

Mooi werk, vanavond maar eens downloaden en eens wat van die nieuwe functies uitproberen.

Vooral die metadata shit is heftig. Waarschijnlijk kun je hierbij denken aan een goede scheiding tussen design en functionaliteit (?). Dat weet ik niet zeker, maar dat lijkt mij in ieder geval erg mooi. Er zijn al pakketten die dit mogelijk kunnen maken, maar het is natuurlijk altijd mooier als het standaard in Java zit.

[ Voor 66% gewijzigd door Donderwolk op 05-02-2004 15:37 ]

[Alarmnummer]

Donderwolk schreef op 05 februari 2004 @ 15:33:
Mooi werk, vanavond maar eens downloaden en eens wat van die nieuwe functies uitproberen.

Vooral die metadata shit is heftig. Waarschijnlijk kun je hierbij denken aan een goede scheiding tussen design en functionaliteit (?). Dat weet ik niet zeker, maar dat lijkt mij in ieder geval erg mooi. Er zijn al pakketten die dit mogelijk kunnen maken, maar het is natuurlijk altijd mooier als het standaard in Java zit.

M.b.v. metadata kan je op een hele declaratieve manier programmeren. Je maakt een beschrijving van wat opgelost moet worden, maar niet hoe.

vb:

code:

[table=Persoon]
class Persoon{
     [column=voornaam]
     private String _voornaam;

     [column=achternaam]
     private String _achternaam;

      .....
}

Je zou nu een metadata tool kunnen pakken die aan de hand van deze metadata de database mapping geneert/aansluit. XDoclet was een noodgreep om dit soort dingen te kunnen doen, maar nu is het echt een onderdeel geworden van Java.

Metadata gaat imho samen met AOP een grote verandering teweegbrengen in de software wereld. Omdat het technieken zijn waarvoor je geen academicus hoeft te zijn om toe te passen en omdat het zoveel problemen oplost waar je anders met design patterns of andere kunstgrepen moest werken. Het is gewoon de volgende logische stap.

[ Voor 5% gewijzigd door Alarmnummer op 05-02-2004 16:04 ]

[Alarmnummer]

Ik krijg het niet aan de praat. De alpha crashte 100% bij het unit testen en regelmatig bij het compileren, en deze versie crasht 100% bij het compileren (bij een project waar ik nu mee bezig ben). Ik heb alle jdk`s/jre`s verwijdert en de nieuwste ANT geinstalleerd, maar de compiler crasht iedere keer. Ga ik terug naar jdk1.4.2 + generics compiler, dan is er niets aan de hand.

[edit]
Het ligt aan de switch case op de enums:
http://developer.java.sun...gParade/bugs/4974322.html

[ Voor 14% gewijzigd door Alarmnummer op 06-02-2004 16:59 ]

[Janoz]

Gadverdamme.... Ze hebben de CachedRowSet toegevoegd, nou, die mag van mij gelijk down the drain eigenlijk.. Voor de rest ben ik erg benieuwd naar het META gebeuren. Zoals ik er nu naar kijk lijkt het wel wat op wat ik tegenwoordig met xdoclet en ant doe.

[Glimi]

Ik wacht eigenlijk liever nog even tot de final en totdat IntelliJ met 4.0 van IDEA uitkomt. Ik vrees dat ik te verwend ben om in iets anders te programmeren

[Janoz]

Glimi schreef op 06 februari 2004 @ 09:33:
Ik wacht eigenlijk liever nog even tot de final en totdat IntelliJ met 4.0 van IDEA uitkomt. Ik vrees dat ik te verwend ben om in iets anders te programmeren

Hoezo? ZIjn er ook andere omgevingen dan?

[Reefer]

[spam die ik in mn mail vond]CodeGuide 6.1 is the first IDE that fully supports the
J2SDK 1.5.0 beta and all the new language features[/spam]

[Alarmnummer]

Janoz schreef op 06 februari 2004 @ 09:30:
Gadverdamme.... Ze hebben de CachedRowSet toegevoegd, nou, die mag van mij gelijk down the drain eigenlijk.. Voor de rest ben ik erg benieuwd naar het META gebeuren. Zoals ik er nu naar kijk lijkt het wel wat op wat ik tegenwoordig met xdoclet en ant doe.

XDoclet doet 'compiletime' iets met metadata, maar voor zover ik weet kan bij de java versie ook runtime iets met metadata gedaan worden (dus ze moeten gewoonbeschikbaar zijn dmv reflectie). Het is denk ik daarom alleen al krachtiger.

Veel EJB problematiek kan ook met metadata opgelost worden en ik hoop dat XDoclet daar snel op inspringen (dat zij dus alle XDoclet transformatoren omzetten naar metadata transformatoren).

*heeft nog veel te veel bloed in zijn koffie*... *schenkt zich daarom maar weer een in*

[ Voor 18% gewijzigd door Alarmnummer op 06-02-2004 09:52 ]

[Stephan Oudmaijer]

Janoz schreef op 06 februari 2004 @ 09:35:
[...]


Hoezo? ZIjn er ook andere omgevingen dan?

Eclipse (WSAD) 4evah

[Robtimus]

CK schreef op 06 februari 2004 @ 09:51:
[...]


Eclipse (WSAD) 4evah

Wat is er mis met een gewone text editor??

[Anoniem: 22001]

IceManX schreef op 06 februari 2004 @ 11:21:
[...]
Wat is er mis met een gewone text editor??

Je doet veel nodeloos werk?

[Robtimus]

Ik heb Eclipse wel uitgeprobeerd, heb IntelliJ ook wel geinstalleerd (bevalt me beter dan Eclipse), maar ik vind TextPad icm Ant toch fijner werken.

Ik zal wel vreemd zijn

[ Voor 10% gewijzigd door Robtimus op 06-02-2004 12:40 ]

[Janoz]

@IceManX: Nog nooit gerefactored zeker

@Alarmnummer: @runtime kan tegenwoordig ook al veel door reflectie. Zie bijvoorbeeld jmx. Misschien dat het nu echter wel een stuk makkelijker wordt. Als ik zo bij de beschrijving kijk is het vooral om het programmeren en deployen te vergemakkelijken. Dat zijn nu juist de dingen die ik met ant en xdoclet doe.

[ Voor 30% gewijzigd door Janoz op 06-02-2004 15:43 ]

[Alarmnummer]

Janoz schreef op 06 februari 2004 @ 15:40:
@Alarmnummer: @runtime kan tegenwoordig ook al veel door reflectie. Zie bijvoorbeeld jmx. Misschien dat het nu echter wel een stuk makkelijker wordt. Als ik zo bij de beschrijving kijk is het vooral om het programmeren en deployen te vergemakkelijken. Dat zijn nu juist de dingen die ik met ant en xdoclet doe.

Met metadata kan je runtime metadata eigenschappen aan code ontdekken dmv reflectie en daar acties op ondernemen. Kan dat ook met jmx? Volgens mij is dat iets volledig anders.

[edit]
Verder kan je compile time op attributen ook extra acties laten plaatsvinden. bv or-mapping genereren of stubs... of... noem maar op dus.

[ Voor 12% gewijzigd door Alarmnummer op 06-02-2004 16:26 ]

[whoami]

Janoz schreef op 06 februari 2004 @ 15:40:
@Alarmnummer: @runtime kan tegenwoordig ook al veel door reflectie. Zie bijvoorbeeld jmx. Misschien dat het nu echter wel een stuk makkelijker wordt. Als ik zo bij de beschrijving kijk is het vooral om het programmeren en deployen te vergemakkelijken. Dat zijn nu juist de dingen die ik met ant en xdoclet doe.

Heb je het hier over die metadata?
In C# is het zo dat je mbhv attributes specifieke eigenschappen kunt meegeven. Je gaat dus -zoals Alarmnummer al zei- declaratief gaan programmeren.

Bv, in .NET heb je het Serializable attribuut. Als je een class 'decoreert' met dit attribuut, dan is die class Serializable, wat wil zeggen dat een Formatter automatisch alle public fields van die class kan serializeren, zonder dat je er code voor hoeft te schrijven.
Waar attributen in .NET nog veel voor gebruikt worden, is voor 'Code access security'.
Het is dus echt wel functionaliteit toevoegen aan je classes, zonder dat je eigenlijk zelf enige logica hoeft te programmeren.

[Anoniem: 1999]

Los van al die mooie nieuwe taal-features (die ik toch pas serieus ga gebruiken zodra de final uit is), heb ik wat performance tests gedaan met wat 1.4.2-based code hier (HTTP server-systeem onder JBoss met veel xml en native java database):

Backup-procedure (SQL select *, xmlwriter, zipstream, encryptionstream): 60% sneller!
Heavy bulk stores from client to server (read/write stream, sax, dom, image-scaling, veel java sql statements): 55% sneller (let op, image processing en database is hier dus ook java code)!
Heavy bulk loads from client to server (read/write stream, dom, SQL select ): 27% sneller!

Niet slecht dus, out-of-the-box 27% tot 60% performance-winst bij vervangen van 1.4.2 door 1.5.0

Wel wat probleempjes nog:
- Memory base is flink hoger geworden .
- "-server" mode nog steeds flink langzamer dan "-client".
- "enum" is helaas een keyword geworden, dus al m'n variabelen die "enum" heten mocht ik gaan renamen (heb veel "Enumeration enum = " gebruikt).
- Ze lijken nu ook native threading te gebruiken op Windhoos, dus de memory-cost voor threads gaat flink omhoog t.o.v. java-only threads (liep hier dus out-of-memory vanwege een programmeerfoutje met threads aanmaken waar ik met 1.4.2 geen last van had LOL).
- Ik moest als extra opstart-parameter "-Djmx.invoke.getters=true" gebruiken om jmx werkend te krijgen (kan ook aan de antieke versie van JBoss liggen).
- Lijken nog wat probleempjes te zijn met de GUI-code (fonts zien er raar uit, text pas net niet op buttons, etc).

Maar qua voordelen vielen me zo direkt op:
- veel sneller
- std bmp image support (hoef jaiiio libs nu alleen nog voor tiff te gebruiken )
- std xpath & schema support

Waar blijft de final?

[Janoz]

Ik heb er ook maar ff vluchtig naar gekeken dus vandaar dat ik de volledige mogenlijkheden van de meta data nog niet door heb.. Daarnaast ben ik pas 2 dagen echt intensief mete jmx bezig .. Ben vandaag nogal druk bezig geweest met mijn eerste block en module te schrijven voor jboss nukes.

[ Voor 17% gewijzigd door Janoz op 06-02-2004 17:03 ]

[Alarmnummer]

Anoniem: 1999 schreef op 06 februari 2004 @ 16:53:
Niet slecht dus, out-of-the-box 27% tot 60% performance-winst bij vervangen van 1.4.2 door 1.5.0

Dat is zeker niet slecht

Wel wat probleempjes nog:
- Memory base is flink hoger geworden .

Ik weet niet welke mode je hebt gebruikt (client/server), maar de client hoort veel minder geheugen te verbruiken.

- "-server" mode nog steeds flink langzamer dan "-client".

Das gek, want de server is voor speed, de client voor geheugenverbruik + opstartsnelheid.

- "enum" is helaas een keyword geworden, dus al m'n variabelen die "enum" heten mocht ik gaan renamen (heb veel "Enumeration enum = " gebruikt).

Kan je ook meteen overstappen op die mooie forlus. Hoef je geen enums of iterators meer expliciet te vermelden.

- Lijken nog wat probleempjes te zijn met de GUI-code (fonts zien er raar uit, text pas net niet op buttons, etc).

Winlaf ben ik gisteren tegen aangelopen. De fout die jij nu krijgt zal hier wel niet mee te verhelpen zijn, maar ik vond dit ook wel een aardig project.

[Anoniem: 1999]

Ik weet niet welke mode je hebt gebruikt (client/server), maar de client hoort veel minder geheugen te verbruiken

.
Ik heb niet zozeer naar de meest kale footprint gekeken (een lege main() met verder niets ofzo), maar naar de situatie direkt na het opstarten van onze servercode.
Als ik de runtime switch van 1.4.2 naar 1.5.0beta (verder precies dezelfde, 1.4.x based gecompileerde code), beide in client-mode trouwens want die bleken het snelst, gebruikt onze server-app (als ie idle is, direkt na het opstarten, verder onbelast) nu 100MB ipv 40MB... Ik hoop dat daar nog wat verandering in komt als we de final krijgen...
Ik nam aan dat de server-mode t.o.v. de client-mode minder GUI-gerelateerde zaken cachet en meer geschikt is voor grote aantallen threads en permanente processing, en bv ook een andere JIT- en garbage-collection strategie volgt, maar het grote verschil in performance tussen client en server mode verbaasde me eerlijk gezegd wel, zat echt in de orde van 10-15%. Moet me daar toch eens wat meer in gaan verdiepen, ben toch wel benieuwd wat voor app je moet hebben voordat de server-mode lonend wordt...

Kan je ook meteen overstappen op die mooie forlus. Hoef je geen enums of iterators meer expliciet te vermelden.

Ja is wel mooi he maar totdat 1.5 final er is blijft onze produktiecode zeker weten gewoon 1.4.x compatible hoor, dus die mooie nieuwe taal-features blijven nog even in de kast...
Maar heb wel vast alle deprecated meldingen gefixed: in de tools met swing code zat bv her en der nog ".show()" i.p.v. "setVisible(true)", krijg je nu een warning voor, dus dat was niet zo moeilijk te fixen, die "enum" variabelen heten nu "enu" en voor enkele undocumented classes die plots verdwenen zijn (tja dat krijg je ervan he) heb ik ook alvast de 1.5-alternatieven opgezocht en geimplementeerd, en nog meer van dat soort kleine zaken, zodat we straks zonder problemen moeten kunnen switchen van 1.4.2 naar naar 1.5 final.
Al met al in een paar uur de hele servercode 1.5-compatible gemaakt dus dat viel me erg mee.

Ben toch wel erg tevreden met wat ik tot nu toe heb gezien, echt enorm veel vooruitgang geboekt qua features en performance dit keer, voor de mensen bij Sun en JCP !

[hobbit_be]

offtopic:
en nu nog tijd vinden om ermee aan de slag te gaan

wellicht domme vraag maar is het dan nog J2EE 'compatible'? met al die extra features wordt er dan nergens iets 'gebroken'?

Dat hij zoveel sneller is vind ik wel enorm positief - maar eigenlijk ook irritant als je na 10 jaar op 1 versie nog ineens 50% sneller boekt was je daarvoor toch maar slecht bezig.

Maar imho belangrijkste change op Programmeer vlak sinds C# (en tot C# v2.0

[Anoniem: 72194]

Ik denk dat sun de hete adem van het c#-team in hun nek voelt. Ze hebben dan ook maar de nieuwste zaken geimplemteerd die ofwel al in c# aanwezig was (declaratief programmeren door attributes/metadata) of door MS is geintroduceerd met c# 2.0 draft (generics). Ik vind het wel een positieve evolutie omdat alleen wij er tenslotte beter van worden .

Ik dacht dat je IntelliJ IDE 4.0 nu kon downloaden!?

In ieder geval zal ik in de nabije toekomst eens gaan programmeren in 1.5.0 beta!

[epo]

is deze versie nou compatible met anti aliasing in 2d ?

[Anoniem: 26970]

Alarmnummer schreef op 05 februari 2004 @ 16:02:
Metadata gaat imho samen met AOP een grote verandering teweegbrengen in de software wereld. Omdat het technieken zijn waarvoor je geen academicus hoeft te zijn om toe te passen en omdat het zoveel problemen oplost waar je anders met design patterns of andere kunstgrepen moest werken. Het is gewoon de volgende logische stap.

Misschien een klein beetje offtopic, maar ook loos voor een apart topic:

Nu er al een grote stap gezet is door Metadata in Java te bouwen, is er dan ook een kans dat AOP ook in 'de officiële Java' komt in een toekomstige versie? In plaats van een addon zoals AspectJ?

Dit vooral omdat AOP al in C# ingebouwd zit, en de concurrentie van C# blijkbaar een enorme stimulans is voor Sun:

Anoniem: 72194 schreef op 20 februari 2004 @ 00:05:
Ik denk dat sun de hete adem van het c#-team in hun nek voelt. Ze hebben dan ook maar de nieuwste zaken geimplemteerd die ofwel al in c# aanwezig was (declaratief programmeren door attributes/metadata) of door MS is geintroduceerd met c# 2.0 draft (generics). Ik vind het wel een positieve evolutie omdat alleen wij er tenslotte beter van worden .

[B-Man]

Anoniem: 1999 schreef op 06 februari 2004 @ 16:53:
Wel wat probleempjes nog:
- "-server" mode nog steeds flink langzamer dan "-client".

Ik draai hier een multi-threaded java app die veel I/O doet, en 24/7 draait, en deze profiteert behoorlijk van de -server modus. De voordelen van -server worden wel pas zichtbaar nadat het spul een tijdje draait, de JVM is "warmgelopen" zeg maar Volgens mij optimaliseert de -client mode met name op responsiveness, en de -server mode op throughput.

Ziet er voorderest goed uit, die performance verbeteringen! Kan het wel gebruiken op het moment, want zit op het moment te overwegen of ik een testapp in c++ ga maken om eens te zien hoeveel sneller dat gaat m.b.t. de kritische onderdelen van m'n app. Ik verwerk veel strings in m'n app, en dat is in java toch behoorlijk traag.
(Al hangt er veel af van de programmeur zie dit topic)

Met name de generics en metadata spreken me aan, de generics schelen een hoop controles @runtime, met name met collections.

Die nieuwe for-loop

[Alarmnummer]

Anoniem: 26970 schreef op 20 februari 2004 @ 00:30:
[...]

Nu er al een grote stap gezet is door Metadata in Java te bouwen, is er dan ook een kans dat AOP ook in 'de officiële Java' komt in een toekomstige versie?

Ik zou er geen geld op durven zetten. Het duurt bij Sun over het algemeen altijd lang dat er iets nieuws in komt, en volgens mij zijn meta-data en generics wel de meest ingrijpende toevoegingen die ooit aan de java taal zijn gedaan. Daarom denk ik dus ze voorlopig nog geen AspectJ gaan introduceren (als dat ooit gaat gebeuren trouwens).

Er zijn heel veel wetenschappelijke projecten gaande waarin je allerlei nieuwe features krijgt zoals de nieuwe zaken van java, maar ook krachtigere typesystemen, kortere syntax, betere ondersteuning voor hogere orde functies, Noem maar op. Ik hoop eigelijk dat net zoals java onstaan is door goed te kijken naar het verleden en daarop verbeteringen door te voeren, dat zich nu ook weer een nieuwe stroom met talen gaat ontwikkelen en uiteraard mainstream gaat worden.

Ik denk alleen dat dit nog wel een tijdje op zich laat wachten, want het .NET platform is pas net serieus van start gegaan en Java is in principe ook nog relatief nieuw. Voorlopig blijft het denk ik nog behelpen

Dit vooral omdat AOP al in C# ingebouwd zit, en de concurrentie van C# blijkbaar een enorme stimulans is voor Sun:

Ik neem aan dat je metadata bedoelt ipv AOP.

[ Voor 5% gewijzigd door Alarmnummer op 20-02-2004 12:03 ]

[Robtimus]

Anoniem: 26970 schreef op 20 februari 2004 @ 00:30:
[...]

Misschien een klein beetje offtopic, maar ook loos voor een apart topic:

Nu er al een grote stap gezet is door Metadata in Java te bouwen, is er dan ook een kans dat AOP ook in 'de officiële Java' komt in een toekomstige versie? In plaats van een addon zoals AspectJ?

Dit vooral omdat AOP al in C# ingebouwd zit, en de concurrentie van C# blijkbaar een enorme stimulans is voor Sun:


[...]

Dan krijg je hetzelfde probleem als met assert, maar dan misschien nog erger: args is een keyword in AspectJ. Ik weet niet hoe het met jou zit, maar mijn aps hebben allemaal een "public static void main(String[] args)". Dat wordt dan flink renamen...

[Macros]

Args is wel een speciaal woord in AspectJ maar geen echt keyword, want ik gebruik een beetje AspectJ en gebruik args als var vaak genoeg en heb nooit geen problemen gehad.

[Robinski]

B-Man schreef op 20 februari 2004 @ 11:46:
[...]

Ik draai hier een multi-threaded java app die veel I/O doet, en 24/7 draait, en deze profiteert behoorlijk van de -server modus. De voordelen van -server worden wel pas zichtbaar nadat het spul een tijdje draait, de JVM is "warmgelopen" zeg maar Volgens mij optimaliseert de -client mode met name op responsiveness, en de -server mode op throughput.

Ziet er voorderest goed uit, die performance verbeteringen! Kan het wel gebruiken op het moment, want zit op het moment te overwegen of ik een testapp in c++ ga maken om eens te zien hoeveel sneller dat gaat m.b.t. de kritische onderdelen van m'n app. Ik verwerk veel strings in m'n app, en dat is in java toch behoorlijk traag.
(Al hangt er veel af van de programmeur zie dit topic)

Met name de generics en metadata spreken me aan, de generics schelen een hoop controles @runtime, met name met collections.

Die nieuwe for-loop

je kan natuurlijk met JNI een deel in C++ schrijven
scheelt waarschijnlijk gigantisch in snelheid

[Anoniem: 26970]

Alarmnummer schreef op 20 februari 2004 @ 12:03:
Ik neem aan dat je metadata bedoelt ipv AOP.

Volgens de 'Microsoft evangelist' bij de .NET presentatie die ik bijgewoond bood C# ook ondersteuning voor AOP. Misschien had hij het fout, of ging het ergens anders over Ik heb me zelf nooit verdiept in C#...

[Alarmnummer]

Anoniem: 26970 schreef op 20 februari 2004 @ 17:58:
[...]

Volgens de 'Microsoft evangelist' bij de .NET presentatie die ik bijgewoond bood C# ook ondersteuning voor AOP. Misschien had hij het fout, of ging het ergens anders over Ik heb me zelf nooit verdiept in C#...

c# heeft geen ondersteuning voor AOP. Maar je kan mbv attributen wel een beetje AOP programmeren, het is echter niet zo krachtig als echte AOP natuurlijk.
Aop in c# mbv metadata

[ Voor 5% gewijzigd door Alarmnummer op 20-02-2004 18:08 ]

[DaCoTa]

Kick van topic.

Inmiddels is na beta2 ook al J2SE 5.0 RC uit. Naam is dus van J2SE 1.5 veranders naar J2SE 5.0 en de target date voor de final staat op 30 september.

Zijn er al mensen die codebase aan het voorbereiden zijn voor de final of al aan het testen zijn met RC? Of is het eerst afwachten op de eerste bugreports en de kat uit de boom kijken?

[ACM]

Ik ben een applicatie aan het ontwikkelen in Java 5 (sinds beta2 oid van 1.4 naar 1.5 overgestapt) en ben nog geen enkele bug tegen gekomen. In die applicatie maak ik onder andere gebruik van de enum's, generics en de for-each loop.

[B-Man]

Ik ga de komende weken wat kleinere applicaties overzetten, zodat ik wat kan testen met de final, als die bevalt, ga ik ook wat grotere (zwaardere) apps omzetten.

Die zou ik sowieso niet direct overzetten, want er zullen toch wel weer wat bugs boven water komen, en die kom ik liever niet in een productie systeem tegen.

[Anoniem: 42145]

Ik ga iniedergeval zeker wat kleine applicaties die we bij ons bedrijf intern gebruiken (en niet heel critisch zijn) naar 5.0 overzetten. Vooral stukken code waarin ik veel hashtables heb die hashtables bevatten met weer iets erin wil ik omzetten naar generics.

Als je nu de declaratie leest is het gewoon niet duidelijk wat erin komt. Ik probeerde dat wel met comments op te vangen, maar dat is natuurlijk niet zoals het hoort.

[MisterData]

Hoe zit het eigenlijk met de Java '5' ondersteuning in Eclipse bijvoorbeeld? Ik weet dat die een eigen compiler gebruikt...

[misfire]

MisterData schreef op 22 september 2004 @ 20:23:
Hoe zit het eigenlijk met de Java '5' ondersteuning in Eclipse bijvoorbeeld? Ik weet dat die een eigen compiler gebruikt...

In Eclipse kun je inderdaad alleen met de "built-in" java versies code schrijven en compileren. Je kunt Eclipse echter wel op Java 5 JRE draaien als je dat wilt. In Eclipse 3.1 kun je wel Java 5 code schrijven en compileren, de eerste milestone build is uit en die ondersteunt generics al best goed.

[Anoniem: 42145]

misfire schreef op 22 september 2004 @ 21:33:
[...]
In Eclipse kun je inderdaad alleen met de "built-in" java versies code schrijven en compileren.

Eigenlijk is dat best wel een nadeel van een voor de rest super goed en open platform. Zelfs het veel meer gesloten Visual Studio maakt wel gebruik van een compiler die ook als commandline tool gebruikt kan worden en dus ook vervangen kan worden (bv cl.exe door icl.exe vervangen).

Uit de FAQ van Eclipse:

Can I use a Java compiler other than the built-in one (javac for example) with the workbench?

No. The JDT provides a number of sophisticated features including fully automatic incremental recompilation, code snippet evaluation, code assist, type hierarchies, and hot code replace. These features require special support found in the workbench Java compiler (an integral part of the JDT's incremental project builder), but not available in standard Java compilers.

Overigens is dit, zowel je mischien uit de faq al kan opmaken, niet een 'defect' in Eclipse maar in de meest gebruikte plug-in voor Eclipse: JDT.

CDT (de C++ plug-in), gebruik wel gewoon een losse compiler.

Je kunt Eclipse echter wel op Java 5 JRE draaien als je dat wilt.

Vreemd is dat je voor sommige features van de GTK implementatie van SWT je juist J2SE 5.0 nodig hebt, terwijl dat niet geldt voor de quartz en win32 implementaties. Als je de 3.0 GTK SWT library op een 1.4 VM draait krijg je soms een "not implemented" en een exception.

Hoewel 3.1M1 wel al goede support heeft duurt het nog -lang- voor de final uit is.

[MisterData]

Dacht toch dat het mogelijk was om Eclipse samen met Ant te gebruiken, dus dan zou dat toch moeten kunnen

[Anoniem: 42145]

MisterData schreef op 22 september 2004 @ 22:07:
Dacht toch dat het mogelijk was om Eclipse samen met Ant te gebruiken, dus dan zou dat toch moeten kunnen

Wat heeft het een met het ander te maken? Er wordt een plug-in voor Ant meegeleverd bij het standaard SDK pakket, maar in het geval van Ant kun je ook een standalone gebruiken.

Of bedoel je dat je een standalone Ant een build van een Eclipse project laat doen? (al dan niet via Eclipse aangestuurd). Dan zou je wel kunnen compilen, maar ik denk niet dat feautures als name completion en code navigation dan nog werken.

Je kunt in Eclipse ook een willekeurige external tool opstarten en dat kan dan ook javac zijn, maar ik denk dat dat niet helemaal de bedoeling is.

Overigens kun je wel een willekeurige JRE in Eclipse kiezen waarmee je de applicatie die je aan het maken bent draait of debugged. Dat kan dan ook een J2SE 5.0 JRE zijn, maar als Eclipse de code niet zelf heeft gecompiled kun je er wel door heen steppen maar werken een aantal dingen niet.

[Anoniem: 42145]

Nou, de final is eindelijk uit vandaag maar hij wordt waarschijnlijk niet al te enthousiast ontvangen. Je hoort er amper iemand over. Mischien is het wel een goed teken, want als er veel bugs in de final gezeten hadden had je natuurlijk ook veel gehoord. Geen nieuws is goed nieuws zullen we maar denken.

Nja, wie gaat deze al in een produktie omgeving gebruiken? Ik zelf iniedergeval niet. Ik ben zo bang voor bugs dat het waarschijnlijk pas over een jaar, mischien anderhalf jaar wordt voordat ik deze ga gebruiken voor produktie. Eigen en interne tooltjes zal ik wellicht wel gaan omzetten of hierop basseren, hoewel de non-support van Eclipse erg jammer is.

[Macros]

Ik ga alleen de features gebruiken die class compatible blijven met 1.4, zodat gebruikers niet perse de nieuwste JRE hoeven te gebruiken. Het is natuurlijk ook wel te verwachten dat het wat tijd kost voordat Eclipse alle nieuwe features ondersteund omdat ze een eigen real-time compiler onderhouden. Voordat al die nieuwe dingen daarheen zijn geport ben je wel een paar maanden verder. Eclipse 3.1 ondersteund al wel Generics.

[Alarmnummer]

Daarom ben ik ook al lang gestopt met afhankelijk te worden van een IDE. Ieder java project compileerd vanaf de commandline (via ANT) zonder ook maar 1 dependency naar een IDE. Ik maak zo nu en dan wel eens gebruik van de compiler van de ide (zoals de incremental compiler van Codeguide) maar kan er ook zonder.

Trouwens fijn dat we weer nieuwe java goodies erbij hebben..

Kan niet wachten op 6.0

[edit]
Ik denk dat metadata/attributen/annotaties de meest krachtige uitbreiding gaat worden sinds java is uitgebracht. Ik denk dat het java op een heel nieuw nivo gaat tillen.

[ Voor 21% gewijzigd door Alarmnummer op 30-09-2004 17:55 ]

[ACM]

Macros schreef op 30 september 2004 @ 17:34:
Voordat al die nieuwe dingen daarheen zijn geport ben je wel een paar maanden verder. Eclipse 3.1 ondersteund al wel Generics.

Ze hebben anderzijds wel al aardig wat tijd gehad om er een begin mee te maken. IDEA beschikt al over (vrijwel?) alle features van Java 5.0. De eerste beta van JDK 1.5 is volgens mij al meer dan een half jaar geleden vrij gegeven?

[Macros]

offtopic:
Als het te langzaam gaat, dan doe je het toch lekker zelf? Het is een open-source ide, dat betekend dat het door vrijwilligers wordt gemaakt en dat het dus gratis is. IDEA is dan sneller, maar daar betaal je dan ook voor, of niet, maar dan ben je crimineel. Ook bestaat als sinds de eerste beta van Java 1.5 een plugin voor de oudere Eclipse waarmee je Java 1.5 kon programmeren, en Ant zit gewoon in Eclipse en kan je ook gebruiken om je project te builden. En nu beloven dat jullie stoppen met flamen.

[.oisyn]

Sorry, maar ik heb dat ontzettend loze argument nou al te vaak gehoord. Het is opensource, dus je mag niet zeiken, of je moet zelf maar meewerken? Kom op, waar gaat dat nou over? Ten eerste hebben we hier in Nederland de vrijheid van meningsuiting, als mensen willen zeiken dat het te lang duurt dan is dat hun volste recht. Ten tweede, het feit dat iets gratis is wil natuurlijk niet zeggen dat je het allemaal maar gewoon moet slikken als updates achter blijven, of dat je niet mag klagen als het geen degelijk product is. Ten derde betekent open source niet meteen dat het door vrijwilligers wordt gemaakt. Eclipse is gewoon een organisatie, ja een non-profit organisatie, maar dat betekent niet dat het alleen uit vrijwilligers bestaat die er verder geen geld voor krijgen. Het betekent slechts dat de organisatie geen winst-oogmerk heeft.

Ze presenteren een tool die het development-werk beter moet maken. Dan moeten ze dat ook gewoon goed bijhouden en niet allemaal developers die het gebruiken op updates laten wachten, dat getuigd gewoonweg niet van professionaliteit. (Ik heb overigens geen ervaring met eclipse, bovenstaande dingen zijn vooral gebaseerd op reacties in deze draad. Ik wilde slechts even reageren op het steeds maar weer terugkerende bullshit argument dat je ineens geen kritiek mag hebben als iets open source is, want dat slaat gewoon nergens op)

Oh en nog iets anders:

is een open-source ide, dat betekend dat het door vrijwilligers wordt gemaakt en dat het dus gratis is

Nee, open source betekent dat je in de source mag kijken. Het betekent niet dat het gratis is of dat het door vrijwilligers wordt gemaakt (dat laatste had ik al gezegd overigens), net als dat closed source niet betekent dat je er voor moet betalen.

[ Voor 30% gewijzigd door .oisyn op 30-09-2004 19:19 ]

[Anoniem: 42145]

Aan de andere kant is Eclipse net zo goed een basis voor Websphere wat helemaal niet gratis is. Volgens mij is het ook zo bedoeld, de basis van websphere is door IBM open-source gemaakt om een edge te krijgen voor hun betaalde produkt.

Eclipse is bijvoorbeeld geen MAME wat wel helemaal door vrijwilligers gemaakt wordt (om maar eens een willekeurig vrijwilligers open source project te nemen). Hoewel het verlijdelijk is het te denken, staat opensource niet gelijk aan vrijwilligers en zelfs niet aan gratis (de bekende open deur, niet op in gaan ).

ANT builds hebben natuurlijk sowieso een groot voordeel, maar het nadeel is wel dat de Eclipse debugger dan niet meer goed werkt. Voor de meeste mensen zal dat hier geen probleem zijn, aangezien een debugger toch al als evil wordt gezien, maar voor mij persoonlijk is dat wel een groot gemis.

Mischien is het een interesant vrijwilligers project: een alternatieve JDT die net zoals CDT gebruik maakt van de platform compiler, een externe builder voor de builds (in dit geval ANT), en toch helemaal goed geintegreerd is met het geheel.

[Anoniem: 42145]

.oisyn schreef op 30 september 2004 @ 19:12:
Ik wilde slechts even reageren op het steeds maar weer terugkerende bullshit argument dat je ineens geen kritiek mag hebben als iets open source is, want dat slaat gewoon nergens op)

Helemaal mee eens. Voor sommige open source projecten zie je ook dat de developpers zich als een soort god gaan voelen als hun produkt een beetje goed loopt. Neem het MAME project maar weer eens als voorbeeld. Als je in het officiele forum wat post, goed bedoeld of niet, wordt je meteen tot de grond toe afgebrand door enerzijds de developpers zelf en anderzijds een grote groep hielenlikkers die zich helemaal geschikt hebben naar de grillen van de developpers en dat ook menen te moeten overdragen aan andere.

Stel je een kleine verbetering voor, krijg je meteen commentaar als:

"if MameDev had wanted that, it would already be there. Since it's not there, they do not want it. Stop whining. Mame is free, they don't owe you anything."

En dat als je voor de eerst keer, heel beleefd en met alle goede bedoelingen, een kleine verandering voorstelt. Dit lijkt echt heel sterk op religieus fanatisme en de woorden zouden niet vreemd geklonken hebben als je MameDev door god veranderd en Mame mischien door de zon, en ze in de 17de eeuw uit de mond van een priester kwamen.

Maar nogmaals, voor Eclipse gaat dit hele verhaal nog niets eens op omdat er wel degelijk een organisatie is die van de ontwikkeling profiteerd. Het is ook nog maar redelijk recent dat Eclipse een eigen organisatie is en het IBM copyright staat nog in zo'n beetje elke source file.

IBM is zeer zeker geen clubje van vrijwilligers die niks aan mij verschuldigd zijn.

[Macros]

Ik bedoelde niet perse dat als het open-source is dat het meteen gratis is, maar Eclipse werd vergeleken met IDEA. IDEA is 500 euro ofzo? en Eclipse is gratis. IDEA is closed source en Eclipse is open-source en een groot plugin systeem. Als er iets niet in Eclipse zit en je vind het heel belangrijk, dan maak je er een plugin voor.
En een erg groot gedeelte van de functionaliteit van Eclipse komt van 3th party plugins, en die zijn bijna altijd door vrijwilligers gemaakt. Ook vaak open-source projecten, en als je daar iets veranderd wilt zien hoef je alleen maar een patch in te sturen en dan wordt het 9 van de 10 keer geaccepteerd, en dat je niet kan coden is je eigen probleem, dan hoef je ook geen IDE te gebruiken
Als je dit allemaal niet wilt opbrengen DAN koop je IDEA of een andere IDE. Maar als je geen zin hebt om wat terug te geven aan de open-source community en alleen maar eisen stelt dan moet je niet zeiken.

Ik kan beide kanten wel zien. Als devver vind je het niet leuk als tig gebruikers die nooit iets voor jou hebben gedaan vanalles van je eisen. En als gebruiker als er iets is met de software dat je graag anders zou willen zien.

Tip: als iets je niet bevalt aan een open-source project en het is maar een klein projectje. Stel dan die vraag en geef ze wat geld, of een krat bier, of iets anders. Voor wat hoort wat, ook al is het maar weinig. Kan je niet programmeren, maar spreek je Timboektoe, stel voor om een vertaling te maken...

En IBM is misschien dan geen clubje van vrijwilligers, maar als je hun niks geeft dan zijn zij jou ook niks verschuldigd.

[Anoniem: 42145]

Als je Eclipse gebruikt dan geef je IBM wel zeker wat:

1) Je trekt klanten weg bij de andere IDE bouwers (market share was een belangrijke motivate voor IBM om Eclipse open-source te maken)

2) Je bent een extra tester voor hun base. Jouw 'gezeik' is input voor de commerciele variant van Eclipse (websphere).

3) Je bent een kandidaat om te 'upgraden' naar de commerciele versie. Er zijn veel fabrikanten die er zowieso al geld voor over hebben om klanten 'proef te laten draaien' op hun systeem.

Tenslotte, formuleer je 'gezeur' dan niet als een klacht tegen Eclipse maar tegen websphere. Zoals gezegd, websphere is niet gratis. Tegenover gebruikers daarvan heeft IBM dus wel zeer zeker een verantwoording. En laat nou net een (groot) deel van websphere uit Eclipse code bestaan?

M.a.w. woorden als betalende websphere gebruiker mag ik dus klagen dat ik het jammer vind dat Eclipse geen J2SE5.0 support heeft in de stabiele versie. Met alle open-source theorieen bij elkaar kun je daar geen spelt tussen krijgen.

[original4u]

Zullen programma's gebasseerd op java ook deze performance winst hebben?
Bijvoorbeeld bij het opstarten van Azureus?

[ Voor 8% gewijzigd door original4u op 30-09-2004 23:19 ]

[ACM]

Macros schreef op 30 september 2004 @ 20:45:
Tip: als iets je niet bevalt aan een open-source project en het is maar een klein projectje. Stel dan die vraag en geef ze wat geld, of een krat bier, of iets anders.

Zo is er inderdaad al es een feature in Xapian/Omega verschenen die we hier op GoT nodig hadden.

[Eelke Spaak]

Net even de bundel met NetBeans 4.0 beta 2 geïnstalleerd; het eerste dat me opvalt is dat NetBeans (ik werk normaal met 3.6) ineens zo langzaam is!

Wanneer ik even in Windows taakbeheer kijk zie ik dat het proces java.exe maar liefst 170 MB (!) aan geheugen aan het wegsnoepen is... Is dit een gevolg van veranderingen aan de JRE of aan NetBeans zelf? De 3.6 versie icm Java 1.4.2 gebruikt nog geen 90 MB aan geheugen, en zoveel vernieuwingen zitten er nou ook weer niet in versie 4.

[Anoniem: 42145]

Mischien komt dat omdat je een netbeans beta gebruikt? Wat doet die zelfde beta dan bij jouw op 1.4.2?

edit:

Mischien is het een domme vraag hoor, ik ken geen netbeans en wellicht dat het niet eens met 1.4.2. werkt

[ Voor 40% gewijzigd door Anoniem: 42145 op 30-09-2004 23:43 ]

[Swinnio]

ACM schreef op 30 september 2004 @ 18:42:
[...]

Ze hebben anderzijds wel al aardig wat tijd gehad om er een begin mee te maken. IDEA beschikt al over (vrijwel?) alle features van Java 5.0. De eerste beta van JDK 1.5 is volgens mij al meer dan een half jaar geleden vrij gegeven?

Toch zijn ze al een behoorlijk eind op weg. 96,8% van alle compliance tests slaagt. Onderstaande komt uit de release notes van 3.1M2 (afgelopen week beschiikbaar gekomen):

The changes to the Java tools to support J2SE 5.0 (aka 1.5) are proceeding nicely. The Eclipse Java compiler now handles generics, enhanced for loops, and hexadecimal floating point literals (at this point we're passing 96.8% of the JCK1.5 compliance tests). The other language additions - enumerations, annotations, static imports, varargs, autoboxing - make it past the parser, but are not yet being processed any deeper than that. Support for these other new language features will be introduced in future 3.1 milestones.
In order to work with any of the new language features you must set the Java project's compiler compliance level to 1.5 (Java Compiler > Compliance and Classfiles > Compiler compliance level > 1.5) and configure the Java build path with the system libraries from an installed 1.5 JRE.

[djengizz]

Dit kon al een hele tijd (sinds de beta) met de genady plugin voor Eclipse. Even wijzen naar de JDK1.5 en compliance level v/d compiler op 1.5 zetten.

[Anoniem: 22001]

Nog even spammen met mijn mening over Java 1.5: Why Java Sucks en A Better Java.

[Eelke Spaak]

Dit doet mij verdriet: een functie System.out.printf(String)...

Juist één van de dingen die zo godsgruwelijk lelijk zijn in C++; wat is er mis met string-appending?!

[Alarmnummer]

Eelke Spaak schreef op 01 oktober 2004 @ 21:09:
Dit doet mij verdriet: een functie System.out.printf(String)...

Juist één van de dingen die zo godsgruwelijk lelijk zijn in C++; wat is er mis met string-appending?!

Je hebt het over de varargs?

[ Voor 13% gewijzigd door Alarmnummer op 01-10-2004 21:11 ]

[.oisyn]

Ten eerste is het C, ten tweede is het lelijk omdat er geen typechecking plaats vindt. Boost kent een type-safe printf functie voor C++, en ook .Net kent een dergelijke constructie. Waarom is zo'n printf lelijk? Waarom wil je per se strings concateneren? En hoe ga je output formatting toepassen bij string concatenaties?

Zo'n printf is, net als parametrized SQL queries, gewoon handig, omdat je de tekst kunt scheiden van data en bovendien in place de formatting kunt specificeren. Ik vind er niets mis mee...

[Eelke Spaak]

@Alarmnummer: De varargs op zich vind ik helemaal niet lelijk, maar wel het gebruik ervan in de nieuwe printf() functie.

@.oisyn: Ook al stamt het wellicht uit C (waar ik persoonlijk nooit mee gewerkt heb), ik ken het vanuit C++.

Parametrized SQL-queries zijn handig omdat ze ervoor zorgen dat de SQL Server het execution plan beter kan cachen dan wanneer 'ie "inline argumenten" tegenkomt. Text formatting kan net zo goed op een andere manier, met iets van een Formatter o.i.d. . De voornaamste reden echter dat ik het lelijk vind is dat het gewoon zo godsgruwelijk onduidelijk en cryptisch is.

Nou moet ik toegeven dat de taal er syntactisch überhaupt niet mooier op geworden is sinds versie 5, maar al met al ben ik er toch erg tevreden over. Vooral autoboxing en de nieuwe for-lus zijn bijzonder handig; en de metadata zal ook een aantal stappen in het ontwikkelproces flink gaan versnellen.

[Macros]

En met printf kan je 1 liner quines schrijven!

[Eelke Spaak]

Macros schreef op 01 oktober 2004 @ 21:42:
En met printf kan je 1 liner quines schrijven!

OK dat is wel gaaf dan...

Heb je een voorbeeldje?

[Alarmnummer]

6.0 gaat trouwens Mustang heten:

link

En 7.0 Dolphin:

link

[ Voor 32% gewijzigd door Alarmnummer op 01-10-2004 22:54 ]

[Macros]

Java:

public class Quine{public static void main(String[] a){System.out.printf(a[0]="public class Quine{public static void main(String[] a){System.out.printf(a[0]=%c%s%c,34,a[0],34);}}",34,a[0],34);}}

Start met:
java Quine.java a

Jammer van al die nutteloze code eromheen, zoals public class, en public static void main. In php kan het veel korter:

PHP:

<?printf($a='<?printf($a=%c%s%c,39,$a,39);?>',39,$a,39);?>

[ Voor 33% gewijzigd door Macros op 01-10-2004 23:04 ]

[eamelink]

Misschien interessant voor de tweakers die net als ik niet weten/wisten wat een Quine is :

Een quine is een programmaatje dat zijn eigen sourcecode uitpoept. Het leuke is om een zo kort mogelijke quine te maken

[DaCoTa]

Alarmnummer schreef op 30 september 2004 @ 17:42:
Ik denk dat metadata/attributen/annotaties de meest krachtige uitbreiding gaat worden sinds java is uitgebracht. Ik denk dat het java op een heel nieuw nivo gaat tillen.

Heeft iemand een korte, begrijpelijke uitleg of link naar wat de voordelen in de echte wereld zijn van deze uitbreiding? Van de meeste andere 5.0 nieuwigheden snap ik het wel, maar hierover heb ik het licht nog niet gezien omdat ik het gewoon niet snap. Ik heb al wel een aantal zaken geleden, maar het stukje in bijvoorbeeld J2SE 5.0 in a Nutshell zegt me echt he-le-maal niks.

[Alarmnummer]

DaCoTa schreef op 02 oktober 2004 @ 00:47:
[...]

Heeft iemand een korte, begrijpelijke uitleg of link naar wat de voordelen in de echte wereld zijn van deze uitbreiding?

Het voordeel aan metadata is dat je allerlei meta informatie bij je classes/velden/methodes mee kan nemen en daarop allerlei tools los te laten. Bv or-mappers, rmi skeleton generators.

Metadata geeft je de mogelijkheid om op een declaratieve manier te gaan programmeren. Jij specificeert wat je wilt, maar je hoeft niet tot in de details uit te gaan leggen hoe jij dit wilt. Declaratieve talen zijn heel leuk, maar hun toepassingsgebied in de praktijk is maar erg klein omdat het vaak 100% oplossingen zijn. Metadata in java is dus niet zo`n oplossing.. het is het beste van declaratief programmeren gecombineerd met het object georienteerde paradigma.

Even een voorbeeldje uit mijn duim gezogen.

code:

[table=PERSON]
class Persoon{
       [column=VOORNAAM]
       String voornaam;

        [lazy=true]
        List kinderen; 

        [transaction]
       setVoornaam(String voornaam){
                this.voornaam = voornaam;
       }
}

Ik neem aan dat XDoclet binnenkort ook binnenkort met metatadata attributen aan komt zetten ipv javadoc toevoegingen.

[ Voor 21% gewijzigd door Alarmnummer op 02-10-2004 01:07 ]

[.oisyn]

En die data kun je dus weer via Reflection (neem ik aan? In .net iig wel) weer uitlezen. Zo zou je bijvoorbeeld een serializer kunnen maken die werkt met de metadata van de class, zodat je niet in de class zelf serialization methods hoeft te implementeren. Ik noem maar een voorbeeld

[Alarmnummer]

.oisyn schreef op 02 oktober 2004 @ 01:13:
En die data kun je dus weer via Reflection (neem ik aan? In .net iig wel) weer uitlezen.

Idd.. maar je kunt geloof ik net zoals bij .NET ook tools maken die compiletime al acties ondernemen op de metadata. Dit moet ik nog even goed nakijken... ik zal binnenkort er eens mee gaan spelen.

En ik denk dat metadata de afstand tussen tool en java ook een stuk kleiner gaat maken. Ipv dat je met de zoveelste (op xml gebaseerd) config bestand zit te knoeien (die uiteraard ook niet meewerkt met je refactor capriolen) vormt het nu meer 1 geheel.

[ Voor 25% gewijzigd door Alarmnummer op 02-10-2004 01:24 ]

[ACM]

DaCoTa schreef op 02 oktober 2004 @ 00:47:
Heeft iemand een korte, begrijpelijke uitleg of link naar wat de voordelen in de echte wereld zijn van deze uitbreiding? Van de meeste andere 5.0 nieuwigheden snap ik het wel, maar hierover heb ik het licht nog niet gezien omdat ik het gewoon niet snap. Ik heb al wel een aantal zaken geleden, maar het stukje in bijvoorbeeld J2SE 5.0 in a Nutshell zegt me echt he-le-maal niks.

De open source object database Ozone gebruikt een combinatie van interfaces en klassen die je als gebruiker moet definieren. Die interface definieer je om aan te geven wat de interface van het "persistent" object is aan de rest van de wereld.
Een belangrijk stukje informatie dat je daar in moet opgeven is dat een methode een transaction nodig heeft. Nu gebeurt dat bijv zo:

Java:

interface PersistentObject
{
   String getName();
   void setName(String name); /* update */
}

Overigens kan het ook met een XML-configuratie file. Maar er moet dus verplicht een of ander tooltje die interface inspecteren om die update-comment op te snorren...
't Is natuurlijk veel beter als er dan zoiets staat:

Java:

interface PersistentObject
{
   String getName();
   @Transaction void setName(String name);
}

Vervolgens zou er dan in de Ozone-server on-the-fly gekeken kunnen worden of die @Transaction-annotation is geplaatst, waarna al-dan-niet een transaction gestart kan worden. Zonder onhandige pre-parsers en het parsen van in wezen niets-zeggende comments.
Sterker nog, op deze manier kan je er ook parameters aan meegeven en heb je er in principe IDE-support voor (ok, xdoclet's/javadoc ook wel, maar het blijven comments).

[flowerp]

Je kunt annotation ook goed gebruiken in plug-ins voor Java. Ik heb bijvoorbeeld een systeem waar een class een interface heeft die een map terug geeft waar strings naar een anonymous inner class mappen. Deze anonymous class implementeerd dan ook weer een interface met 1 standaard method die dan opgeroepen kan worden.

Met annotations zou ik deze mapping meteen boven de method kunnen zetten die de functionaliteit implementeerd. De plug-in loader kan dan de juiste methods via reflection opsporen via een universeel mechanisme.

Er hoeft dan niet meer in de plug-in class met de hand een map aangemaakt te worden die string keys naar methods mapped.

Overigens maakt het nieuwe Beehive framework (wat op JSF en Struts bouwt) ook veelvuldig gebruik van annotations.

[EfBe]

Alarmnummer schreef op 02 oktober 2004 @ 00:55:
Het voordeel aan metadata is dat je allerlei meta informatie bij je classes/velden/methodes mee kan nemen en daarop allerlei tools los te laten. Bv or-mappers, rmi skeleton generators.

In theorie wel, in de praktijk is het onbegonnen werk. Neem een gemiddelde enterprise database met 500+ tables. Je zit dan aan 500 classes (of meer) te denken en wellicht 5 a 10 fields per class. Dat zijn 2500 tot 5000 attributes die je moet vermelden, en wellicht een veelvoud daarvan ivm verschillende opties die je wilt. Dit moet je allemaal met de hand ingeven.

Iets zegt me dat je daar beter een computer voor kunt gebruiken

Op zich zijn attributes verder wel aardig, echter wordt hun noodzaak vaak erg overtrokken (IMHO).

en .NET heeft geen compile time attribute usage. Waar je waarschijnlijk mee in de war bent is dat sommige O/R mappers code genereren op basis van die attributes en daarmee de in-memory instance van een class 'patchen'. in java is dat gemeengoed, in .NET is dat onverantwoord ivm CLR eigenaardigheden.

[ Voor 16% gewijzigd door EfBe op 02-10-2004 11:10 ]

[Anoniem: 42145]

Nou nou, het is wel duidelijk dat Java 5 niet echt leeft onder de tweakers. Als je de groeisnelheid van dit topic als graad meter zou nemen dan kun je wel stellen dat Java 5 al op sterven na dood is...

[Alarmnummer]

Anoniem: 42145 schreef op 05 oktober 2004 @ 14:01:
Nou nou, het is wel duidelijk dat Java 5 niet echt leeft onder de tweakers. Als je de groeisnelheid van dit topic als graad meter zou nemen dan kun je wel stellen dat Java 5 al op sterven na dood is...

We werken er gewoon al lang mee

Ik werk in ieder geval al een lange tijd met syntax van 1.5 en draai thuis als ontwikkeling omgeving ook al tijden 1.5 beta`s. Dus de stap was niet zo groot beta-final. Ik vond de latere beta`s stabiel genoeg om er thuis mee aan de slag te gaan.

[Anoniem: 42145]

Aha :-)

En in produktie omgeving? Zijn daar nog veranderingen kwa gebruik van 5.0 in opgetreden na de final?

Bij ons zei de manager overigens het volgende over het overstappen op J2SE 5.0:

"Software is net als wijn, des te ouder des te beter. Alleen soms is oude wijn toch bedorven, in de software wereld ga je alleen dan over naar een nieuwe versie."

Toen ik vroeg waarom wij dan nog nieuwe versies van onze eigen software uitbrengen werd het overigens wel stil

[Anoniem: 16744]

Anoniem: 42145 schreef op 05 oktober 2004 @ 14:26:
"Software is net als wijn, des te ouder des te beter..."

En jullie gebruiken als OS Windows 3.1 of gewoon nog DOS 5?

En geldt ie stelling van jouw baas ook bij hem thuis of draait toch stiekem WinXP?

[DaCoTa]

We gaan binnenkort wel testen, maar onze IDE (Eclipse) heeft nog geen volledige support voor J2SE5 en dat duurt helaas nog een flink aantal maanden.

[Anoniem: 42145]

Anoniem: 16744 schreef op 05 oktober 2004 @ 15:42:
[...]

En jullie gebruiken als OS Windows 3.1 of gewoon nog DOS 5?

Het scheelt niet veel!

De produktie server gebruikt de Application Server Orion 1.3.8 (en die is -heel- oud!) en de JVM 1.4.0 met nog een subversie die ik niet precies weet. Ze hebben ooit eens, voor ik er kwam, een nieuwere JVM geprobeerd en die klapte er meteen uit met rare VM errors. Sindsdien 'durft' niemand meer de JVM te updaten. Het zelfde geldt voor Orion. Het werkt nu, dus men wil niet over gaan op de nieuwste 2.02 (die ook alweer oud is eigenlijk; juni 2003).

Ik ben het er zelf als developper niet helemaal mee eens, maar dat is ook wel een beetje omdat developpen op nieuwe tech 'cooler' is. Echter vanuit een management standpunt begrijp ik het wel. "If it ain't broke, don't fix it". In een vorige baan wilde men bv absoluut op Solaris 7 blijven werken terwijl 9 al uit was, gewoon omdat alles het goed deed.

Toch heeft het voor het developpen wel nadelen; alle leuke nieuwe frameworks kun je dus niet gebruiken. De hele web applicatie is puur Servlet (2.2) en JSP/bean based. Zelfs dingen uit Servlet 2.3 zijn al te nieuw.

En geldt ie stelling van jouw baas ook bij hem thuis of draait toch stiekem WinXP?

Waarschijnlijk draait ie thuis wel gewoon de nieuwste software overal van. Het gaat hem puur om de ontwikkel omgeving en produktie software op de servers.