А на оф сайте android sdk до сих пор 6-ая в требованиях.

а оракл сидит на 5-ке :(

и с выходом финальной версии - переползать

Ползите-ползите. Рождённый ползать...

не понял? Если речь про субд, то там в 12ой уже семерка запилена.

оно конечно да, но Ынтерпрайз на 11.2 в лучшем случае. в лучшем! до 12-ой еще дойти надо...

Поделки оракла годятся только для распил-отката и освоения бюджета. Не всё равно ли, какая там версия жабы?

Поделки оракла годятся только для распил-отката и освоения бюджета.

а еще за это платят.

Не всё равно ли, какая там версия жабы?

с этим есть обратная зависимость размера геморроя :)

Проекты можно собирать семеркой, работает.

Да я в курсе, просто факт интересный.

Они разве не собирались в 8 сделать TCO? Почему-то не нашёл данной фичи в списке. Кто-нибудь знает почему передумали делать?

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

оно конечно да, но Ынтерпрайз на 11.2 в лучшем случае. в лучшем! до 12-ой еще дойти надо...

Опаньки, вот я медленный какой, в этом году собираюсь переползать с 10-ки на 11.2.

Какие нововведения кроме лямбд? Перегрузки операторов до сих пор нет?

не не, у тебя как раз как везде ))

Не собирались. И не собираются. Во всяком случае не слышал.

Перегрузки операторов до сих пор нет?

И не будет, не нужно же

Насколько помню, ни Сан, ни Оракл не собирались и не собираются прикручивать оптимизацию хвостовой рекурсии.

Можно сказать, что он счастливчик, переползают на 11-ый оракл.

Можно сказать, что он счастливчик, переползают на 11-ый оракл.

Во всём виноват вендор, который сказал, что теперь только Оракл 11. Причём версии, поддерживающей и 10-ый и 11-ый не было, надо сразу мигрировать на следующую версию и самого приложения и Оракла.

Это был сарказм. Лямбды тоже не нужны. Джава катится в мультипарадигмальный язык, а должна стремиться к Ъ-ООПу.

Ползите-ползите. Рождённый ползать...

+1

Вкусняшка

Stream + parallel

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

Джава катится в мультипарадигмальный язык, а должна стремиться к Ъ-ООПу.

Есть уже Ъ-smalltalk и судя по его распространенности вполне можно увидеть - на чем реальные разработчики этот Ъ-ооп крутили и с какой амплитудой его труба шатали.

И не будет, не нужно же

Я бы сказал что нужно в ограниченных масштабах, фактически только для BigDecimal/BigInteger.

ForkJoinPool в Java 8

http://www.youtube.com/watch?v=t0dGLFtRR9c

Ну хоть на этот раз жабка научилась не тормозить?

А куда нам деваться если
Java 7 End of Public Updates: March 2015

А можно ченджлог, для Ъ.

Но добавили адский implementation для интнерфейсов.
Песец.
Нет чтобы сделать как в C#

Но им видимо религия не позволяет фичу нормально передрать :(

Но добавили адский implementation для интнерфейсов.

А какие конкретно претензии к default методам в интерфейсах?

Diamond inheritance problem слышали?

Так вот оно самое.

Но главная претензия, что это работает только с интерфейсом.

Extensions в C# работаю с любыми типами не создавая проблем.

Нет там никакой diamond inheritance problem. Именно из за того, что работает только с интерфейсами, в которых невозможно инкапсулировать состояние, А если нет состояния, то нет и проблем.

Вы видимо не в курсе, что это такое.
Рекомендую почитать.

Что такое diamond inheritance - я в курсе. Из проблем с ним я помню только проблему с вызовами деструкторов, когда не понятно - в каком порядке они будут вызваны и не будет ли вызван деструктор базового метода несколько раз. При отсутствии состояния - данная проблема не актуальна.

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

Step (3) in the resolution
procedure above addresses the case of ambiguous default
implementations. It is allowable to inhe
rit a default through multiple paths (such as
through a diamond-shaped interface hierarchy),
but the resolution procedure is looking
for a
unique, most specific defaul
t-providing interface.
If one default “shadows” another
(where a subinterface provides a different de
fault for an extension method declared in a
superinterface), then the less specific interf
ace is pruned from consideration – no matter
where it appears in the inheritance hierarchy.
If two or more extended interfaces provide
default implementations, and one is not a superi
nterface of the other,
then neither is used
and a linkage exception is thrown indicat
ing conflicting default implementations

нет никакой diamond problem в java8

Очевидно что не в курсе.
Даже в вики есть http://en.m.wikipedia.org/wiki/Diamond_inheritance
К состоянию она не имеет отношения.

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

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

А поискать статью в вики по Java 8 слабо?

Кстати вы так и не поняли суть проблемы, если такое пишете.

По твоей же ссылке сказано:

Java 8 introduces default methods on interfaces. If A,B,C are interfaces, B,C can each provide a different implementation to an abstract method of A, causing the diamond problem. Either class D must reimplement the method (the body of which can simply forward the call to one of the super implementations), or the ambiguity will be rejected as a compile error. [6]

Cool.
Т.е. вы уже согласны Diamond Inheritance проблема существует?

в вики написано же - компилер ругнется. если компилер не ругается (напирмер скомпилено более старой версией jre) - рантайм ругнется (я тебе цитату привел чуть ли не из спецификации java?)

существует, но в java её нет.

Нет чтобы сделать как в C#

реализация в C# тоже не блещет красотой, надо сказать (я про отсутствие полиморфизма).

В том виде, в котором она существует - это не баг а фича. Нигде не создается плавающих багов и unexpected behavior.

Я плакаль.
Плакаль и осознаваль мудрость моего Dev.Manager сказавшего что Java была создана чтобы утилизировать людской ресурс не способный осилить CS в нормальном объёме.

Вы русский язык понимаете?

Я говорю о наличи проблемы а не о том, что есть средства ее решения.

А производительность VM хоть в чём-нибудь улучшили? Может, она памяти жрёт чуть меньше? После Sun как-то несколько печальные фичи предоставляют нам, имхо.