- 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
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
//javax.swing.JTree
public void setBounds(Rectangle r) {
AccessibleContext ac = getCurrentAccessibleContext();
if (ac instanceof AccessibleComponent) {
((AccessibleComponent) ac).setBounds(r);
} else {
Component c = getCurrentComponent();
if (c != null) {
c.setBounds(r);
}
}
}
public void setSize (Dimension d) {
AccessibleContext ac = getCurrentAccessibleContext();
if (ac instanceof AccessibleComponent) {
((AccessibleComponent) ac).setSize(d);
} else {
Component c = getCurrentComponent();
if (c != null) {
c.setSize(d);
}
}
}
public void requestFocus() {
AccessibleContext ac = getCurrentAccessibleContext();
if (ac instanceof AccessibleComponent) {
((AccessibleComponent) ac).requestFocus();
} else {
Component c = getCurrentComponent();
if (c != null) {
c.requestFocus();
}
}
}
public void addFocusListener(FocusListener l) {
AccessibleContext ac = getCurrentAccessibleContext();
if (ac instanceof AccessibleComponent) {
((AccessibleComponent) ac).addFocusListener(l);
} else {
Component c = getCurrentComponent();
if (c != null) {
c.addFocusListener(l);
}
}
}
public boolean isFocusTraversable() {
AccessibleContext ac = getCurrentAccessibleContext();
if (ac instanceof AccessibleComponent) {
return ((AccessibleComponent) ac).isFocusTraversable();
} else {
Component c = getCurrentComponent();
if (c != null) {
return c.isFocusTraversable();
} else {
return false;
}
}
}
Follow us!
вот еще пример - InputStream и OutputStream implements Closeable
А java.sql.Connection, java.sql.Statement и java.sql.ResultSet не реализуют этого интерфейса.
Говорят в 7-ой жабе это пофиксили, но сколько ж лет оно так криво было.
Дурно пахнущий код, который ещё и непонятно как рефакторить - явный признак ошибки на уровне архитектуры.
Тут это слишком накладно м наверняка им стоило завести какой-то общий интерфейс.
>>> A Component is an object having a graphical representation that can be displayed on the screen
>>> The AccessibleComponent interface should be supported by any object that is rendered on the screen.
>>>should be supported by any object that is rendered on the screen.
>>>any object that is rendered on the screen
Потому что тут явно у кого-то проблемы с логикой.
Кстати схожие ощущения.
И по скорости исполнения тоже неплохо так смотрится. В отличии от Groovy.
Почти дочитал Programming in Scala, пока в восторге. Реально сокращает число букв, которые нужно набирать. Плюс есть полная обратная совместимость с Java. Единственный ощутимый косяк - нет пока нормальной IDE (язык настолько мощный, что я понимаю, почему её сложно сделать). Говорят, для IntelliJ IDEA есть нормальный плагин, но я его пока не пробовал. Поскольку пишу пока только игрушечный код, мне вполне хватает emacs + scala interpreter + maven.
http://stackoverflow.com/questions/419207/which-is-the-best-ide-for-scala-development
Никак нет, сер. Там очень много классов с методом close.
RMIConnection, например.
public void close() throws IOException; а интерфейс не имплементит
>А зачем?
Обычно пресловутый Exception игнорится и если хочется чего-то закрыть нужно писать
try{
close(something);
}catch(){}
А если нужно закрыть PreparedStatement, а за ним Connection, или 2 Connection подряд приходится новое закрытие снова оборачивать в try-catch. По понятным причинам.
А если оно все имплементит Closable делаем метод
static void close(Closable cl){
try{cl.close}catch(Exception e){};
}
или даже так
static void close(Closable... cl){
Да и вообще речь о том, что если уж вводить новый интерфейс с методом
>close is invoked to release resources that the object is holding.
то стоит сделать его универсальным.
Кстати, Closeable ведь только с 1.5. Вот и ответ на вопрос.
Да в большинстве случаев этот "надёжный код" просто выводит сообщение и закрывает программу. В принципе абсолютно то же самое происходит при стандартное поведении системы при непойманном исключении, только вот весёлый Гослинг заставляет нас писать больше букав просто так.
Если уж и заботиться о суперкритичном софте (типа софта для бирж), то можно было бы сделать свитч компилятора XX:+critical, который бы не компилировал код при непойманных исключениях, и XX:-critical, который бы просто выводил ворнинг. Выбирай нужный свитч под тип приложения.
кстати, Ховард негодует тоже:
даже если он не знает, какие именно
Как я уже сказал, можно было просто выводить ворнинг, а не вообще отказываться компилировать. Хорошие программисты обратят внимание на ворнинг, а плохие будут делать путые try...catch...finally в любом случае и при checked exceptions, ровно как и игнорировать ворнинги. Так что толка нет никакого.