delphi = pascal = языки для начинающих

← →
Piter © (2007-11-15 18:59) [360]

Джо, а давай такой пример рассмотрим, на Delphi:

someClass := TFileStrean.Create... someClass.Read... someClass.Write... // вот тут, если не закрыть файл, открытый для эксклюзивного доступа // случится хрень someClass = TFileStream.Create someClass.Read... someClass.Write...

здесь тебя почему-то не удивляет, что случится хрень? А вот с Java удивляет! К чему бы это?

← →
Черный Шаман (2007-11-15 19:02) [361]

> Piter © (15.11.07 18:47) [357]
>
> кстати, также очень бы хотелось услышать комментарии на
> это:
>
> Юрий Зотов © (15.11.07 17:38) [312]
> А еще разберись с тем, почему бывает невозможно удалить
> файл, хотя программа, которая его юзала, уже завершилась
>
> как я понимаю, Юрий говорит о том, что файл уже больше ни
> одной программой не используется, а удалить его нельзя.
> Я такого не встречал. Очень хочу комментарий, когда это
> возможно и почему.

Иногда бывают такие хитрые баги, когда Windows при падении проекта, отлаживаемого в Delphi не собирает все открытые им дескрипторы. Даже после закрытия Delphi. Почему это происходит неясно, но происходит очень редко.

Похоже это баг операционной системы.

← →
Piter © (2007-11-15 19:03) [362]

Черный Шаман (15.11.07 19:02) [361]
Похоже это баг операционной системы.

это я вполне допускаю. Но Юрий говорил о том, что пока я не изучу этот вопрос - смысла разговаривать нет. Получается, я должен изучить то, что в ОС Windows есть баги?

← →
Юрий Зотов © (2007-11-15 19:06) [363]

> Piter © (15.11.07 18:42) [352]

> Давайте рассмотрим, например, файлы

Миш, рассмотри коннект к БД Paradox и успокойся. Заодно это и будет комментарий по поводу повисания ресурса.

Кстати, ты в курсе, что если программа загрузила DLL, а потом не вызвала FreeLibrary, то эта DLL в текущей сессии системы уже не выгрузится никогда, даже после завершения всех юзающих ее программ? Потому что система будет считать ее используемой.

Кстати, ты в курсе, что если программа захватила объекты GDI и не освободила их, то они будут заняты и после завершения программы?

Кстати, ты в курсе, что объекты ядра тоже могут оказаться занятыми и после завершения программы, если она их не освободила?

Кстати, ты в курсе, что файл - это тоже объект ядра?

Ну и т.д.

> Порш (15.11.07 18:45) [353]

> Если объект уничтожен сборщиком мусора, то finalize этого обьекта
> вызван 100%. Если не был вызван close или в finalize не освободили
> ресурс, то кто виноват ясно.

Пожалуйста, ветку прочтите сначала. Хотя бы для того, чтобы стало ясно, что речь в ней идет о джаве, а не о дотнет. А еще там выше примеры есть, по поводу вызовов finalize, их тоже не мешало бы посмотреть.

← →
Юрий Зотов © (2007-11-15 19:16) [364]

> Piter © (15.11.07 18:59) [360]

> здесь тебя почему-то не удивляет, что случится хрень? А вот с Java
> удивляет! К чему бы это?

Миш, ты некорректно перевел код с джавы на Delphi. Вот правильный перевод:

someClass := TFileStrean.Create...
someClass.Read...
someClass.Write...
someClass.Free; // Вот в чем фокус.

someClass = TFileStream.Create
someClass.Read...
someClass.Write...

А теперь тебя ничего не удивляет?

А меня удивляет. То, что ты так упорно споришь о том, в чем толком не разбираешься. Даже в элементарной джаве.

Извини, достал уже. Хватит, Миш, а?

← →
SergeR___ (2007-11-15 19:33) [365]

