Java 8

[Mifesto]

Я вот незнаю - смысл ли есть J#

Например я видел обратное - C# -> Java

https://code.google.com/p/stab-language/

Читаем года разработки вики:

http://ru.wikipedia.org/wiki/Java
http://ru.wikipedia.org/wiki/C_Sharp

как видно разработка явы была начата в 95 а шарпа в 98

Добавлено через 2 минуты

Да, шарпе не лямбды, а LINQ, это немного другое.

Ну тут вы не правы, http://ru.wikipedia.org/wiki/Language_Integrated_Query

[VISTALL]

Читаем года разработки вики:

http://ru.wikipedia.org/wiki/Java
http://ru.wikipedia.org/wiki/C_Sharp

как видно разработка явы была начата в 95 а шарпа в 98

Да знаю я когда и что было раньше.

Только вот ток ШШарп развивается куда быстрей, но у него цель ВСЕ И СРАЗУ)

Сахара в синтаксе там ппц

[JavaMan]

Ребят, а как вам замечательный класс Optional который позволит избавиться от нуллов и связанных с ними ошибок ? Красота же !

Пример Optional

Было:
[SRC="java"]
public static Action find(final int id)
{
for(final Action action : Action.values())
if(action.id == id)
return action;

return null;
}

final Action action = Action.find(_actionId);
if(action == null)
{
// явко код
}
[/SRC]


Стало:
[SRC="java"]
public static Optional<Action> find(final int id)
{
for(final Action action : Action.values())
if(action.id == id)
return Optional.of(action);

return Optional.empty();
}

final Optional<Action> actionOptional = Action.find(_actionId);
if(actionOptional.isPresent())
{
final Action action = actionOptional.get();
// явко код
}
[/SRC]

PS задолбал ваш тупой холивар явка против шарпика. Модеры, подчистите пожалуйста этот холивар.

[JavaMan]

Сегодня состоялся релиз явки 8.

[ReaM]

Сегодня состоялся релиз явки 8.

производители оперативки радуются новым объемам поставки

[SouthBridge]

Подниму пожалуй темку из-за одного странного случая, а возможно бага в API Java 8.

Недавно перевел сервер на восьмерку, все бы прекрасно, если бы сегодня не заметил дикое потребление оперативки, причем явно мусорное (до 5,5гб мусора за несколько секунд).
Профайлер показал бесконечный цикл там, где по сути его и быть то не должно.

В качестве примера я набросал тест-кейс (код тут) и опробовал под Java 6-7 и Java 8. Результат меня удивил.
Под 6 и 7 работает как должен (см. вывод на ideone).
Под восьмёркой же, что-то нездоровое происходит с итератором:

--> 544 8966093/18
--> 672 8966094/18
--> 544 8966095/18
--> 672 8966096/18
--> 544 8966097/18
--> 672 8966098/18

(С обычным HashMap тем временем все ок, возбуждает CME.)

Методом тыка и удалением операции map.remove удалось нормализовать работу на Java 8.
Разумеется, map.delete в связке с map.put не имеет смысла. Но, как бы, подобный гомнолегаси код (а я боюсь что такая конструкция не единственная) становится абсолютно нерабочим на Java 8, чего уж быть явно не должно.

Есть у кого какие мнения?

[VISTALL]

Есть у кого какие мнения?

не юзать Java 8. Спустя только 10 реализов можно будет юзать в продакшене

[ProDev]

Мнения - подождать немного именно с такой ошибкой не сталкивался, но вообще и других хватает, где все встает колом. AOP AspectJ, Parboiled, ASM, все OSGi контейнеры - только несколько примеров, которые сразу падают при переходе на J8. Потратил денек на попытки смигрироваться - понял, что объем костылей не соответствует получаемому профиту откатился на Java7.

А по коду выше - получается, что на каждый вызов remove/put элемент переезжает, поэтому вывод зацикливается на двух элементах.

[SouthBridge]

Благодарю, теперь вижу и понимаю насколько нестабилен релиз, не я один такой "пострадавший".
Сейчас на глазок все стабильно заработало, но наверное рисковать не стану и откачусь.

[acmi]

Благодарю, теперь вижу и понимаю насколько нестабилен релиз, не я один такой "пострадавший".
Сейчас на глазок все стабильно заработало, но наверное рисковать не стану и откачусь.

Поведение соответствует документации. Если оно не совпадает с Вашими ожиданиями, то это не показатель "нестабильности релиза".
Да, с переходом на новый Stream API переписали итераторы и убрали "guarantees to traverse elements as they existed upon construction of the iterator".
В любом случае итерирование изменяемой ConcurrentHashMap непредсказуемо, как вариант использовать промежуточный new HashSet(map.keySet()).