Разработка JDK 8 достигла стадии Developer Preview

А если из метода может вернуться как [], так {} или вообще int?

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

Idea работает с JavaScipt без всяких аннотаций и автокомплит пашет.

быть такого не может :)

function my_func (arg_obj) {
    // ...
    // ...
    var other_object = arg_obj.xxx<какой-тут-будет-автокомплит?>...
    // ...
    // ...
}

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

А ты откуда про скалу знаешь вообще?

А ты откуда про скалу знаешь вообще?

Я на ней пишу :) Летом запустил highload на scala в продакшен :)

О, круто. Я думал, ты какой-то низкоуровневый с++-писатель.

Да, это почти так, мой основной язык это C++, но к нему я последний раз прикасался в феврале этого года :)

Так тогда ты тем более должен знать, что там у каждого Nil и Nothing свое место, и бардака нет.

Это ты в хайлоаде привык не различать None, null, Nil и Nothing? Кстати, раз уж у нас день буквы N, то ты еще Null забыл.

Автокомплит может брать информацию из рантайма. Тогда типов не надо.

Что было нужно сделать - implicit кастинг из Object в любой класс.

Для любителей поотлавливать тупых багов в рантайме есть всякие пыхпыхи и пистоны.

От этого не бывает тупых багов в рантайме. Проверено Objective C.

Ну и джавовские генерики никак на рантайм не влияют.

От этого не бывает тупых багов в рантайме.

От этого бывает ClassCastException — по-моему, наитупейший баг вместе с NullPointerException.

Ну и джавовские генерики никак на рантайм не влияют.

Твои познания в таких деталях жабского рантайма, как type erasure, тут абсолютно не в тему. Генерики не дают скомпилироваться коду, который бы в рантайме вызвал бы ClassCastException.

От этого бывает ClassCastException — по-моему, наитупейший баг вместе с NullPointerException.

На практике не бывает.

Генерики не дают скомпилироваться коду, который бы в рантайме вызвал бы ClassCastException.

как раз генерики и вставляют инструкции, выбрасывающие ClassCastException где надо и где не надо.

как раз генерики и вставляют инструкции, выбрасывающие ClassCastException где надо и где не надо.

Покажи пример, где они что-то выбрасывают, где не надо.

И Java7 ненужно. Java6 идеальна, любые изменения только все портят.

Конечно... Жаль, что ченджлоги никто не читает.

Да и вообще, пример того, что они там вставляют по сравнению с не-генерик кодом?

