Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Java Committee Process - How to make it better?
URL: JCP
At 10:25 AM on Nov 30, 2007, Jean-Marie Dautelle
wrote:
Fresh Jobs for Developers Post a job opportunity
This is a good opportunity for the community to tell us what they think of the JCP and how it could be improved/changed. Feel free to speak your mind (as long it is not insulting) and come up with great ideas (as Javalobby readers often do)!
43 replies so far (
Post your own)
Re: Java Committee Process - How to make it better?
Two words : PUBLIC debate.Public and open mailing lists (or even better - forums), public interim releases and public(and open) meetings.
Re: Java Committee Process - How to make it better?
> Two words : PUBLIC debate.>
> Public and open mailing lists (or even better -
> forums), public interim releases and public(and open)
> meetings.
I would like that too! But in practice companies representatives avoid taking any kind of official (less along public) position. For example, we will discuss "Android" in an "unofficial/informal" manner
-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: Java Committee Process - How to make it better?
> I would like that too! But in practice companies> representatives avoid taking any kind of official
> (less along public) position.
Forgive my snark here, but that is their own problem. The fact is, in spite of the title here, JCP stands for *community*, not committee, and not corporate. If said companies want to be a part of the community, then they can participate in a community centric manner. If they are unable or unwilling to designate someone who can speak publicly on their behalf, then they have no business participating in a "Community Process."
Re: Java Committee Process - How to make it better?
I 2nd public meetings and open forums its COMMUNITY not CommittersRe: Java Committee Process - How to make it better?
Hi Jean-Marie,Should be an interesting meeting, to say the least
Certainly, there are a number of things that must be addressed to keep JCP meaningful.
I think, first and foremost, we need more involvement from individuals and small companies. The JCP has been largely dominated by large corporations and their agenda. That's not say big players can't have a voice but that in the past the playing field was completely tilted in their favor.
Next, the JCP needs to be made more compatible with the open source model and development processes. In particular, development of implementations of JSRs in the open must be possible even if they don't pass the TCK during development phase. Also, proprietary components and NDAs should get a long hard look - they are very problematic.
Finally, participation on EGs should be more open ... the current process of not allowing valuable opinions to join an EG after it has formed shuts out a lot of good input and gives the appearance of elitism.
Good luck!
-- Terrence
Re: Java Committee Process - How to make it better?
> I think, first and foremost, we need more involvement> from individuals and small companies. The JCP has
> been largely dominated by large corporations and
> their agenda.
Agree, but don't forget "you" are the ones electing the representatives (with a propensity to favor companies instead of individuals).
> Next, the JCP needs to be made more compatible with
> In
> particular, development of implementations of JSRs in
> the open must be possible even if they don't pass the
> TCK during development phase. Also, proprietary
> components and NDAs should get a long hard look -
> they are very problematic.
You have an excellent point here (and it will be discussed).
> Finally, participation on EGs should be more open ...
> the current process of not allowing valuable opinions
> to join an EG after it has formed shuts out a lot of
> good input and gives the appearance of elitism.
Good point (I will bring it to the table).
-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: Java Committee Process - How to make it better?
So, is it really *your* barn? How is the meeting going to work? Is there a set agenda?-- Terrence
Re: Java Committee Process - How to make it better?
I've been actively following JSR296, the Java Application Framework, and I think what Hans has done is perfect. An open mailing list, an open source repository, frequent updates and ruthlessly focusing on the right balance between extensibility and simplicity is a good start for any JSR.Quite frankly, I don't think it is possible to anticipate the design of any JSR without running into a bunch of unforeseen problems. The JCP can focus on three things to make sure that APIs run into these problems early.
1. Make sure at least one person on the JSR has spent considerable time solving problems in the JCP's domain.
2. If there is an open source solution that already covers the JSR, then serious consideration should be made on integrating it. JSR47, the Logging API, is probably one of the JCPs most shameful moments. The product of which was an API totally inferior to Log4J. Instead of ridding Java of a plethora of Logging APIs it only served to further fragment the domain.
3. Do all JSRs like JSR296. Regular real-world testing and developer feedback on mailing lists should greatly improve the quality of first-release JSRs.
Regards,
Brendon McLean.
Re: Java Committee Process - How to make it better?
> I think, first and foremost, we need more involvement> from individuals and small companies. The JCP has
> been largely dominated by large corporations and
> their agenda. That's not say big players can't have
> a voice but that in the past the playing field was
> completely tilted in their favor.
Frequently, the big hitters will register on the expert group simply because they can. These posts then serve largely as observers roles rather than active participants, only actually chipping in when something obviously affects them.
In reality, JSRs are likely to benefit most from a few highly motivated individuals mostly working in their own time for their own reasons. These types of individuals have benefited Hans's JSR more so than most of the people on the EG.
Open it up and you can't go wrong.
Re: Java Committee Process - How to make it better?
> > Two words : PUBLIC debate.> >
> > Public and open mailing lists (or even better -
> > forums), public interim releases and public(and
> open)
> > meetings.
>
> I would like that too! But in practice companies
> representatives avoid taking any kind of official
> (less along public) position. For example, we will
> discuss "Android" in an "unofficial/informal" manner
> ;)
Well, then we have an explanation for the endless stream of BS coming from the JCP process, and why it takes 4+ years and 3+ versions to arrive at something barely usable and decent. EJB, JSF, Logging, XML, Web Services, 3D and what not. It's not a coincidence that most of the innovation in the Java arena is happening outside the JCP umbrella.
At least don't be hypocrites and call it Java Corporate Process, which is what it is. The "C" in JCP stands for Community as much as Microsoft's OOXML means that Microsoft favours open standards.
By the way, your very own JSR is not open.
Re: Java Committee Process - How to make it better?
> Frequently, the big hitters will register on the> expert group simply because they can. These posts
> then serve largely as observers roles rather than
> active participants, only actually chipping in when
> something obviously affects them.
>
> In reality, JSRs are likely to benefit most from a
> few highly motivated individuals mostly working in
> their own time for their own reasons. These types of
> individuals have benefited Hans's JSR more so than
> most of the people on the EG.
I've had pretty much the same experience on JSR-310, Date and Time. There are basically no private EG mails, just what is public. And much useful discussion has come from that - a true, interested, EG.
Re: Java Committee Process - How to make it better?
I was going to reply here, but I had way too much to say:http://www.jroller.com/scolebourne/entry/is_the_jcp_broken
Re: Java Committee Process - How to make it better?
> So, is it really *your* barn? How is the meeting> going to work? Is there a set agenda?
Yes, it is neutral territory - perfect for what the others EC members call: "barnstorming"
-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: Java Committee Process - How to make it better?
[To Delete - Duplicate]-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!