Kymmenen kohdan lista Java2-ohjelmointikielen vioista

Ei nyt ehkä aivan näinkään. Pitää muistaa, että Java voi tarkoittaa sekä ohjelmointikieltä, kokoelmaa kirjastoja, tai virtuaalikone/kehityspakettitoteutusta. Erityisesti tuossa viimeisimmässä _on_ ongelmia, jotka ovat alustariippuvaisia ja jotka tulevat usein yllätyksenä, ja joita ei ole dokumentoitu eikä ole mielekästä odottaakaan dokumentoiduksi samassa paketissa kielen syntaksin ja standardirajapintojen kanssa.

Joskus täytyy tehdä tällaisia valintoja ja yksinkertaisesti pakottaa ihmisiä siirtymään pikkuhiljaa pois vanhoista standardeista niin, että uudemmat versiot eivät enää tue kaikkia vanhempien ominaisuuksia. Kerralla ei kannata vain minusta tehdä kauhean montaa tällaista muutosta, koska muuten käyttäjät pitävät uuden version ominaisuuksia pienempänä hyötynä kuin sitä vaivaa, joka softan päivittämisestä seuraa.

Mikäänhän ei tietenkään estä pitämästä kahta JDK:ta koneella...

Onhan Java nimenomaan syönyt C++:n asemaa.

Ei mikään huono idea. BigIntegereiden, Vectoreiden ja Matrixien käsittely helpottuisi huomattavasti. Sallitaanhan perus-javassa Stringillekkin + operaattori. Javalle on olemassa preprocessoreita, jotka tekevät tämän operation overloadinging.

Tolkienin haltiakieli ja nuotit eivät liene riittävän painavia syitä sallia tekstin kuluttaa 2x enemmän muistia.

Kaveri mainitsi, että tekstipohjainen serialisointi olisi nopeampaa ja pienempää kuin binaarivastaava. Haluasin tietää, miten tällainen onnistuu, jos esimerkiksi int a = 2000000 vie neljän tavun sijasta 8 * sizeof(char) eli 16.

Kuoleekohan selainpohjainen Java nyt kun Microsoft tappoi tuen sille tulevissa versiossa? Jos appletteja käytetään efekti-kikkailuun Flash nousee paremmaksi vaihtoehdoksi huomattavasti pienemmän runtimensa puolesta. Toisaalta, jos tehdään asiakas-serveri sovelluksia, puhdas HTTP ja servletit riittävät useasti.

Mahdollisuus kontrolloida koska piirretään, eikä, että piirretään kun ehditään, jos ehditään.

Samoin. Sun on myös dokumentoinut mielestäni esimerkillisesti miksi deprecated-metodeja (esim. Thread.stop()) ei tule käyttää ja mitä niiden tilalla tulee käyttää ongelmien välttämiseksi.

Samoin.

Ehdottomasti. Se joka väittää ettei tehokkuutta tarvitse miettiä "kun koneet on kehittyneet niin paljon" on väärässä. Myös järjestelmien koko ja käsiteltävän datan määrä kasvaa koko ajan.

Ja tämä taas tuottaa uusia ongelmia. Javastahan on jätetty ihan tarkoituksella mm. tämä c++:sta löytyvä ominaisuus pois.

Sinänsä en ihan näe miksi javasta pitäisi tehdä "puhdas oliokieli" - eihän mikään estä nytkään kirjoittamasta puhdasta olio-ohjelmaa sillä.

Sunin alkuperäinen tarkoitus kai oli että sama JDK kelpaisi kaikkiin tarkoituksiin, mutta nythän on erikseen J2EE, J2SE ja J2ME, joten ehkä ne eriytyvät myös kielen tasolla enemmän jatkossa. Saa nähdä.

ja tehottomalta. Esim. RMI toimii siten että olioita serialisoidaan, jolloin siirrettävän datan koolla on huomattava korrelaatio tehokkuuteen. XML olisi tuhlausta.

Tietysti olisi hienoa jos olioita voisi ulostaa sekä "packed binary" muodossa että XML muodossa, mutta tätä varten on jo olemassa koodia.

"eliminate Vector and Hashtable completely. An ArrayList can do anything a Vector can do and a HashMap can replace a Hashtable."

Näinhän se on, mutta aika moni olemassaoleva ohjelma kuitenkin nojaa Hashtableen ja Vectoriin. Muistaakseni HashMap ei ole tarjolla ME:ssä, joten koodin portattavuuden kannalta SE-ME voi olla perusteltua säilyttää nuo vanhat.

Sinänsä olen samaa mieltä että pitäisi olla yhtenäisempi collection api.

vähän heikoksi jäi tuon esityksen pohjalta se, onko kyse bugista vai ei. Yleensähän ohjelmassa käytetään yhtä classloaderia, jolloin ongelmaa ei esiinny, mutta classloader kikkailu mahdollistaa joitakin siistejä juttuja joten ei sitä noin vain kannata sorkkia :)

tämä olisi kyllä kiva monesti, mutta siitä voisi aiheutua paljon ongelmia.

mulla olisi lisäyksenä:

"type-safe enumeration pattern" on ainoa järkevä tapa tehdä luetelty tyyppi javassa, ja se toimii hienosti, mutta serialisoinnin yhteydessä joutuu tekemään ruman kikan (pitää määritellä public konstruktori, joka taas mahdollistaa koko patternin pilaamisen). Jos sen saisi jotenkin hoidettua, niin olisi kaunista.

Siitä olen varauksetta samaa mieltä kirjoittajan kanssa että long ja double -tyyppien kuuluisi ehdottomasti olla atomisia, kuten kaikki muut primitiiviset tyypit ovat. Sarjassamme yksi typerimpiä tapoja ampua itseään jalkaan multithreadaavassa softassa.

Tuon muuttaminen ei edes rikkoisi mitään olemassaolevaa.

Kuten artikkelissa todetaan, Java on muutenkin hidasta, ja konetehon kasvaessa prosessiajasta yhä pienempi ja pienempi osa kuluu luokkiin pakattujen muuttujien käsittelyyn. Primitiivit hidastavat yhä vähemmän ja vähemmän prosentuaalisesti koneita. Itse olen samaa mieltä artikkelin kirjoittajan kanssa.

Charhan on jo nyt UNICODEn takia 2 tavua, joten se voitaisiin myös kasvattaa nelitavuiseksi. Musiikin ja muun mölön tallettaminen stringeihin ei ehkä olisi kauhean mielenkiintoista, mutta kielet, joiden takia UNICODEEN alun perin mentiinkin (itämaiset kielet) vievät enemmän tilaa kuin sen 2 tavua. Siirrytään joko täyteen neljään tavuun tai kutistetaan se takaisin länsimaiseen yhteen tavuun.

Niin, suurin osa kommenteista liittyi APIn putsaamiseen. Kannattaisin kaikkia ehdotettuja muutoksia.

No XML nyt on taas niin trendikäs juttu. Sitä voidaan käyttää IPC:hen, viesteihin, tietokantoihin.. mutta miksi sitä pitäsi käyttää pickle-tyyliseen varastointiin tai konffistiedostoihin? Niitä konffiksiakaan harvemmin lukee kuin yksi ohjelma.