классы не работают как функции, например, не возвращают значения. Если _весь_ код будет на «вложенных классах», плюс многопоточность, то этот безобидный синтаксис превратится в 100-этажный огород, в котором днем с огнем не отыщешь смысла :-(

На практике не бывает.

чего не бывает, CCE или NPE?

btw, я за то, чтобы методы от null делали <nothing>, либо генерировали какой-нибудь ворнинг отлавливаемый внешними тулазами со специально выставленными флагами. Но это все от желания сделать из Java то, чем она не является.

классы не работают как функции, например, не возвращают значения.

Почему не возвращают? interface Function<X, Y> { Y call(X param); }

Если _весь_ код будет на «вложенных классах», плюс многопоточность, то этот безобидный синтаксис превратится в 100-этажный огород, в котором днем с огнем не отыщешь смысла :-(

Ну так лямбды почти ничего не делают, чтобы это исправить. Всё, что они делают - убирают несколько токенов синтаксического мусора. С этим и идея прекрасно справляется.

Они хоть возможность модифицировать внешние переменные без уродства с final int[] var = new int[1]; поправили?

чего не бывает, CCE или NPE?

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

А вот проблемы с хитрозакрученными генериками были. Как выдаст тебе ошибку, и сиди, думай, то ли ты на джаве пишешь, то ли на С++.

В Objective C, кстати, тоже нет генериков и можно из Object-а кастовать без приведения в любой класс. Тоже проблем ни у кого не возникает. И на Objective C++, в котором есть шаблоны, никто почему-то не спешит переходить.

btw, я за то, чтобы методы от null делали <nothing>, либо генерировали какой-нибудь ворнинг отлавливаемый внешними тулазами со специально выставленными флагами. Но это все от желания сделать из Java то, чем она не является.

Генерики как раз сделали из Java то, чем она не являлась.

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

зачем в Эклипсе открывать HTML в браузере?.. И что под этим имеется в виду - какой-то плугин со встроенным браузером, или внешний system.exec на Хромиум?

Почему не возвращают? interface Function<X, Y> { Y call(X param); }

ты точно пишешь код в функциональном стиле с использованием таких штук или это теоретизирование?

Они хоть возможность модифицировать внешние переменные без уродства с final int[] var = new int[1]; поправили?

нед

final int[] var = new int[1];

AtomicReference жэ.

package com.olegchir.java8test;

import java.util.concurrent.atomic.AtomicReference;

public class Main {
    public static void main(String[] args) {

        System.out.println("=== RunnableTest ===");

         AtomicReference<String> helloWorldString = new AtomicReference<>("Hello world one!");

        // Anonymous Runnable
        Runnable r1 = new Runnable(){

            @Override
            public void run(){
                System.out.println(helloWorldString);
            }
        };

        helloWorldString.set("Hello world two!");

        // Lambda Runnable
        Runnable r2 = () -> { System.out.println(helloWorldString); };

        // Run em!
        r1.run();
        r2.run();

    }
}

если превратить в String, будет генерить ошибку «needs to be declared final»

Проблем с тем, что не тот класс в мапу положили - не было.

Только вот, чтобы понять, что можно из мапы доставать, нужно сначала порыться по коду — посмотреть, что туда кладут. Что совсем не ускоряет процесс разработки.

Генерики как раз сделали из Java то, чем она не являлась.

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

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

Всё, что они делают - убирают несколько токенов синтаксического мусора.

Если писать в функциональном стиле, то мусора столько, что кода за ним не видно. Идее за грим конечно спасибо, но в исходниках то все равно какашки остаются.

И как бы не только. В рантайме поддержка тоже будет.

Они хоть возможность модифицировать внешние переменные без уродства с final int[] var = new int[1]; поправили?

Ну как бы модифицировать внешние переменные с точки зрения функционального подхода и есть уродство. И в чем проблема свой MutableInteger класс сварганить? Это ж тру жаба-вей.

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

Strring s = map.get(1);

тут вставляется checked cast.

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

С чего это вдруг? Очень удобная фича.

И в чем проблема свой MutableInteger класс сварганить? Это ж тру жаба-вей.

Нафиг такой вей, компилятор может многие случаи соптимизировать без вынесения объекта в кучу. Чаще всего замыкание не выходит за пределы функции, а значит можно просто обращаться выше по стеку.

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

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

Strring s = map.get(1);

тут вставляется checked cast.

А без генериков чект каста не будет что ли?

С чего это вдруг? Очень удобная фича.

Функция перестает быть чистой.

Нафиг такой вей, компилятор может многие случаи соптимизировать без вынесения объекта в кучу. Чаще всего замыкание не выходит за пределы функции, а значит можно просто обращаться выше по стеку.

Не следил за развитием JVM. Она уже умеет размещать объекты в стеке?

Но даже если так, то хрен ты объекты, захваченные замыканием из внешней функции в стеке разместишь. Потому что замыкание чаще всего куда-то передается параметром, и дальнейшая его судьба в общем случае неизвестна, и, соответственно, время жизни.

Но, допустим, компилятор смог узнать, что время жизни замыкания меньше времени жизни функции, и MutableInteger таки можно разместить в стеке. В чем проблема тогда?

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

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

При чем тут без генериков? Речь шла про генерики.

Функция перестает быть чистой.

Я не считаю хаскель эталоном функциональности и не считаю иммутабельность необходимым признаком функционального языка. Это отдельная фича со своими плюсами и минусами. Тот же лисп прекрасно обходится без иммутабельности. Джаваскрипт — тоже. Функциональность это способность оперировать функциями, как объектами первого порядка, вот и всё. А если язык не дает изменять захватываемые переменные, это его ограничение т.к. никаких плюсов это не прибавляет.

Не следил за развитием JVM. Она уже умеет размещать объекты в стеке?

Примитивы — умеет. Ссылку на объект тоже умеет. Если мы хотим мутабельную ссылку на объект, придется делать еще один вспомогательный объект.

Но даже если так, то хрен ты объекты, захваченные замыканием из внешней функции в стеке разместишь. Потому что замыкание чаще всего куда-то передается параметром, и дальнейшая его судьба в общем случае неизвестна, и, соответственно, время жизни.

В общем то можно отследить дальнейшую судьбу замыкания. Чаще всего это будет какой-нибудь map или filter, который очевидно замыкание нигде не сохранит.

Но, допустим, компилятор смог узнать, что время жизни замыкания меньше времени жизни функции, и MutableInteger таки можно разместить в стеке. В чем проблема тогда?

Уже писал, что имел в виду примитивы и ссылки, а не объекты. Не знаю насчет размещения объектов в стеке.

не считаю иммутабельность необходимым признаком функционального языка. Это отдельная фича со своими плюсами и минусами

никому эти функциональный языки не нужны сами по себе. прекрасно в 90-х годах обходились без них и в мобилках/эмбеде и так обходятся. потребность достать функциональщину из ветхих чуланов появилась из-за массового паралеллизма, когда Intel в последние годы с 2005го или примерно тогда, перестал наращивать частоту процев и стал везде и всюду пропихивать многоядерность. и функциональщину вытащили из-за единственной фичи: иммутабельности, именно благодаря ей проще писать многопоточные программы

При чем тут без генериков? Речь шла про генерики.

как раз генерики и вставляют инструкции, выбрасывающие ClassCastException где надо и где не надо.

Дык хочу увидеть код без дженериков и без инструкций выбрасывающих ClassCastException где надо и где не надо.

Примитивы — умеет. Ссылку на объект тоже умеет. Если мы хотим мутабельную ссылку на объект, придется делать еще один вспомогательный объект.

Локальные переменные примитивных типов и ссылки на объекты всю жизнь были в стеке. Наоборот, покажи, как их в heap запихнуть.

В общем то можно отследить дальнейшую судьбу замыкания. Чаще всего это будет какой-нибудь map или filter, который очевидно замыкание нигде не сохранит.

На этапе компиляции это не понятно. С жабской динамической линковкой следить придётся в рантайме.

Немутабельные переменные копируются в поля объекта-замыкания. Так что они тоже не только в стеке память занимают.