[j2ee] wie gebruikt JMX?

[Alarmnummer]

Een van de technieken waar ik zeer enthousiast over ben is JMX: Java Management Extensions. Hiermee is het erg eenvoudig om bepaalde componenten binnen je systeem te monitoren. Standaard worden bij de meeste applicatieservers wel een html-console voor JMX aangeboden, maar eventueel kan het bv ook via RMI worden aangesproken.

Je hoeft dus niet langer zelf allerlei monitor componenten in elkaar te zetten, maar er is dus een heel framework voor aanwezig. Een ander voordeel is dat veel meer systemen gebruik maken van JMX, als je bv gebruik maakt van hibernate kun je daar ook managed beans van monitoren.

Java 5 heeft trouwens ook JMX componenten voor de meeste onderdelen van de VM. Je kunt precies zien welke threads er draaien, de stacktraces uitlezen. Ze hebben zelfs een remote tool gemaakt: JConsole.




Het enigste dat ik wel erg jammer vind is dat Java 5 en JBoss het slecht met elkaar kunnen vinden.

Tot zover mijn enthousiasme over JMX... in de toekomst zal het een integraal onderdeel gaan worden van al onze webapplicaties. En zeker met Spring is het echt peanuts. Wat vinden jullie van JMX en hoe zo`n belangrijke rol neemt het in in jullie systemen?

[ronaldmathies]

Ik ken het inderdaad ook van JBoss, die is er volledig mee gebouwd, alleen moet je goed bedenken dat JBoss 3.x gebruik maakt van een vorige specificatie van JMX en JBoss 4.x maakt gebruik van de laatste specificatie. Mischien dat hier een probleem in zit? Welke versie van JBoss gebruik je waarbij je problemen ondervindt?

Ik vindt het zelf erg interesant, maar heb me er nog niet in verdiept. Maar het staat zeker op mijn lijstje om een keer naar te kijken.

[Alarmnummer]

ronaldmathies schreef op donderdag 17 februari 2005 @ 13:50:
Ik ken het inderdaad ook van JBoss, die is er volledig mee gebouwd, alleen moet je goed bedenken dat JBoss 3.x gebruik maakt van een vorige specificatie van JMX en JBoss 4.x maakt gebruik van de laatste specificatie. Mischien dat hier een probleem in zit?

Ik heb problemen met JBoss 4.0 en JDK 1.5. Het probleem zit hem geloof ik in de JMX vergaarbak waar alle JMX agents zich melden. Aangezien Sun pas laat met een JMX implementatie kwam en JBoss al eerder, is er nu een conflict.

[djengizz]

Wij gebruiken JMX in combinatie met Tivoli monitoring (server breed). Je kan op deze manier makkelijk monitoring plugins schrijven aangezien Tivoli gebaseerd is op JMX. Verder gebruiken wij een generiek JMX component om monitoring op applicatief niveau toe te passen.

[Verwijderd]

JMX lijkt me zeer interesant in de VM zelf. Alleen, het vereist dus JDK 5.0 en die gebruikt toch nog steeds bijna niemand?

Wat is eigenlijk precies het probleem met JBoss en JDK 5.0? Gaat het alleen fout als je JMX gebruikt, of zijn er ook al andere problemen? En het conflict wat je noemde, betekent dat dat de VM of AS eruit klapt, of dat JMX gewoon niet werkt?

[flowerp]

Het is inderdaad zo dat nog bijna niemand JDK 5.0 gebruikt. Sun zelf springt hier op in door bij de JDK download section ook 1.4.2 aan te bieden als directe link en niet via het archief. Dat deden ze vroeger nooit met bv 1.3.x en 1.4.0.

Het zou me niet verbazen als Sun na verloop van tijd 5.0 helemaal terug trekt en met 1.4.3 verder gaat. Mischien als Eclipse eindelijk eens met 5.0 support komt dat er dan wel een paar mensen over gaan, verlopig echter zit iedereen nog op 1.4.2 en blijft daar lekker zitten.

[Alarmnummer]

flowerp schreef op vrijdag 18 februari 2005 @ 23:16:
Het is inderdaad zo dat nog bijna niemand JDK 5.0 gebruikt. Sun zelf springt hier op in door bij de JDK download section ook 1.4.2 aan te bieden als directe link en niet via het archief. Dat deden ze vroeger nooit met bv 1.3.x en 1.4.0.

Het zou me niet verbazen als Sun na verloop van tijd 5.0 helemaal terug trekt en met 1.4.3 verder gaat.

Die kans lijkt me eerlijk gezegt kleiner dan 0. JDK 5.0 voegt een 2 tal dingen toe aan java die al lange tijd nodig zijn: generics (de minst belangrijke) en metadata. Metadata zal ervoor zorgen dat Java een volledig nieuwe dimensie van functionaliteit zal leren kennen. In principe kon het wel via oplossingen zoals Commons Attributes.. maar het feit dat het onderdeel van de taal is geworden zal declaratief programmeren binnen Java eindelijk een onmisbare onderdeel maken.

Mischien als Eclipse eindelijk eens met 5.0 support komt dat er dan wel een paar mensen over gaan,

Afgezien van het feit dat ik Eclipse een naar product vind om mee te werken (Idea kicks Eclipse ass anyday) loopt Eclipse achter de feiten aan. Het feit dat een ide te achterlijk is om die features te implementeren kan geen reden zijn voor sun om het terug te trekken. Trouwens... er is al 1.5 ondersteuning vanuit Eclipse...

verlopig echter zit iedereen nog op 1.4.2 en blijft daar lekker zitten.

In 24/7 omgevingen zal 1.4 nog wel even de standaard blijven. Maarja.. dat het je met de release van 1.4 ook . Pas toen 1.4.2 werd uitgebracht was het ineens koek en ei.

Java 1.5 is here to stay.. Jdk1.4 voegde nauwelijks iets aan de taal toe (als je de assert durft mee te rekenen), maar 1.5 is echt een volgende stap.

[ Voor 20% gewijzigd door Alarmnummer op 19-02-2005 01:26 ]

[CubicQ]

In echte 24/7 omgevingen is 1.4 nu (en ik verwacht de komende 2-3 jaar) nog niet eens standaard. IBM gebruikt 1.4 pas sinds WebSphere 6.0, en die is nog best nieuw te noemen (als in: nog geen proven technology, misschien is het niet verstandig om daar al voor te kiezen). WebSphere 5.0 / 5.1 is 1.3, en het is al vrij progressief om daarvoor te kiezen. Ik zie om me heen nog echt veel WebSphere 3.5 (1.2) gebruikt worden (en nieuwe applicaties voor ontwikkeld worden).

Dus dat je nu nog geen 5.0 ziet is niet meer dan logisch, sterker nog: het zou me heel erg verbaasd hebben.

[flowerp]

Aan de ene kant is het wel logisch dat je wacht met iets te gebruiken, maar als iedereen gaat wachten dan weet je toch nooit of het goed is?

Ik zie inderdaad dat er mensen zijn die bijvoorbeeld nu pas Solaris 9 gaan gebruiken (op het moment dat 10 uitkwam), etc. Als je pas op JDK 1.3 overgaat op het moment dat 1.5 uitkomt dan veranderd dat toch niks aan die 1.3 release van toen?

Begrijp met niet verkeerd, ik snap wel dat veel bedrijven een zekere voorzichtigheid in achting nemen en niet zomaar iets nieuws gaan gebruiken zonder het eerst even te testen. Aan de andere kant elke nieuwere versie fixed ook weer bugs en problemen in de voorgaande versies. Je kunt nu wel heel stoer 1.3.07 gaan gebruiken (noem maar wat), maar daar zaten ook weer bugs in. Je komt dan op 1.3.08 uit, maar daar zaten ook weer enkele tekort komingen in. Ga zo door, en je komt vanzelf uit bij 1.5.01.

Software is toch geen wijn? Het wordt toch niet met de jaren vanzelf beter?

Wat natuurlijk wel zo is, is dat je weet welke problemen er in oude versies zaten en daar omheen kunt werken. Helaas is dat niet altijd zo eenvoudig. Wat zijn nou de bugs van 1.3.08? Zijn dat alle bugs die gefixed zijn t/m 1.5.01? Voor een aantal inderdaad, maar ook voor een aantal niet want die werden pas geintroduceerd met zeg 1.4.

Daarbij komt, als iedereen 3 jaar gaat zitten wachten, kun je software net zo goed eerst 3 jaar in een brandkast liggen alvorens het te releasen. Er zullen toch tenminste een aantal mensen het moeten gaan gebruiken, en dan niet alleen hobbyisten, maar ook echt bedrijven voor zware dingen. -> Someone has to take the first risk...

[flowerp]

Alarmnummer schreef op vrijdag 18 februari 2005 @ 23:31:
[...]

Die kans lijkt me eerlijk gezegt kleiner dan 0. JDK 5.0 voegt een 2 tal dingen toe aan java die al lange tijd nodig zijn: generics (de minst belangrijke) en metadata. Metadata zal ervoor zorgen dat Java een volledig nieuwe dimensie van functionaliteit zal leren kennen. In principe kon het wel via oplossingen zoals Commons Attributes.. maar het feit dat het onderdeel van de taal is geworden zal declaratief programmeren binnen Java eindelijk een onmisbare onderdeel maken.

Ben ik het helemaal mee eens. Leuk om te zien hoe in een J2EE omgeving Beehive hier mee omgaat. Wat ik alleen nog in 1.5 mis is operator overloading zodat je ook in Java dingen kunt schrijven als myhash["bar"];

Het feit dat een ide te achterlijk is om die features te implementeren kan geen reden zijn voor sun om het terug te trekken.

Het was ook een beetje sarcastisch bedoeld Maar serieus, eigenlijk is het niet de Eclipse zelf die er geen support voor kan bieden, maar een gedeelte daarvan, namelijk de JDT die met een eigen compiler werkt. Dat dat binnnen het Eclipse platform niet hoeft zie je met CDT (de omgeving binnen Eclipse voor C/C++ dev), die gewoon gcc gebruikt.

Trouwens... er is al 1.5 ondersteuning vanuit Eclipse...

Klopt, en sinds M4 is er zelfs een MyEclipse release voor, maar het blijft natuurlijk een alpha versie.

Java 1.5 is here to stay.. Jdk1.4 voegde nauwelijks iets aan de taal toe (als je de assert durft mee te rekenen), maar 1.5 is echt een volgende stap.

En daarom wil ik het al developper ook graag gebruiken. Ik wordt dan ook een beetje gefrustreerd dat alle bedrijven (inclusief die waar ik werk) alleen maar willen wachten en wachten. Zoals het er nu bij ons uitziet duurt het nog wel een jaar voordat er gekeken gaat worden naar 1.5. Begrijpelijk? Mischien. Leuk voor een techneut? Niet echt

[Alarmnummer]

flowerp schreef op zaterdag 19 februari 2005 @ 13:12:
[...]


Ben ik het helemaal mee eens. Leuk om te zien hoe in een J2EE omgeving Beehive hier mee omgaat. Wat ik alleen nog in 1.5 mis is operator overloading zodat je ook in Java dingen kunt schrijven als myhash["bar"];

Ik zou het ook graag zien. Ik betwijfel of het verstandig is om bijna alle operators te kunnen overloaden (zoals bij c++), maar de standaard operatoren waarover geen onduidelijkheid kan bestaan zeker.

BigInteger i = k.add(l.sub(m)).

of:

BigInteger i = k+(l-m).

Lijkt me vrij duidelijk...

Dit zijn wel leuke details voor het programmeren, maar geen belangrijke toevoeging zoals attributen/metadata/annotations

Het was ook een beetje sarcastisch bedoeld Maar serieus, eigenlijk is het niet de Eclipse zelf die er geen support voor kan bieden, maar een gedeelte daarvan, namelijk de JDT die met een eigen compiler werkt. Dat dat binnnen het Eclipse platform niet hoeft zie je met CDT (de omgeving binnen Eclipse voor C/C++ dev), die gewoon gcc gebruikt.

Tja.. ik heb het niet op geintegreerde buildomgevingen. Een buildscript is imho de enigste manier om te builden. Ik doelde voornamelijk op de ondersteuning in de IDE: syntax checking etc voor generics.

En daarom wil ik het al developper ook graag gebruiken. Ik wordt dan ook een beetje gefrustreerd dat alle bedrijven (inclusief die waar ik werk) alleen maar willen wachten en wachten. Zoals het er nu bij ons uitziet duurt het nog wel een jaar voordat er gekeken gaat worden naar 1.5. Begrijpelijk? Mischien. Leuk voor een techneut? Niet echt

Op mijn werk werk ik ook met 1.4, maar in de dingen die ik thuis schrijf werk ik voornamelijk met 1.5

[Alarmnummer]

Ik heb net update 2 van jdk 1.5 erop gezet en nu werkt jmx (ook in de vm) perfect met JBoss. Ik heb nu JConsole open en kan zien wat er op de applicatieserver allemaal gaande is... perfect..

[edit]
Deze straks ook eens proberen icm 1.5
http://mc4j.sourceforge.net/

[ Voor 18% gewijzigd door Alarmnummer op 14-03-2005 20:19 ]

[ronaldmathies]

Alarmnummer schreef op maandag 14 maart 2005 @ 20:10:

Tja.. ik heb het niet op geintegreerde buildomgevingen. Een buildscript is imho de enigste manier om te builden. Ik doelde voornamelijk op de ondersteuning in de IDE: syntax checking etc voor generics.


[...]

Op mijn werk werk ik ook met 1.4, maar in de dingen die ik thuis schrijf werk ik voornamelijk met 1.5

Eclipse ism MyEclipse kan een geïntegreerde build omgeving zijn. Ik gebruik echter Ant en XDoclet voor het builden. Eclipse is juist een enorm vrije omgeving als het gaat om dit soort dingen. Dat kan ik bijvoorbeeld niet van JBuilder en JDeveloper zeggen. Wat ik me nu eigenlijk af vraag wat voor ontwikkelomgeving gebruik je eigenlijk? Want ik heb dat eigenlijk nog nooit gelezen.

[Alarmnummer]

ronaldmathies schreef op maandag 14 maart 2005 @ 23:59:
[...]


Eclipse ism MyEclipse kan een geïntegreerde build omgeving zijn. Ik gebruik echter Ant en XDoclet voor het builden. Eclipse is juist een enorm vrije omgeving als het gaat om dit soort dingen.

Dat zijn de meeste ide`s toch?

