Bill,
Thanks a lot for the input.
I can't entirely speak for Antonio, but one aspect of what he does seem to
hope is something more along the lines of SLF4J. A far more flexible and
versatile aporoach than, sorry to say java.util.logging.
As for JSRs lead by Individuals, Academics (like Doug Lea) or lose groups
of people neither affiliated with Oracle or Red Hat (the two companies with
by far the largest contribution to JSRs) how about JSR 310, aiming at
another java.util problem child, and hopefully making it into Java 8
Or the 2 winners of JCP Awards 2010, JSR 321 and 331, both lead by
Individuals or smaller (Academic) entities.
CDI foundation JSR 330 was also lead by Individual Member Bob Lee, though
when he started it he still worked for Google.
We haven't seen any JUG or its Representative effectively leading a JSR as
Spec Lead, but I also won't leave out the JUG Initiatives like Adopt-a-JSR,
which helped JSRs, not just some I mentioned already. Thus there is no
doubt, should somebody like Antonio succeed in getting such JSR created,
those would also support it and add recources where they should be as
scarce as 310 Spec Lead Stephen Colebourne found them at times.
I won't go further into the "Transplant JSR" proposal, as we still
negotiate these tools in the EC/358EG, but the aim expressed by former
Intel EC Rep Wayne Carr was to avoid "Reinventing the Wheel" and allowing
established or otherwise standardized technologies to enter the JCP more
easily.
Kind Regards,
Werner
Am 07.09.2012 21:47 schrieb "Bill Shannon" <bill.shannon_at_oracle.com>:
> I'm not sure I fully understand what you're proposing...
>
> If you're proposing a new logging framework to replace java.util.logging,
> then, well, I can't speak for the JDK team but I think you need to engage
> with them in the OpenJDK project to see what they would think of that. I
> have a hard time believing that java.util.logging is so broken it can't be
> made better and has to be replaced.
>
> If you're proposing something specific to Java EE that works with or
> layers on java.util.logging, then I need to understand it better before I
> can support it.
>
> In either case, you should note that the track record of individuals
> delivering successful JSRs through the JCP is very poor. Delivering a JSR
> is a significant amount of work, usually much more work than any single
> person can do. I would be very skeptical of any individual, or even some
> loosely affiliated open source project, being able to deliver a JSR
> successfully. It requires a lot of hard work that isn't just the "fun"
> part of writing the code. It's not impossible, but there aren't many
> existence proofs. Oracle "supporting" the JSR is not going to change
> that. It's not (just) about motivation or commitment, it's about resources.
>
>
> Antonio Goncalves wrote on 09/07/12 05:29:
>
> Hi everybody,
>
> Just to let you know that my blog has been viewed by 1401 people in the
> last 24 hours and I've received many tweets and comments... mostly by
> developers who struggle on a day to day basis with logs.
>
> Bill, Linda, shall we go a little bit further and have Oracle clearly
> support this effort ? I think individual developers are scared to put their
> finger into the JCP : it's much easier to create a GitHub repository and
> create a new/funny logging framework than fill JSPA forms to become spec
> lead. If you think this Logging API JSR is important (inside Java EE 7 or
> not, that's not the issue now, but just to have a JSR), then it would
> encourage developers if you would publicly (blog ? tweet ?) support the
> idea and encourage them to become spec lead.
>
> What do you think ?
>
> Antonio
>
> On Fri, Sep 7, 2012 at 11:04 AM, Werner Keil <werner.keil_at_gmail.com>wrote:
>
>> ...will be, it hasn't happened yet, sorry.
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter<http://twitter.com/agoncal>|
> LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org> |
> Devoxx France <http://www.devoxx.fr>
>
>
>