Вышла Java SE 7

> А json подразумевает взаимно однозначное соответствие содержимого файла и его модели в программе, поэтому и надобность в отдельном валидаторе чисто умозрительная. Вполне достаточно валидации, которая по любому уже есть в программе.

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

или я не понял ход твоей мысли или валидация JSON идет через libastral?

>> Ценность XSD в том что написав XSD ты применяешь стандартую либу для валидации XML. Это не тоже самое что писать ручной валидатор для каждого ини файла.

Ценность сего весьма условна. Для большинства форматов схемы просто нет. Не написали.

Как только вы ничинаете интегрироваться с другой системой, а лучше несколькими, так сразу ценность XSD становится на вес золота. к примеру приходят данные и обработчик разваливается - кто идиот?

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

как это сделать на JSON? глазками будете кило- и мега- байты данных просматривать? запаритесь ;)

> формально рассуждать о свойствах программы

Позвольте, но Вы ответили мне, как ученый-теоретик, а не как программист-практик.

Зачем мне практически нужны лямбды? Для каких конкретно задач?

как минимум чтобы не городить реализацию интерфейса на каждый чих

Позвольте, но Вы ответили мне, как ученый-теоретик, а не как программист-практик.

Повзольте, но Вы дочитали пост до конца:

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

Все остальные и так отставали в технологическом плане от Java лет на 15 минимум, а теперь и вовсе никаких шансов не осталось догнать.

Так смешно, когда кто-то смеет вякать против Java! Это делают только те, кто не смог осилить всей глубины технологической пропасти между Java и отстающими.

> Жду лямбда-выражения как соловей лета.

Только не в моей Java!

Опыт дотнета доказал, что практической пользы от этой матанистой чуши никакой, а write only код писать с ними становится на порядок легче. Это совсем не то, что нужно языку программирования 21-го века.

> Глядишь, лет через 20ть, и аналог LINQ осилят :-D

Ты бы еще предложил осилить указатели из C и COMMON-блок из Фортрана.

В современном языке программирования такие уродливые извращения просто не нужны. Перестаньте пачкать идеально прекрасный язык Java своими грязными идеями!

> В современном языке программирования такие уродливые извращения просто не нужны

Ты вообще здоровый? С головой дружишь? Или не в теме?

> Лямбда исчисление нам нужно, для того чтобы можно формально рассуждать о свойствах программы, но это вообще отдельная тема.

Halting problem уже решили? Нет? Тогда все эти «формальные рассуждения» куска какашки не стоят на практике. На практике надежность достигается за счет фанатичного следования best practices, грамотному применению паттернов, unit testing и continuous integration. Никаких «формальных рассуждений» нигде в реальной практике нет и быть не может.

Фактиечски это небольшой синтаксический сахар для уже имеющихся в Java локальных классов.

Этот синтаксический сахар позволяет превращать програмы в синтаксический мусор. Java идеально прекрасна, и добавление любой «более короткой» формы записи чего бы то ни было моментально нарушает гармонию.

Когда же оно подохнет окончательно...

Ты вообще здоровый? С головой дружишь? Или не в теме?

Я думаю, он просто толстый тролль.

> Ты вообще здоровый? С головой дружишь? Или не в теме?

это такой веселый троллинг )))

.properties? сходи голову подлечи... пропертями он собрался описывать спринговые бины...

<bean id="petStore" class="org.springframework.samples.jpetstore.services.PetStoreServiceImpl">
    <property name="accountDao" ref="accountDao"/>
    <property name="itemDao" ref="itemDao"/>
</bean>

bean1.id="petStore"
bean1.class="org.springframework.samples.jpetstore.services.PetStoreServiceImpl"
bean1.property1.name="accountDao"
bean1.property1.ref="accountDao"
bean1.property2.name="itemDao"
bean1.property2.ref="itemDao"

Это ппц какой косяк с 1 и 2 у property и bean. А заменять это на какие-то значения будет последний кретин только, который будет послан далеко нахрен. Так как никто не будет потом строк штук 20 редактить, когда в xml это всего одно значение.

>А если это данные созданные старой версией программы?

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

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

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

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

а программа будет хавать все подряд?

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

В общем случае это будет жирный комбайн. xslt тому яркое подтверждение.

>как это сделать на JSON? глазками будете кило- и мега- байты данных просматривать? запаритесь ;)

1) формальное описание формата

2) валидатор, соответствующий этому описанию.

Написать xsd зачастую сложнее, чем написать валидатор.

xsd и есть формальное описание формата. формальнее некуда )))

Замыкания конечно заманчивы, но я недавно прочел документ в котором разъяснялось как дорого обойдется их ввод. Нам же не нужны замыкания в вакууме, нужно обновить API, например добавить метод forEach в интерфейсы коллекций, для удобного прохода по всем элементам. Если мы добавим этот метод в Collections то все классы реализующие этот интерфейс должны быть переписаны, т.е. мы тогда поломаем обратную совместимость. Для сохранения совместимости будет доработана концепция интерфейсов, так чтобы было необязательно реализовывать все его методы.

interface Collections<E> {
 // ...

  void forEach(Body<E> b) default Collections.<E>forEach(b) 

}

Вам еще нужны замыкания?

Замыкания конечно заманчивы, но я недавно прочел документ в котором разъяснялось как дорого обойдется их ввод

Можно ссылку?

Если мы добавим этот метод в Collections то все классы реализующие этот интерфейс должны быть переписаны

А зачем forEach добавлять в интерфейс Collection? Эта функция может быть определена на итераторах, см. STL.

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

Что собственно и предлагалось, только не таблица преобразований, а набор правил преобразования версии N в N+1.

а программа будет хавать все подряд?

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

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

и молча падать или выполнять случайный набор инструкций, если ей подсунули что-то иное?

>xsd и есть формальное описание формата. формальнее некуда )))

Ну так и в чем вопрос?

Для json схема будет заметно проще.

> INI не иерархический или имеет странный синтаксис для вложенности одних данных в другие.

+ много. У нас на фирме в 90-е, пока XML ещё не было, насоздавали сложных описаний на основе INI. Поскольку из соображений совместимости тащить эти форматы кое-где приходится до сих пор, я порой открываю файлы и содрогаюсь.

Файл pdf из которого я узнал о грядущих изменениях я не нашел. Думаю подойдет ссылка на JCP документ с запросом на реализацию замыканий, см пункт 2.7: http://www.jcp.org/en/jsr/proposalDetails?id=335

We propose extending the semantics of interfaces in the Java Language to support virtual extension methods, whereby an interface can nominate a static default method to stand in for the implementation of an interface method in the event that an implementation class does not provide an implementation of the extension method. This enables interfaces to be augmented with new methods «after the fact» without breaking existing implementation classes.

Думаю подойдет ссылка на JCP документ с запросом на реализацию замыканий, см пункт 2.7

Вам еще нужны замыкания?

Вы хотели сказать, что замыкания потребуют работы со стороны Oracle? Не вижу в этом проблемы, совместимость сохранится при переходе на Java 8.