Onderwerp: Ervaring met J2EE applicaties

Ik ben begonnen met een soort van cms in php.. maar
ik ben van plan over te stappen op J2ee. vooral omdat het
een complex systeem is die niet lekker te onderhouden is met php.
en met j2ee heb ik veel meer mogelijkheden.
Maar uiteindelijk zullen er MKB-websites op draaien. niet bedrijfs-kritische applicaties.

Is J2EE hier wel voor geschikt? Ik hoor dat J2EE webapplicaties ook trager zijn dan
php maar dat lijkt mij toch onzin.

Klopt het dat j2EE geheugen vreet? Of ligt dit echt aan de programmeur die het systeem maakt?

M.a.w. wat zijn de ervaringen met J2ee

Tjerk Wolterink wrote:
> Ik ben begonnen met een soort van cms in php.. maar
> ik ben van plan over te stappen op J2ee. vooral omdat het
> een complex systeem is die niet lekker te onderhouden is met php.

Waarom zou eeen php site minder goed te onderhouden zijn dan een site die
met java gemaakt is ? Volgens mij ligt dat vooral aan het ontwerp van je
software, wat met php niet veel anders hoeft te zijn dan met java.
Hoogstwaarschijnlijk kun je het ontwerp met java iets handiger naar
werkelijke software omzetten, maar dat is het dan ook wel.

> en met j2ee heb ik veel meer mogelijkheden.

Welke mogelijkheden doel je op ? Ik kan me er best wat bij voorstellen,
maar je kunt het andersom ook zo stellen, afhankelijk van wat je wilt gaan
doen.

> Maar uiteindelijk zullen er MKB-websites op draaien. niet
> bedrijfs-kritische applicaties.
>
> Is J2EE hier wel voor geschikt? Ik hoor dat J2EE webapplicaties ook
> trager zijn dan
> php maar dat lijkt mij toch onzin.

Het hangt er vooral vanaf welke applicatie server je gebruikt, wat voor
applicatie, hoeveel hits je hebt en nog wel wat zaken. Om het zo bot te
stellen is onzin. Zeer grote applicaties zullen met Java zeker efficienter
draaien.

>
> Klopt het dat j2EE geheugen vreet? Of ligt dit echt aan de programmeur
> die het systeem maakt?

Vreet is een groot woord. Een Java applicatie server laad een programma
over het algemeen bij het opstarten al geheel in het geheugen, zodat je
bij een request gelijk de pagina kan serveren. Bij PHP wordt over het
algemeen voor elke request het script van disk geladen, gecompileerd en
uitgevoerd (al heb je hierbij natuurlijk caching op verschillende niveaus)
De hogere efficientie van Java heb je echter alleen wat aan als je ook
veel hits hebt.

> M.a.w. wat zijn de ervaringen met J2ee

Mijn ervaringen met J2EE zijn best OK. Als taal is Java in ieder geval een
stuk fijner dan PHP, wat toch altijd een beetje kneuterig blijft. Voor PHP
zul je wel wat makkelijker goedkope hosting kunnen vinden, wat voor het
MKB nog wel eens een punt zou kunnen zijn.

Tjerk Wolterink wrote:

> Ik ben begonnen met een soort van cms in php.. maar
> ik ben van plan over te stappen op J2ee. vooral omdat het
> een complex systeem is die niet lekker te onderhouden is met php.
> en met j2ee heb ik veel meer mogelijkheden.
> Maar uiteindelijk zullen er MKB-websites op draaien. niet
> bedrijfs-kritische applicaties.
>
> Is J2EE hier wel voor geschikt? Ik hoor dat J2EE webapplicaties ook
> trager zijn dan
> php maar dat lijkt mij toch onzin.