Dat kan ik bijvoorbeeld niet van JBuilder en JDeveloper zeggen.

Hoe bedoel je? Als je maar een ANT kan opstarten is dat toch geen probleem? Ik heb vroeger wel eens iets gedaan met JBuilder.. maar dat is niet mijn ding.

Wat ik me nu eigenlijk af vraag wat voor ontwikkelomgeving gebruik je eigenlijk? Want ik heb dat eigenlijk nog nooit gelezen.

Er staat toevallig een topic over IDEA hier IntelliJ IDEA is de enigste IDE voor mij... Het is enorm slim, helpt me overal waar het kan, extreem krachtige refactor opties. Voor de dingen die ik van een IDE verwacht vind ik in IDEA het beste.. Eclipse die bungelt er maar een beetje achter aan... ik vind het maar een half af product dat intussen ook zo traag als de pest begint te worden. Slappe JSP support, slappe XML support, slappe HTML support, geen CSS support, voelt rommelig en half af aan. Ik snap eerlijk gezegd niet waar die hele hype over gaat want zo bijzonder is Eclipse zeker niet.

[ Voor 9% gewijzigd door Alarmnummer op 15-03-2005 08:12 ]

[MSalters]

Alarmnummer schreef op zaterdag 19 februari 2005 @ 13:26:
[...]
Ik zou het ook graag zien. Ik betwijfel of het verstandig is om bijna alle operators te kunnen overloaden (zoals bij c++), maar de standaard operatoren waarover geen onduidelijkheid kan bestaan zeker.

