- 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
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
public Miner(String s) {
super(s);
MenuBar mb = new MenuBar();
setMenuBar(mb);
Menu mFile = new Menu("Файл");
Menu mHelp = new Menu("Справка");
mb.add(mFile);
mb.setHelpMenu(mHelp);
MenuItem create = new MenuItem("Новая игра",new MenuShortcut(KeyEvent.VK_N));
Menu mColor = new Menu("Цвет");
MenuItem mGreen = new MenuItem("Зелёный");
MenuItem mRed = new MenuItem("Красный");
MenuItem mBlue = new MenuItem("Синий");
MenuItem mGray = new MenuItem("Серый");
mColor.add(mGreen);
mColor.add(mRed);
mColor.add(mBlue);
mColor.addSeparator();
mColor.add(mGray);
Menu mHard = new Menu("Сложность");
MenuItem mDummy = new MenuItem("Новичок");
MenuItem mUser = new MenuItem("Среднячок");
MenuItem mHaker = new MenuItem("Проффи");
mHard.add(mDummy);
mHard.add(mUser);
mHard.add(mHaker);
MenuItem mSound = new MenuItem("Звук");
mSound.setEnabled(false);
MenuItem exit = new MenuItem("Выход",new MenuShortcut(KeyEvent.VK_X));
mFile.add(create);
mFile.add(mColor);
mFile.add(mHard);
mFile.add(mSound);
mFile.addSeparator();
mFile.add(exit);
Scribble scr = new Scribble(this,480,480);
mGreen.addActionListener(scr);
mRed.addActionListener(scr);
mBlue.addActionListener(scr);
mGray.addActionListener(scr);
add(scr);
Difficult diff = new Difficult(this,480,480);
mDummy.addActionListener(diff);
mUser.addActionListener(diff);
mHaker.addActionListener(diff);
add(diff);
create.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
status = 0;
repaint();
RandomArray();
}
});
exit.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
System.exit(0);
}
});
MenuItem mInfo = new MenuItem("О программе",new MenuShortcut(KeyEvent.VK_H));
mHelp.add(mInfo);
mInfo.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
new AboutProgram("О программе");
}
});
setBounds(0,0,480,480); // setSize(480,480);
setVisible(true);
setLayout(null);
addMouseListener(this);
addWindowListener(new WinClose());
}
Follow us!
када засирается память - все рушицо нахуй или жоска тормозит. нормальной жавапрограмме достаточна часа работы для наступления пиздеца :)
а хуле - индусы же не знают что такое деструктор и что память чистить надо. потому в жабе ево и нет :)
> нормальной жавапрограмме достаточна часа работы для наступления пиздеца :)
тогда её код нужно выкладывать сюда
> индусы же не знают что такое деструктор и что память чистить надо.
это вы не знаете, если так судите.
а правила управления памятью в жабке довольно простые:
1.повторно использовать обьекты - вместо создания новых.
это касается this.getSize(size) вместо size=this.getSize(), Integer.valueOf(i) вместо new Integer(i) и list.clear() вместо list=new ArrayList(); а так же совместно используемых ресурсов
2. уничтожая созданный обьект - уничтожать ВСЕ ссылки на него.
В том числе: удаление из коллекций, разрегистрирование слушателей, если перезагружаем класс - то не забываем избавиться и от соотв. classloader'а (во избежание outofmemory error:permgen space). Здесь же хочется упомянуть про грамотный выход (не System.exit()).
3. используем ленивую загрузку (late binding) ресурсов, не забывая, что в отличие от дотнета, виртуальная машина не будет кормить нас доп.памятью. и загружаем в память только то, что необходимо сейчас (картинки тоже поменьше, а не 2000х3000). А для кеша есть такая замечательная штука, как WeakHashMap :)
а еще прекрасно помню как начали свинг внедрять тогда когда средний комп имел 32 мега оперативы. было от чего посрать кирпичами :)
еще прекрасно знаю как при работе томката и оперфайра засираецо память.
10-15 дней и процесс надо перегружать иначе он сука блянеработоспособен.
ну или выделяе ему ищо и ищо рамы. ога.
или ебись с опцияме gc типо -Xincgc которые вроде облегают тока VM от этова чутка медленнее становицо. в общем нахуй.
нормальные суровые мущины пишут демоны на C
> нормальные суровые мущины пишут демоны на C
где утечка мозгов вероятна ничуть не меньше
сделайте дамп, и посмотрите йоркитом -- чем засрана куча
наверняка она засрана Вашими же классами)
пишут конечно, но не энтерпрайз проекты а небольшие но требовательные к производительности проги
все таки нужно понимать что у разных языков разная область применения
tomcat: может быть в те времена, когда было 32 -- томкат и тек памятью. сейчас он у меня работает месяцами (и джетти тоже) и что я делаю не так?)
Памятью текут говнопрограммы, но это решается профилированием и йоркитом.
и да: когда мне надо сделать СRM уровня salesforce, я конечно пишу его на сях. Причем с ноля, и протокол HTTP сам реализовываю, ага))))) Ну просто у меня есть пара лет свободного времени
Реализовать протокол HTTP - можно меньше чем за месяц (если не торопиться).
Ну и язычёк...
<frammarNazi>и девчЁнка, угу</grammarNazi>
ну всё дело в том, что там примерно такое:
Специально для Вас:
язычЁк
Табличку сарказм поднять? )
>дело в том
ОК. Думал Вы прo int getSize()
> int getSize()
это мой фейл, скопропастил.
size=this.getSize()
до
this.getSize(size)
А у Java как с этим дела обстоят?
Я, как программист, должен заботиться о грамотном построении аппликации самостоятельно, а не надеяться, как макака, что мне все равно подотрут жопу
мы видим как пример пхп, с теми же, скажем, волшебными кавычками, который пытался подтирать жопу горе-кодерам, которые не знали, что параметры надо перед выводом эскейпить - и сильно обосрался.
Отсюда я делаю вывод, что принцип "наименьшей неожиданности" все же должен соблюдаться
А как нужно и почему?
>System.exit() немедленно убивает всю виртуальную машину
Тоесть System.exit() может убить одновременно несколько приложений? ОМГ. Какой удар по безопасности...
>Несколько аппликаций могут разделяться одной виртуальной машиной
А можно "срать" в соседние аппликации?
>Несколько аппликаций могут разделяться одной виртуальной машиной
Тоесть, если аппликация за собой до конца не почистит при завершении, то таким образом часть ресурсов может быть захвачена убитой аппликацией?
ну, вообще и тут подумано. Например, броузер использует одну ВМ для всех апплетов, но в тех же апплетах System.exit() вызовет SecurityException. Все зависит от методов запуска. Если мы вызываем процесс java.exe, то приложение запустится в новой ВМ.
> А можно "срать" в соседние аппликации?
в аппликации, наверное, только с помощью JNI. А вот в апплетах есть, кажется, AppletContext.getApplets(), c помощью которого можно общаться с другими апплетами
> Тоесть, если аппликация за собой до конца не почистит при завершении, то таким образом часть ресурсов может быть захвачена убитой аппликацией?
смотря о каких ресурсах говорим. В общем случае, ВМ сама пытается убирать после себя(закрывает сокеты, снимает блокировки файлов, закрывает соединения,стримы и т.д.). Но, например, если вы используете файлы-"семафоры"(может, так захотели предотвратить запуск более одной копии аппликации), то, очевидно, что это уже для ВМ слишком умно. Также в этом случае могут быть не опустошены буферы потоков(Stream, не Thread)
> Страсти то какие...
Это еще что. Меня вот вообще некогда убило наличие Field.setAccessible(boolean), который через отражение позволяет вопреки принципам ООП получать доступ к приватным полям.
"You can never be too safe" (ц)
Ну это врятли кто-то будет использовать. Покрайней мере на говнокоде пока такого кода не видел, тк это не удобно. Обычно говнокодеры лёгким движением руки исправляют private на public.
Зато крайне полезно для организации unit- test и особенно serialization.
В С++ рефлектора нет и паттерн serialization приходится реализовывать вручную, а не делать это автоматически за пару строчек.
Например, в том же мной хваленом java-фреймворке Tapestry5 пишем
что потом преобразуется в
и попытка написать
приведет к TapestryException: property field must be private
Впрочем, быть может, для этого и не используется именно упомянутая фишка. Не знаю, что там Javassist генерит в рантайме
Я принципиально никогда не трогаю минус.
Лично я считаю, что и ненужно абсолютно все пихать в один язык. Пусть каждый реализует свою идеологию и используется по своему назначению. Благо языков сейчас дохренища
на самом деле в томкат может несколько war загрузить и крутить.
там весь ввод/вывод, системная требуха - не минует SecurityManager.
если его врубить - часть аппликух типа того же jforum резко перестает работать(о ужас).
я как-то конфигурил томкат чтобы и секурити была и то что надо работало
и не суди о языке/платформе по тому, как на ней пишут твои одноклассники.
и про System.runFinalization();
и про finalize и зануление указателей знаю.
говно есть говно - с чисткой там всегда было плохо.
а ебнуть объект у кодера нет никакой возможности - хоть обобнуляйся указателев.
Да, пул памяти проблему частично решает(шоб срать было на gc). но именно что частично. ибо не для всех задач подходит.
ну если правда ссылок нет, то System.gc() как бе должен грохнуть обьект. Хотя это и не обязательно
> ибо не для всех задач подходит.
вот! не для всех задач. Если вам критично, полно других прекрасных языков. Но на Java можно написать многое и красиво.
ИМХО, в Java самый красивый кодстайл и ООП (в отличие от того же пхп)
Нет. Их куча, особенно, если активно используется наследование и включение. Для каждого потомка и включаемого объекта приходится писать вызов уничтожения объекта вручную.
А если сложная логика обработки исключений, то finally тоже много получается...
Если этот объект владел ресурсами, то он так и оставит эти ресурсы заблокированными, пока не произойдёт очистка объекта через GC, а она может произойти, например, когда приложение будет завершаться, когда будет уже поздно.
Допустим, открыли мы в конструкторе объекта файл на запись, затем объект уже не используется, но сборщиком мусора ещё не удалён, а значит файл не закрыт.
Мы опять конструируем этот объект и он пытается открыть тот же файл, но файл занят и конструирование не удаётся, тк не удаётся открыть файл.
в крестах надо удалять за собой объекты
в сях надо отдавать память
в жабе надо закрывать файлы
нет?
Впрочем, Вы уже сказали, что в Java - многословный язык с лишними словами...
элегантного решения нет
в C# есть using, кажется в седьмой жабке будет что-то типа этого
Не очень красивое решение, но много лучше finally.
Какие?
>не менее элегантные, чем в C#
В C# не элегантный способ, а костыль. Хоть using лучше finally, но в C# он иногда глючит...
по этому хорошим тоном считается закрывать их в том же месте, где и открыл.
Тоесть херово открыть файл (или коннекшен), положить его дескриптор в свойство объекта, объект в кучу, и ждать 100500 лет пока GC его удалит (GC, кстати, может никогда не удалить объект, если памяти много -- а знач finally никогда не вызовеца).
За открытие и закрытие внешних ресурсов должен отвечать один класс, и надо бы спроектировать его так, что бы риск утекания его объектов был минимальным)
в сях++ конечно проще: delete, и точно знаешь что все файлы (и дефицитные ресурсы типа коннектов к бд) закрылись.
с другой стороны, надо всегда явно удалять объекты (ну или полагаться на автоматические средства типа auto_ptr) а это тоже бойлерплейт, не хуже файнали))
жаба очень многословный язык, там очень много буков писать надо
но с другой стороны с современными иде это не оч напрягает
>жаба очень многословный язык
Не очень, но всё-таки страдаете? ))
>жаба очень многословный язык
Операторы не поддерживает и шаблоны не всеми версиями...
да. не все в жабе прекрасно.
>>Операторы не поддерживает и шаблоны не всеми версиями...
перегрузку операторов, Вы имеете ввиду?
Это не самый страшный грех. Я уже привык без нее, впринципе не очень напрягает.
Шаблоны -- это генерики? Ну так он их уже лет 5 как поддерживает (хотя и не так красиво, как clr) -- слава богу я уже давно пишу на шестой жабе, там с этим проблем нет.
вот чего мне не хватает в жабе -- так это множественного наследования.)))
PS: сиплюсплюсник детектед)
Да, но не на все платформы есть новая Java с генериками.
>Шаблоны -- это генерики?
Нет. Генерики - это частный случай шаблонов, притом очень скудой, по сравнению с ними по возможностям.
например где ее нет?
на макоси классической разве что
на линухе есть (штуки четыре)
на винде есть
даже на фре есть
>>Генерики - это частный случай шаблонов
так вроде бы в джаве только генерики и были. Шаблонов в плюсовом понимании не было
Это же явно лучше.
и вынести из него локализацию
тут хотя бы в гуи нет бизнес-логики -- и то хлеб)
"чучело на букву м" -- творческий псевдоним автора