Het probleem met J2EE is dat je er erg veel mee kan. Als je niet oplet
kun je er een complexe boel van maken die niet vooruit te branden is
(schijnt vooral voor te komen als je veel EJB's gebruikt.)

Er is de laatste tijd ook een tegenstroming, die juist streeft naar
lichte raamwerken. Zij gebruiken dan bijvoorbeeld Struts en Hibernate.

Wat snelheid betreft zijn de benchmarks verdeeld. Soms is PHP sneller,
soms J2EE (JSP). Probleem met deze benchmarks is dat ze vaak een enkele,
losstaande pagina meten, terwijl je bij een wat complexere webapplicatie
een raamwerk wilt gebruiken. Daar is Java geschikter voor, omdat
objecten in het geheugen blijven staan en niet bij elke pagina-opvraging
opnieuw moeten worden aangemaakt zoals bij PHP.

> Klopt het dat j2EE geheugen vreet? Of ligt dit echt aan de programmeur
> die het systeem maakt?

J2EE vraagt inderdaad meer geheugen dan PHP of Perl. Reken op in ieder
geval 36MB. Acht jaar geleden was dat veel. Tegenwoordig heeft een
server minimaal een Gig aan boord dus om je daar nu zorgen over te maken?

Groeten,
Edwin Martin

--
http://www.bitstorm.org/

Michiel de Roo wrote:
> Tjerk Wolterink wrote:
>
>>Ik ben begonnen met een soort van cms in php.. maar
>>ik ben van plan over te stappen op J2ee. vooral omdat het
>>een complex systeem is die niet lekker te onderhouden is met php.
>
>
> Waarom zou eeen php site minder goed te onderhouden zijn dan een site die
> met java gemaakt is ? Volgens mij ligt dat vooral aan het ontwerp van je
> software, wat met php niet veel anders hoeft te zijn dan met java.
> Hoogstwaarschijnlijk kun je het ontwerp met java iets handiger naar
> werkelijke software omzetten, maar dat is het dan ook wel.

nou interfaces in java maken mijn software een stuk beter te onderhouden.. Interfaces
worden niet ondersteund in php.
Als ik in java een lib wel installeren is dat gewoon een kwestie van een .jar in mijn .war plaatsen.
in php is het naar mijn inziens een gekloot.


>
>
>>en met j2ee heb ik veel meer mogelijkheden.
>
>
> Welke mogelijkheden doel je op ? Ik kan me er best wat bij voorstellen,
> maar je kunt het andersom ook zo stellen, afhankelijk van wat je wilt gaan
> doen.

distributed applications, webservices, betere xml mogelijkheden.

Edwin Martin <e.j.martin@chello.nl> wrote:
> Wat snelheid betreft zijn de benchmarks verdeeld. Soms is PHP sneller,
> soms J2EE (JSP).

Wat zou de OP bedoelen met j2ee? Voor jsp/servlets heb je geen
(volledige) j2ee omgeving nodig, het is als die kaas reclame: alles wat
er niet aankomt, hoeft er ook niet af. (resp overhead en performance)

Tjerk Wolterink wrote:
> Michiel de Roo wrote:
>
>> Tjerk Wolterink wrote:
>>
>>> Ik ben begonnen met een soort van cms in php.. maar
>>> ik ben van plan over te stappen op J2ee. vooral omdat het
>>> een complex systeem is die niet lekker te onderhouden is met php.
>>
>>
>>
>> Waarom zou eeen php site minder goed te onderhouden zijn dan een site die
>> met java gemaakt is ? Volgens mij ligt dat vooral aan het ontwerp van je
>> software, wat met php niet veel anders hoeft te zijn dan met java.
>> Hoogstwaarschijnlijk kun je het ontwerp met java iets handiger naar
>> werkelijke software omzetten, maar dat is het dan ook wel.
>
>
> nou interfaces in java maken mijn software een stuk beter te
> onderhouden.. Interfaces
> worden niet ondersteund in php.

Je kunt ook in PHP met interfaces programmeren, alhoewel de taal die niet
als zodanig ondersteund. Gewoon een kwestie van de interface in je ontwerp
opnemen en ervoor zorgen dat het object dat die implementeert alle
methoden van de interface implementeert. Ik heb dat al vele malen gedaan.
Het enige nadeel is dat de compiler niet voor je checkt of het goed hebt
gedaan.

PHP is zowieso een type-less taal, het maakt dus geen bal uit wat voor
soort object je aan een methode doorgeeft. Alhoewel dit in de praktijk
vaak niet erg handig is, laat het wel de deur open staan om zaken als
interfaces te implementeren.

Maar je hebt best een stuk gelijk, in Java worden dit soort dingen veel
beter geregeld.

> Als ik in java een lib wel installeren is dat gewoon een kwestie van een
> .jar in mijn .war plaatsen.
> in php is het naar mijn inziens een gekloot.

Ik gooi regelmatig libraries in mijn lib directory onder php. Omdat die in
mijn include path staat worden ze automatisch gevonden :-)

