Too many questions and concerns on java.util.logging package

@Kirk I couldn’t have said it better

I have a better question, why is the design upside down? Why were levels used instead of digitial taxonomy?

And using a verb as a name does break the semantics of usage. What I want is a Log to which a I read from and write to. Methods are where the action is

Disclaimer: I’m a C++ programmer and have no experience with java.util.logging. That said, I still think I’m right

>VERB: Inflected forms: logged, log·ging, logs

Since just about any verb can be turned into a gerund, most dictionaries aren’t going to call out that fact in every entry. It doesn’t mean it can’t be a gerund (and thus a noun) in the right usage.

>It breaks the semantics of usage.

I disagree. The whole point of making package, class, and variable names nouns and method names verbs is to easily and unambiguosly tell where the action is (in the method). Using “log” as an example, I can very easily see somebody creating a method with the name of “log()” (a verb in this context) that inserts a vlog record into some sort of repository. Given this common verb usage of “log”, it become a less than ideal choice for a package name. On the other hand, “logging” is in fact an unambiguous noun (gerund) in this context. I can’t possibly imagine anybody creating a method called “logging()”. It’s the wrong tense as a verb. You don’t logging something, you log it. Doing so is the act of logging (a noun in this context).

@Brian In that context, yes. But in our context it is a verb. Please see below.

@Alexander
Bartleby says:
VERB: Inflected forms: logged, log·ging, logs
https://www.bartleby.com/61/86/L0228600.html

@Michael
> I agree. However, I don’t see it as a big problem.
It breaks the semantics of usage.

> Have you seen the other Java API’s? This one is pretty nice compared to most of the rest of them.

Seen quite a lot actually since 1996
I wasn’t intending on an ugliness contest, but seriously which ones do you find uglier?

> I’m no Einstein and it took me about 3 seconds to realize the relationsship based on the current doc.

Care to explain you line of reasoning?

> You have the exception and the message. What else do you need?

The problem is to process errors pprogramatically, I would have to subclass ErrorManager. I expected a default implementation would at least provide a means to access the data. Is that too much to ask?

> I don’t see the need here. Sounds like you want to peek into the encapsulated data.

Again the question is usability. A common usage of MemoryManager would be to capture Exceptions and process them later at leisure. At that point I need some way to be able to access the data, which having to subclass. It is not a question of breaking encapsulation. The class does nothing with the data, other then to pass it to another handler. This is a dumb implementation. Looging is about accessing the logged data at the very core. The API fails consistently there.

>Why is the package name a verb? Package names
>should be nouns as can be seen in the rest of the
>API. Why did the author suddenly decide on a verb?

It’s hard to say when it’s not used in the context of a sentence, but one could argue that “logging” is a gerund (which is in fact a noun). See https://www.bartleby.com/64/C001/028.html

logging

noun : the work of cutting down trees for timber

>…Package names should be nouns…
I agree. However, I don’t see it as a big problem.

>How is Logger.getLogger(String name) related to LogManager.getLogManager().getLogger(String name) ?

As you may know, the former is a convenience method for the latter. There should be a link in the JavaDoc. However, I think it’s pretty clear. I’m no Einstein and it took me about 3 seconds to realize the relationsship based on the current doc.

And I like the convenience method. I like that I don’t need to import 2 classes.

>Why is Logger.getLogManager() required when we have LogManager.getLogManager()?

Yeah, I kinda agree on this one.

>Why isn’t a ErrorManager provided which can be asked about the errors?

You have the exception and the message. What else do you need?

>Why doesn’t MemoryHandler have no method to fetch LogRecord’s? To access a LogRecord there is no simpler way but to create a LogHandler yourself!

I don’t see the need here. Sounds like you want to peek into the encapsulated data. Perhaps you are looking for more functinality than just plain logging; You want to query the logging data too. That’s really beyond the scope of what a logging API *must* provide to the runtime environment.

Have you seen the other Java API’s? This one is pretty nice compared to most of the rest of them.