Valget for JCP EC medlemmer er i gang, og innen neste uke en ny komité skal være på plass. Så det er en viktig tid å forstå hvor JCP står og hva EF-medlemmer kan muligens gjøre for å gjøre ting bedre for JCP og Java samfunnet.
Enkelt sagt, er JCP medlem drevet organisasjon til å opprette standarder for Java-språket og plattformen. Ideelt hensikt det å være felles aggregering punktet for alle stemmene i samfunnet. Dessverre så er det fremdeles langt unna å realisere denne drømmen. Det finnes over 10 millioner programmerere og tusenvis av bedrifter som aktivt bruker Java for å lage sine produkter og leverer sine tjenester. Det er imidlertid mindre enn 1500 JCP-medlemmer som det står i dag. I tillegg, bare en håndfull av disse 1500 er aktive i å foreslå JSR (s), deltakelse i ekspertgrupper eller gir aktiv tilbakemelding på spesifikasjonene. Derfor representerer JCP knapt flertall av fellesskapet.
Hvorfor er det viktig at et flertall av fellesskapet ta aktivt del i JCP? Standarder gir mening bare når de er vedtatt med stort flertall. Når det gjelder Java det betyr,
- selskaper som gjør Java-verktøy og produkter trenger å gjøre sine produkter og tilbudene i samsvar med standarder og
- utviklere og tjenesteleverandører som bruker Java i å lage programmer trenger å adoptere og akseptere det.
Den nåværende gapet er tydelig fra det faktum at mange JCP laget standarder er knapt i bruk. For eksempel JSR 69 (Java OLAP Interface), som ble vedtatt tilbake i juni 2004, har aldri hatt en "final release" og er neppe støttes av OLAP leverandører eller utviklerne i dag. Det kan være en liten gruppe fortsatt bruker det, men alternative standarder har gjort den ubrukelig fra den tiden det var fremdeles under utforming.
Ting er bedre selv! De siste månedene har vi sett en økt deltakelse fra alle hjørner. Dette gjør spesifikasjoner mer relevant og meningsfull. Imidlertid er det ikke nok ennå, og mye mer deltakelse fra samfunnet er nødvendig.
Bortsett fra mindre deltakelse, har JCP prosessen ytterligere svakheter som er som følger:
- For mange JSR (e) ikke har nådd ferdigstillelse og være i limbo i over 3 år nå. Disse JSR (e) enten må tas til ferdigstillelse eller offisielt forlatt. I noen tilfeller kan det være fornuftig å starte nye JSR (r) for å dekke behov som tidligere JSR har besluttet å adresse.
- Mange JSR (e) prøve å løse det samme problemet. Det er fornuftig å slå sammen noen spesifikasjoner hvor de overlapper hverandre. Det kan også være lurt å refactor relaterte JSR (s) noen ganger.
- Mange JSR (e) må være drastisk forenklet. Enterprise Java kompliseres ytterligere vil tillegg av kompliserte JSR (s). Arbeidet med å forenkle EJB spesifikasjonen er en god suksesshistorie å etterligne.
- Mange JSR (e) må være stoppet. Noen ganger standardene kroppen har aktivt forsøkt å opprette standarder i et område som fremdeles er volatile, og har derfor ikke sett mye suksess. Ingen vits å starte for tidlig. Standarder er ikke om "tidlig adoptert" eller "blødning teknologi".
Nå som vi er klar over noen av områder å arbeide på, la oss se hvor EU kan potensielt bidra. For det første er rollen til EU for ikke å behandle hver av JSR (e). Den JSR spec bly og ekspert gruppemedlemmer kjøre og håndtere saker av sine respektive JSR. EF rolle er å håndtere JCP prosessen selv. Sin plikt er å gi sjekker og balanserer ved å stemme for eller mot forslag JSR (r) og tilrettelegge for arbeid i JCP.
Derfor følger det viktigste bidraget i EU kan gjøre kan oppsummeres som:
- Evangelisme - oppfordrer alle medlemmer av JCP å delta og selv ta på seg ekstra ansvar for å spre ordet til det større samfunnet. Også arbeide med standarder adopsjon når de er etablert.
- Process Democratization - Arbeide for å redusere ubalansen mellom bedriftens påvirkning og individuelle medlemmer. Tillate noen nyere prosesser - for eksempel tillater endring av spec lead (ikke nødvendigvis fra samme selskap) mellomlang sikt hvis nødvendig, spesielt hvis ting er på gang forkjært i det bestemte JSR.
- Aktiv Collaboration - Foreslå og støtte samarbeid mellom relaterte JSR (s). Arbeid på refactoring eksisterende JSR (e) der det er nødvendig.
- Future Direction - Aktivt identifisere områder der standardisering vil hjelpe Java ta en jevn kurs inn i fremtiden og oppmuntre til deltakelse fra medlemmer som arbeider i slike områder. For eksempel JSR 292 (Hjelpemiddel Dynamisk skrevet språk på Java Platform) er et godt initiativ for å forenkle utviklingen av Java.
Nå har du en følelse av hva jeg tenker. Mye må sagt og gjort, men jeg skal stoppe her og begynne å gjøre meg litt for å gjøre JCP en mer effektiv organisasjon.
La meg begynne med å appellere til alle dere til å komme delta i JCP. For de som ennå ikke er dens medlemmer, kan du komme med på og gjøre ditt merke. For dem som allerede er medlemmer, kan du avgi stemme (https: / / www.jcpelection2008.org/jcp/election_ballot) og lage din tilstedeværelse filt.
0