BigInteger i = k.add(l.sub(m)).

of:

BigInteger i = k+(l-m).

Lijkt me vrij duidelijk...

Sterker nog: is essentieel voor generics. Schrijf maar eens een generic accumulate(container) als je niet weet hoe je twee elementen optelt. Dan lukt het met N elementen ook niet.

[Verwijderd]

Alarmnummer schreef op dinsdag 15 maart 2005 @ 07:33:
[...]
Slappe JSP support

De JSP support is nu nog redelijk slap ja. Er zijn 2 serieuze projecten mee aan de gang:het Web Tools Project en MyEclipse. MyEclipse gaat voor de basis steeds meer op WTP bouwen en zich meer focussen op high level dingen voor support voor Struts, Spring, Hibernate etc.

Met de huidige versie van WTP kun je nog bijna niks standalone doen, en de JSP editor van MyEclipse is heel erg buggy (see support forum op www.myeclipseide.com ). Samengevat komt het er op neer dat de validatie in de editor helemaal over de rooie gaat bij een bepaald soort gebruik van scriptlets en static jsp includes met scriptlets. Editor wordt dan extreem traag, copy paste werkt niet meer, als je typed komt je tekst achterstevoren, etc.

geen CSS support

Die zit er wel in hoor. Werkt zelf met content assist (ms term: intellisense). Je kunt CSS support zowel standalone gebruiken als in een style attribuut van een tag in een HTML of JSP file.

