- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
/**
* Imbues the given {@link Font} with support for fallback fonts,
* needed to display CJK characters in fonts that do not support them.
*
* This is an ugly mess that depends on internal Sun APIs. Use sparingly!
*
* @param font the font
* @return the composite font UI resource
*/
public static FontUIResource getCompositeFontUIResource(final Font font) {
try {
Class<?> klass;
try {
// Java 7
klass = Class.forName("sun.font.FontUtilities");
} catch (final ClassNotFoundException e) {
// Java 6
klass = Class.forName("sun.font.FontManager");
}
// Invoke static method that wraps the font
val method = klass.getMethod("getCompositeFontUIResource", Font.class);
return (FontUIResource) method.invoke(null, font);
} catch (final ClassNotFoundException e) {
// Long block of catches that cannot happen on a Sun JRE
throw new AssertionError(e);
} catch (final IllegalAccessException e) {
throw new AssertionError(e);
} catch (final IllegalArgumentException e) {
throw new AssertionError(e);
} catch (final InvocationTargetException e) {
throw new AssertionError(e);
} catch (final NoSuchMethodException e) {
throw new AssertionError(e);
} catch (final SecurityException e) {
throw new AssertionError(e);
}
}
Follow us!
Меня насмешило вот что:
>catch (final ClassNotFoundException e) {
> catch (final IllegalAccessException e) {
> catch (final IllegalArgumentException e) {
> catch (final InvocationTargetException e) {
На кой там final у всех эксепшонов поставлен?
во-первых, чтобы не присвоить случайно,
во-вторых, final-переменные доступны в замыканиях внутренних анонимных классах.
я уже упоминал, что я настроил Eclipse так, чтобы он все неизменяемые переменные (плюс поля и параметры) сам делал finalьными - так я автоматически получаю их в анонимных классах, а также сразу информирован, если случайно попытаюсь изменить. Убрать при необходимости final просто, а багов, связанных с изменениями ссылок (скажем, передал объект куда-то, потом создал вместо него новый, а переданный старый объект-то живет и не отражает изменений)
КАК?! Хотеть!
-- Java -> Editor -> Save Actions
--- "Perform the selected actions on save", "Additional actions", "Configure..."
---- "Code Style", "Use modifier 'final' where possible" и там все эти галки "Private fields", "Parameter","Local variables"
а вообще я там отметил все, кроме:
"Sort members" - т.к. вместе с форматированием в редких случаях работает некорректно и портит код (видимо, пытается параллельно и отформатировать и отсортировать)
"Unused code" - не надо убирать при сохранении
Но эти галки в похожем диалоге "Code cleanup" есть.
Если еще форматирование настроить под себя (например, я сделал чтобы убирались пустые строки), то вообще сказка.
Ну и в "Java"->"Compiler"->"Errors/Warnings" поставил почти все галки, вкупе с FindBugs вообще подсвечивает все подозрительные места. Я не успокаиваюсь, пока в коде есть ворнинги.
а findbugs практически не надо конфигить
только сконфигю их как умолчания workspace, а то на работе они не умолчания - тут иной кодстайл
Это известно. Кто в здравом уме будет туда передавать исключение и главное зачем?
>чтобы не присвоить случайно
Так эксепшен же.
но я привык именно к такой настройке и мне комфортно.
>у меня автоматом this. ставятся, где возможно
Ну вот еще один типичный джавизм - чем больше говна символов, тем лучше проекту.
просто this. без всяких подсветок ясно говорит, что это поле или метод, причем ЭТОГО класса - не переменная и не параметр
Боитесь, что после долгой бессонной ночи или спросонья, перепутаете язык Java с С++ или PHP?
И решил что Люр таки в чем-то глубоко прав.
final хоть и замусоривает код, но жабу лишним кейвордом не исправишь - всё равно многословное унылое говно.
А вот помочь обойти всякие грабли JMM вроде безопасных многопоточности и публикации объектов, это final может, да.
Собственно это созвучно посту Романа
>после пятого языка лень вспоминать, где как нужно
Чтобы не опубликовать недостроенный объект, например. То лень думать где в коде нужен этот final.
А вызов метода текущего объекта без this можно спутать только с вызовом глобальной функции (которых в с++ не так уж и много, и, часто, перед ними стоит имя неймспейса) или с вызовом функции (или функтора), указатель на которую лежит в локальной переменной/параметре (но это встречается не на каждом шагу, и, в небольших методах, совсем не вносит путаницы).
Так что this для всех полей методов текущего объекта в с++ это скорее дело вкуса, или, возможно, требование корпоративного style guide, нежели необходимость.
> как второй вариант - делать typedef на тип предка и квалифицировать через него, но это обычно больше символов
И, в добавок, не получится вызывать виртуальные методы...
меня на первых порах вымораживало портировать отлаженный под студией код на gcc 3.x, сейчас смиренно расставляю this в нужных местах еще до компиляции
Да, использую final, когда пишу иммутабельный класс или нужны аргументы в анонимных классах. В остальных же случаях, на мой взгляд, final лишь засоряет код, ухудшая читаемость. Но это дело вкуса, и тут можно поспорить.
В Scala вон написать val также просто, как и var, поэтому можно использовать иммутабельность без вреда для читаемости, чем частенько и пользуюсь.
Потому что lombok.
Потому что Scala