Daniel Tryba wrote:
> Edwin Martin <e.j.martin@chello.nl> wrote:
>
>>Wat snelheid betreft zijn de benchmarks verdeeld. Soms is PHP sneller,
>>soms J2EE (JSP).
>
>
> Wat zou de OP bedoelen met j2ee? Voor jsp/servlets heb je geen
> (volledige) j2ee omgeving nodig, het is als die kaas reclame: alles wat
> er niet aankomt, hoeft er ook niet af. (resp overhead en performance)
>

Gewoon J2EE: de jvm met bijvoorbeeld tomcat application server etc.

Maar ik neem aan dat je doelt op Distributed Enterprise apps die geimplementeerd
zijn met J2ee & Enterprise Beans?

Enterprise Beans ga ik denk ik niet gebruiken (ook ivm performance), het gaat mij vooral om de jsp/servlets
en de xml mogelijkheden van het java platform. (eventueel ook RMI)

Tjerk Wolterink wrote...
> Daniel Tryba wrote:
> > Edwin Martin <e.j.martin@chello.nl> wrote:
> >
> >>Wat snelheid betreft zijn de benchmarks verdeeld. Soms is PHP sneller,
> >>soms J2EE (JSP).
> >
> >
> > Wat zou de OP bedoelen met j2ee? Voor jsp/servlets heb je geen
> > (volledige) j2ee omgeving nodig, het is als die kaas reclame: alles wat
> > er niet aankomt, hoeft er ook niet af. (resp overhead en performance)
> >
>
> Gewoon J2EE: de jvm met bijvoorbeeld tomcat application server etc.

Dat is precies waar Daniel op doelt: Tomcat is geen volledige J2EE
omgeving (het is feitelijk alleen een webcontainer).

Als je de memory footprint van Tomcat vergelijkt met de memory footprint
van bijvoorbeeld WebSphere Application Server scheelt dat behoorlijk.
Maar in de praktijk zijn de absolute verschillen niet echt om wakker van
te liggen.

Groeten,
David

Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
>> Wat zou de OP bedoelen met j2ee? Voor jsp/servlets heb je geen
>> (volledige) j2ee omgeving nodig, het is als die kaas reclame: alles wat
>> er niet aankomt, hoeft er ook niet af. (resp overhead en performance)
>>
>
> Gewoon J2EE: de jvm met bijvoorbeeld tomcat application server etc.

Tomcat is dus geen j2ee maar een servlet engine (een heeeeel klein
onderdeel van j2ee).

> Maar ik neem aan dat je doelt op Distributed Enterprise apps die
> geimplementeerd zijn met J2ee & Enterprise Beans?

En weet-ik-veel-wat-er-nog-meer-in-j2ee zit.

> Enterprise Beans ga ik denk ik niet gebruiken (ook ivm performance),

Dat is wat ik ook heb gehoord van ejb, maar ik ben nog geen reden tegen
gekomen om daar gebruik van te moeten maken.

> het gaat mij vooral om de jsp/servlets en de xml mogelijkheden van het
> java platform. (eventueel ook RMI)

Dan ben je dus gewoon met j2se bezig. Anders dan de grotere memory
footprint is het afhankelijk van wat je doet en hoe je het doet of php
sneller/trager is dan java.

Michiel de Roo wrote:

> Tjerk Wolterink wrote:
>> Ik ben begonnen met een soort van cms in php.. maar
>> ik ben van plan over te stappen op J2ee. vooral omdat het
>> een complex systeem is die niet lekker te onderhouden is met php.
>
> Waarom zou eeen php site minder goed te onderhouden zijn dan een site
> die met java gemaakt is ?

Omdat PHP als taal een bijeengeraapte berg rommel is, en dat uit die
rommel de documentatie gedistelleerd is hier en daar aangevuld door n00b
scriptkiddies?

> Volgens mij ligt dat vooral aan het ontwerp
> van je software, wat met php niet veel anders hoeft te zijn dan met
> java.

Pfft, ik hoop van harte van wel.

> Hoogstwaarschijnlijk kun je het ontwerp met java iets handiger
> naar werkelijke software omzetten, maar dat is het dan ook wel.

Denk het niet.

> Mijn ervaringen met J2EE zijn best OK. Als taal is Java in ieder geval
> een stuk fijner dan PHP, wat toch altijd een beetje kneuterig blijft.

Amen :-D

> Voor PHP zul je wel wat makkelijker goedkope hosting kunnen vinden,
> wat voor het MKB nog wel eens een punt zou kunnen zijn.

Pfft, volgens mij doet mijn 1 USD / maand hoster ook Java.

