Конец Java? (5 стр)

batment
> Сам пробовал?
Ну как бы интел выпускает компайлеры для фортрана и С/С++. Не зря наверное.

Den Zurin
> Это почему? Она во многом превосходит C++.
> Вот, например, в Java можно проверить принадлежность объекта к классу. Можно ли
> это сделать в C++?
typeid(xxx) и dynamic_cast.
А в C++ есть детерминированные деструкторы и гарантированное освобождение памяти. Можно ли это сделать в жабе? :)

> Или взять те же хваленые шаблоны C++. В Java же шаблоны просто не нужны - можно
> использовать класс Object, а примитивные типы (int, char и т.д.)

template<int N>
class X { ... X<N-1> ... };

template<>
class X<0> { ... };

...

template <int N>
class Y { ... X<N> x; ... }

> Правда, в 5-ю версию все
> же непонятно зачем добавили шаблоны.
Вот потому и добавили, что увидели, насколько убого
> использовать класс Object

И вообще афтары Ъ-ооп языков, задиравшие шнобель и говорившие "а у нас такая концепция", всё больше и больше дают петуха и оглядываются на С++. Что очень и очень показательно.

> Вообще, ООП в Java ближе к Smalltalk/Objective-C, чем к C++.
Smalltalk интересен, как концепция, но вот уже много лет как не более того. ОС - непотребное убожество, под которое, плача и колясь, пишут только мазохисты, влекомые тщетными надеждами заработать миллионы на хомячках в аппсторе (и уже одно это показывает, чей удел - писать на подобных языках).

Zefick
> Спецификацию на > 100 страниц с графиками, таблицами и рисунками не в формате PDF я побоюсь даже открывать где бы то ни было.
Мои менеджеры так не думают ) + иногда приходится такие документы редактировать (все изначально пишется в ворде) + отчеты в doc на 60-80 страниц править приходилось.

> Ах, чуть не забыл, в C++ ведь есть dynamic_cast, которым вы так умело кастите void*, но вот незадача - dynamic_cast работает только при наличии в классе виртуальной таблицы, а с void* не работает вообще.
Увлекся, сморозил чушь. Давно не плюсовал, только мелочи чтобы оценить какую-то новую фичу.

Den Zurin
> error: cannot dynamic_cast ‘pobject’ (of type ‘void*’) to type ‘class MyClass*’ (source is not a pointer to class)
Да, ссори, сморозил глупость. typeid тоже не сработает, шлак. Но:
1. Изначально я советовал все кастить к void* с сарказмом как пример того как делать не надо. Честно, не считал что ты воспримешь это как руководство к действию.
2. Никто не отменял разные Variant, boost::any, QVariant и прочие приблуды для записи всего в куда угодно

Zefick
> Каких именно средств вам в Java не хватает?
Ну я уже писал чего не хватает в 6й джаве. Лямбд, синтаксического сахара наподобие пропертей с автосгенерированными get*|set* или elvis-operators, вывода типов,  миксин. Есть предположение что перегрузка операторов - это хорошо, но сверхвыгоды я тут не вижу.  Офигенно харит то, что я в родовом методе не могу создать новый экземпляр объекта - параметра дженерика (std::map, вложенный в std::map в этом плане лучше чем HashMap, вложенный в HashMap). Плохо то, что это все отодвигают с 7го релиза на 8й, а некоторые неудобства языка (те же дженерики) объявляют фичей и не собираются исправлять. Вот это больше тянет на "смерть Java", чем Появление 2х эдишенов JRE.

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

CAJ
> Плохо то, что это все отодвигают с 7го релиза на 8й, а некоторые неудобства
> языка (те же дженерики) объявляют фичей и не собираются исправлять.
  А что там исправлять в дженериках? Они и так сделали по максимуму что могли, оставшись в рамках спецификации JVM. Даже добавили ограничения на шаблонные типы, которых в C++ опять не будет. Сделать как в плюсах не получится, это будет уже другой язык. Посмотрите какие там извраты с шалонами. Приходится определять шаблоны в одном месте с заголовком. Но если для Java это не проблема, то генерация множества реализаций одного шаблона уже генерирует проблемы. А создавать новые экземпляры классов в генериках можно через рефлексию, вызывая getInstance().
  Экспорт шаблонов - не путать с extern, - который был ещё в старом стандарте С++ (уже 12 лет прошло!) до сих пор реализован только в одном компиляторе, и то платном - Comeau, а остальные на это просто забили. Так что тут история аналогичная, только уже в более крупных масштабах.

  Кстати, ещё одна высокоуровневая фишка Java, о которой ещё не говорили - возможность вызова метода по имени (опять же, правда, рефлексия). Помню я так в одном проекте меню делал - создал класс, который в конструкторе принимал имя функции, которая должна вызываться при выборе пункта и соответствующий ему текст. Получилось ещё компактнее, чем ресурсы в винде.

Sbtrn. Devil
> И вообще афтары Ъ-ооп языков, задиравшие шнобель и говорившие "а у нас такая
> концепция", всё больше и больше дают петуха и оглядываются на С++. Что очень и
> очень показательно.
  Это в чём это создатели Java оглядываются на С++? Опять какое-то голословное утверждение. Лямбды это не ООП, а функциональное и обобщённое программирование. Все эти сиплюсплюсные танцы с указателями и ссылками джаве по барабану. Вот создатели C# те уж точно хватаются за любую идею, даже не ООП, лишь бы конвейер свистоперделок не простаивал.

Zefick
> А создавать новые экземпляры классов в генериках можно через рефлексию, вызывая getInstance().
Только если есть прототип объекта, взять класс шаблона-параметра в дженерике и применить рефлексию по полной нельзя. В том - же шарпе все немного лучше в этом плане.

>Они и так сделали по максимуму что могли, оставшись в рамках спецификации JVM
>Вот создатели C# те уж точно хватаются за любую идею, даже не ООП, лишь бы конвейер свистоперделок не простаивал.
Не вижу проблем в том, чтобы менять внутренности скомпилированного кода и спеков JVM. Майкрософт то для своего .NET делает и очень часто. Я, конечно, не советую каждые несколько лет менять спецификацию, но раз в 5-6 лет с новой мажорной версией можно. Скорее всего главное препятствие здесь - финансы, а не соображения технарей.
Майкрософт в этом плане молодцы, свистоперделки то хорошие получаются, неважно что лямбды - не ООП. SQL Тоже не ООП, но его же никто из-за этого в мусорник не выбросит? Вот LINQ разные и рулят

CAJ
> Не вижу проблем в том, чтобы менять внутренности скомпилированного кода и
> спеков JVM.
Получается старый код придется перекомпилировать?
Это все таки не есть хорошо. Один главных принципов явы был в том, что написал, скомпилил - и больше ничего править не надо. Обратная совместимость таки.
CAJ
> Майкрософт в этом плане молодцы, свистоперделки то хорошие получаются, неважно
> что лямбды - не ООП. SQL Тоже не ООП, но его же никто из-за этого в мусорник не
> выбросит? Вот LINQ разные и рулят
с одной стороны свистоперделки - очень удобно и круто.
С другой стороны есть недостатки.
Надо перейти на другой язык, а программист уже и стандартные средства забыл. Хотя это больше проблема самого программиста.
Второй недостаток, ИМХО, слишком сильный сахар вреден тем, что теряется основная парадигма, все-таки каша из парадигм, особенно в руках неопытных программистов, приводит к такой же каше в коде. Но опять таки дело в опыте программиста.

Zefick
> будут радоваться 1% прироста производительности
Это сейчас разница только 1%, а что будет потом? Безнадежное отставание бесплатной JVM от платной?
Java раньше была свободной технологией, Sun обладала только торговой маркой Java.
Сейчас Oracle пытается ограничить использование технологии.

Sbtrn. Devil
> А в C++ есть детерминированные деструкторы и гарантированное освобождение памяти. Можно ли это сделать в жабе? :)

myObject = null;
System.gc();

CAJ
> Да, ссори, сморозил глупость. typeid тоже не сработает, шлак. Но:
Но нужно писать свой универсальный класс.
> Никто не отменял разные Variant, boost::any, QVariant и прочие приблуды
Вместо одного стандартного.
Кстати, интересный момент. В Objective-C и Java есть базовый класс Object, в Delphi - TObject, а вот в C++ он почему-то отсутствует.
Один этот небольшой момент показывает, насколько "хорошо" реализовано ООП в C++.

CAJ
> пропертей с автосгенерированными get*|set*
"Лично мне свойства не нравятся, и я был бы рад, если бы их поддержку убрали из Microsoft .NET Framework и сопутствующих языков программирования. Причина в том, что свойства выглядят как поля, на самом деле являясь методами." Джеффри Рихтер.

Серый крокодильчик
> все-таки каша из парадигм, особенно в руках неопытных программистов, приводит к такой же каше в коде.
Это и есть главный недостаток C++, C# и прочих подобных языков.

> Но опять таки дело в опыте программиста.
В правильно спроектированном языке подобное просто невозможно.

Den Zurin
На самом деле JVM делают все кому не лень, например IBM, RedHat и еще многие.

batment
> На самом деле JVM делают все кому не лень, например IBM, RedHat и еще многие.
Ага, Гугль вот тоже делает. Даже не JVM, а просто VM. И то нашли, к чему придраться.

batment
> На самом деле JVM делают все кому не лень, например IBM, RedHat и еще многие.
  "Окласите весь список пжалста" (с): http://ru.wikipedia.org/wiki/Список_виртуальных_машин_Java

Den Zurin
> Сейчас Oracle пытается ограничить использование технологии.
  Сделав какую-то одну реализацию JVM платной они этого не добьются. Этих виртуалок действительно много, и кстати, J9 от IBM когда-то была самой лучшей, а вовсе не сановский HotSpot, скорее всего и сейчас так. К тому же на разных системах разные JVM-ки могут рулить.

CAJ
>спецификацию на > 100 страниц с графиками, таблицами и рисунками. Я из-за такого купил майкрософтовский
А что такая пиписька короткая? В OO и по 2к страниц с рисунками, таблицами, графиками и формулами верстают. При этом открывается документ быстрее, чем в MSO.

Den Zurin
> Похоже, это конец Java как свободной технологии.
Тем временем, с 16 апреля сего года, джентльмэны, оракл ввёл подписку на коммерческое использование java.

Doctor_Bro.
Своих реализаций или вообще?

beejah

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

=A=L=X=
нет, closed source можно распространять как хочешь
https://opensource.stackexchange.com/questions/4854/is-it-legal-t… e-application