Учебник по java.

← →
картман © (2013-04-17 19:47) [0]

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

← →
Дмитрий С © (2013-04-18 00:46) [1]

> создание web-приложений

Грубо говоря сайта?

← →
Компромисс1 (2013-04-18 12:36) [2]

Слишком много всего перечислено. Что нужно, от того и отталкивайся. Можно быть J2EE разработчиком, но не использовать ни аплеты, ни сервлеты. И наоборот )

← →
картман © (2013-04-18 16:09) [3]

> Грубо говоря сайта?

у тру-джавистов нету сайатов - есть веб-приложения, причем, высоконагруженные))

> Что нужно, от того и отталкивайся.

не могу себе представить, как смог бы начать писать на дельфи, называйся книги а-ля джава: технология BeginThread, технология TThread, библиотека Classes, технология TTreeList - вот мне б какое-нибудь на пальцах разъяснение, что такое есть компоненты, многопоточность, что вин-апи, а что стандартная библиотека и что для пользовательского интерфейса.

← →
Компромисс1 (2013-04-18 16:32) [4]

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

Наследование в Java такое же, как в Delphi.
Учить просто Win API не имеет смысла, аналогично и в Java, слишком много классов. "Стандартных" библиотек нет вообще.
Пользовательский интерфейс на Java лучше не писать.

Я "учил" Java по стандартным Java Language Reference Guide с сайта Sun, теперь так не получится, нет такого сайта :)

А если серьезно - при наличии знаний процедурного программирования, ООП, опыта программирования на Delphi могу только повторить - изучать надо средства под конкретную задачу. Я и сам под каждый новый проект бываю вынужден учить новый framework (а ля "стандартная" библиотека). Ни разу не работал с аплетами, threads, аудио, видео и т.д. Зачем же это изучать?

← →
Компромисс1 (2013-04-18 16:37) [5]

Ну вот, нашел навскидку

Java Technologies to Use in Web Applications There are too many Java technologies to list in one article, so this article will describe only the ones most frequently used.

http://www.oracle.com/technetwork/articles/javase/webapps-1-138794.html

← →
Компромисс1 (2013-04-18 16:38) [6]

И продолжение

The number of technologies listed here can appear overwhelming. Keep in mind that you will not need to use them all. In fact, a web application often consists of nothing more than one page created with the JavaServer Pages (JSP) technology. Sometimes you will combine three or more such technologies. No matter how many you end up using, it"s good to know what is available to you and how you can use each one in a web application.

← →
картман © (2013-04-18 17:08) [7]

> Компромисс1 (18.04.13 16:37) [5]

спасибо, именно то, что нужно. Жаль, по ихнему...

← →
Плохиш © (2013-04-18 18:00) [8]

> Учебник по java.

Их примитивная справка, сделанная в последних традициях создания справок, и справка к делфи7.

← →
Vegeta (2013-04-19 00:39) [9]

для начала - http://rutracker.org/forum/viewtopic.php?t=669943
по потокам - "Java Concurrency in Practice"
по J2EE что-то начальное тут: http://javatutor.net/books/tiej но вообще на русском не советую читать.

← →
Vegeta (2013-04-19 00:48) [10]

> Компромисс1 (18.04.13 16:32) [4]
> "Стандартных" библиотек нет вообще.

А JDK - это что?

← →
Юрий Зотов © (2013-04-19 09:03) [11]

> картман © (17.04.13 19:47)
> Учебник по java.
> В первую очередь, интересует создание web-приложений.

А. Л. Фридман.
Построение Интернет-приложений на языке Java. Практический курс.

Пару недель назад купил в книжном магазине у метро "Сокол" (находится на перекрестке Ленинградского проспекта с Балтийской улицей, вход с проспекта). Скорее всего, в продаже еще есть.

А сама Java (J2SE), ее концепции, объектная модель, базовые классы и библиотеки - книга Брюса Эккерта "Философия Java" (в оригинале - "Thinking in Java"). В Инете есть и на русском, и в оригинале.

← →
O'ShinW © (2013-04-19 09:16) [12]

> Юрий Зотов © (19.04.13 09:03) [11]

ява богаче делфи?

← →
Юрий Зотов © (2013-04-19 09:40) [13]

> книга Брюса Эккерта
Эккеля, не Эккерта. Сорри.

> O"ShinW © (19.04.13 09:16) [12]
> ява богаче делфи?

По самому языку - вряд ли. Все то же самое, что и в других языках. Основное отличие - в Джаве "всё есть объект". Даже простейшие скалярные типы (int, double, boolean...) можно представлять и как объект тоже. И все методы в Джаве виртуальные, аналогов дельфишным статическим методов там нет (методы static есть, но это аналоги дельфишных классовых методов).

