java.util.logging을 사용하면 어떨까요?

java.util.logging을 사용하면 어떨까요?

나는 태어나서 처음으로 오픈 소스로 제공되는 자바 API를 쓰는 처지에 놓였다.다른 많은 프로젝트에 포함되기를 바랍니다.

I 실제로은 JULJUL)을 .java.util.logging문제가 전혀 없었습니다.하지만 이제 API 개발을 위해 무엇을 해야 하는지 좀 더 자세히 이해해야 합니다.이것에 대해 몇 가지 조사를 해봤는데, 내가 가지고 있는 정보로 인해 더 혼란스러울 뿐이다.그래서 이 투고입니다.

나는 JUL에서 왔기 때문에 그것에 편중되어 있다.나머지 지식은 그리 크지 않다.

제가 조사한 결과, 사람들이 JUL을 좋아하지 않는 이유가 다음과 같습니다.

1. "저는 Sun이 JUL을 출시하기 훨씬 전에 Java에서 개발을 시작했고, 새로운 것을 배우는 것보다 logging-framework-X를 계속하는 것이 더 쉬웠습니다."음, 농담 아니에요, 사실 사람들이 그렇게 말해요.이 논쟁으로 우리는 모두 COBOL을 할 수 있다.(하지만 나는 이것이 게으른 남자라는 것에 확실히 공감할 수 있다.)

2. "JUL 로그 레벨 이름이 마음에 안 들어"좋아요, 정말이에요, 이건 새로운 의존관계를 도입할 충분한 이유가 아니에요

3. "JUL의 표준 출력 형식이 마음에 안 들어"흠이것은 단순한 설정입니다.코드와 관련된 작업을 수행할 필요도 없습니다.(옛날에는 포메터 클래스를 만들어야 올바르게 사용할 수 있었습니다).

4. logging-framework-X를 사용하는 다른 라이브러리를 사용하고 있기 때문에 그 라이브러리만 사용하는 것이 더 편하다고 생각했습니다.이건 순환논쟁이죠?왜 'everybody'는 JUL이 아닌 logging-framework-X를 사용합니까?

5. "다른 사람들은 모두 logging-framework-X를 사용하고 있습니다."이것은 나에게 있어서, 상기의 특수한 경우에 지나지 않습니다.과반수가 항상 옳은 것은 아니다.

그래서 진짜 큰 질문은 왜 JUL이 아니냐는 것이다.내가 뭘 놓쳤지?로깅 파사드의 존재 이유(SLF4J, JCL)는 역사적으로 여러 로깅 구현이 존재해왔기 때문에 그 이유는 JUL 이전 시대로 거슬러 올라갑니다.JUL이 완벽하다면 로그패스는 존재하지 않을 것입니다.더욱 혼란스러운 것은 JUL은 어느 정도 표면 그 자체이기 때문에 핸들러, 포메터, LogManager를 교환할 수 있다는 것입니다.

같은 작업(로깅)을 여러 가지 방법으로 수행하는 것이 아니라 애초에 그것들이 왜 필요했는지 의문을 제기해야 하지 않을까요?(그런 이유가 아직 존재하는지 확인합니다)

지금까지의 조사 결과, JUL의 실제적인 문제가 되고 있는 것을 알 수 있었습니다.

1. 퍼포먼스SLF4J의 성능이 남들보다 뛰어나다는 평가도 있다.이것은 시기상조라고 생각됩니다.초당 수백 메가바이트를 기록해야 하는 경우 올바른 경로인지 잘 모르겠습니다.JUL도 진화하여 Java 1.4에서 수행한 테스트가 더 이상 사실이 아닐 수 있습니다.여기서 읽어보실 수 있습니다.이 수정은 Java 7로 되어 있습니다.또한 로깅 메서드에서 문자열 연결의 오버헤드에 대해서도 많은 사람들이 언급하고 있습니다.그러나 템플릿 기반 로깅을 사용하면 이 비용이 발생하지 않으며 JUL에도 존재합니다.개인적으로 저는 템플릿 기반 로깅을 실제로 작성하지 않습니다.그러기엔 너무 게을러요.예를 들어 JUL을 사용하여 이 작업을 수행하는 경우:

    log.finest("Lookup request from username=" + username 
       + ", valueX=" + valueX
       + ", valueY=" + valueY));
   

   IDE가 경고하고 다음 항목으로 변경할 수 있는지 여부를 묻습니다.

    log.log(Level.FINEST, "Lookup request from username={0}, valueX={1}, valueY={2}", 
       new Object[]{username, valueX, valueY});
   

   ..물론 받아들일게요허가되었습니다! 도와주셔서 감사합니다.

   그래서 제가 직접 그런 글을 쓰는 게 아니라 IDE가 쓰는 거예요

   성과에 대한 결론으로, 나는 JUL의 성과가 경쟁사들에 비해 좋지 않다는 것을 아무것도 발견하지 못했다.