--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html

Daniel Tryba wrote:
> Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
>
>>>Wat zou de OP bedoelen met j2ee? Voor jsp/servlets heb je geen
>>>(volledige) j2ee omgeving nodig, het is als die kaas reclame: alles wat
>>>er niet aankomt, hoeft er ook niet af. (resp overhead en performance)
>>>
>>
>>Gewoon J2EE: de jvm met bijvoorbeeld tomcat application server etc.
>
>
> Tomcat is dus geen j2ee maar een servlet engine (een heeeeel klein
> onderdeel van j2ee).
>
>
>>Maar ik neem aan dat je doelt op Distributed Enterprise apps die
>>geimplementeerd zijn met J2ee & Enterprise Beans?
>
>
> En weet-ik-veel-wat-er-nog-meer-in-j2ee zit.

Wat zit er volgens jou allemaal in J2EE dan?
Volgens mij behoort het volgende echt specifiek tot j2ee:

- jsp pages
- jsp documents
- servlet api
- enterprise javabeans

en dit behoort tot het java platform en dus ook tot j2ee

- een boel xml libs // behoort
- remote method invocations etc (soap)// maar behoort ook tot j2se en de andere java distributies

ben vast wel wat vergeten, dus vul maar aan :-)

>
>
>>Enterprise Beans ga ik denk ik niet gebruiken (ook ivm performance),
>
>
> Dat is wat ik ook heb gehoord van ejb, maar ik ben nog geen reden tegen
> gekomen om daar gebruik van te moeten maken.
>
>
>>het gaat mij vooral om de jsp/servlets en de xml mogelijkheden van het
>>java platform. (eventueel ook RMI)
>
>
> Dan ben je dus gewoon met j2se bezig. Anders dan de grotere memory
> footprint is het afhankelijk van wat je doet en hoe je het doet of php
> sneller/trager is dan java.
>


Nee hoor, dat (jsp/servlets) is toch echt J2EE, ik lees dat tenminste allemaal in de J2EE Tutorial.
In de SE libs vindt je echt geen javax.servlet package hoor.

Tjerk Wolterink wrote:

> Nee hoor, dat (jsp/servlets) is toch echt J2EE, ik lees dat tenminste
> allemaal in de J2EE Tutorial. In de SE libs vindt je echt geen
> javax.servlet package hoor.

Tomcat/Jakarta kon je altijd bij J2SE hangen, en dan had je nog lang geen
J2EE. Weet niet hoe dat nu zit. Het is wel zo dat in J2EE o.a. het servlet
gebeuren zit, maar dat wil niet zeggen dat Tomcat gebruik gelijk J2EE is.

--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html

Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
> Nee hoor, dat (jsp/servlets) is toch echt J2EE, ik lees dat tenminste allemaal in de J2EE Tutorial.
> In de SE libs vindt je echt geen javax.servlet package hoor.

Je kan servlets best buiten een J2EE omgeving gebruiken, tomcat is daar
het perfecte voorbeeld van, het is de reference implementatie van
servlets/jsp in j2ee maar een jre met tomcat is geen j2ee. Zie bv het
verschil tussen geronimo en tomcat (zo is tomcat niet eens de enige
servlet engine in geronimo).

pars pro toto enzo.

BTW zet je regel lengte eens op iets zinnigs (<80)

Daniel Tryba wrote:
> Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
>
>>Nee hoor, dat (jsp/servlets) is toch echt J2EE, ik lees dat tenminste allemaal in de J2EE Tutorial.
>>In de SE libs vindt je echt geen javax.servlet package hoor.
>
>
> Je kan servlets best buiten een J2EE omgeving gebruiken, tomcat is daar
> het perfecte voorbeeld van, het is de reference implementatie van
> servlets/jsp in j2ee maar een jre met tomcat is geen j2ee. Zie bv het
> verschil tussen geronimo en tomcat (zo is tomcat niet eens de enige
> servlet engine in geronimo).

bedankt voor de info

>
> pars pro toto enzo.
>
> BTW zet je regel lengte eens op iets zinnigs (<80)
>

Ow, geen rekening gehouden met die iets lagere resoluties :-)

Tjerk Wolterink wrote:

>> BTW zet je regel lengte eens op iets zinnigs (<80)
>
> Ow, geen rekening gehouden met die iets lagere resoluties :-)

Het heeft niet zo zeer met resolutie te maken, maar met leesbaarheid, lange
regels lezen lastiger :-D.

--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html