StreamInput si;
try {
si = new FileInputStream("aaa");
si.read(...
} catch (...) {
} finally {
si.flush();
si.close(); // Чем отличается?!
}
try {
si = new FileInputStream("aaa");
...
или я слепой?!

← →
Джо © (2007-11-15 19:38) [366]

> [365] SergeR___ (15.11.07 19:33)
> si.close(); // Чем отличается?!

Например тем, что у TStream может не быть Close (или Flush) и у его потомка TFileStream их нужно будет вводить :) Последствия этого — очевидны и я об этом рассуждать не стану.

← →
serger___ (2007-11-15 19:42) [367]

public abstract class InputStream implements Closeable {
...

package java.io;

import java.io.IOException;

/**
* A <tt>Closeable</tt> is a source or destination of data that can be closed.
* The close method is invoked to release resources that the object is
* holding (such as open files).
*
* @version 1.4 03/12/19
* @since 1.5
*/

public interface Closeable {

/**
* Closes this stream and releases any system resources associated
* with it. If the stream is already closed then invoking this
* method has no effect.
*
* @throws IOException if an I/O error occurs
*/
public void close() throws IOException;

}

← →
Piter © (2007-11-15 19:43) [368]

Юрий Зотов © (15.11.07 19:06) [363]
Миш, рассмотри коннект к БД Paradox и успокойся. Заодно это и будет комментарий по поводу повисания ресурса

зачем мне парадокс. Я вам задал КОНКРЕТНЫЙ вопрос про файлы в пику вашего разговора о подвисании ресурсов. Вы сделали вид, что этот вопрос не заметили. Ну что сказать ;)

Юрий Зотов © (15.11.07 19:06) [363]
Кстати, ты в курсе, что если программа загрузила DLL, а потом не вызвала FreeLibrary, то эта DLL в текущей сессии системы уже не выгрузится никогда, даже после завершения всех юзающих ее программ? Потому что система будет считать ее используемой.

Кстати, ты в курсе, что если программа захватила объекты GDI и не освободила их, то они будут заняты и после завершения программы?

Кстати, ты в курсе, что объекты ядра тоже могут оказаться занятыми и после завершения программы, если она их не освободила?

не в курсе. Я меня есть вот какой источник информации - фамилия у него Рихтер и вот что он пишет:

[b]Что происходит при завершении процесса:[/b]

1. Выполнение всех потоков в процессе прекращается
2. Все User- и GDI-объекты, созданные процессом, уничтожаются, а объекты ядра закрываются (если их не использует другой процесс)
3. Код завершения процесса меняется созначения STILL_ACTIVE на код, переданный в ExitProcess или TerminateProcess.
4. Объект ядра "процесс" переходит в свободное, или незанятое (signaled) состояние. Прочие потоки в системе могут приостановить свое выполнение вплоть до завершения даного процесса.
5. Счетчик объекта ядра "процесс" меньшается на 1.

Юрий, вы должны согласится, что это достаточно хороший источник, или нет? Я теперь не знаю кому верить. Я пока считаю, что Рихтер описал КАК ДОЛЖНА РАБОТАТЬ Windows, то - что задокументировано. Вы же скорее всего описали как в реальности это обстоит. И это можно назвать БАГАМИ WINDOWS (есть еще один вариант - вы неправы).

Так что вы от меня хотели? Вы хотите, чтобы я знал баги windows перед тем, как с вами разговаривать? Не кажется ли это несколько... мммм... неправильным?

Юрий Зотов © (15.11.07 19:16) [364]
someClass.Free; // Вот в чем фокус

Вот вот. А лучше фокус сделать вот так:

someClass.Close; // Вот в чем фокус. someClass.Free;

Только уж так принято, что сам вызов деструктора и финализация класса вынесены в ОДИН метод. А java позволяет избавиться вот от этого:

someClass.Free;

И в результате должно остаться это:

someClass.Close; // Вот в чем фокус.

а вы убрав СОВМЕЩЕННЫЙ метод говорите - "опля, а java то - хрень полная". Интересный подход! Вы от java требуете, чтобы вообще никакого метода не вызывалось, хотя для delphi не против, чтобы вызывался метод Free. И вы его вызываете, не забываете! А вот вызвать close сложно.

← →
oxffff © (2007-11-15 20:19) [369]

Объяните пожалуйста вкраце что за спор,
а то перечитать 19 страниц я бы рад,

От поста к посту нить разговора теряется.
Вижу только один сплошной finalize.

Есть в JAVA аналог SuppressFinalize из .NET ?

← →
Джо © (2007-11-15 20:36) [370]

> [369] oxffff © (15.11.07 20:19)
> Объяните пожалуйста вкраце что за спор,

Оооо... С этим могут возникнуть сложности :)