По сравнению с D7, в Джаве, пожалуй, побогаче RTTI (только там оно называется reflection), но по сравнению с современными Delphi и это примерно одинаково. Еще в Джаве по сравнению с D7 существенно богаче набор коллекций, но в современных Delphi и он тоже есть.

Основное богатство Джавы - это ее библиотеки, которых море (впрочем, как и основное богатство Delphi - это тоже ее библиотеки, которых тоже море). Здесь, пожалуй, Java побогаче будет, но реально нужным это богатство бывает нечасто (разве что потребовалось что-то экзотическое). А на уровне повседневности - примерно одинаково. Особенно, если сравнивать с современными Delphi.

Что не нравится лично мне, так это обилие скобок (снижают читабельность), но это уже мелочи. И что не нравится не только мне - это отсутствие возможности самому уничтожать объекты (сборщик мусора это, конечно, делает, но тогда, когда сам сочтет нужным, а не тогда, когда хочу я).

← →
знайка (2013-04-19 10:41) [14]

> сборщик мусора это, конечно, делает, но тогда, когда сам
> сочтет нужным, а не тогда, когда хочу я
и часто у вас с ним разногласия? и почему?

← →
картман © (2013-04-19 10:58) [15]

> Юрий Зотов © (19.04.13 09:40) [13]

еще среда разработки Delphi по сравнению с Intellij IDEA выглядит блокнотом.

> это отсутствие возможности самому уничтожать объекты

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

← →
Плохиш © (2013-04-19 11:06) [16]

> По сравнению с D7, в Джаве

Ну, современный фиат, то же круче по начинке мерседеса 20летней давности :-)

PS. A static, что в джаве, что в .net, это обычные глобальные переменные, без которых, как бы не визжали о вреде и мастдай, так современные дерьмокодеры кодить и не научились.

← →
Плохиш © (2013-04-19 11:08) [17]

> как быстро сборщик решает, когда ему освободить ресурсы?

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

← →
icelex © (2013-04-19 11:09) [18]

> еще среда разработки Delphi по сравнению с Intellij IDEA
> выглядит блокнотом.

делфи даже по сравнению с эклипсом выглядит блокнотом :D

> это очень плохо... и как быстро сборщик решает, когда ему
> освободить ресурсы? Мне как раз решать задачу со-множеством
> вновь создаваемых объектов.

ну, если уж совсем зудит, то System.gc()
а вообще, не твое это дело следить за ресурсами в java

← →
icelex © (2013-04-19 11:14) [19]

> а вообще, не твое это дело следить за ресурсами в java

пробакланил: за управляемыми ресурсами; неуправляемые будь бобр закрывай за собой

← →
Юрий Зотов © (2013-04-19 11:30) [20]

> знайка (19.04.13 10:41) [14]
> и часто у вас с ним разногласия? и почему?

Возникают редко, но уж если возникают, то бороться с ними гораздо сложнее, чем было бы в Delphi (где ненужные объекты можно просто уничтожить). Вот реальный пример.

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

Сразу после обработки каждого объекта из списка было бы самое время уничтожить этот объект - он уже не нужен. Но сборщик мусора этого сделать не может, потому что ссылка на объект есть в самом списке. Сборщик мусора сможет убить объект только после его удаления из списка (вариант "переменная списка переинициализирована, либо вышла из области видимости" не рассматриваем, потому что это произойдет лишь в конце работы программы).

Но даже и после удаления объекта из списка сборщик мусора убивает его не сразу, а когда сам захочет - то есть, какое-то время уже ненужный объект еще висит в памяти. А за это время программа уже успела прокрутить несколько новых циклов - то есть, построить и обработать несколько новых списков (объекты из которых тоже пока еще висят в памяти). И т.д.

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

Картину эту позволил выяснить лишь специальный мониторинг (мы же доверяем сборщику мусора? поэтому все были уверены, что объекты освобождаются). И мониторинг показал, что количество "зависших" объектов исчисляется чуть ли не миллионами, а памяти они отжирают немеряно.

Принудительный вызов сборщика мусора к успеху не привел (почему - никто не знает). Пришлось перекраивать алгоритм - искусственно ограничивать длину списка. Что и читабельность снижает, и алгоритм усложняет, и намного более трудоемко, чем был бы простой вызов Free.

← →
Компромисс1 (2013-04-19 11:36) [21]

> И что не нравится не только мне - это отсутствие возможности
> самому уничтожать объекты (сборщик мусора это, конечно,
> делает, но тогда, когда сам сочтет нужным, а не тогда, когда
> хочу я).