voelt rommelig en half af aan. Ik snap eerlijk gezegd niet waar die hele hype over gaat want zo bijzonder is Eclipse zeker niet.

1 woord (vooral voor Nederlanders belangrijk): G R A T I S!

Voorderest kun je er lekker makkelijk plug-ins voor ontwikkelen en werkt het ook weer niet slecht. Mijn andere IDE ervaring is Visual Studio 5 t/m 2003 en in vergelijking met dat kan ik niet echt iets extreems slecht aan Eclipse vinden. Ok, mischien 1 ding: de opstart tijd is toch wel erg lang, zeker op snellere machines merk je dat. VS staat op een machine zoals je die nu in de winkel koopt bijna onmiddelijk op je scherm, maar zelfs op zo'n nieuwe bak presteerd Eclipse het nog om 10 tallen seconden het splash screen te laten zien bij het opstarten.

[Alarmnummer]

Verwijderd schreef op dinsdag 15 maart 2005 @ 18:32:
[...]


De JSP support is nu nog redelijk slap ja. Er zijn 2 serieuze projecten mee aan de gang:het Web Tools Project en MyEclipse. MyEclipse gaat voor de basis steeds meer op WTP bouwen en zich meer focussen op high level dingen voor support voor Struts, Spring, Hibernate etc.