← →
Юрий Зотов © (2007-11-15 20:39) [371]

> serger___ (15.11.07 19:42) [367]

Можно привести пример логгера, который:
- открывает файл в своем конструкторе;
- имеет метод записи переданной строки;
- закрывает файл, когда становится не нужен.

← →
Piter © (2007-11-15 20:52) [372]

Юрий Зотов © (15.11.07 20:39) [371]

так что, получается Рихтер неправ?

← →
Юрий Зотов © (2007-11-15 21:22) [373]

> Piter © (15.11.07 20:52) [372]

1. Ты просто его не дочитал. Почитай, что он пишет об аварийном завершении (которое программист тоже должен предполагать).

2. В теории система гарантирует освобождение каких-то (не всех) ресурсов и при аварийном завершении. На практике эти гарантии выполняются не всегда. Примеры тебе уже приводились, и не только мною.

← →
Плохиш © (2007-11-15 22:40) [374]

> oxffff © (15.11.07 20:19) [369]
> Объяните пожалуйста вкраце что за спор

Бесконечный цикл и никакого спора...

← →
iZEN © (2007-11-15 23:20) [375]

> Piter © (15.11.07 17:21) [305]
>
> В чем я с вами согласен, дядь Юра, так это в том, что нефиг
> вообще было включать в Java такое понятие как finalize,
> если оно имеет такой глючный механизм исполнения. Может
> выполнится, а может и нет, это считай говорит о том, что
> никакого кода туда лучше вообще не писать, а тогда и само
> понятие нафиг не нужно.

Золотые слова.
Кстати, Джошуа Блох в том же духе о finalize высказался. ;)

← →
iZEN © (2007-11-15 23:35) [376]

> Джо © (15.11.07 19:38) [366]
>
> > [365] SergeR___ (15.11.07 19:33)
> > si.close(); // Чем отличается?!
>
> Например тем, что у TStream может не быть Close (или Flush)
> и у его потомка TFileStream их нужно будет вводить :) Последствия
> этого — очевидны и я об этом рассуждать не стану.

Таки это предусмотрели в иерархии системных классов Java. ;)

← →
iZEN © (2007-11-15 23:42) [377]

Разрешите подытожить тему.

Описние метода finalize в JavaDoc неного несоответствует действительности. В разных JVM переопределённый в потомках java.lang.Object полиморфный метод finalize не гарантирует своего выполнения никоим образом, вполне допуская возможные утечки памяти из-за неполностью разрушаемых GC объектов (например, в случае выброса заведомо неперехватываемых исключений в теле метода и захвата других ресурсов перед освобождением одних т.д.).

Такое глючное поведение метода finalize в контексте сборщика мусора известно давно и, похоже, программисты на него давно забили. Но Юрий Зотов, такой вот упёртый человечек, пытается нам внушить, что это НЕПРАВИЛЬНО и ТАК_ДЕЛА_НЕ_ДЕЛАЮТСЯ. Согласен. Но лично я ничего с этим поделать не могу.

Мир несовершенен.

← →
Юрий Зотов © (2007-11-16 00:35) [378]

> iZEN © (15.11.07 23:42) [377]

Ну а раз обеспечить надежную работу метода finalize в контексте GC практически нереально, стало быть - что?

Стало быть, ошибочна сама его концепция. И этот заведомо глючный механизм должен быть помечен, как deprecated и постепенно предан забвению.

Это раз.

Но тогда возникает вопрос - если метод finalize объявить нерекомендуемым, то где же тогда освобождать неуправляемые ресурсы? Очевидно, в каком-то другом методе, больше негде. Но вместо того, чтобы отдавать это дело на откуп тысячам разработчиков и плодить зоопарк имен для одного и того же, по сути, метода (close, dispose, cleanup, ... продолжите сами) не лучше ли поступить иначе?

