Vaalit JCP EY: n jäsenille on käynnissä, ja ensi viikolla uusi komitea on käytössä. Joten se on tärkeä aika ymmärtää, jos JCP seisoo ja mitä EY: n jäsenet voivat mahdollisesti tehdä tehdä asiat paremmin JCP ja Java-yhteisö.
Yksinkertaisesti sanottuna, JCP kuuluu ajaa järjestön luoda standardit Java-kielellä ja laiturin. Ihannetapauksessa se aikoo olla yhteinen yhdistäminen kohta kaikki äänet yhteisössä. Valitettavasti se kuitenkin on vielä kaukana toteuttamisessa tämän unelman. On yli 10 miljoonaa ohjelmoijia ja tuhannet yritykset, jotka aktiivisesti käyttää Java luoda niiden tuotteita ja tarjota palvelujaan. On kuitenkin vähemmän kuin 1500 JCP jäseniä kuin se on tänään. Lisäksi vain muutama näistä 1500 on ehdottanut aktiivisesti JSR (t), osallistuminen asiantuntijaryhmiin ja antaa aktiivisesti palautetta vaatimukset. Siksi, JCP tuskin edustaa enemmistön yhteisössä.
Miksi on tärkeää, että suurin osa yhteisön osallistua aktiivisesti JCP? Standardit on järkeä vain silloin, kun ne hyväksyttiin suurella enemmistöllä. Kun kyseessä on Java se tarkoittaa,
- yritykset, jotka tekevät Java-työkalut ja tuotteet on tehdä tuotteista ja palveluista noudattavat standardeja ja
- sekä palveluntarjoajat, jotka käyttävät Java luomaan sovelluksia tarvitse omaksua ja hyväksyä se.
Nykyinen ero käy ilmi, että monet JCP luonut standardit eivät juurikaan käytössä. Esimerkiksi JSR 69 (Java OLAP Interface), joka hyväksyttiin jo kesäkuussa 2004, ei ole koskaan ollut "lopullinen versio" ja tuskin tukee OLAP myyjät tai kehittäjät tänään. Voi olla pieni ryhmä vielä käyttää sitä, mutta vaihtoehtoisia standardeja on tehnyt siitä mitään hyötyä, kun se oli vielä työn alla.
Asiat paranevat vaikka! Viime kuukausien aikana olemme nähneet osallistumisen lisääminen eri puolilta. Tämä tekee vaatimukset merkityksellisempää ja mielekäs. Kuitenkin, se ei vielä riitä, ja paljon enemmän osallistumista yhteisön on tarpeen.
Lukuun ottamatta vähemmän osallistumisesta, JCP prosessi on muita puutteita, jotka ovat seuraavat:
- Liian monta JSR (t) ei ole päästy loppuun ja edelleen epävarmuuteen yli 3 vuotta. Nämä JSR (t) joko on ryhdyttävä loppuun tai virallisesti hylätty. Joissakin tapauksissa se voi järkevää aloittaa uusi JSR (t) tarpeisiin että aikaisempi JSR voi päättää käsitellä.
- Monet JSR (t) yrittää ratkaista sama ongelma. On järkevää yhdistää joitakin vaatimukset, jos ne ovat päällekkäisiä. Se voi myös järkevää Refactor liittyvät JSR (t) joskus.
- Monet JSR (t) on huomattavasti yksinkertaistettu. Enterprise Java mutkistaa entisestään se lisäämistä monimutkaisia JSR (s). Työn yksinkertaistaa EJB erittely on hyvä menestystarina jäljitellä.
- Monet JSR (t) on pysähtynyt. Joskus standardointielin on aktiivisesti pyrkinyt luomaan normeja alueella, joka on edelleen epävakaa, ja siksi ei ole nähnyt paljon menestystä. No kohta alkaa liian aikaisin. Standardit eivät ole "varhain omaksuvat" tai "Bleeding huipputekniikkaa".
Nyt kun olemme tietoisia joidenkin alueiden työtä, let's see, jos EY: n voi mahdollisesti vaikuttaa. Ensinnäkin, EY: n tehtävänä ei ole johtaa kunkin JSR (s). JSR spec johtaa ja asiantuntijaryhmän jäsenet suorittaa ja hoitaa asioita niiden JSR. EY: n tehtävänä on hallinnoida JCP prosessin itse. Sen tehtävänä on antaa valvontaa ja tasapainoa äänestämällä puolesta tai vastaan ehdotettu JSR (t) ja helpottaa toimintaa JCP.
Siksi merkittävin panos EY voi tehdä voidaan tiivistää seuraavasti:
- Evankelioiminen - Kannusta kaikkia jäseniä JCP osallistua ja jopa ottamaan lisää vastuuta levittää sanaa laajemmalle yhteisölle. Myös työn vaatimusten hyväksymisestä sen jälkeen, kun ne ovat sijoittautuneet.
- Prosessin Demokratisointi - Työ lieventämiseksi epätasapaino yritysten vaikutusvalta ja yksittäisiä jäseniä. Annetaan muutama uudempi menetelmät - esimerkiksi, jotta muutos spec lyijyn (ei välttämättä saman yrityksen) puolivälin tarvittaessa, etenkin jos asiat ovat tällä hetkellä menossa pieleen, on kyseisen JSR.
- Aktiivinen yhteistyö - ehdottaa ja tukea yhteistyötä muun liittyvät JSR (t). Työ refactoring olemassa JSR (t) tarvittaessa.
- Tulevasta suunnasta - aktiivisesti tunnistamaan alueet, joilla standardoinnin avulla Java ottaa sujuvasti kurssin tulevaisuuteen ja edistää osallistumista jäsentä työskentelee näillä alueilla. Esimerkiksi JSR 292 (tukeminen dynaamisesti kirjoitetut kielten Java Platform) on hyvä tapa edistää kehitystä Java.
Kun nyt sinulla on tunne, mitä ajattelen. Paljon on sanottu ja tehty, mutta lopetan tähän ja alkaa tehdä minun vähän tehdä JCP tehokkaampi organisaatio.
Aloitan valittamalla teidät kaikki tulevat osallistua JCP. Niille, jotka eivät vielä ole sen jäseniä, tulkaa liittyä ja tee merkki. Niille, jotka ovat jo jäseniä, ole hyvä äänestykset (https: / / www.jcpelection2008.org/jcp/election_ballot) ja tee läsnäolo.
0