Die highlevel support interesseert me niet echt. Ik wil gewoon dat de editors die erin zitten het gewoon goed doen. Ik erger me groen en geel als ik met Eclipse aan de slag met en nog geen 10e van de editor functionaliteit van IDEA erin aantref. Ik hoef geen crappy gui`s van tools die ik zelf ook goed met de hand kan bewerken. Hierbij is het wel prachtig dat IDEA bv code completion in de XML geeft op basis van de DTD. Verder experimenteer ik ook graag met beta`s en dan is zo`n gui per definitie een blok aan je been aangezien die nooit up to date zijn.

Met de huidige versie van WTP kun je nog bijna niks standalone doen, en de JSP editor van MyEclipse is heel erg buggy (see support forum op www.myeclipseide.com ).

Zelfs de java editor is buggie. Weiger om code completion te doen vaak (hoor collega vaak genoeg schelden en rammen op zijn toetsenbord).

Samengevat komt het er op neer dat de validatie in de editor helemaal over de rooie gaat bij een bepaald soort gebruik van scriptlets en static jsp includes met scriptlets. Editor wordt dan extreem traag, copy paste werkt niet meer, als je typed komt je tekst achterstevoren, etc.

Probeer IDEA eens. Schop je Eclipse meteen bij het grof vuil. Volledige refactoring (ook over JSP), taglet support (code completion).

zit er wel in hoor. Werkt zelf met content assist (ms term: intellisense). Je kunt CSS support zowel standalone gebruiken als in een style attribuut van een tag in een HTML of JSP file.

Dat wist ik nog niet. Maar ook refactorings? Automatisch linken naar de w3c specs?

Voorderest kun je er lekker makkelijk plug-ins voor ontwikkelen en werkt het ook weer niet slecht.

TJa.. plugins.. wat moet ik ervan zeggen. Die hele Eclipse is een ratjetoe van plugins en 9 van de 10 plugins zie ik liever als anttask zodat ik het vanuit ANT altijd onder mijn controle heb. En mijn algemene indruk van die plugins is dat ze een erg lage kwaliteit hebben, check bv dit hoopje ellende:
http://www.japisoft.com/exslt

Dit neem je toch niet serieus...

Mijn andere IDE ervaring is Visual Studio 5 t/m 2003 en in vergelijking met dat kan ik niet echt iets extreems slecht aan Eclipse vinden. Ok, mischien 1 ding: de opstart tijd is toch wel erg lang, zeker op snellere machines merk je dat. VS staat op een machine zoals je die nu in de winkel koopt bijna onmiddelijk op je scherm, maar zelfs op zo'n nieuwe bak presteerd Eclipse het nog om 10 tallen seconden het splash screen te laten zien bij het opstarten.

Je maakt dan ook een vergelijking.. Visual Studio staat qua intelligentie echt in geen vergelijking met ide`s zoals IDEA en zelfs met Eclipse.. Refactoring support hebben we onder Java al jaren, maar bij VS.NET is het relatief nieuw..

[ Voor 6% gewijzigd door Alarmnummer op 15-03-2005 19:03 ]

[Verwijderd]

Alarmnummer schreef op dinsdag 15 maart 2005 @ 18:54:
Hierbij is het wel prachtig dat IDEA bv code completion in de XML geeft op basis van de DTD.

Zonder nu meteen als een super Eclipse evangelist te willen overkomen (er mankeert genoeg aan Eclipse), moet ik toch wel even melden dat XML code completion ook in Eclipse zit. Mischien dat niet iedereen het waardeert, maar er zit zelfs een optie in voor code completion van XML files waar geen DTD of schema voor is. De editor gokt dan de completion aan de hand van hoe je eerder tags en attributen hebt gebruikt.

Verder experimenteer ik ook graag met beta`s en dan is zo`n gui per definitie een blok aan je been aangezien die nooit up to date zijn.

Hangt opzich van het component af. Zoals gezegd, CDT stuurt voornamelijk externe componenten aan: gcc voor het compileren en default make voor het builden. Die kun je zo vervangen door andere. Je kunt zelfs de vrij verkrijgbare cl.exe (ms c/c++ compiler) voor het compileren gebruiken.