Зачем это нужно? По соображениям безопасности?
Можно присвоить переменной null и вызвать принудительную сборку мусора. Только это не рекомендуется обычно.

← →
Компромисс1 (2013-04-19 11:41) [22]

> Картину эту позволил выяснить лишь специальный мониторинг
> (мы же доверяем сборщику мусора? поэтому все были уверены,
> что объекты освобождаются). И мониторинг показал, что количество
> "зависших" объектов исчисляется чуть ли не миллионами, а
> памяти они отжирают немеряно.

Странно. Либо баг, либо надо было настроить сборщик мусора.

← →
O'ShinW © (2013-04-19 12:01) [23]

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

А.. Ну теперь все понятно

в другом месте :)
Работает приложение, сервлет. Присоединился клиент, что-то сделал, что-то сделал - ушел. Секунд 5.
По логам, мониторингу запросов - постоянно штук 20 активно,
А по объемам памяти и кол-ву открытых коннектов - на порядок больше, и даже еще больше.
Картина маслом: Все работают, коннектов over 1000, своппинг зашкаливает.
Сервис рубанул, опять запустил - красота.
И начался рост потребления ресурсов.А по логам - никто ничего больше нормы не делает.
Поди тоже - тупо не убиваются

← →
Компромисс1 (2013-04-19 12:14) [24]

O"ShinW © (19.04.13 12:01) [23]

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

← →
знайка (2013-04-19 12:15) [25]

> Юрий Зотов © (19.04.13 11:30) [20]

> Потом эти объекты обрабатываются в цикле и после цикла ссылок
> на эти объекты уже нет.
............
> Но сборщик мусора этого сделать не может, потому что ссылка
> на объект есть в самом списке.
тут не понятно, где нет? локальная переменная из области видимости ушла? так это ничего не значит, коли список еще жив..
отработали цикл, почистите список...

← →
jack128_ (2013-04-19 12:29) [26]

> И мониторинг показал, что количество
> "зависших" объектов исчисляется чуть ли не миллионами, а
> памяти они отжирают немеряно.

а джависты так на могучий escape analysis фапают...
А кстати, вы какую версию JVM используете??

← →
картман © (2013-04-19 13:45) [27]

> Странно. Либо баг, либо надо было настроить сборщик мусора.

> Держу пари, что настроен слишком большой кэш коннектов.

а GC vs NotGC - холивар?

← →
Компромисс1 (2013-04-19 13:53) [28]

> Держу пари, что настроен слишком большой кэш коннектов.

Я имел в виду, что наверняка используется какой-то J2EE контейнер, в котором какой-нибудь MAX_CONNECTIONS равен 10000. Лечится уменьшением значения, возможные баги сборщика мусора тут совершенно ни при чем

← →
O'ShinW © (2013-04-19 13:58) [29]

> Компромисс1

я молчу ,потому что ничего не могу сказать :)
Мне прислали с инструкцией по установке, я поставил
и чего там именно какое значение имеет - не знаю.

Но поведение очень похоже на то, что ЮЗ написал

← →
Компромисс1 (2013-04-19 14:01) [30]

O"ShinW © (19.04.13 13:58) [29]

Я гений :)

maxConnections The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will not accept any more connections until the number of connections falls below this value. The operating system may still accept connections based on the acceptCount setting. Default value varies by connector type. For BIO the default is the value of maxThreads unless an Executor is used in which case the default will be the value of maxThreads from the executor. For NIO the default is 10000. For APR/native, the default is 8192.http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

← →
Компромисс1 (2013-04-19 14:02) [31]

Хотя нет, это не кэш. Я не гений :)

← →
Компромисс1 (2013-04-19 14:06) [32]

Больше похоже на

Tomcat maxThreads represents the maximum number of request processing threads to be created by the HTTPConnector.

Default 250

← →
O'ShinW © (2013-04-19 16:46) [33]

> Компромисс1 (19.04.13 14:06) [32]

попробую

← →
Юрий Зотов © (2013-04-19 17:47) [34]

> Компромисс1 (19.04.13 11:41) [22]

> Либо баг
После долгих поисков причину мы все же нашли, она описана в [20]. Если это и баг, то не наш.

> либо надо было настроить сборщик мусора.
Пытались, причем не только мы сами, а еще и специалисты всемирно известной фирмы, в рамках техподдержки. Нужного результата не получилось ни у кого. Почему - сие неведомо, все вроде бы делали по документации.

PS
Заметьте, что если бы было можно просто убить объект руками, то не было бы никаких проблем.

