[
https://issues.apache.org/jira/browse/SOLR-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020323#comment-15020323
]
Uwe Schindler edited comment on SOLR-8324 at 11/21/15 8:21 AM:
---------------------------------------------------------------
bq. I did try and use MethodHandles when Mike mentioned it, but eclipse didn't
offer me the option to import the class when I pasted that code in, so I
thought Java 7 didn't have the option.
Eclipse is sometimes not good to work with copypasted code. If you cklick on
class names it used it is ery bad to resolve them correctly. If you type in the
code char by char it works quite fine. If you type "MethodHandles." then it
offers you the lookup() method asap (which imports while selecting it). It is
indeed strange.
Another pattern for logging I see very often is importless loggers. Because the
logging code and its imports (for this pattern actually 3 imports: factory,
logger, method handles) clutters the imports with stuff nowhere used in the
class; many people declare their loggers with a single line using class names
including packages. By this you dont need imports and its friendly for
copypaste:
{code:java}
private static final org.slf4j.Logger log =
org.slf4j.LoggerFactory.getLogger(java.lang.invoke.MethodHandles.lookup().lookupClass());
{code}
was (Author: thetaphi):
bq. I did try and use MethodHandles when Mike mentioned it, but eclipse didn't
offer me the option to import the class when I pasted that code in, so I
thought Java 7 didn't have the option.
Eclipse is sometimes not good to work with copypasted code. If you cklick on
class names it used it is ery bad to resolve them correctly. If you type in the
code char by char it works quite fine. If you type "MethodHandles." then it
offers you the lookup() method asap (which imports while selecting it). It is
indeed strange.
Another pattern for logging I see very often is importless loggers. Because the
logging code and its imports (for this pattern actually 3 imports: factory,
logger, method handles) clutters the imports with stuff nowhere used in the
class, any people declare their loggers with a single line using class names
including packages. By this you dont need imports and its friendly for
copypaste:
{code:java}
private static final org.slf4j.Logger log =
org.slf4j.LoggerFactory.getLogger(java.lang.invoke.MethodHandles.lookup().lookupClass());
{code}
> Logger Untanglement
> -------------------
>
> Key: SOLR-8324
> URL: https://issues.apache.org/jira/browse/SOLR-8324
> Project: Solr
> Issue Type: Improvement
> Reporter: Mike Drob
> Fix For: Trunk
>
>
> I propose that we do a thorough examination of how we use loggers over the
> whole project. There are many instances of loggers being shared between
> classes that make troubleshooting difficult, and we can probably clean up
> some of the usage that has accumulated over numerous code moves and
> refactorings.
> Because this has the potential to scope wildly out of control, I would like
> to break the work down into several subtasks.
> * Loggers should be declared all three of {{private static final}} when
> possible. This both helps avoid the situations described in later bullets,
> and might provide a very minor performance improvement.
> * Distinct classes should not use loggers from other classes, unless they are
> explicitly delegated to do so.
> * Subclasses should declare their own loggers instead of relying on loggers
> from parent classes.
> * Examine if forbidden-api or some other tool(s) can help maintain this, once
> we reach a desired state.
> Each bullet might turn into one or more tasks, depending on how invasive
> individual changes become.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
