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
BaseLoggerName: defaults to LOG.
logger initialization expr: defaults to either
System.getLogger(class-FQN) or Logger.getLogger(class-FQN)
depending on (3).
Preferred logger: System.logger or JUL.
This option is currently found in surround with try catch hint.
Where to put this UI?
Tools > Options > Java > Java Logging
Tools > Options > Java > Java
- Somewhere in hints?
-
Templates
- new templates like
slog for System.Logger vs log for JUL.
- 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.
- 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
- 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
- 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)
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.
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)
-
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<String>
-
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
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
BaseLoggerName: defaults toLOG.logger initialization expr: defaults to eitherSystem.getLogger(class-FQN)orLogger.getLogger(class-FQN)depending on (3).
Preferred logger: System.logger or JUL.This option is currently found in
surround with try catchhint.Where to put this UI?
Tools > Options > Java > Java LoggingTools > Options > Java > JavaTemplates
slogfor System.Logger vslogfor JUL.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
"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.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 Codeaction/dialog, akaGenerate > Logger...Surround with try-catchhint, underError FixeshintsLogginghintsThere might be other items that should be added to the above list.
A key question is how to specify which Logger, between
Systemandjava.util, to use. CouldTools > Options, examplesTools > Options > Java > Java LoggingTools > Options > Java > Javafor future lookingTools > Options > Editor > Hints > Java > Surround with try-catchwith
Use java.lang.System.Logger((2.) included in #8253)
Doing (2) above is the simplest. I'd be inclined to put it above
java.utiland 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 byGenerate > 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.
Generate>Logger...private static final Logger LOG = Logger.getLogger(Mavenproject5.class.getName());Surround with try-catchLogger.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-catchSystem.getLogger(Mavenproject5.class.getName()).log(Level.ERROR, null, ex);LOG.log(Level.ERROR, null, ex);// If "use existing logger" implementedAdditional
Generate>Logger...options for considerationWith these options, a generated logger would look like
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.
Inspect & Transform.System.Logger; fewer templates are needed.Additional features
Added 2025-02-16
JULtoSystem.Logger. Use withRefactor > 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.
Logginghints category" included in #8253)Logginghints categoryCode TemplatesUse case/motivation
Provide access to newer, as of Java-9, capability
Related issues
No response
Are you willing to submit a pull request?
Yes