Либо ввести этот метод сразу в класс Object (вариант 1), либо объявить интерфейс IDisposable уже на уровне java.lang (вариант 2). Аналогично Cloneable. И все сразу становится просто и понятно. Я, как пользователь класса, в нужный мне момент либо просто дергаю этот метод (в варианте 1), либо сначала смотрю, реализует ли этот класс IDisposable (вариант 2).

Это два.

Как тут уже многие говорили, никому, конечно же, не влом вызвать метод освобождения ресурсов из своего кода. И это нормально. Ненормально другое - поскольку я не могу знать реализацию юзаемого мною чужого класса, то я не могу и знать, хавает ли этот класс неуправляемые ресурсы, или нет. Соответственно, мне неизвестно надо ли для этого класса вызывать какой-то его метод освобождения ресурсов, или не надо. А если надо, то спрашивается - а как же этот метод в этом классе называется?

В общем, бардак и зоопарк. Которого вполне можно было бы избежать, притом очень легко. И очень странно, что этого не было сделано сразу.

Вот об чем и весь сыр-бор, собственно.

← →
mephasm (2007-11-16 00:41) [379]

Юрий Зотов © (16.11.07 00:35) [378]

Можно уменьшить скоуп ручного контроля за ресурсами, введя что-нибудь подобное LogManager в log4j. Конечно это приносит свои проблемы, но освобождает от других.

← →
iZEN © (2007-11-16 01:06) [380]

> Юрий Зотов © (16.11.07 00:35) [378]
> Либо ввести этот метод сразу в класс Object (вариант 1),
> либо объявить интерфейс IDisposable уже на уровне java.
> lang (вариант 2). Аналогично Cloneable. И все сразу становится
> просто и понятно. Я, как пользователь класса, в нужный мне
> момент либо просто дергаю этот метод (в варианте 1), либо
> сначала смотрю, реализует ли этот класс IDisposable (вариант
> 2).

Не, не пойдёт.
Концепция управляемого языка изменится, а это не входит в планы ни Sun, ни IBM, в общем, никого, кроме вас. ;) Зоопарк с новыми методами очистки будет продолжаться и с этим ничего поделать нельзя. Наверно, это к лучшему, но для вас это выглядит странно, поскольку на Java, ещё раз повторяю, нужно мыслить не в терминах Delphi — мир Java гораздо богаче и допускает наличие определённых глюков. :)

← →
Германн © (2007-11-16 01:27) [381]

> iZEN © (16.11.07 01:06) [380]
>
>
> > Юрий Зотов © (16.11.07 00:35) [378]
> > Либо ввести этот метод сразу в класс Object (вариант 1),
>
> > либо объявить интерфейс IDisposable уже на уровне java.
>
> > lang (вариант 2). Аналогично Cloneable. И все сразу становится
> > просто и понятно. Я, как пользователь класса, в нужный
> мне
> > момент либо просто дергаю этот метод (в варианте 1), либо
> > сначала смотрю, реализует ли этот класс IDisposable (вариант
> > 2).
>
> Не, не пойдёт.
> Концепция управляемого языка изменится, а это не входит
> в планы ни Sun, ни IBM, в общем, никого, кроме вас. ;) Зоопарк
> с новыми методами очистки будет продолжаться и с этим ничего
> поделать нельзя. Наверно, это к лучшему, но для вас это
> выглядит странно, поскольку на Java, ещё раз повторяю, нужно
> мыслить не в терминах Delphi — мир Java гораздо богаче и
> допускает наличие определённых глюков. :)
>

Еще раз хочу кое-что добавить. Насколько я понял посты ЮЗ, суть его высказываний относится не к Delphi, а к общим принципам ООП. В терминах ООП его высказывания кажутся мне весьма обоснованными. В отличии от высказываний его оппонентов.

← →
Канадец (2007-11-16 01:53) [382]

Интерфейс, это контракт. Это обязательство объекта поддержать некую функциональность. Подписывать на это Object не правильно, т.к. 90% объектов не нуждаются в данном контракте и не готовы его имплементировать.

