Valg til JCP EF-medlemmer er i gang, og i næste uge et nyt udvalg vil være på plads. Så det er en vigtig tid til at forstå, hvor JCP står, og hvad EF-medlemmer kan eventuelt gøre for at gøre tingene bedre for JCP og Java samfund.
Præciserede blot, JCP er medlem drevet organisation til at skabe standarder for Java-sproget og platformen. Ideelt set, den har til hensigt at være den fælles sammenlægning punkt for alle stemmer i samfundet. Men desværre er det stadig langt fra at realisere denne drøm. Der er over 10 millioner programmører og tusindvis af virksomheder, der aktivt bruger Java til at skabe deres produkter og levere deres tjenester. Men der er mindre end 1500 JCP medlemmer, som det ser ud i dag. Desuden er der kun en håndfuld af disse 1500 aktive i at foreslå JSR (r), der deltager i ekspertgrupper eller yde en aktiv feedback på specifikationerne. Derfor JCP næppe udgør et flertal af samfundet.
Hvorfor er det vigtigt, at et flertal af samfundet tager aktivt del i JCP? Standarder giver kun mening, når de er vedtaget med stort flertal. I tilfælde af Java det betyder,
- virksomheder, der gør Java-værktøjer og produkter, der skal gøre deres produkter og tilbud er i overensstemmelse med de standarder og
- udviklere og udbydere, der bruger Java i at skabe applikationer behov for at vedtage og acceptere det.
Den nuværende hul fremgår tydeligt af det faktum, at mange JCP skabt standarder er næppe i brug. For eksempel JSR 69 (Java OLAP Interface), som blev godkendt tilbage i juni 2004, aldrig har haft en "endelig release" og er næppe støttes af OLAP-leverandører eller udviklere i dag. Der kan være en lille gruppe stadig bruger det, men alternative standarder har gjort det ubrugeligt fra det tidspunkt, var det stadig at blive oprettet.
Tingene er bedre selv! I løbet af de sidste par måneder har vi oplevet en øget deltagelse fra alle hjørner. Dette gør specifikationer mere relevant og meningsfuld. Men det er ikke nok endnu, og meget mere deltagelse fra lokalsamfundet er påkrævet.
Bortset fra mindre deltagelse, JCP processen har flere mangler, der er som følger:
- Alt for mange JSR (r) ikke er nået til afslutningen og forblive i limbo i over 3 år nu. Disse JSR (r) enten skal tages til ende eller officielt opgivet. I nogle tilfælde kan det være fornuftigt at starte nye JSR (r) for at løse de behov, som tidligere JSR måtte have besluttet at behandle.
- Mange JSR (r) forsøge at løse det samme problem. Det giver mening at fusionere nogle specifikationer, hvor de overlapper hinanden. Det kan også være fornuftigt at Refactor relaterede JSR (r) til tider.
- Mange JSR (r) skal drastisk forenklet. Enterprise Java kompliceres yderligere vil tilsætning af komplicerede JSR (r). Arbejdet for at forenkle EJB-specifikationen er en god succeshistorie at efterligne.
- Mange JSR (r) skal stå. Undertiden standardiseringsorgan har aktivt forsøgt at skabe standarder på et område, som stadig er ustabil, og har derfor ikke set meget succes. Intet punkt starter for tidligt. Standarder er ikke om "early adopters" eller "bleeding edge teknologi".
Nu, hvor vi er opmærksomme på nogle områder at arbejde på, lad os se, hvor EF potentielt kunne bidrage. For det første den rolle, som EF er ikke til at styre hver enkelt af de JSR (r). Den JSR spec bly og ekspertgruppens medlemmer køre og lede af deres respektive JSR. EU's rolle er at håndtere JCP processen selv. Dens opgave er at sikre kontrol og balance ved at stemme for eller imod forslaget JSR (r) og lette arbejdet i JCP.
Derfor er det mest betydningsfulde bidrag til EF kan yde, kan sammenfattes som følger:
- Evangelisering - opfordre alle medlemmer af JCP for at deltage og selv påtage sig yderligere ansvar for at sprede ordet til de større samfund. Også arbejde med standarder vedtaget, så snart de er etableret.
- Proces Demokratisering - Arbejde for at mindske ubalancen mellem virksomhedernes indflydelse og individuelle medlemmer. Tillad et par nyere processer - for eksempel ændre på spec bly (ikke nødvendigvis fra samme firma) midtvejs, hvis det kræves mulighed, især hvis tingene er ved at gå galt i denne særlige JSR.
- Aktivt samarbejde - foreslå og støtte samarbejde mellem beslægtede JSR (r). Arbejdet med refactoring eksisterende JSR (r), hvor det er påkrævet.
- Future Direction - aktivt på at identificere områder, hvor standardisering vil hjælpe Java tage en glat løbet ind i fremtiden og tilskynde til deltagelse fra medlemmer, der arbejder i disse områder. For eksempel JSR 292 (Støtte Dynamically Maskinskrevet Sprog på Java Platform) er et godt initiativ for at fremme udviklingen af Java.
Nu har du en fornemmelse af, hvad jeg tænker. Meget skal siges og gøres, men jeg vil stoppe her og begynde at gøre mig lidt at gøre JCP en mere effektiv organisation.
Lad mig starte med at appellere til jer alle til at komme deltage i JCP. For dem, der endnu ikke er medlemmer, kan du komme deltage i og gøre dit varemærke. For dem, der allerede er medlem, kan du afgive din stemme (https: / / www.jcpelection2008.org/jcp/election_ballot) og gør din tilstedeværelse mærkes.




























































0