2. classpath에서 설정.기본 제공 JUL은 클래스 경로에서 구성 파일을 로드할 수 없습니다.그렇게 하는 것은 몇 줄의 코드입니다.이것이 왜 짜증나는지는 알겠지만 해결책은 간단하고 간단하다.

3. 출력 핸들러의 가용성.JUL에는 콘솔, 파일 스트림, 소켓 및 메모리의 5가지 출력 핸들러가 포함되어 있습니다.이것들은 확장하거나 새로운 것을 쓸 수 있습니다.예를 들어 UNIX/Linux Syslog 및 Windows 이벤트 로그에 쓰는 경우가 있습니다.저는 개인적으로 이 요구 사항을 받아본 적도 없고 사용한 적도 없지만, 왜 그것이 유용한 기능인지 확실히 알 수 있습니다.예를 들어 로그백에는 Syslog용 Appender가 포함되어 있습니다.그래도 나는 그렇게 주장할 것이다.

   1. 출력처에 대한 요구의 99.5%는 JUL에 포함되어 있는 즉시 사용할 수 있는 것으로 충족됩니다.
   2. 특별한 요구는 JUL 위에 있는 커스텀 핸들러에 의해 다른 것 위에 있는 것이 아니라 충족될 수 있습니다.JUL용 Syslog 출력 핸들러를 쓰는 데 다른 로깅 프레임워크에서 쓰는 것보다 시간이 더 걸리는 것은 없습니다.

제가 간과한 게 있어서 정말 걱정이에요.JUL 이외의 로그 패시드와 로그 실장 사용은 매우 광범위하기 때문에 저는 이해하지 못하는 것은 저라는 결론에 도달해야 합니다.처음은 아닙니다. :-)

그럼 API는 어떻게 해야 하나요?나는 그것이 성공하기를 바란다.물론 "흐름에 따라" SLF4J(요즘 가장 인기 있어 보이는 것)를 구현할 수는 있지만, 저는 여전히 모든 흐릿함을 보증하는 오늘날의 JUL이 정확히 무엇이 문제인지 이해할 필요가 있습니다.제 라이브러리로 JUL을 선택함으로써 제 자신을 파괴할 수 있을까요?

퍼포먼스 테스트

(2012년 7월 JUL에서 nolan600에 의해 추가된 섹션)

SLF4J의 매개 변수가 JUL의 매개 변수보다 10배 이상 빠르다는 Ceki의 언급이 아래에 있습니다.그래서 간단한 테스트를 시작했습니다.언뜻 보면 그 주장은 확실히 옳다.다음은 예비 결과입니다(단, 계속 읽어 보십시오).

• 실행시간 SLF4J, 백엔드 로그백: 1515
• 실행시간 SLF4J, 백엔드 JUL: 12938
• 실행 시간 JUL: 16911

위의 수치는 msec이므로 작을수록 좋습니다.10배의 퍼포먼스 차이는 처음에는 상당히 비슷합니다.초기 반응:정말 많네요!

이것이 테스트의 핵심입니다.알 수 있듯이 정수와 문자열은 루프로 변환되어 로그문으로 사용됩니다.

    for (int i = 0; i < noOfExecutions; i++) {
        for (char x=32; x<88; x++) {
            String someString = Character.toString(x);
            // here we log 
        }
    }

(log 스테이트먼트에 원시 데이터 타입(이 경우는 int)과 보다 복잡한 데이터 타입(이 경우는 String)을 모두 사용하고 싶다고 생각하고 있습니다.그게 중요한지는 모르겠지만, 당신은 그걸 가지고 있어요.)

SLF4J의 log 문:

logger.info("Logging {} and {} ", i, someString);

JUL 로그문:

logger.log(Level.INFO, "Logging {0} and {1}", new Object[]{i, someString});

실제 측정을 수행하기 전에 동일한 테스트를 한 번 실행하여 JVM을 '워밍업'했습니다.Windows 7 에서는 Java 1.7.03 이 사용되었습니다.최신 버전의 SLF4J(v1.6.6) 및 로그백(v1.0.6)이 사용되었습니다.Stdout 및 stderr이 늘디바이스로 리다이렉트 되었습니다.