Конечно, несколько неудобно, что java.lang не содержит подобия .NET-кого IDisposable, но как по мне, то неудобством проблема и заканчивается. Если мы говорим о серьёзных разработах и серьёзном проектировании, то никто не мешает на уровне сore библиотек определить этот интерфейс и раз и на всегда забыть про эту проблему. Конечно, мир не идеален и в нём полно "китайских" разработчиков. Вполне возможно кому-нибудь придётся столкнуться с проблемой когда каждый "китаец" по-своему решает где ему релизить ресурсы. Ну а где гарантия, что эти "китайцы" будут для этого использовать IDisposable если он появится в java.lang? Где вообще гарантия, что подобные товарищи будут релизить ресурсы в деструкторах неуправляемых языков? Кто им помешает написать Close (Release, ReleaseAll, Clear and etc.) на Delphi или C++? Так что IHMO проблема всё-таки в головах, а не в языке.

P.S. Ни в коем случае не хотел обидить китайцев, большинство из них очень милые люди :)

← →
Черный Шаман (2007-11-16 02:04) [383]

> Юрий Зотов © (16.11.07 00:35) [378]

Дядя Юра это не поможет. В одном из моих первых проектов когда учился на своих ошибках, так как не у кого было особо спросить(остальные были еще хуже) я деструктор назвал в своих классах

Destructor Free;

Вот так вот жестко. И TObject не спас :) А уровень армии китайских и индусских программистов примерно на том же уровне на котором я был 5 лет назад.

Так что не поможет... индусом много, а проектов мало и каждый индус чтит свою собственную камасутру.

← →
Piter © (2007-11-16 02:15) [384]

Юрий Зотов © (15.11.07 21:22) [373]
Ты просто его не дочитал. Почитай, что он пишет об аварийном завершении (которое программист тоже должен предполагать).

в моем цитировании есть фраза:

"Код завершения процесса меняется созначения STILL_ACTIVE на код, переданный в ExitProcess или TerminateProcess"

Вы хотите сказать, что TerminateProcess - это не аварийное завершение? Я сколько не читал, Рихтер всегда говорил одно - система ДОЛЖНА уничтожать все захваченные ресурсы при завершении процесса, даже если сам процесс этого не сделал. И не только Рихтер это говорил.

Если не сложно - процитируйте тогда слова Рихтера об ином развитии событий.

← →
Piter © (2007-11-16 02:26) [385]

Юрий Зотов, хотя вам конечно лень искать нужное место. Нет проблем, давайте просто поэкспериментируем.

Я взял одну из своих библиотек, обычная DLL, ничего особенного - плагин под Miranda. Берем приложение, код простейший:

procedure TForm1.Button1Click(Sender: TObject); begin LoadLibrary("tz_test.dll") ; end;

Жмакаю на кнопку, библиотека грузится, после чего пытаюсь удалить библиотеку из проводника. Получаю вот это:

http://sovserv.ru/dc/fileexchange/dll_test.gif

Заметьте! Нигде в программе нет FreeLibrary для этой библиотеки и быть не может, так как хэндл не сохраняется.

Я открываю диспетчер задач - снимаю процесс (это не аварийное завершение?!) - и ?!?!? И библиотека спокойно удаляется!

Теперь ваши слова, сказанные с гонором, с упреком:

"Кстати, ты в курсе, что если программа загрузила DLL, а потом не вызвала FreeLibrary, то эта DLL в текущей сессии системы уже не выгрузится никогда, даже после завершения всех юзающих ее программ? Потому что система будет считать ее используемой"

С каких пор дядя Юра система считает библиотеку используемой, но позволяет ее легко удалять?

Мне кажется я предоставляю аргументы.

Если вы сейчас не скажите никакой конкретики, а отмахнетсь только тем, что мол "ты ниечего не понимаешь, иди учи" - то я умою руки, разговаривать в таком ключе бесполезно.

← →
Piter © (2007-11-16 02:29) [386]

весь этот простейший эксперимент можете скачать здесь:

http://sovserv.ru/dc/fileexchange/dll_test.zip (218 KB)

И убедиться самостоятельно.

← →
umbra © (2007-11-16 04:24) [387]

2 Piter ©

если Вы еще не заметили, здесь речь идет не об операционных системах, а о структуре разных языков программирования.

← →
Юрий Зотов © (2007-11-16 05:37) [388]

Миш, задолбал.

"W для П", 3-е издание, стр 47, 4-й абзац сверху. Читай на здоровье.

