Thanks, that goes along the lines of some JCP.next related discussions here
today.
E.g. that a TCK and Spec often only get tested well enough if more than one
implementation exists. Take CDI with its RI and at least 2 others
(OpenWebBeans, or a Caucho implementation, I believe there might be at
least one more) that is something, JUL never offered due to the design as
Antonio mentions again here.
Werner
On Tue, Sep 11, 2012 at 2:50 PM, Antonio Goncalves <
antonio.goncalves_at_gmail.com> wrote:
> Again, I have nothing against JUL, I try to use it each time I can in
> projects, but it's closer to zero (because projects already use other
> logging frameworks). So my proposal to create a standard has nothing with
> "I don't like it" or "It's too hard" but more "people don't use it, so
> let's ask ourselves why".
>
> I see several technical reasons : JUL is made of classes, no interfaces,
> so there is no way to change the implementation. If people didn't like
> the default JUL implementation (because of any kind of reasons), they would
> be able to build new implementations based on the interfaces. It's not the
> case. Logs make me think of XML manipulation : it's vital, it's on every
> project. So why don't we have a separate JSR that handles it (like JAXP and
> so on) ? JUL hasn't changed since day one... but the world is changing. If
> we had a JSR we would have had JUL 1.0, JUL 1.1, JUL 2.0 with a RI, a TCK
> and several implementations (LOG4J, SLF4J...). Look at JCache. At least
> there is a JSR. It can be dormant but one day reappears and
> gets completely rewritten following the JCP rules.
>
> I agree with you that sometimes developers prefer to write their own
> frameworks rather than changing the existing one. But because of the
> structure of JUL (classes, no interface) and the fact that there is only
> one implementation (no JSR) there is not much developers can do if they are
> not happy. What not do like Date/Tim JSR ? Calendar/Date in Java doesn't
> suit every use case, let's do something different. Developers have at least
> the choice to use Dates in the JDK or one in JSR 310 which are (will be)
> standard. I don't know how Steve Colbourne handled it, but I'm sure that
> trying to radically change java.util.Date in the JDK was much more
> difficult (or impossible) than creating a JSR. So I really don't feel like
> talking to the JDK team would help. If you want me to, I will, but I don't
> see how we could change JUL (we would deprecate most of the API to create a
> new one in the same package, not worth it).
>
> I want to stress out that I'm still receiving many emails, comments and
> tweets about this Logging API spec. So it really looks like the community
> has the same struggles with the dozens of frameworks out there and want to
> do something more standard. A Logging API with a set of interfaces, a RI
> and a TCK would really help (and who knows, JUL would maybe implement it).
>
> Antonio
>
> On Mon, Sep 10, 2012 at 9:53 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
>
>> It's always easier to create something new that meets exactly your own
>> needs, with no requirement to be compatible with anything. But if you want
>> Oracle to support a new standard API for logging, I think you're going to
>> need to convince us that the existing standard API for logging can't be
>> improved to meet your needs.
>>
>> "I don't like it" is not a reason.
>>
>> "It's too hard" is not a reason.
>>
>> "No one uses it" is not a reason.
>>
>> "That's not the way I would've done it" is not a reason.
>>
>> The existing API wasn't created in a vacuum - it was created by a group
>> of experts from many companies who had experience with logging. Maybe
>> we've learned a lot about logging since then. If so, convince us.
>>
>> My impression is that most of the existing logging frameworks were
>> created by someone who wanted something more or different out of logging
>> than they could get with java.util.logging, and since they couldn't change
>> java.util.logging they built something alongside it or on top of it. Well,
>> what if you *could* change java.util.logging? Could you make it do what
>> you think it should do?
>>
>> Either way, the place to make your argument is probably in the OpenJDK
>> project.
>>
>>
>> Antonio Goncalves wrote on 09/09/12 09:51:
>>
>> Hi Bill,
>>
>> As for JUL I won't go to any debat. I was the first one to push it on
>> my project back in 2003/2004. Since then, I've never seen it used (except
>> in GlassFish). So I'm not saying it's broken, I'm saying that nobody uses
>> JUL, so let's use something else... but standard. A bit like JodaTime which
>> is preferred to the Calendar/Date API. And, to be honest, I think it will
>> be much more difficult (or impossible) to change JUL in the JDK than
>> creating something new (a bit like changing Calendar/Date, rather use 310).
>> Hopefully, when the JDK becomes modular, JUL will be a module we can skip.
>>
>> Like you I think that being a spec lead is hard work (that's why I
>> won't do it), that's why I asked you if Oracle would support this effort.
>> For what I've seen in my blog and Tweets, it looks like there are many
>> people out there who would be interested in taking the job. But because
>> it's so much hard work, an official support would help. Like Werner
>> mentioned, there are a few JSRs out there that have been pushed by
>> individuals (Date/Time is one of them). But I've seen that maybe some
>> companies could also lead this JSR... who knows.
>>
>> I really think that people are waiting for a standard Logging API and
>> trying to enhance JUL is risky and would be very time consuming (as people
>> would disagree with each other, as they've been doing with all the logging
>> frameworks out there for so long). So if a bunch of experts are ready to
>> seat around the table and create a new JSR, why not ?
>>
>> Antonio
>>
>> On Fri, Sep 7, 2012 at 9:47 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
>>
>>> 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>
>>>
>>>
>>>
>>
>>
>> --
>> 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>
>>
>>
>>
>
>
> --
> 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>
>