현재할 점은 JUL이 만, 은 jul은, 은은은은은에서 보내고 있다는 것입니다.getSourceClassName()기본적으로 JUL은 소스 클래스 이름을 출력에 출력하지만 Logback은 출력하지 않기 때문입니다.그래서 우리는 사과와 오렌지를 비교하고 있다.테스트를 다시 실행하여 로그 실장을 같은 방법으로 설정하여 실제로 동일한 내용을 출력해야 합니다.lf4 、 SLF4J + Logback 、 상기의고고고 、 상고고고고고고고고 。츠키노

이 테스트는 실제로 SLF4J 또는 Logback을 사용해 본 적이 없습니다.즐거운 경험.JUL은 확실히 당신이 시작할 때 훨씬 덜 환영한다.

퍼포먼스 테스트 (파트 2)

(2012년 8월 JUL에 nolan600에 의해 추가된 섹션)

JUL에서 패턴을 구성하는 방법(소스 이름 포함 여부 등)은 성능에는 크게 문제가 되지 않습니다.매우 간단한 패턴으로 시도했습니다.

java.util.logging.SimpleFormatter.format="%4$s: %5$s [%1$tc]%n"

그리고 그것은 위의 타이밍을 전혀 바꾸지 않았다.가 아직 을 '로거' .getSourceClassName()츠미야

따라서 적어도 테스트된 템플릿 기반 로그 문에서는 JUL(느림)과 SLF4J+Logback(빠른)의 실제 성능 차이가 대략 10배인 것으로 보인다는 성능 문제에 대해 결론을 내리고 있습니다.Ceki가 말한 대로야.

SLF4J SLF4J의 SLF4J의 SLF4J도 볼 수 있습니다.getLogger() 대 0).(프로파일러가 정확한 경우 95밀리초 대 0.3밀리초).구현의 어느 .SLF4J는 기반이 되는 로깅 구현의 바인딩에 대해 어느 정도 시간을 할애해야 합니다.「 「 」이러한 타임중에 이어야 합니다.이러한 콜은 어플리케이션의 라이프 타임에서는 다소 드물어야 합니다.고속성은 실제 로그콜에 포함되어 있어야 합니다.

최종 결론

(2012년 8월 JUL에 nolan600에 의해 추가된 섹션)

답변해 주셔서 감사합니다.당초의 생각과는 달리, API에 SLF4J를 사용하게 되었습니다.이는 다음과 같은 몇 가지 사항과 귀하의 의견을 기반으로 합니다.

1. 도입 시 로그 구현을 유연하게 선택할 수 있습니다.

2. 응용 프로그램 서버 내에서 실행할 때 JUL 구성이 유연하지 않은 문제.

3. SLF4J는 특히 Logback과 결합하면 위에서 설명한 바와 같이 훨씬 더 빠릅니다.비록 이것이 간단한 테스트라고 해도, JUL보다 SLF4J+Logback의 최적화에 더 많은 노력이 들어갔다고 생각할 이유가 있습니다.

4. 문서.SLF4J의 문서는 훨씬 더 포괄적이고 정확합니다.

5. 패턴의 유연성테스트를 수행하면서 JUL이 Logback의 기본 패턴을 모방하도록 설정했습니다.이 패턴에는 스레드 이름이 포함됩니다.JUL은 이것을 바로 할 수 없다는 것이 판명되었습니다.네, 지금까지 놓치지 않았습니다만, 로그 프레임워크에서 누락되어서는 안 된다고 생각합니다.마침표!

6. 오늘날 대부분의 (또는 많은) Java 프로젝트에서는 Maven을 사용하고 있기 때문에 종속성을 추가하는 것은 그다지 큰 문제가 되지 않습니다.특히 종속성이 비교적 안정적이고 API를 지속적으로 변경하지 않는 경우에는 더욱 그렇습니다.이것은 SLF4J에도 해당이 되는 것 같습니다.또한 SLF4J 항아리와 친구들은 크기가 작습니다.