Это что касается выгрузки DLL. А что касается того, как ты тут неоднократно пытался заставить сборщик мусора еще и ресурсы чистить - ну, тут no comments.

И еще - тебе тут уже подтверждали, что на практике некоторые вещи выглядят не совсем так, как в книжках.

> DiamondShark © (15.11.07 12:10) [252]

В JAVA это декларативно не запрещено. Я могу например вызвать dspose() для JFrame из другого потока (в отличие от .NET, где явный вызов освобождения окна из другого потока вызовет Exception). Более того, поток в JAVA создавший объект класса JFrame в методе main программы не является GUI потоком, обрабатывающим события GUI интерфейса. Поток GUI интерфейса создается при первом вызове метода JFrame.show() или JFrame.SetVisible(true), после чего обычно поток main(первичный поток приложения) и завершает работу(если нет другого кода далее).

Другое дело, что при "работающем" окне не хорошо что-то, что требует синхронизации с потокм GUI, но если ссылки на ресурс обнулены и GC посчитает необходимым освободить ресурс, он его освободит.

Думаю и .NET можно было бы решить этот вопрос через Invoke, в нем окна действительно "принадлежат" создавшему их потоку.

← →
serger___ (2007-11-16 07:34) [390]

Можно привести пример логгера, который:
- открывает файл в своем конструкторе;
- имеет метод записи переданной строки;
- закрывает файл, когда становится не нужен.

public static java.util.logging.Logger log;
...
// Настройка логгирования LogManager manager = LogManager.getLogManager(); Logger log = Logger.getLogger("log.txt"); FileHandler fh; if (lim >=0) fh = new FileHandler(System.getProperty("user.dir")+props.getProperty("logFile"), lim, 1, true); fh.setEncoding("Cp1251"); log.addHandler(fh); manager.addLogger(log); ... log.log(Level.INFO,"Я тут!"); ... log.log(Level.INFO,"Или тут!"); ...

Внутри:

Runtime
/** * Registers a new virtual-machine shutdown hook. * * The Java virtual machine shuts down in response to two kinds * of events: * * <ul> * * <li> The program exits normally, when the last non-daemon * thread exits or when the <tt>{@link #exit exit}</tt> (equivalently, * <tt>{@link System#exit(int) System.exit}</tt>) method is invoked, or * * <li> The virtual machine is terminated in response to a * user interrupt, such as typing <tt>^C</tt>, or a system-wide event, * such as user logoff or system shutdown. * * </ul> * * A shutdown hook is simply an initialized but unstarted * thread. When the virtual machine begins its shutdown sequence it will * start all registered shutdown hooks in some unspecified order and let * them run concurrently. When all the hooks have finished it will then * run all uninvoked finalizers if finalization-on-exit has been enabled. * Finally, the virtual machine will halt. Note that daemon threads will * continue to run during the shutdown sequence, as will non-daemon threads * if shutdown was initiated by invoking the <tt>{@link #exit exit}</tt> * method. * * Once the shutdown sequence has begun it can be stopped only by * invoking the <tt>{@link #halt halt}</tt> method, which forcibly * terminates the virtual machine. * * Once the shutdown sequence has begun it is impossible to register a * new shutdown hook or de-register a previously-registered hook. * Attempting either of these operations will cause an * <tt>{@link IllegalStateException}</tt> to be thrown. * * Shutdown hooks run at a delicate time in the life cycle of a virtual * machine and should therefore be coded defensively. They should, in * particular, be written to be thread-safe and to avoid deadlocks insofar * as possible. They should also not rely blindly upon services that may * have registered their own shutdown hooks and therefore may themselves in * the process of shutting down. * * Shutdown hooks should also finish their work quickly. When a * program invokes <tt>{@link #exit exit}</tt> the expectation is * that the virtual machine will promptly shut down and exit. When the * virtual machine is terminated due to user logoff or system shutdown the * underlying operating system may only allow a fixed amount of time in * which to shut down and exit. It is therefore inadvisable to attempt any * user interaction or to perform a long-running computation in a shutdown * hook. * * Uncaught exceptions are handled in shutdown hooks just as in any * other thread, by invoking the <tt>{@link ThreadGroup#uncaughtException * uncaughtException}</tt> method of the thread"s <tt>{@link * ThreadGroup}</tt> object. The default implementation of this method * prints the exception"s stack trace to <tt>{@link System#err}</tt> and * terminates the thread; it does not cause the virtual machine to exit or * halt. * * In rare circumstances the virtual machine may abort, that is, * stop running without shutting down cleanly. This occurs when the * virtual machine is terminated externally, for example with the * <tt>SIGKILL</tt> signal on Unix or the <tt>TerminateProcess</tt> call on * Microsoft Windows. The virtual machine may also abort if a native method goes awry * by, for example, corrupting internal data structures or attempting to * access nonexistent memory. If the virtual machine aborts then no * guarantee can be made about whether or not any shutdown hooks will be * run. * * @param hook * An initialized but unstarted <tt>{@link Thread}</tt> object * * @throws IllegalArgumentException * If the specified hook has already been registered, * or if it can be determined that the hook is already running or * has already been run * * @throws IllegalStateException * If the virtual machine is already in the process * of shutting down * * @throws SecurityException * If a security manager is present and it denies * <tt>{@link RuntimePermission}("shutdownHooks")</tt> * * @see #removeShutdownHook * @see #halt(int) * @see #exit(int) * @since 1.3 */ public void addShutdownHook(Thread hook) { SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(new RuntimePermission("shutdownHooks")); } Shutdown.add(hook); }

