Логирование в L2J

[bloodshed]

ой сори, не то увидел. Всё ок.
п.с. затераю свой преыдущий текст Кто успел прочитать - тот поймет с чем я затупил)

в случае с String.format("%1$tH:%1$tM:%1$tS %2s %3s %4s %5s%n"
Будет использоваться другой метод (может ошибаюсь, копаться особо не охота):
java.util.Formatter.FormatSpecifier#printDateTime

[SRC="java"] private void printDateTime(Object arg, Locale l) throws IOException {
if (arg == null) {
print("null");
return;
}
Calendar cal = null;

// Instead of Calendar.setLenient(true), perhaps we should
// wrap the IllegalArgumentException that might be thrown?
if (arg instanceof Long) {
// Note that the following method uses an instance of the
// default time zone (TimeZone.getDefaultRef().
cal = Calendar.getInstance(l == null ? Locale.US : l);
cal.setTimeInMillis((Long)arg);
} else if (arg instanceof Date) {
// Note that the following method uses an instance of the
// default time zone (TimeZone.getDefaultRef().
cal = Calendar.getInstance(l == null ? Locale.US : l);
cal.setTime((Date)arg);
} else if (arg instanceof Calendar) {
cal = (Calendar) ((Calendar)arg).clone();
cal.setLenient(true);
} else {
failConversion(c, arg);
}
// Use the provided locale so that invocations of
// localizedMagnitude() use optimizations for null.
print(cal, c, l);
}[/SRC]

Который не намного лучше, при чём будет создаваться ещё один Foramter, StringBuilder и ещё куча всего

[ANZO]

А посмотреть во что это в компилированном состоянии превращается я как понимаю никак?

[acmi]

Немного загрустив о L2 решил посмотреть как там использовалось логирование.
После чего был сильно опечален.
...

Когда что-то исправляют и ломают thread-safety, это тоже сильно печалит.

[VISTALL]

Мне написал человек их L2J, насчет этой темы, я ему посоветовал перейти на Slf4J, и тестить с Log4J vs Logback

[GuildHack]

смирись. Есть люди которые её юзают, после СП1 она стала по лучше.

Как и большинство юзеров - юзают Клипсу, а она такое *овно

Другие юзеры - юзают IntelliJ IDEA, она не сильно отошла от Клипсы

Ты сам когда-то пользовался IDEA :redlol:. И кстати Eclipse и IDEA самые ходовые среды разработки (Если не учитывать NetBeans). Не знаю, что ты в них "*овеного" нашел, достаточно удобно и функционально.

[ALF.]

Когда что-то исправляют и ломают thread-safety, это тоже сильно печалит.

Немного не понял, но
http://docs.oracle.com/javase/6/docs/api...ogger.html

All methods on Logger are multi-thread safe.

[JavaMan]

Немного не понял, но
http://docs.oracle.com/javase/6/docs/api...ogger.html

Он говорил про класс Date.

[VISTALL]

Ты сам когда-то пользовался IDEA :redlol:. И кстати Eclipse и IDEA самые ходовые среды разработки (Если не учитывать NetBeans). Не знаю, что ты в них "*овеного" нашел, достаточно удобно и функционально.

Юзаю сейчас IntelliJ IDEA CE by VISTALL.

В планах перейти на Consulo (IDE by VISTALL).

А говненно - это код, отношения компании, прочее

[ALF.]

Он говорил про класс Date.

В нашем случаи не будет никаких конфликтов
Ибо все функции логирования вызываются через объект класса Logger-а

log.log("blablabla");

И только через внутренние вызовы будет вызван наш форматтер.
Естественно что там никогда не будет 2 потока одновременно, если вручную не вызвать местод форматтера.

п.с. public static Logger getLogger(String name) не требует синхронизации и не создает новый объект логера

[JavaMan]

В нашем случаи не будет никаких конфликтов
Ибо все функции логирования вызываются через объект класса Logger-а

log.log("blablabla");

И только через внутренние вызовы будет вызван наш форматтер.
Естественно что там никогда не будет 2 потока одновременно, если вручную не вызвать местод форматтера.

п.с. public static Logger getLogger(String name) не требует синхронизации и не создает новый объект логера

Да, ты прав, Formatter#format вызывается в синхронизированном методе.
Это конечно потокобезопасно, но ужасно медленно. Так что лучше использовать нормальный логгер, типа logback или log4j2.