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

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

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

Мощная идея. А там сказано, что функция (или метод) должен вернуться после того, как выполнился?

дело в том, что стандарт разрабатывает та же организация, что и саму джабу.

в джаве нет функций.

Я на стороне тех, кто считает, что жаба не нужна.

Писать надо так, чтобы работало под той средой, в которой оно будет крутиться. Теоретики идут лесом.

Гибкость.

Не нужно метаться в крайности, но проявлять гибкость.

> Вообразите ситуацию, когда объект уже создан и кто-то с ним работает, а метод-конструктор всё еще не отработал, т.е. по сути происходит работа со сломанным объектом.
Извините, а это соббсно как? Это возможно только внутри конструктора. И что в объекте «сломано»? Структурно он уже вполне себе объект, просто не до конца проинициализированный правильными данными и правильными действиями.

который воспользуется каким-нибудь недоработавшим конструтором для мега-оптимизаций

Расплывчато. Можно по-конкретней?

> Еще более прикольно, что кое-что там не написано.

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

Угу, c++ болеет этой болезнью в полный рост. Компияторщики раз за разом находят в стандарте лазейки, которые позволяют вкрячить новые оптимизации, правда сломав при этом часть наивно написанных программ.

>>Структурно он уже вполне себе объект, просто не до конца проинициализированный правильными данными и правильными действиями
++
что такого то?

>Например, не сказано, что конструктор должен вернуться обязательно после того, как выполнился. Вообразите ситуацию, когда объект уже создан и кто-то с ним работает, а метод-конструктор всё еще не отработал, т.е. по сути происходит работа со сломанным объектом. Ну и так далее.

Ну есть конечно идиоты с С++ головного мозга, которые обожают запихнуть всю инициализацию в конструктор и все поля объявить как final. Конечно же, инициализация зачастую включает в себе регистрацию недосозданного объекта где-то вовне, в другом треде.

просто не до конца проинициализированный правильными данными и правильными действиями.

с точки зрения бизнес логики, объект, который ведет себя фиг знает каким образом - поломан.

Расплывчато. Можно по-конкретней?

поконкретней - любыми. Придумают какую-нибудь оптимизацию типа «откладывание выполнения конструторов», чтобы запускать их потом пачками, вот и приплыли ;)

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

public class MyInt{
    private int x;

    public MyInt(int y){
        this.x = y;
    }

public int getValue(){
        return x;
    }
}

> в джаве нет функций.

Специально для таких, как ты, в скобках было написано «или метод».

> Поэтому, например, вот такой класс не будет потокобезопасным:

Уже сейчас или с гипотетическим отложенным исполнением конструкторов?

потому что не «или метод», а только метод

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

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

Бред. К getValue() ты можешь обратиться только через ссылку:

public class MyClass {
    public static MyInt myint;
}

/* parallel thread_1 */
MyClass.myint = new MyInt()

/* parallel thread_2 */
MyClass.myint->getValue()

>Вообразите ситуацию, когда объект уже создан и кто-то с ним работает, а метод-конструктор всё еще не отработал, т.е. по сути происходит работа со сломанным объектом.

Ситуацию вообразить легко: (говнокод) final class, в конструкторе проинициализированно всё что надо, в конце вызывается некая внешняя херь с передачей ей this. Вот только работы со сломанным объектом не наблюдается...

class MyClass {
    public static MyClass instance;
    private int x;

    MyClass(int x) {
        this.x = x;
        instance = this;
    }

    public int getX() { return x; }
}

В первом потоке

new MyClass()

Во втором потоке

MyClass.instance.getX();

Если в конструкторе компилятор переставит инструкции (или просто кеш в процессорах не будет синхронизирован), то во втором потоке можно увидеть 0.

>Придумают какую-нибудь оптимизацию типа «откладывание выполнения конструторов», чтобы запускать их потом пачками, вот и приплыли ;)

Вот в этом параграфе JLS написано, что конструктор должен отработать до того, как ссылка на объект будет возвращена. Не понимаю, с чего вы взяли, будто конструктор не обязан вернуться.

http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.5

Другое дело, что возможна утечка this из конструктора, но это только в случае, если так программист напишет в коде. Кроме того, объект к моменту запуска конструктора уже полностью сформирован и с ним можно работать.

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

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

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

Придумают какую-нибудь оптимизацию типа «откладывание выполнения конструторов», чтобы запускать их потом пачками, вот и приплыли ;

Нет методов против некорректной оптимизации. Это бессмысленный разговор.

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

Расскажите, пожалуйста, каким образом будет вызвано getValue у несозданного объекта?

> в конце вызывается некая внешняя херь с передачей ей this.
Вот это и есть маразм автора конструктора. Это просто бага.

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

Давайте фантазировать дальше, мол, любые участки кода с побочными эффектами могут выполнятся в произвольном порядке, чё.

А нечего писать громоздкие конструкторы.

Есть такой прием еще - создание по требованию. Т.е. конструктор пишется максимально маленьким, а некоторые вспомогательные объекты создаются по первому требованию. Пишется геттер, который проверяет, существует ли объект, если еще нет - создает, если уже существует, то возвращает его. И обращаться к объекту можно например так: GetSomeObject().Property.

> потому что не «или метод», а только метод

Ну ты понял, куда тебе, такому умному и полезному, идти.

А нечего писать громоздкие конструкторы.

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

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

ну там есть исключения, конечно.

>Вот это и есть маразм автора конструктора. Это просто бага.

Я не спорю. Но даже в этой «баге» всё работает!

> Но даже в этой «баге» всё работает!
Это, конечно, не обязательно - действительно некие важные данные могут быть не проинициализированы, и если this отдали кому-то снаружи, можно нарваться на неприятности. Но зачем же делать глупости-то?

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

я же писал - после инициализации всего и вся. Да, делать так не стоит! Я просто не смог представить, как , помимо вот такого «хука», конструктор может не отработать, а с объектом уже работают. но даже в этом случае всё работает (для тех, кто до этого не читал - для «файнал классов» и после всей инициализации)

И что в объекте «сломано»? Структурно он уже вполне себе объект, просто не до конца.

;)

Ну, скажем, не выполняются инварианты которые требуются для правильной работы методов и, соответственно, такие «сломанные» объекты могут приводить к отложенным (трудно диагностируемым) ошибкам или даже к эксплуатируемым уязвимостям.

Как я уже сказал, нефиг this куда попало внутри конструктора совать.

Вообразите ситуацию, когда объект уже создан и кто-то с ним работает, а метод-конструктор всё еще не отработал, т.е. по сути происходит работа со сломанным объектом.

Мне трудно вообразить такую ситуацию. Конструктор в Java выполняется атомарно. Он либо завершает работу с инстанцированным валидным объектом, либо завершается с ошибкой создания объекта. В последнем случае ссылка на объект == null.

И, да, тем, кто из конструктора вызывает другие методы, нужно бить по рукам, пока не пройдёт.

>Поэтому, например, вот такой класс не будет потокобезопасным:

Этот класс полностью потокобезопасен, так как основывается на следующих утверждениях:
1) Конструктор в Java атомарен;
2) Метод чтения приватного члена не нуждается в защитной блокировке (синхронизации), так как метод модификации члена не определён и не может быть вызван из другой нити по факту своего отсутствия.

Стандарты всегда неполны, чего удивляться. Хочешь чтобы твой JVM был популярным, в первую очеред сделай его 100% совместимым с HotSpot, точка