← →
serger___ (2007-11-16 07:34) [391]

LogManager() :
// This private class is used as a shutdown hook. // It does a "reset" to close all open handlers. private class Cleaner extends Thread { public void run() { // If the global handlers haven"t been initialized yet, we // don"t want to initialize them just so we can close them! synchronized (LogManager.this) { // Note that death is imminent. deathImminent = true; initializedGlobalHandlers = true; } // Do a reset to close all active handlers. reset(); } } /** * Protected constructor. This is protected so that container applications * (such as J2EE containers) can subclass the object. It is non-public as * it is intended that there only be one LogManager object, whose value is * retrieved by calling Logmanager.getLogManager. */ protected LogManager() { // Add a shutdown hook to close the global handlers. try { Runtime.getRuntime().addShutdownHook(new Cleaner()); } catch (IllegalStateException e) { // If the VM is already shutting down, // We do not need to register shutdownHook. } } /** * Reset the logging configuration. * * For all named loggers, the reset operation removes and closes * all Handlers and (except for the root logger) sets the level * to null. The root logger"s level is set to Level.INFO. * * @exception SecurityException if a security manager exists and if * the caller does not have LoggingPermission("control"). */ public void reset() throws SecurityException { checkAccess(); synchronized (this) { props = new Properties(); // Since we are doing a reset we no longer want to initialize // the global handlers, if they haven"t been initialized yet. initializedGlobalHandlers = true; } Enumeration enum_ = getLoggerNames(); while (enum_.hasMoreElements()) { String name = (String)enum_.nextElement(); resetLogger(name); } }

> serger___ (16.11.07 07:34) [390]

Вот именно. Простейшая, детская задачка потребовала выкрутасов на уровне хуков VM. Похоже, что-то не так в датском королевстве?

Сколько же можно сокрушаться по поводу несовершенства мира ? :)

> Сколько же можно сокрушаться по поводу несовершенства мира
> ? :)

А никто и не сокрушается. Зотова попросили объяснить, почему он чувствует, что java - это трехколесный велосипед.
Хотя код serger___ показывает, что скорее - это айсберг :)

спор на самом деле ни о чем.
Дельфи не заменяет Явы, Ява Дельфи тоже не заменяет...

> Romkin © (16.11.07 10:34) [394]

Был показан исходный код библиотечного класса, намного превышающий запрошенную функциональность. Я не знаю JAVА достаточно хорошо, но сделать простой однопоточный логгер не проблема, если почитать документацию и использовать правильно например synchronized, то вполне можно использовать и как threadsafe класс.
Быстрое, без синхронизации для многопоточности, без проверок на корректность и проверки на компилируемость - нет JAVA под рукой (Из кода Зотова) - Здесь применено агрегирование, хотя можно было и сделать и с наследованием. Файл закрывается после записи в него строки

