There's a big philosophical issue here about whether APIs should be composed
only of interfaces or whether concrete classes are appropriate. I'm going to
try not to get into that...
I'm not really a java.util.logging expert, but my understanding is that it was
designed to allow different implementations to extend or customize the
behavior. You can subclass Logger (although it's not as easy as it should be),
and you can provide your own LogManager that hands out your subclass of Logger.
Formatters and Handlers provide a great deal of flexibility in how log messages
are formatted and where they're written or stored.
One of the key questions here is, in the context of an application server, how
much of this is in the domain of the application and how much is in the domain
of the application server?
I've been assuming that applications mostly only need to produce log messages,
and thus only need to use the Logger class.
I've been assuming that the application server is responsible for formatting and
storing the log messages, rotating log files, providing ways to view or search
the log files, etc. These are largely things we haven't tried to standardize in
Java EE. And these are things that the application server administrator will
configure for all applications running in the server.
If you believe that applications should be managing log files themselves, with
each application in the server using different log files with a different
format, there are probably bigger problems with using java.util.logging.
Antonio Goncalves wrote on 09/11/12 05:50:
> 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
> <mailto: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
>> <mailto: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
>>> <mailto: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>