← →
Юрий Зотов © (2013-04-19 18:02) [35]

> знайка (19.04.13 12:15) [25]

Структура кода такая:
for (Iterator iter = myList.iterator(); iter.hasNext();) { MyClass myObject = (MyClass) iter.next(); // Здесь операции с myObject iter.remove(); }
Как видите, объект из списка удаляется и на следующей итерации цикла (а также после завершения цикла) должен бы быть убит сборщиком мусора. Но сборщик мусора не торопится, а пока он дремлет, программа успевает построить и обработать новый myList - далее см. [20].

А если бы в самом конце цикла можно было поставить myObject.Free, то не было бы никаких проблем.

← →
картман © (2013-04-20 01:29) [36]

я так понимаю [27] был проигнорен в виду очевидности?
Тогда переиначу: на кой хрен нужен сборщик мусора, избавляющий от очевидных проблем, но вносящий непредсказуемые?

← →
Юрий Зотов © (2013-04-20 13:26) [37]

> > O"ShinW © (19.04.13 09:16) [12]
> > ява богаче делфи?

Забыл добавить - а вот построение GUI в Delphi на два порядка лучше.

← →
Плохиш © (2013-04-20 14:27) [38]

Про приоритет сборщика сказано в [17], и это документировано. Но все почему-то надеятся на чудо.

← →
wl © (2013-04-20 16:47) [39]

> Компромисс1 (19.04.13 11:36) [21]
> Можно присвоить переменной null и вызвать принудительную
> сборку мусора. Только это не рекомендуется обычно.

в j2me на дохлых мобилах этим грешил даже сам Gameloft. игрушки не падали, покупатели счастливы

← →
Компромисс1 (2013-04-22 10:17) [40]

> Тогда переиначу: на кой хрен нужен сборщик мусора, избавляющий
> от очевидных проблем, но вносящий непредсказуемые?

Если для системы, то:
1. Надежность
2. Безопасность

Если для программиста, то:
1. Удобство разработки
2. Скорость разработки

Никогда не имел проблем со сборщиком мусора, наверное, мне повезло. Точнее, скорее не повезло тем, кто имел проблемы, я впервые о таком слышу.

← →
Юрий Зотов © (2013-04-22 10:42) [41]

> Компромисс1 (22.04.13 10:17) [40]

Гм... а как сборщик мусора влияет на надежность и безопасность?

Все же серьезные программы, где действительно требуются надежность и безопасность, пишутся, надеюсь, не юными пионерами, которые забывают поставить finally Free.

← →
знайка (2013-04-22 10:43) [42]

> Никогда не имел проблем со сборщиком мусора, наверное, мне
> повезло. Точнее, скорее не повезло тем, кто имел проблемы,
> я впервые о таком слышу.
аналогично.

← →
картман © (2013-04-22 10:46) [43]

> Никогда не имел проблем со сборщиком мусора,

ну, а я не имел проблем с утечкой памяти

← →
Компромисс1 (2013-04-22 10:57) [44]

> Гм... а как сборщик мусора влияет на надежность и безопасность?
>
>
> Все же серьезные программы, где действительно требуются
> надежность и безопасность, пишутся, надеюсь, не юными пионерами,
> которые забывают поставить finally Free.

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

← →
Компромисс1 (2013-04-22 10:58) [45]

> ну, а я не имел проблем с утечкой памяти

Прекрасно, когда человек рождается с безусловным рефлексом писать Free везде, где надо. Большинству не так повезло.

← →
картман © (2013-04-22 11:51) [46]

> с безусловным рефлексом писать Free везде, где надо

боже упаси, но пропущенный Free находится моментально

← →
Компромисс1 (2013-04-22 11:57) [47]

> боже упаси, но пропущенный Free находится моментально

Это и называется ненадежность: когда ошибки исправляются после их выявления, а не предотвращаются заранее. Еще в Java нет pointer и связанного с ним выделения памяти - когда от профессионализма программиста зависит, будет ли освобождено именно то, что было запрошено у менеджера памяти. А ведь можно еще попытаться вернуть не всё и не сразу, тут еще больше простора для возможных ошибок.

← →
картман © (2013-04-22 12:21) [48]

> Еще в Java нет pointer

и это вот очень хреново! Может, есть возможность как-нибудь им попользоваться?

← →
Компромисс1 (2013-04-22 12:25) [49]

> и это вот очень хреново! Может, есть возможность как-нибудь
> им попользоваться?

Зачем?

> Зачем?

например, есть у меня дерево в дельфи:
TMyRec = record
Next: Integer;
Prev: Integer;
SomeVal: Integer;
end;

TMyArray = TArray<TMyRec>;

в дельфи можно шустро сохранять/загружать этот массив с/на диск одной операцией.

а как сделать подобное на джаве?

← →
Компромисс1 (2013-04-22 12:38) [53]

Вот, нашел в инете

FileOutputStream fos = new FileOutputStream("c://list.ser");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(treemap);
oos.close();

> это массив вроде )