Het is ook zo dat Eclipse zelf eigenlijk een platform is. De core is niet eens een IDE opzich, je kunt er ook een office suit mee bouwen (zie rich client platform). De Java JDT IDE plug-in is dan wel de dominante toepassing (en ook waar de architectuur van Eclipse uit voortgekomen is), maar zeker niet de enige. Vanuit een developper gezien zou je de Eclipse core ook als een application framework kunnen zien.

Zelfs de java editor is buggie. Weiger om code completion te doen vaak (hoor collega vaak genoeg schelden en rammen op zijn toetsenbord).

De code completion in de MyEclipse JSP editor faalt behoorlijk vaak, maar in de Java editor ben ik dat eigenlijk niet niet tot heel erg weinig tegengekomen. De code completion van VS faalde wat dat betreft wel redelijk vaak.
Veel buggy dingen ben ik niet echt tegengekomen in de java editor. Een klein ding wat ik me zo voor de geest kan halen is de folding support. Inner classes worden automatisch gefolded (zichtbaar door de "..."), maar als je ze unfolded dan komen er dikwijls achter elke regel "..." markers te staan. Dit lijkt alleen een rendering fout te zijn, maar is wel duidelijk een bug natuurlijk.

Neem ik echter de Eclipse JSP editor dan kan ik wel aan de gang blijven met bugs opnoemen. Uit mijn hoofd kan ik er zo al een stuk of 12 echte nasty ones (complete showstopper) opnoemen. Het rare daarvan wel is dat het sterk afhankelijk is van de soort JSP code die je gebruikt. Sommige mensen hebben dan ook nergens last van, terwijl andere amper kunnen werken.

Probeer IDEA eens. Schop je Eclipse meteen bij het grof vuil. Volledige refactoring (ook over JSP), taglet support (code completion).

Wil ik zeker eens proberen ja. Staat voorlopig nog op mijn persoonlijke todo lijst

Dat wist ik nog niet. Maar ook refactorings? Automatisch linken naar de w3c specs?

Ik werk weinig met CSS opzich, dus weet niet of het refactoring support. Aan welke operatie moet ik dan denken? Alle class attributen in tags van een nieuwe waarde voorzien of wat anders?

TJa.. plugins.. wat moet ik ervan zeggen. Die hele Eclipse is een ratjetoe van plugins en 9 van de 10 plugins zie ik liever als anttask zodat ik het vanuit ANT altijd onder mijn controle heb. En mijn algemene indruk van die plugins is dat ze een erg lage kwaliteit hebben, check bv dit hoopje ellende:
http://www.japisoft.com/exslt

In de hele repository van eclipse plug-ins zit inderdaad veel rommel. Mensen die een maandje wat inelkaar brouwen en het dan maar meteen releasen. Voor mezelf vind ik het wel lekker om snel en makkelijk plug-ins te maken. Ik ben een tijd bezig geweest met een eigen taaltje voor data transformations en kon daar zeer snel een plug-in set voor elkaar zetten (oa een editor) die mooi integreerde met de rest van Eclipse. Zelfs al zou ik niet kijken naar de integratie dan nog was het Eclipse framework handig om te gebruiken als een 'editor toolkit'. Mijn plugins zijn niet iets om te releasen, maar voormezelf wel erg handig.

Wat dat betreft heeft Eclipse mischien een beetje last van het Visual Basic syndroom (tegenwoordig PHP): Het is te makkelijk om plug-ins te maken. Veel mensen (waaronder ik zelf) kunnen zo even een editor of andere tool in elkaar flansen zonder dat ze echt de knowhow daarvoor hebben. Het werkt allemaal al heel snel heel erg aardig. Pas bij echt gebruik van de plug-in merk je dat er toch wel wat meer dingetjes bij komen kijken.

[ Voor 6% gewijzigd door Verwijderd op 15-03-2005 22:58 ]

[Alarmnummer]