그래서 이상한 일은 SLF4J와 조금 같이 일하다가 JUL에게 상당히 화가 났다는 것입니다. JUL은 완벽과는 거리가 멀지만, JUL은 그 일을 하고 있습니다.그냥 충분치 않을 뿐이야. 경우에도 수 있습니다.Properties예를 들어, 다른 사용자가 자신의 구성 라이브러리에 연결할 수 있도록 추상화하는 것은 생각하지 않습니다.는 ★★★★★★★★★★★★★★★★★★★★★★★★.Properties오늘날 JUL의 경우 그 반대인 반면 막대 바로 위에 있습니다. 과거에는 존재하지 않았기 때문에 0이 되었습니다.

면책사항:저는 log4j, SLF4J 및 logback 프로젝트의 창시자입니다.

SLF4J를 선호하는 객관적인 이유가 있습니다.첫째, SLF4J를 사용하면 최종 사용자가 기본 로깅 프레임워크를 자유롭게 선택할 수 있습니다.또한 보다 현명한 사용자는 log4j 이상의 기능을 제공하는 logback을 선호하며 j.u.l은 훨씬 뒤처집니다.일부 사용자에게는 기능적인 j.u.l로 충분할 수 있지만 다른 사용자에게는 그렇지 않습니다.간단히 말해 로깅이 중요한 경우 기본 구현으로 로그백과 함께 SLF4J를 사용할 수 있습니다.로그가 중요하지 않은 경우 j.u.l.도 괜찮습니다.

단, os 개발자로서 자신의 취향뿐만 아니라 사용자의 취향도 고려해야 합니다.따라서 SLF4J가 j.u.l보다 낫다고 확신하기 때문이 아니라 현재(2012년 7월) 대부분의 Java 개발자가 SLF4J를 로깅 API로 선호하기 때문에 SLF4J를 채택해야 합니다.만약 당신이 궁극적으로 대중의 의견에 신경 쓰지 않기로 결정한다면, 다음 사실을 고려하세요.

1. J.U.L을 선호하는 사람들은 J.U.L이 JDK에 번들되어 있기 때문에 편의상 그렇게 합니다.내가 알기로는 j.u.l.을 지지하는 다른 객관적인 주장은 없다.
2. 네가 좋아하는 건 그냥, 그냥 좋아하는 거야

그러므로, 겉보기에는 용감해 보이지만 여론 위에 "확실한 사실"을 두는 것은 이 경우에 논리적인 오류이다.

그래도 납득이 가지 않는 경우 JB Nizet은 다음과 같은 추가적이고 강력한 주장을 펼칩니다.

단, 최종 사용자는 이미 자신의 코드 또는 log4j 또는 logback을 사용하는 다른 라이브러리에 대해 이 커스터마이즈를 했을 가능성이 있습니다.j.u.l은 확장 가능하지만 로그백, j.u.l, log4j를 확장해야 합니다.또한 4개의 다른 로그 프레임워크를 사용하는 것은 번거롭기 때문입니다.SLF4J를 사용하면 선택한 로깅 프레임워크가 아닌 원하는 로깅 프레임워크를 설정할 수 있습니다.일반적인 프로젝트에는 고객만의 라이브러리가 아니라 무수한 라이브러리가 사용됩니다.

어떤 이유로든 당신이 SLF4J API를 싫어하고 그것을 사용하는 것이 당신의 일의 재미를 망친다면, 반드시 j.u.l.을 선택해주세요.결국 j.u.l을 SLF4J로 리다이렉트하는 수단이 있습니다.

덧붙여서 j.u.l 파라미터화는 SLF4J보다 적어도 10배 느리므로 현저한 차이가 발생합니다.

1. java.util.logging 1되었습니다.그 이전에도 로깅의 용도가 있었습니다.API를 사용하다이러한 API는 Java 1.4 이전부터 많이 사용되었기 때문에 1.4 출시 시 0으로 떨어지지 않은 시장 점유율을 가지고 있었다.

2. JUL은 그렇게 잘 시작하지 않았다.말씀하신 것 중 상당수는 1.4에서 훨씬 더 악화되었고 1.5에서 개선되었을 뿐입니다(그리고 6에서도 개선되었을 것입니다만, 잘 모르겠습니다).

3. JUL은 동일한 JVM에서 서로 다른 구성을 가진 여러 애플리케이션에 적합하지 않습니다(상호 작용하지 않아야 하는 여러 웹 애플리케이션).Tomcat은 이 기능을 이용하기 위해 몇 가지 후프를 통과해야 합니다(제대로 이해한 경우 JUL을 효과적으로 재실장).

