hwechtla-tl:
Javan huonoista puolista
Tämä sivu kirjoitettiin vuonna 2005. Asiat ovat muuttuneet sen jälkeen
jonkin verran, mutta eivät mitenkään hirveän olennaisesti, katso
nettipäiväkirja 22.10.2015 sekä esimerkkejä Java-kulttuurista. Ehkä
suurin muutos on se, että virtuaalipalvelinten potkiminen pystyyn on
nykyään niin triviaalia, että sitä ei voi enää pitää olennaisena
kynnyksenä softan ketterälle käyttöönotolle; katso
pilvilaskennasta ja pilvipalveluista ja nettipäiväkirja 08.09.2015.
Olen itse rakentamassa J2EE-pohjaista CMS-systeemiä OpenSource-pohjalla, ja
koitan saada selville mihin käyttötarkoituksiin se voisi sopia.
LAMP-pohjaiset ympäristöt ovat kai kuitenkin vielä standardi.
Niin, paitsi meillä se on FAMP.
<vuodatus>
Mitäpä tähän sanoisi. Java-ratkaisut ovat mielestäni tuotantokäyttöön
huonoja (ainakin tällä hetkellä) vielä seuraavilla tavoilla:
- ne ovat törkeän raskaita. Ongelma ei ole niinkään Java-kielessä, vaan siinä, että kaikki miljoonat abstraktiotasot toteutetaan sillä, jolloin lopputulos on niin raskassoutuinen ettei ole tosikaan.
- niitä ei tyypillisesti ole suunniteltu monikäyttäjä- eikä varsinkaan moniasiakasympäristöihin. (Tomcatin saaminen toimimaan niin, että asiakkaat pystyvät tekemään tarvitsemiaan asioita ja vain tarvitsemiaan asioita, on aika epätoivoista.)
- Java-kehittäjillä on ikävä tapa toteuttaa kaikki vähän ad hoc. Joka softalla on oma tapansa asentaa, pitää yllä, konfiguroida ja niin edelleen. Kirjastojen suhteen käytäntö on selvimmin muotoutunut mutta sekin on huono käytäntö (joka kirjastolle omat .jarrit jotka pitää lisätä CLASSPATH:iin sen sijaan, että kirjastot olisivat yhdessä puussa)
- niillä on hämmästyttävä taipumus rohkaista kehittäjiä tekemään tarpeetonta monimutkaisuutta ratkaisuihinsa. Samaa voi sanoa kyllä aika monesta muustakin teknologiasta. Aika usein nämä teknologiat kulkevat käsi kädessä Javan kanssa (XML ja siihen liittyvät, web services, lukuisat uudet "yleispätevät" protokollat). (PHP taas rohkaisee tekemään kaiken huonosti.)
- tyypillisellä Java-ratkaisulla on hirveän tarkat dependenssit: tietty jvm, tietty jdk, tietty servlet container, tiettyjen kirjastojen tietyt versiot... usean Java-ratkaisun dependenssien yhteensovittaminen on usein hirveä homma. (Ja jokaisessa uudessa versiossa jdk:t bloattaavat kaksinkertaisiksi.)
- Java ei ole kielenä ihan hirveän nerokas. (Kuten ei PHP:kään.)
Näistä syistä olen ollut huomaavinani, etteivät useimmat firmat /
organisaatiot halua hostata Java-softia koneissaan. Nimenomaan
ylläpitäjille nämä ratkaisut ovat ongelmallisia. Kaikkein helpoin niitä
olisi pyörittää dedikoiduissa (virtuaali-)koneissa dedikoiduissa IP:ssä,
mutta tällaisesta pitäisi jo veloittaa paljon enemmän kuin mitä ihan
tavallisesta virtuaalihostauksesta... usein toivon, että muut
ympäristöt (esim. mod_python) olisivat ohjelmoijille houkuttelevampia
kuin Java-ympäristöt, jottei tulisi vastaan tilanteita, joissa on
ohjelmia joita kukaan ei halua hostata...
</vuodatus>
kommentoi
(viimeksi muutettu 08.02.2017 11:59)