Ik erger me vooral om die hele hype om eclipse heen.. Het is een f*cking ide... meer niet... het is geen applicatieserver, of vm (check javalobby voor dit soort totaal stompzinnige opmerkingen). Het zal java zeker niet een nieuwe eeuw in dragen... Het is een ide... meer niet.. mijn code is per definitie niet gebonden aan een bepaalde IDE... iedere applicatie is volledig te builden en te deployen vanaf de commandline zonder dat ik me druk hoef te maken over rare dependencies of gekke libraries (nog een min punt aan veel ide`s.. krijg je ineens ide afhankelijk ANT scripts )

Daarbij wou ik het ook wel laten.. Eclipse is een IDE die zeker in mijn top 3 staat van beste Java IDE`s, maar daarmee is de kous ook wel af

[Verwijderd]

Dan toch nog even een stiekeme laatste comment over dit onderwerp

Een gedeelte van het Eclipse gebeuren zou Java wel degelijk een stap verder kunnen brengen: SWT. Dit is een complete widget library die eigenlijk absoluut compleet los staat van Eclipse. Het is eigenlijk hetzelfde idee als AWT (native implementaties van widgets), maar dan veel geavanceerder en vooral simpelweg moderner. Aan AWT kan 'nooit' meer ( lees, redelijk moeilijk) iets toegevoegd worden: Sun moet alles met Swing doen. SWT is een nieuwe kans om het native widget concept weer helemaal in het nieuwe millenium te introduceren.

Ok, dat laatste was standaard marketting cr*p maar de SWT library die Eclipse mee brengt is zeker interesant voor elke type client applicatie.

[ronaldmathies]

Als dit soort discussies gevoerd worden zou ik het persoonlijk prettig vinden dat als men een onderdeel gaat beoordelen of men dan ook het stuk software erbij benoemd. Want ik lees nu geregeld dat de JSP editor beroerd is in Eclipse (in sommige gevallen) maar bij mijn weten heeft Eclipse totaal geen ondersteuning tot wat voor soort J2EE component dan ook.

Dus hebben we het dan over MyEclipse of over andere vormen van tools / plugins die er te krijgen zijn.

Wel moet ik opmerken dat de JSP editor voor een hele lange tijd problemen had met scriptlets en syntax highlighting. Daarnaast was deze enorm traag. Deze problemen ben ik eigenlijk met 3.8.3 van MyEclipse niet meer tegen gekomen (soms wil de syntax highlighting nog wel eens raar doen maar dit is erg zelden)

[Verwijderd]

ronaldmathies schreef op woensdag 16 maart 2005 @ 09:32:
Dus hebben we het dan over MyEclipse of over andere vormen van tools / plugins die er te krijgen zijn.

Als ik bovenstaande posts lees dan zegt men dat er maar 2 serieuze J2EE projecten zijn, MyEclipse en WTP en dat die eerste op de 2de bouwt die zelf niet standalone te gebruiken is. Ik neem aan MyEclipse dus.

Wel moet ik opmerken dat de JSP editor voor een hele lange tijd problemen had met scriptlets en syntax highlighting. Daarnaast was deze enorm traag. Deze problemen ben ik eigenlijk met 3.8.3 van MyEclipse niet meer tegen gekomen (soms wil de syntax highlighting nog wel eens raar doen maar dit is erg zelden)

Dat is compleet niet mijn ervaring. Wij gebruiken de J2EE extensie MyEclipse al bijna 1.5 jaar. Nooit echt grote problemen gehad, tot de 3.8.x serie voor Eclipse 3.0. Alle genoemde problemen zagen wij ook, en we hebben er ook over gepost op het MyEclipse forum. (volgens mij Henk_de_man ook, want ik zie daar ook postings van ene henk langskomen over precies dit onderwerp

Het MyEclipse team beloofd telkens beterschap, maar kwa JSP editor veranderd er weinig. Dit kun je zelfs tussen de regels doorlezen, omdat 1 post over de JSP editor werd beantwoord met de vraag of de problemen pas in 3.8.4 waren gekomen en dat dat raar zou zijn omdat er bijna niks veranderd was tussen 3.8.4 en 3.8.3 aan de JSP editor.

De genoemde problemen met de JSP editor zijn dan ook nooit weggegaan tussen 3.8.0 en 3.8.4. Wel kwamen er postings langs die 1 patroon lieten zien waarbij de editor vaak helemaal over de nek van gaat:

- variable declareren in jsp
- static include van een file met .jsp extensie (ipv .jspf) die deze var gebruikt
- scriptlet code gebruiken na de include

[PhoneTech]

Verwijderd schreef op woensdag 16 maart 2005 @ 00:38:
Dan toch nog even een stiekeme laatste comment over dit onderwerp

Een gedeelte van het Eclipse gebeuren zou Java wel degelijk een stap verder kunnen brengen: SWT. Dit is een complete widget library die eigenlijk absoluut compleet los staat van Eclipse. Het is eigenlijk hetzelfde idee als AWT (native implementaties van widgets), maar dan veel geavanceerder en vooral simpelweg moderner. Aan AWT kan 'nooit' meer ( lees, redelijk moeilijk) iets toegevoegd worden: Sun moet alles met Swing doen. SWT is een nieuwe kans om het native widget concept weer helemaal in het nieuwe millenium te introduceren.

Ok, dat laatste was standaard marketting cr*p maar de SWT library die Eclipse mee brengt is zeker interesant voor elke type client applicatie.

Ik vind dat hele SWT gebeuren zwaar overhyped! Het is een mooie techniek om mooie GUI's te maken, maar waar is de fokking documentatie! SWT is heel goed te gebruiken voor kleine simpele GUI's waar alles nog te overzien is, maar als je wat grotere apps aan het ontwikkelen ben, dan heb je geen zin meer om voor destructor te spelen aangezien de garbage collector te SWT widgets niet opruimt...

Ben nu al een een half jaar fulltime met swing bezig, en swing is gewoon niet langzaam meer. mits je er goed gebruik van maakt natuurlijk

Geen problemen die niet met metaal zijn op te lossen

[Verwijderd]

PhoneTech schreef op woensdag 16 maart 2005 @ 11:37:
[...]
Ik vind dat hele SWT gebeuren zwaar overhyped! Het is een mooie techniek om mooie GUI's te maken, maar waar is de fokking documentatie!

Als je bijvoorbeeld bij Scheltema binnenloopt dan zie je dat er best wel een aantal boeken zijn die over SWT of Eclipse development gaan.

SWT is heel goed te gebruiken voor kleine simpele GUI's waar alles nog te overzien is, maar als je wat grotere apps aan het ontwikkelen ben, dan heb je geen zin meer om voor destructor te spelen aangezien de garbage collector te SWT widgets niet opruimt...

Is dat zo'n groot probleem dan? DB connecties moet je in Java toch ook vrij geven, files moet je sluiten, etc. Zie SWT widgets niet als geheugen maar als een 'resource' en je hebt geen probleem meer.

SWT heeft zeker potentie. Het is gewoon nog niet zo heel erg bekend. Zodra alle major IDEs een "nieuw SWT project" wizard hebben, kan het best wel eens snel gaan.

[misfire]

Het standaard Eclipse product dat je kunt downloaden op eclipse.org is een tool om Eclipse plugins mee te maken. Het is geen J2EE ontwikkeltool, voor deze functionaliteit moet je andere op Eclipse gebaseerde producten gebruiken. Er wordt hier MyEclipse en WTP vergeleken met iets dergelijks als IDEA. MyEclipse kost 30$ per jaar, en WTP is gratis, en van beiden wordt hier over versies gediscussieerd die nog in beta zijn, versus een commercieel stabiel product wat enkelen honderden dollars kost.

Als je op zoek gaat naar een stabiele J2EE ontwikkelomgeving op basis van Eclipse dan heb je bijvoorbeeld ook IBM Rational Application Developer. Daar werken refactorings ook prima door in JSP pagina's enz. en kan echt wel als een serieuze J2EE IDE gezien worden. Ik vraag me overigens wel af waarom dit zo belangrijk is, aangezien nette JSP pagina's in de regel geen Java code bevatten.

Dat er voor SWT geen documentatie zou zijn is gewoon FUD. In de meegeleverde Eclipse Help wordt een zeer uitgebreide documentatie over SWT en JFace meegeleverd, met voorbeelden, API docs enz. Er zijn ook verschillende goede boeken op de markt, en de site www.eclipsefaq.org biedt een wereld van informatie.

Er worden inderdaad verschillende debiele dingen op javalobby en theserverside enz over Eclipse geschreven, maar is daarom Eclipse een slecht initiatief? Ik denk zelf dat de doelstelling van Eclipse zeer aantrekkelijk is, zowel voor developers als voor tool vendors, en dat zie je nu terug in de "hype" die omtrent het platform ontstaat, de partijen die aanschuiven, en de cijfers van het gebruik. Het is een goede keuze, net zoals IDEA een goede keuze kan zijn. Zolang je maar de goede argumenten gebruikt om de keuze te maken zijn er nog alternatieven genoeg in Java land, en dat is maar goed ook.

Oh ja, en JMX vind ik ook interessant, maar we hebben in projecten wel praktische problemen met documentatie en implementatie issues. Er is relatief weinig documentatie voor sommige applicatieservers op dit gebied, en dat maakt het soms best pittig om relatief simpele problemen te tackelen. De toevoeging van JMX aan de J2EE standaard en Java 5, en integratie in bijvoorbeeld Spring maakt het echter steeds interessanter om deze libraries te gaan benutten. Ik zou iedere Java developer aanraden om eens naar JMX te kijken!

[ronaldmathies]

Nu heb ik dit hele topic nog eens doorgelezen maar wat ik mij nu afvraag, zijn er bij mensen sites/tutorials bekend die aan te raden zijn?