public class Loggger {

private FileOutputStream stream;

public Loggger(string FileName) {

string fileName;
try {
fileName=FileName;
}
catch (IOException e) {
e.printStackTrace();
}
}

public void writeString(String s) throws IOException {
stream = new FileOutputStream(fIleName,true);
stream.write((s + "\n").getBytes());
stream.Flush;
stream.close();
}
}

Evgeny V © (16.11.07 11:32) [397]

немного исправил, ибо копи и пасте к дору как всегда не привели

public class Loggger {

private FileOutputStream stream;

potected string fileName;

public Loggger(string FileName) {

fileName=FileName;
}

public void writeString(String s) throws IOException {
try {

stream = new FileOutputStream(fIleName,true);
stream.write((s + "\n").getBytes());
} end try
finally
{
if (null!=stream)
{
stream.Flush;
stream.close();
}//end if
}end finally
catch (IOException e) {
e.printStackTrace();
}//end catch
}//end write string
}//end class

Юрий Зотов © (16.11.07 5:37) [388]
Миш, задолбал

Юрий, вам не надоело это повторять? Мы или разговариваем, или нет. Вы за последние 5 постов не сказали НИЧЕГО КОНКРЕТНОГО, хотя я пытаюсь приводить аргументы, реальные, цитаты, пишу ПРИМЕРЫ ПРОГРАММ. Так скажите сразу - мне мало лет и я ничего не понимаю, и успокойтесь, это в последнее время стандартная тактика.

Я вам написал, чтобы вы хоть что-то конкретное сказали. Вы опять НИ-ЧЕ-ГО не сказали? Где тот Зотов, который ВСЕГДА спорил аргументировано, даже с полными чайниками? Теперь офигевающий от своей крутости профессионал, с нисхождением смотряющий на всех и вся? Ну так честно слово - лучше ВООБЩЕ ничего тогда не писать.

Юрий Зотов © (16.11.07 5:37) [388]
"W для П", 3-е издание, стр 47, 4-й абзац сверху. Читай на здоровье

у меня четвертое издание, страница там о другом эта.

Юрий Зотов © (16.11.07 5:37) [388]
Это что касается выгрузки DLL

а что вы скажите про мой пример? Я вам написал РЕАЛЬНЫЙ пример, библиотека загрузилась - ее удалить нельзя, FreeLibrary не вызывалась, после завершения процесса DLL легко удалилась. Это что, просто так?
Почему вы легко игнорируете "неприятные" вам места? Может, вы это сами объяснить не можете? А зачем тогда на меня гнать, какой я лох?

Юрий Зотов © (16.11.07 5:37) [388]
И еще - тебе тут уже подтверждали, что на практике некоторые вещи выглядят не совсем так, как в книжках

естественно. Но повторюсь - вы с ГОНОРОМ утверждали, что коли я этого не знаю - что мне сюда лезть. А что я по сути не знал? Я не знал о каких-то ГЛЮКАХ WINDOWS. Очень хорошее средство загнобить человека дяд Юра, честное слово - браво! Упрекнуть человека в том, что он не знает о каком-то глюке windows (кстати, еще не доказанном вообще, никаких подтверждений от ВАС не поступало, в отличии от меня) и на самом деле этот глюк мог быть например на XP первой версии, а в SP2 все давно исправили. И на основании этого факта говорить, что я ничего не понимаю.

Следующим шагом будет гнобление по возрасту и вероиспеводению - я так понимаю? Нет слов, сори.

Есть набор совершенно произвольных классов, о каждом из которых известно лишь то, что он имеет метод execute.

Кривобокие несколько классы - творить их нужно в два приема, а убивать хотим одним ударом :-) Иначе говоря, их сначала нужно сотворить, а потом сказать "ха", т.е. вдохнуть в них жизнь, чтобы они зашевелились. Акт творения и оживления, вообще-то, легко было делать в одном лишь конструкторе. Но уж если там, где легко, делаем в два шага, то почему же и на убиение не потратить ровно столько же!

Хотя, я согласен, кривость финализатора не украшает Яву :-)

delphi = pascal = языки для начинающих Найти похожие ветки