4. 라이브러리가 사용하는 로깅 프레임워크에 항상 영향을 줄 수는 없습니다.따라서 SLF4J(실제로 다른 라이브러리보다 매우 얇은 API 레이어)를 사용하면 로깅 세계 전체의 일관된 그림을 유지할 수 있습니다(따라서 같은 시스템에서 라이브러리 로깅을 유지하면서 기본 로깅 프레임워크를 결정할 수 있습니다).

5. 라이브러리는 쉽게 바뀌지 않습니다.이전 버전의 라이브러리가 logging-library-X를 사용했을 경우, Logging-library-Y(JUL 등)로 쉽게 전환할 수 없습니다.이 라이브러리의 모든 사용자는 새로운 로깅 프레임워크를 학습하고 (적어도) 로깅을 재구성해야 합니다.그건 절대 안 돼, 특히 대부분의 사람들에게 명백한 이득을 가져다 주지 않을 때 말이야.

JUL이 적어도 요즘 다른 로깅 프레임워크에 대한 유효한 대안이라고 생각한다.

IMHO는 slf4j와 같은 로깅 파사드를 사용할 때 가장 큰 장점은 최종 사용자에게 선택을 강요하는 것이 아니라 라이브러리의 최종 사용자가 원하는 구체적인 로깅 구현을 선택할 수 있다는 것입니다.

아마도 그는 Log4j 또는 LogBack(특수 포맷자, 부록 등)에 시간과 비용을 투자하고 있으며, Jul을 구성하기보다는 Log4j 또는 LogBack을 계속 사용하는 것을 선호할 것입니다.문제 없습니다. slf4j는 그것을 허용합니다.jul보다 Log4j를 사용하는 것이 현명한 선택입니까?그럴지도, 아닐지도.하지만 넌 신경 안 써최종 사용자가 원하는 것을 선택할 수 있도록 합니다.

당신처럼 JUL을 사용하기 시작했습니다. 왜냐하면 JUL이 바로 시작할 수 있는 가장 쉬운 방법이었기 때문입니다.하지만 몇 년 동안, 저는 고르는 데 시간을 좀 더 썼으면 하는 아쉬움이 생겼습니다.

현재 나의 주요 이슈는 많은 어플리케이션에서 사용되는 상당한 양의 '라이브러리' 코드가 있고 그들은 모두 JUL을 사용한다는 것이다.웹 서비스 타입의 앱에서 이러한 툴을 사용할 때마다 로그가 사라지거나 예측 불가능하거나 이상한 곳으로 이동합니다.

이 솔루션은 라이브러리 코드에 파사드를 추가하는 것입니다.이는 라이브러리 로그 콜이 변경되지 않고 사용 가능한 로깅 메커니즘으로 동적으로 리다이렉트됨을 의미합니다.POJO 툴에 포함되어 있는 경우는 JUL로 전송되지만 웹 어플리케이션으로 전개되어 있는 경우는 LogBack으로 리다이렉트 됩니다.

유감스럽지만, 라이브러리 코드는 파라미터화된 로깅을 사용하지 않지만, 이제 필요할 때 이를 수정할 수 있습니다.

slf4j를 사용하여 파사드를 만들었습니다.

logback-1.1.7에서 slf4j-1.7.21에 대해 jul을 실행하여 SSD, Java 1.8, Win64로 출력했습니다.

jul은 48449밀리초, 로그백 27185밀리초를 실행하였습니다.

그래도 조금 더 빠르고 멋진 API는 3개의 라이브러리와 80K의 가치가 없습니다.

package log;

import java.util.logging.Level;
import java.util.logging.Logger;

public class LogJUL
{
    final static Logger logger = Logger.getLogger(LogJUL.class.getSimpleName());

    public static void main(String[] args) 
    {
        int N = 1024*1024;

        long l = System.currentTimeMillis();

        for (int i = 0; i < N; i++)
        {
            Long lc = System.currentTimeMillis();

            Object[] o = { lc };

            logger.log(Level.INFO,"Epoch time {0}", o);
        }

        l = System.currentTimeMillis() - l;

        System.out.printf("time (ms) %d%n", l);
    }
}

그리고.

package log;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class LogSLF
{
    static Logger logger = LoggerFactory.getLogger(LogSLF.class);


    public static void main(String[] args) 
    {
        int N = 1024*1024;

        long l = System.currentTimeMillis();

        for (int i = 0; i < N; i++)
        {
            Long lc = System.currentTimeMillis();

            logger.info("Epoch time {}", lc);
        }

        l = System.currentTimeMillis() - l;

        System.out.printf("time (ms) %d%n", l);
    }

}

언급URL : https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging