Будущее Java или ломаем backward compatibility полностью

Звучит здорово, сделал javaX, проверяй

Так обратная совместимость это и есть одно из главных преимуществ Явы.

Было бы неплохо. Как и var/val по умолчанию в языке, да ещё и как единственный вариант (один фиг, без IDE разработка превращается в ад).

Python 3? Ну как успех?

Взял и выкинул все за что любят джаву

1. Пофиг.
2. Пофиг, для побайтовых манипуляций нормально.
3. Да.
4. Пофиг.
5. Да.
6. Возможно.
7. Пофиг.

А что если

Можно просто перейти на дотнет. Или на Моно, если уж так.
В любом случае, лучше с Наделой, чем с Эллисоном.

Python 3

«3 недели сиськи мыла и соляркою ссала» (с) Сектор Газа

спорно, они вдвоем капиталисты... это как бутерброд и клизьма.

Толку то от Java если сломать совместимость со старым кодом?

Со старым кодом совместимость никто ломать не будет - будут поддерживаться версии JVM до 9. Лет 5-8, например. За это время можно подготовиться к переходу на Java X.

Со старым кодом совместимость никто ломать не будет - будут поддерживаться версии JVM до 9.

Т.е. ты предлагаешь переписать весь прикладной код, что написан на Java до 10й версии? Не взлетит от слова совсем. Слишком большие трудозатраты.

С таким же успехом можно на .NET перейти или еще куда.

Ничего не думаю. Я - джава-неосилятор.

лучше с Наделой, чем с Эллисоном

«Оба хуже» (ц)

Можно просто перейти на дотнет.

Шило на мыло.

Ты сначала определись, что тебе не нравиться. Дизайн языка или как JVM с байт-кодом работает. Язык можно взять и выбросить, а вот JVM придется есть и плакать.
И да, Одерски им предлагал нормальные дженерики, но кто-то не захотел ломать совместимость еще на 5.0.

Отсутствие компилятора забыл.

Обратная совместимость – одна из киллер-фич Java.

Это было бы замечательно, но оракл не пойдет на такое.

checked exceptions

Можно убрать из языка не ломая обратную совместимость.

Отсутствие беззнаковых типов, вследствии чего имеем кривой API и трудности работой с сетью.

В Java есть беззнаковые типы. Про кривой API и трудности работы с сетью подробней.

Убогие Generics, которые дженериками и не являются

Являются. Все проблемы можно исправить не ломая обратную совместимость.

Примитивные типы не являются объектами. Существуют убогие костыли-обертки, которые уродуют концепцию

Тут нет никаких проблем.

Длина массивов не может превышать Integer.MAX. Огромные массивы не поддерживаются

Это можно исправить не ломая обратную совместимость.

Отсутствие Properties. Геттеры и сеттеры раздувают код и делают его нечитабельным

Это можно исправить не ломая обратную совместимость.

Кривой дизайн Cloneable и Serializable

В нём нет ничего кривого.

Целый зоопарк всяких языков (Scala, Kotlin etc), которые по факту используют legacy JVM со всеми ее недостатками, пытаясь как-то выправить ситуацию и облегчить жизнь разрабов.

А тут-то в чём проблема?

Ты одно не учёл: за те 5 лет переходного периода твоя Java X обрастёт собственными недостатками и проблемами.

Треть является достоинствами, ещё треть не является проблемами, оставшаяся треть может быть пофикшена с сохранением совместимости.

Python 3? Ну как успех?

Perl 6 лучше :D

Эта мысль не новая, мягко говоря. Про странный и уродливый дизайн языка писали все кому не лень с момента появления жабы. И общее мнение было, что ничего исправить там нельзя, она должна умереть своей смертью.

То, что ты описал, называется Kotlin. И он уже существует.

Каков смысл в этом обсуждении, если оно ни на что не повлияет?

Можно убрать из языка не ломая обратную совместимость.
не ломая обратную совместимость

да? ну-ка расскажи, что станет с кодом, который проверяет checked exception при пересборке на новой версии языка

олсо, считаю checked exceptions фичей, убирать её не нужно

Все проблемы можно исправить не ломая обратную совместимость.

ну давай расскажи свои истории, как ты будешь симулировать не-type-erasure дженерики поверх обычных, оставаясь в рамках языка

Примитивные типы не являются объектами.
Тут нет никаких проблем.

да вообще-то куча проблем, лень перечислять - в интренете об этом есть, читай и обрящешь :)

есть беззнаковые типы

покажи мне unsigned int

«Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is.» - Гослинг

другое дело что это мелочь

В нём нет ничего кривого.

ну вообще-то есть, нет никакой настоящей необходимости переопределять clone. но это мелочь

ТС может пойти и сделать патч на OpenJDK, и распрострянять его самостоятельно!

текущие проблемы Java:

У какой эксперт

всё верно ты сказал.

Из всего что ты привел, можно выделить только дженерики, и глупый Integer.MAX. Я задам простой вопрос, ты дверью не ошибся?

Текущие проблемы Java:

Думаю тебе стоит вернуться обратно на C++, или откуда ты там пришел.

да? ну-ка расскажи, что станет с кодом, который проверяет checked exception при пересборке на новой версии языка

Ничего не станет, как работал, так и будет работать. Всё, что изменится — компилятор перестанет проверять всё, что связано с checked exceptions, т.е. станет принимать код, который раньше был невалидный. Тот код, который был валидный, таким и останется.

ну давай расскажи свои истории, как ты будешь симулировать не-type-erasure дженерики поверх обычных, оставаясь в рамках языка

Добавить в Object поле, которое будет хранить всю информацию об использованных типах.

да вообще-то куча проблем, лень перечислять - в интренете об этом есть, читай и обрящешь :)

Чего мне читать, если у меня с этим никогда не было никаких проблем? Хочешь — используй врапперы вместо примитивных типов, всё будет работать примерно как и работало, только в N раз медленней. А я с примитивными типами буду C обгонять по старинке.

покажи мне unsigned int

int

ну вообще-то есть, нет никакой настоящей необходимости переопределять clone. но это мелочь

Нет необходимости — не переопределяй. Тут дело в другом — такое клонирование нужно почти никогда, а то, что нужно — не требует какой-либо поддержки языка, делай свой метод copy и всё. Но если тебе надо скопировать объект без вызова конструктора — то тут тебе язык и поможет.

ТС, ты забыл бесконтрольное пожирание памяти

int

ты действительно не знаешь, что такое unsigned или просто притворяешься поехавшим?

Нет необходимости — не переопределяй.

опять притворяешься поехавшим? Чтобы использовать метод clone нужно пометить класс интерфейсом Clonable и потом переопределить метод clone, иначе он не доступен. Это лишнее действие, известная ошибка в дизайне Object.

Добавить в Object поле, которое будет хранить всю информацию об использованных типах.

каким образом добавь? Давай расскажи, как ты без оверхэда напишешь препроцессор в рантайме, при этом не раскрыв кода приложения

Хочешь — используй врапперы вместо примитивных типов, всё будет работать примерно как и работало, только в N раз медленней

в C# можно сделать лист из примитивного типа, он не будет забоксен. Например, List<int> имеет внутри реализацию через int[]. Как видишь, эту фичу можно сделать правильно, и ничего не тормозит.

А возможна эта фича потому, что у C# нормальные дженерики, в отличие от джавы. См свой наивный ответ выше.

Есть Scala.

а вот и фанаты ручного управления памятью подтянулись :)

-xMx ?

кассандре это скажи, она тебя внимательно выслушает и все равно полгига минимум сожрет. На инфраструктуре норм, а на виртуалке тухло

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

не, вмваря с центосью. Даже если дать max 64M это дело все равно меньше 512 метров не жрет пустое. Там кстати часть опций вырезали в минорном релизе, в т.ч. пара из них давала отрезку по памяти. Можно в рецепте для шефа посмотреть, там они выделены какие были удалены

кто что думает по этому поводу

Я думаю, java она как C — пока хипсторы соревнуются кто громче пернет, на этих языках молча делаются вещи уже не один десяток лет.

Все кукаретики про обратную совместимость никогда не юзали Vector в java? Еще в 2010 н там был. Где он теперь?

Заодно вместо JVM заюзать что-то нанотехнологичное, и инновационное! Типа llvm.

Вроде бы на месте. А к чему этот странный вопрос?

А что если с 10-й версии исправить все эти проблемы, полностью игнорируя обратную совместимость?

Получится Common Lisp.

В Java 10+ и так будет многое из указанного. http://openjdk.java.net/projects/valhalla/

Отсутствие Properties. Геттеры и сеттеры раздувают код и делают его нечитабельным

А вот это нафиг не надо.

Отсутствие беззнаковых типов

ктото не осилил джаву или программирование.....хммм дажеж не знаю

конкретно тобой описанное не верно по отношению к ...почти всем языкам программирования

и вообще я детектирую бред джаваскриптера

может ты еще скажешь что Си не может существовать из за отсутствия строк как типа?

иди учи матчасть идиот

java3d(как класс джавы встроенный) где он сейчас (совместимость умерла еще в 2004)

java swing где он сейчас (совместимость тамже)

java бинарные биндинги к многопотчным библиотекам-ломаются каждую минорную версию(в джаве) и лепятся костыли в коде (джава) или бинарная прослойка для синхронизации

могу долго продолжать но не буду

Пасть свою захлопни, недодетектор хренов. В Си со строками проблем нет. Да и вообще, Си один из самых удачных и простых языков. Клоун, как объяснишь мне то, что например в Java array.length имеет тип int? Выходит, что length может иметь негативное значение? Нет. Почему тогда возвращаемый тип int, а не uint? И таких мелочей полно.