apache / apache/netbeans

Additional features for working with `Logger`s

Open
#8,240 17 comments 1 reaction 0 assignees View on GitHub
hints Java kind:feature
Dominant language
Java
Stars
3.1k
Forks
935
Avg merge
2d 3h
Merged PRs (30d)
17

Description

### Description

With #8253 merged, most of the things brought up in the original feature request are handled (see below). There's still some remaining things to consider.

- Create an UI panel for additional logger configuration including at least
1. `BaseLoggerName`: defaults to `LOG`.
2. `logger initialization expr`: defaults to either
`System.getLogger(class-FQN)` or `Logger.getLogger(class-FQN)`
depending on (3).
3. `Preferred logger`: System.logger or JUL.
This option is currently found in `surround with try catch` hint.

Where to put this UI?
1. `Tools > Options > Java > Java Logging`
2. `Tools > Options > Java > Java`
3. Somewhere in hints?
- Templates
1. new templates like `slog` for System.Logger vs `log` for JUL.
2. Modify available logging templates depending on logger preference.
Don't know how/if this is possible. Maybe swap in a different set of
templates depending on preferred logger.
- Hints to convert JUL to System.Logger; use primarily for bulk `Inspect & Transform`.
- Any logger configuration should be per project possible.
Aside: IIUC, either almost everything is per project or nothing is. Would be nice if could
select things that should be per project. That's certainly out of scope for this.

Other notes

- The all-caps logger name, `"LOG"`, is a violation of some coding standards including the original java coding standards and Google's coding standard. This is because a logger has mutable state.
- https://stackoverflow.com/questions/1417190/should-a-static-final-logger-be-declared-in-upper-case
- https://web.archive.org/web/20120911192801/developers.sun.com/sunstudio/products/archive/whitepapers/java-style.pdf
- https://google.github.io/styleguide/javaguide.html#s5.2.4-constant-names
- There are comments in this feature request about handling 3rd party loggers.
If/when that happens, good to seemlessly integrate in an existing UI.

---
### Old notes that lead to #8253

This affects (the hints are under `Options > Editor > Hints > Java`)
- `Insert Code` action/dialog, aka `Generate > Logger...`
- `Surround with try-catch` hint, under `Error Fixes` hints
- `Logging` hints

There might be other items that should be added to the above list.

A key question is how to specify which Logger, between `System` and `java.util`, to use. Could
1. Add a new option somewhere; like a new tab under `Tools > Options`, examples
- `Tools > Options > Java > Java Logging`
- `Tools > Options > Java > Java` for future looking
2. Extend list at `Tools > Options > Editor > Hints > Java > Surround with try-catch`
with `Use java.lang.System.Logger`

((2.) included in #8253)

Doing (2) above is the simplest. I'd be inclined to put it above `java.util` and have it check-marked by default. Consider that in most instances at run-time, there is little practical difference from the current behavior. These options could be used by `Generate > Logger...`, and in other cases as needed, to select which of the two loggers to use to initialize the logger. If this is acceptable, I volunteer.

A few additional things that could be done

A "use existing logger" option for `Surround with try-catch`. (included in #8253)

For reference, here the current and proposed code.

- Current
- `Generate>Logger...`
`private static final Logger LOG = Logger.getLogger(Mavenproject5.class.getName());`
- `Surround with try-catch`
`Logger.getLogger(Mavenproject5.class.getName()).log(Level.SEVERE, null, ex);`

("proposed" included in #8253)
- Proposed (when option is for System.Logger)

- `Generate>Logger...`
`private static final Logger LOG = System.getLogger(Mavenproject5.class.getName());`

- `Surround with try-catch`
- `System.getLogger(Mavenproject5.class.getName()).log(Level.ERROR, null, ex);`
- `LOG.log(Level.ERROR, null, ex);` // If "use existing logger" implemented

Additional `Generate>Logger...` options for consideration
- specify name of generated logger, e.g. "logger" instead of "LOG"
- expression to use to init logger, e.g. "Utils.getLogger()" vs System.getLogger(...)

With these options, a generated logger would look like
```
private static final Logger logger = Utils.getLogger();
```
---
The following text is added (note the dates) after this feature request opened.

#### After #8253

Added 2025-02-26

With #8253 (in review) in place these are direct follow ups which could be useful.

- Hints to convert JUL to System.Logger; use primarily for bulk `Inspect & Transform`.
- Code templates for `System.Logger`; fewer templates are needed.

#### Additional features

Added 2025-02-16

- Hints that convert from `JUL` to `System.Logger`. Use with `Refactor > Inspect and Transform...`.

#### Other existing NetBeans logger stuff

Added 2025-02-16

_If there's missing things, LMK and I'll include them here_

("1. `Logging` hints category" included in #8253)
1. `Logging` hints category
```
Logger declaration is not static final
Multiple loggers
No loggers
String concatenation in logger
and new fix available: convert string concatenation to Supplier
```

2. `Code Templates`
```
log, logb, logbp, logbps, loge, logp, logr, logrb
```

### Use case/motivation

Provide access to newer, as of Java-9, capability

### Related issues

_No response_

### Are you willing to submit a pull request?

Yes

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the existing Generate > Logger..., Surround with try-catch, Logging hints, and Code Templates entry points, along with the proposed Tools > Options > Java locations. Done requires an agreed scope and implementation for the remaining logger configuration, templates, conversion hints, and per-project behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.