дерево в массиве

> Компромисс1 (22.04.13 12:38) [53]
>
> Вот, нашел в инете

дык, дело не в принципиальной невозможности, а в том, как это будет происходить? Думаю, что в цикле и пообъектно - что есть зло и медленно

← →
Компромисс1 (2013-04-22 12:46) [56]

> дык, дело не в принципиальной невозможности, а в том, как
> это будет происходить? Думаю, что в цикле и пообъектно -
> что есть зло и медленно

Необязательно. Есть System.arraycopy, например.

Ты в курсе, что Java в принципе медленнее, чем native языки (Delphi тоже native)?

← →
Компромисс1 (2013-04-22 12:49) [57]

Хотя вообще-то это стандартная сериализация (если ссылок нет). Так что никакого цикла быть не должно.

Удивительно как Java стала такой популярной.

← →
Компромисс1 (2013-04-22 12:56) [59]

> Удивительно как Java стала такой популярной.

One of the main reasons Java is so popular is its platform independence, which means that Java programs can be run on many different types of computers.

http://www.dummies.com/how-to/content/what-is-java-and-why-is-it-so-great.html

И всё? Фрипаскаль что-то не такой популярный пока.

> Удивительно как Java стала такой популярной.

задача: сделать А
решение: использовать объект для решения А

> Необязательно. Есть System.arraycopy, например.
Хотя вообще-то это стандартная сериализация

ну, надо смотреть, что за arraycopy и как там сериализация устроена

← →
Компромисс1 (2013-04-22 13:03) [62]

> ну, надо смотреть, что за arraycopy и как там сериализация
> устроена

В любом случае это проблема класса, который сериализуется. Если есть способ избавиться от цикла, со временем он появится в реализации, а клиентский код не придется менять.

← →
Компромисс1 (2013-04-22 13:07) [63]

> И всё? Фрипаскаль что-то не такой популярный пока.

Кто знает, что было бы с Фрипаскаль, если б он имел сборщик мусора :)

← →
Компромисс1 (2013-04-22 13:09) [64]

Кстати, нашел подтверждение своей точки зрения, что не надо учить "Java как таковую", а только то, что надо.

The Java language has only 50 keywords, but the Java API has several thousand classes — with tens of thousands of methods you can use in your programs.

You don"t have to learn anywhere near all of the Java API. Most programmers are fluent with only a small portion of it. If you need to use some class from the API that you aren"t yet familiar with, you can look up what the class does in the Java API documentation.

http://www.dummies.com/how-to/content/what-is-java-and-why-is-it-so-great.html

> Компромисс1 (22.04.13 10:57) [44]

Уверяю Вас (и жизнь это подтверждает), что если программист способен упустить из виду finally Free, то он непременно накосячит где-то еще, причем никакой сборщик мусора ему не поможет. Например, ResultSet не закроет, или закроет, но не в finally - и есть еще сто миллионов мест, где можно накосячить.

Доверять таким людям серьезные проекты просто нельзя. А те, кому доверять можно, finally Free уж точно не забудут.

← →
Опытный (2013-04-22 17:53) [66]

тому кто любит яву, нельзя доверять серьезные проекты.
ибо будут делать силами 5хN программистов в течение 5хM лет.

Где N и M - число программистов на нормальном языке и количество их лет на разработку такой же точно системы.

разница лишь в том, что у первых после 5хM лет будет первая глючная и тормозная пре-альфа, а у вторых - десятый стабильный релиз.

> Опытный (22.04.13 17:53) [66]

кстати, да, видел один такой проект, думал - исключение, ан нет...

← →
компромисс1 (2013-04-22 20:07) [68]

Юрий Зотов © (22.04.13 17:42) [65]

Моя практика говорит об обратном - всегда есть место для ошибок и человеческий фактор никто не отменял. Unit tests не только новички используют. Или скорее, вовсе не новички

← →
компромисс1 (2013-04-22 20:09) [69]

Опытный (22.04.13 17:53) [66]

Доля истины в этом есть, только дело вовсе не Java, а в размере организации. Зачастую на Java реализуют enterprise level системы с сотнями разработчиков.

Учебник по java. Найти похожие ветки