Asiakas, tilasitko Javalla tehdyn systeemin ?
Toivottavasti et.
Turha nimittäin ihmetellä, kun systeemi aina silloin tällöin pysähtyy 30 sek - 2 min mittaiseksi ajaksi, ja tänä aikana Javasovellus ei vastaa mihinkään pyyntöihin ollenkaan.
JAVAlla tehtyjen sovellusten osalta tuo ei ole vika, vaan ominaisuus.
Mutta: Miksi asiakkaana maksaisit kalliin hinnan sovelluksest5a, jossa on tuollaisia "ominaisuuksia" jotka ovat käyttäjän kannalta vikoja.
Asiassa ei auta yhtään, että sovelluksen tekijänä on iso ja tunnettu IT -talo (se vain nostaa sovelluksen hintaa huomattavasti).
Miten olisi, jos tilaamisen sijasta pyytäisit trarjouksen joltain suuryritykseltä, joka tekee tällaisia Javalla - ja sen jälkeen tilaisit minulta saman systeemin puolella suuryhtiön haluamasta hinnasta.
Ja jos sovelluksesta ensimmäisen vuoden aikana löytyy yksikin sellainen turva-aukko, joka sallii hyökkääjän ajaa omaa koodiaan koneessasi sovelluksessani olevan tietoturvareiän takia, saat hinnasta vielä 50% lisäalennuksen.
Koska en aio koodata sovellusta Javalla, on sanomattakin selvää, ettei sovellukseni pysähtele silloin tällöin 30 sek - 2min ajaksi tottelematta sillä aikaa tulevia palvelupyyntöjä.
Kannattaa yleensäkin laatia sopimus, jossa mainitaan, että mikäli sovellus pysähtelee pitkähköiksi ajanjaksoiksi (esim. yli 15 sek) niin sovellusta ei makseta, ennen kuin ko. vika on korjattu.
Esimerkki sovelluksesta, joka pysähtelee silloin tällöin, ja jopa kaatuu usein kokonaan, löydät täältä:
http://www.siirretytnumerot.fi/
Siinä Javalla tehty heikkolaatuinen servletti, joka usein hidastelee, ja joskus kaatuu kokonaan.
Kahdennetusta, toisiaan varmistavasta palvelintekniikasta tuon sovelluksen tekijä (= tietojeni mukaan Accenture) ei ilmeisesti ole koskaan kuullutkaan.
Toivottavasti et.
Turha nimittäin ihmetellä, kun systeemi aina silloin tällöin pysähtyy 30 sek - 2 min mittaiseksi ajaksi, ja tänä aikana Javasovellus ei vastaa mihinkään pyyntöihin ollenkaan.
JAVAlla tehtyjen sovellusten osalta tuo ei ole vika, vaan ominaisuus.
Mutta: Miksi asiakkaana maksaisit kalliin hinnan sovelluksest5a, jossa on tuollaisia "ominaisuuksia" jotka ovat käyttäjän kannalta vikoja.
Asiassa ei auta yhtään, että sovelluksen tekijänä on iso ja tunnettu IT -talo (se vain nostaa sovelluksen hintaa huomattavasti).
Miten olisi, jos tilaamisen sijasta pyytäisit trarjouksen joltain suuryritykseltä, joka tekee tällaisia Javalla - ja sen jälkeen tilaisit minulta saman systeemin puolella suuryhtiön haluamasta hinnasta.
Ja jos sovelluksesta ensimmäisen vuoden aikana löytyy yksikin sellainen turva-aukko, joka sallii hyökkääjän ajaa omaa koodiaan koneessasi sovelluksessani olevan tietoturvareiän takia, saat hinnasta vielä 50% lisäalennuksen.
Koska en aio koodata sovellusta Javalla, on sanomattakin selvää, ettei sovellukseni pysähtele silloin tällöin 30 sek - 2min ajaksi tottelematta sillä aikaa tulevia palvelupyyntöjä.
Kannattaa yleensäkin laatia sopimus, jossa mainitaan, että mikäli sovellus pysähtelee pitkähköiksi ajanjaksoiksi (esim. yli 15 sek) niin sovellusta ei makseta, ennen kuin ko. vika on korjattu.
Esimerkki sovelluksesta, joka pysähtelee silloin tällöin, ja jopa kaatuu usein kokonaan, löydät täältä:
http://www.siirretytnumerot.fi/
Siinä Javalla tehty heikkolaatuinen servletti, joka usein hidastelee, ja joskus kaatuu kokonaan.
Kahdennetusta, toisiaan varmistavasta palvelintekniikasta tuon sovelluksen tekijä (= tietojeni mukaan Accenture) ei ilmeisesti ole koskaan kuullutkaan.
Vastaukset 13
Vanhimmat
jos koodarit on juuri koulun penkeiltä valmistuneita törppöjä joiden ensikosketus ohjelmointiin tapahtui muutama vuosi sitten?
ole Javan vika, jos asiakkaalle myytiin ylimääräisiä kilkkeitä kuten j2ee server, jonka arkkitehtuuria ei kukaan ymmärtänyt ja koodaajatkin olivat jotakin sattumalta alalle eksyneitä, mahdollisesti intiaaneja :D
Ei mitään uutta ac:lta..
Onkohan Suomi24:kin tehty Javalla, kun se pysähtelee ja jumii välillä aivan jatkuvastikin. Myös viestejä katoilee ja muutenkin systeemi bugittaa aivan täysillä.
Valitettavasti moni yrityksen IT -asioista vastaava johtaja ei juurikaan tunne tekniikkapuolta pintaa syvemmältä. Jos tuntuisi, JAVAsta ei olisi koskaan tullut suosittua ja paljon käytettyä kieltä yritysten sovelluksissa, esim. web -sellaisissa.
Tuo JAVA -sovellusten jumittelu kun johtuu JAVA:n dynaamisen muistinhallinnan roskienkeruupohjaisuudesta.
Tuo johtaa väistämättä koko järjestelmän jumiutumiseen aina, kun roskienkeruueräajo suoritetaan. Ja systeemi pysyy jumiutuneena, kunnes roskienkeruueräajo on saatu onnistuneesti päätökseen... sitten systeemi taas toimii häiriöttä... aina seuraavaan roskienkeruueräajoon saakka.
Ja vielä: mitä seuraakaan, jos ongelmaa yritetään ratkaista esim. tuplaamalla palvelimen muistimäärä, RAM -muistin hintahan on varsin alhaalla - itsekin laitoin uuteen koneeseeni 4 gigatavua RAMmia.
Vastaus: tuplaamalla RAMmin määrä, muistin siivous eli roskienkeruueräajo suoritetaan kaksinkertaisin väliajoin vanhaan verrattuna - mutta se ajo vastaavasti kestää tuplasti pidempään. Itseasiassa kerroin voi olla yli 2, koska sehän pitäisi laskea JAVA:n dynaamisen muistinhallinnan piirissä olevan RAMmin määrästä eikä RAMin kokonaismäärästä.
JAVAlla tuo on väistämätön ominaisuus, jolle ei voi mitään, paitsi uudelleenkoodata sovellus paremmalla kielellä ja unohtaa Java.
Kommenttina allaolevalle kirjoittajalle, joka ei tilaisi minulta mitään:
Hienoa, ettet! Toivottavasti pahin kilpailijasi tekee tilauksensa pian - kun uusi systeemi valmistuu, eiköhän kilpailutilanne palkitse järkiratkaisun tekijää...
Toimitan muuten mielelläni myös järjestelmiä siten, että osa palkkiosta on kiinteän summan sijasta provisio palvelun tuotosta. Näin minulla on suora taloudellinen motiivi parhaan mahdollisen laadun toimittamiseen - mitä häiriöttömämmin järjestelmä toimii, sitä tyytyväisempi on loppuasiakas, mikä todennäköisesti johtaa liikevaihdon ja sitä kautta myös provisioni kasvuun.
Win-Win -tilanne parhaimmillaan, eikö totta ?
Tähän ei voi muuta kuin todeta, että johan oli täyttä potaskaa.
En tunne Javaa täysin, mutta käsittääkseni roskienkeruu pystytään toteuttamaan tausta-ajoina niin, ettei se näy käytännön suorituskyvyssä.
Näinhän se roskienkeruu toimi aikoinaankin Commodore 64:n BASICISSA. Aina kun muuttuja sai uuden arvon, se kirjoitettiin uuteen muistiosoitteeseen, kunnes saavutettiin muistin loppu ja roskienkeruu piti käynnistää.
Java ei siis ole yhtään sen kehittyneempi kuin 80-luvun alun tietokoneet. Tällainen systeemi myös fragmentoi vapaana olevaa muistia siinä määrin tehokkaasti, että jossain välissä myös koko järjestelmän boottaus tulee aiheelliseksi.
Vähintä mitä voisi ohjelmointikieleltä odottaa olisivat tietotyyppeihin perustuvat, muistiosoitteisiin lukitut muuttujat, jotta softa pysyy kiltisti sillä alueella mitä se todella tarvitsee eikä roskaa koko RAMmia joutavanpäiväisesi. Mutta eihän Javaa voikaan kutsua ohjelmointikieleksi. Se on nykyajan Basic niille, jotka eivät ole viitsineet opetella oikeasti ohjelmoimaan.
Jos osaat käynnistää selaimen, niin kirjoitappa vaikka Googleen nämä hakusanat: "jvm performance tuning". Etsi tuloksista sitten artikkelit, jotka liittyvä garbage collector virittämiseen.
Tarkemmin ajatelle, jospa aloittaisit ihan perusteista, noi artikkelit voi olla liian vaikeita ja ovat vielä kaiken lisäksi ulkomaan kielillä.
mutta tämä on ihan c kielisen ohjelman ongelma myöskin, jos sen kuvitellaan toimivan serverinä, jota 'ei koskaan' sammuteta välillä. RAM roskaantuu/fragementoituu aina, jos siihen ei ole toteutettu erikseen tätä varten korjaavaa ominaisuutta. Javan bean applikaatioserverit ovat aika mielipuolinen keksintö. Ne toimivat melko hyvin, jos kaikki vivut ovat oikein konffattu, mutta siinä se ongelman ydin. Erittäin vaikea saada kaikki kohdalleen.
En kyllä tuosta viestistä henkivän tietotaidon pohjalta tilaisi teiltä yhtään mitään :D
Niin, esim. eBay on toteutettu Java EE:llä. Surkea ja huonosti toimiva palvelu, jolla on mitättömät käyttäjämäärät, eiks jeah? Ei tarvitse koko tekniikkaa tuomita, jos joku pässi ei ole sitä osannut käyttää ja tehnyt huonosti toimivan järjestelmän.
Joo, ja hieno Enterprise Edition joka on niin portattavaa että.
IBM:llä, Oraclella, BEA:lla, Sunilla ja ties kellä
omat 'viritetyt' virtuaalikoneet omine bugeineen.
Ja koodin siirrettävyys: portatkaa ensin WebSphere
projekti vaikkapa Oracle OC4J:hin ja katsokaa montako riviä työkalut tai te itse kirjoititte uusiksi.
Siinä sitä siirrettävyyttä. Ja paskat.
Kuka tässä nyt siirrettävyydestä on puhunut mitään? Ei Java EE -speksi edes väitä, että saman EAR:in pitää toimia automaattisesti kaikissa sovelluspalvelimissa. Ajoympäristön vaihto riippumatta käytetyistä ohjelmointikielistä ja -tekniikoista on aina raskas operaatio ja aina joutuu tekemään raakaa työtä ja kirjoittamaan koodia uusiksi. Javalla portattavuus sentään on jossain määrin mahdollista ilman että kaikkea koodia pitää kirjoittaa uusiksi. Tietysti aina parempi mitä vähemmän on käytetty valmistajakohtaisia luokkakirjastoja.
Se on kumma, miten joidenkin mielestä näin huono tekniikka on kuitenkin niin laajasti käytössä. Yleensä vielä niin, että mitä isompi ja kriittisempi web-sovellus on kyseessä, sitä todennäköisemmin se on Java EE:llä tehty.