Говорят, java - универсальный язык программирования

>Говорят, java - универсальный язык программирования

Брешут.

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

Нужно знать ооп и его недостатки, знать английский и не иметь бана в гугле.

/me j2ee programmer: spring, wicket, jpa, maven, eclipse, jetty, JUnit, Junit, JUnit, Junit, JUnit, Junit, JUnit, Junit...

и не практиковать копипейст :)

> какие существуют специализации у программистов, использующих преимущественно java (имеется ввиду тех, которые зарабатывают этим на жизнь)

Работа дешёвой рабочей силов при написании GUI- или Web-обёрток к базам данных.

Остальные специализации программистов, использующих жаву, с ней мало связаны.

> какие технологии необходимо знать для той или иной специализации?

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

Серверные приложения на яве вроде пишут. Кроме того, у меня товарищи работают в одной англо-русской конторе - они делают системы составления расписаний.

жаба хороша только для низкоквалифицированных кодеманкейс. 

«Универсальный» != «В каждую бочку затычка».

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

> Технолонии учить по мере погружения ибо их дофига

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

JEE - это, я так понял, основное, чем занимаются программисты, использующие java (далее java-программисты). Там куча всего, но это все web как бы, так? Т.е. делание сайтов, web-сервисов, так? Ну тут наверное тоже как-то подразделяются, кто фронтенд, кто бекэнд делает, так?

ps извините за сумбур, освоил Java Core и думаю что дальше, просто тут так много buzzwords, что право слово и не знаешь за что взяться, для чего вообще половина предназначена.

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

А это модно так. Назвать загадочной аббревиатурой. Чем проще вешь, тем у нее серьезнее название.

Толстое заглавие - позволяет раздуть срач из которого автор выделит суть раскрывающую его вопрос, зри в кроень!

Толстое заглавие позволяет тебе пометанировать на неделю вперёд.

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

> А это модно так. Назвать загадочной аббревиатурой. Чем проще вешь, тем у нее серьезнее название.

А у физматовцев и мехматовцев баззвордов разве меньше? :) особенно названия предметов

> А у физматовцев и мехматовцев баззвордов разве меньше? :) особенно названия предметов

Вот на военной кафедре есть названия из 25 букв, которые при этом являются аббревиатурой. Точно не помню, но что-то типа ППУОЭРТОВНП...

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

Я бы отметил такие:

1. Любое, в т.ч. простейшее приложение, будет стартовать как минимум 0.1 мс. Для больших приложений это, понятное дело, не принципиально.

2. Это не си. Как, впрочем, и любой другой язык, который не си.

3. По производительности в 2 раза (1.5 .. 3) уступает сям. Как, впрочем, и многие другие языки, которые не си.

4. Не имеет типа complex. И этот complex нельзя эффективно реализовать ООП-шными средствами, т.к. массив таких Complex'ов будет просто массивом ссылок на объекты в свободной памяти. Впрочем, это большое неудобство - но не фундаментальная беда.

5. Имеет малозаметные, но труднопреодолимые ограничения в "стандартных библиотеках". Например, было дело (раньше это было так, но не знаю как сейчас), что её сетевая подсистема навсегда кэшировала все DNS-записи (как следствие, прокси, написаный на Java, приходилось ежедневно перезапускать).

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

Плюсы, наверное, ты и так знаешь.

Я программирую в основном на Java (обычная J2SE); задачи разные, к самой "технологии" никак не привязаны.

>слабые места (не связанные с памятью о Томми).

>2. Это не си.

>…. уступает сям.

Это не си! Это ява.

> 5. Имеет малозаметные, но труднопреодолимые ограничения в "стандартных библиотеках".

Особенно органично смотрится

List<Integer> a = new List<Integer>();
a.add(1).add(3.141592565).add("jopa");

которое скомпилируется безо всяких нареканий. :)

хм, нетбинс такое непроглатыват.

А орешки непростые, все скорлупки золотые!

Вы о чём?

$ javac A.java
A.java:6: boolean cannot be dereferenced
a.add(1).add(3.141592565).add("jopa");
^
1 error


$ javac A.java
A.java:7: cannot find symbol
symbol : method add(double)
location: interface java.util.List<java.lang.Integer>
a.add(3.141592565);
^
A.java:8: cannot find symbol
symbol : method add(java.lang.String)
location: interface java.util.List<java.lang.Integer>
a.add("jopa");
^
2 errors

> хм, нетбинс такое непроглатыват.

Поправили в новой жабе значит. Ранее в List.add аргументом стоял Object.
Пруфлинк: http://www.math.tu-berlin.de/geometrie/f5/j2sdk_docs/api/java/util/List.html#...

Поправили с тех пор как появились генерики http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html#add(E) а это было в мохнатыя времена, ты яву когда последний раз видел?

> Ранее в List.add аргументом стоял Object

Ага, в 1.4 и ранее. Но, если используете 1.4, то не пишите ни List<Integer> (generics: 1.5 and higher), ни add(1) (autoboxing: 1.5 and higher).

Если вы ненавидете жабу - не трогайте её, и да не нагонит вас Томми.

> Поправили с тех пор как появились генерики http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html#add(E) а это было в мохнатыя времена, ты яву когда последний раз видел?

Полгода назад. В эклипсе стояла совместимость с 1.5, так что это компилилось.

>Ранее в List.add аргументом стоял Object.

Это было до 1.5.

>Полгода назад. В эклипсе стояла совместимость с 1.5, так что это компилилось. В 1.5 много полезного добавили, covariant returns, например.

А чем компилировали ? JVM от Sun, IBM, BEA или gcj ?

В List<Integer> не засунуть нечто, отличное от Integer

В List можно затолкать все что угодно.

>какие существуют специализации
умирающий ME и бурно растущий Android,
полуживой, но теоретически перспективный JavaFX,
энтерпрайзный JavaEE,
стандартный SE,
ультрасовременный/модный groovy/grails,
не совсем java для любителей ФП scala.

Тем самым подтверждается истина о том что эклипс - фекалие.

Абсолютно верно говорят. Более того, Java -- самый универсальный из всех языков программирования.

На плюсах пишут те, кто не осилил яву, а на хаскелле -- те, кто не осилил плюсы.

List<Integer>.contains(Object o) - это номер раз.
List<Integer>.toArray() - это номер два.

А на java пишут индусы и им сочуствующие. И пишут дережабли вроде веб-сервисов передающих XML строкой в параметр. Да еще не просто так а с выдумкой... типа XML со схемой вида <xs:any />.

> List<Integer>.contains(Object o) - это номер раз.

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

> List<Integer>.toArray() - это номер два.

Integer[] List<Integer>.toArray(Integer[])

А вообще оно, конечно, не от хорошей жизни так в Java, все из-за type erasure ради совместимости с предыдущим кодом...

> Как и пытаться удалять объекты любого типа.

ой ли? :)

>> Как и пытаться удалять объекты любого типа.

> ой ли? :)

http://stackoverflow.com/questions/104799/why-arent-java-collections-remove-m...

http://www.ibm.com/developerworks/java/library/j-jtp01255.html

Да не... все нормально просто C++ или C# разработчик будет ожидать от компилятора сообщения об ошибке там, где java компилятор все проглотит и создаст ошибку в runtime.