Вышла Java SE 7

Я не понял, что ты этим хотел сказать. Если я вдруг невнятно выразился, повторю. Меня, как и многих других, не интересуют вознаграждения от корпорации. Меня интересует чтобы мой аппликейшен стабильно работал на их платформе. Чем такой подход плох? В чём я виноват?

Что не понятно? у ублюдков из Lucene было полтора! года для тестирования их говна под beta семерки. Они предпочли сидеть на попе, а за день до выхода высунулись с объявлением о найденном баге. Всем остальным этот баг не помешал пользоваться jdk7, у меня RSS, Vuze, Jdownloader, etc etc уже 1,5 года работают под семеркой и не крэшатся, не глючат, не падают, не вылетают

Все мы знаем что Apache набрасывает говно на вентилятор потому что их реализация Jeronimo не получила штампик соответствия жаба-спецификации. У них по этому поводу лютый батхёрт

>А где эти идиоты были раньше? полгода на сайте оракла предлагалась награда за найденные баги в jvm 7

А с какого перелляха все должны решать проблемы софта сана? Кривому софту место в биореакторе. А оракул вообще не имеет права на существование.

>> Какие из перечисленных «альтернатив» имеют эти возможности?

json

а у JSON есть схема данных аналогичная XSD?

>а у JSON есть схема данных аналогичная XSD?

json не требует какой-то отдельной схемы данных. Если так уж нравится, можно использовать xsd.

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

>> а у JSON есть схема данных аналогичная XSD?

json не требует какой-то отдельной схемы данных. Если так уж нравится, можно использовать xsd.

а как его использовать? есть готовый стандарт описывающий как json-XSD сверяется с JSON? есть готовые либы под большинство языков программирования, умеющие валидировать JSON по этим json-XSD?

думаю нет, а самостоятельно писать подобные либы - за это не платят, а значит либо в личное время либо никогда ;)

На самом деле xml мог бы давно перевернуть интернет и сделать из него семантический веб. Он обеспечивает взаимодействие M2M. Но тогда экономическая основа интернета а именно зарабатывание денег на показах баннеров, в том числе при показе результатов поиска, рухнет и интернет схлопнется как мыльный пузырь

на XML есть хотя бы стандарт для крипто-подписи. а для INI и YAML вы сами себе стандарты придумывать будете чтобы и на C# и на java и на C++ подпись тождественных документов совпадала? ;)

Засунь .properties файл в JAR и подпиши. Делов-то?

Ну возьмем теже spring и hibernate. Какая альтернатива xml там может быть для описания нескольких тысяч бинов?

.properties-файл.

> Например, вы можете в XSD задать тип документа и при вводе (например) вручную данных в XML, привязанный к XSD, уважающий себя редактор подчеркнёт вам, если вы ошибётесь с форматом и даже ошибку покажет.

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

Часто бывает так, что фармат данных нужно поменять. А что делать, если у вас >9000 файлов хранятся в старом формате, а программа кушает только новый? Пишите XSLT.

Часто бывает так, что формат данных тупо-блоб, а переводить его надо... :))

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

Не такой уж странный синтаксис для описания бложенных данных, похож на нэймспейс ООП-языка программирования:

project1.name="HelloWorld"
project1.groupId="com.mycompany"
project1.artifactId="mavenproject0"
project1.version="1.0-SNAPSHOT"
project1.packaging="jar"
project1.url="http://maven.apache.org"
project1.properties.build.sourceEncoding="UTF-8"
project1.dependencies.dependency1.groupId="junit"
project1.dependencies.dependency1.artifactId="junit"
project1.dependencies.dependency1.version="4.8.2"
project1.dependencies.dependency1.scope="test"
project1.build.plugins.plugin1.groupId="org.apache.maven.plugins"
project1.build.plugins.plugin1.artifactId="maven-compiler-plugin"
project1.build.plugins.plugin1.version="2.3.2"
project1.build.plugins.plugin1.configuration.source="1.6"
project1.build.plugins.plugin1.configuration.target="1.6"

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.mycompany</groupId>
    <artifactId>mavenproject0</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>mavenproject1</name>
    <url>http://maven.apache.org</url>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.8.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
  
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>
        </plugins>
    </build>                
                      
</project>

Кроме того пока нет формального описателя метаданных для INI сравнимого хотя бы с XSD.

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

сравни вот с этой порнографией:

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

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

Вот теперь раскажи мне как редактор используя эту самую программу см одет реализовать автодополнение элементов и проверку на лету.

Простите, а зачем Вам лямбда-исчисления?

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

Мне ведь реальные задачи решать. а не понты гнуть в клубе поклонников ПроФФеССора В.С.ЛугоФФского.

Сурова гордость неосиляторов.

И, кстати, тут ещё вопрос проектирования схемы:

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.8.2</version>
            <scope>test</scope>
        </dependency>

Можно было бы записать как:

<dependency groupId="junit" artifactId="junit" version="4.8.2" scope="test"/>

И получилось куда компактнее properties.

сравнил. хочу порнографии

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

хотя согласен, что в одну строку было бы проще

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

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

> Засунь .properties файл в JAR и подпиши. Делов-то?

основная проблема что f1.property key1=val1 key2=val2

f2.property key2=val2 key1=val1

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

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

>> Например, вы можете в XSD задать тип документа и при вводе (например) вручную данных в XML, привязанный к XSD, уважающий себя редактор подчеркнёт вам, если вы ошибётесь с форматом и даже ошибку покажет.

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

давно уже пишут ))) xforms & orbeon

>> на XML есть хотя бы стандарт для крипто-подписи. а для INI и YAML вы сами себе стандарты придумывать будете чтобы и на C# и на java и на C++ подпись тождественных документов совпадала? ;)

Засунь .properties файл в JAR и подпиши. Делов-то?

подписание XML != подписание файла XML

хрень в том, что проперти можно разбрасать и перемешать как угодно!!!

project1.name=«HelloWorld»
project1.build.plugins.plugin1.artifactId=«maven-compiler-plugin»
project1.dependencies.dependency1.version=«4.8.2»
project1.artifactId=«mavenproject0»
project1.version=«1.0-SNAPSHOT»
project1.url="http://maven.apache.org"
project1.properties.build.sourceEncoding=«UTF-8»
project1.dependencies.dependency1.groupId=«junit»
project1.build.plugins.plugin1.groupId=«org.apache.maven.plugins»
project1.dependencies.dependency2.artifactId=«junit»
project1.packaging=«jar»
project1.dependencies.dependency1.scope=«test»
project1.build.plugins.plugin1.configuration.source=«1.6»
project1.build.plugins.plugin1.configuration.target=«1.6»
project1.groupId=«com.mycompany»
project1.build.plugins.plugin1.version=«2.3.2»

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

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

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

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

Про какие обёртки и шелуху обработчиков с оверхедом идёт речь - я вообще не понимаю.

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

И получилось куда компактнее properties.

Скобочки убивают всю идиллию. Тем более, что XML заголовок с ненужным URL никуда не делся.

хрень в том, что проперти можно разбрасать и перемешать как угодно!!!

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

Всё-таки человеко-читаемый формат это .properties, а XML — это смесь французского шампанского с нижегородским квасом.

В этой порнографии сразу видна структура, а твоём примере .properties куча избыточного текста

Это 1-в-1 с XML, чтобы не было лишнего батхёрта.

В .properties можно укоротить нэймспейсы или вообще свернуть:

project1.name="HelloWorld"
HelloWorld.groupId="com.mycompany"
HelloWorld.artifactId="mavenproject0"
HelloWorld.version="1.0-SNAPSHOT"
HelloWorld.packaging="jar"
HelloWorld.url="http://maven.apache.org"
HelloWorld.properties.build.sourceEncoding="UTF-8"

HelloWorld.dependencies.groupId="junit"
HelloWorld.junit.artifactId="junit"
HelloWorld.junit.version="4.8.2"
HelloWorld.junit.scope="test"

HelloWorld.build.plugins.plugin1="compiler"
HelloWorld.compiler.groupId="org.apache.maven.plugins"
HelloWorld.compiler.artifactId="maven-compiler-plugin"
HelloWorld.compiler.version="2.3.2"
HelloWorld.compiler.configuration.source="1.6"
HelloWorld.compiler.configuration.target="1.6"

Скобочки убивают всю идиллию.

Чем тебе скобочки не нарвятся?

Тем более, что XML заголовок с ненужным URL никуда не делся.

1. В XML он необязателен.

2. А в properties его быть нет может и неизвестно что это за документ, что он описывает и чему ддолжен соответствовать.

Всё-таки человеко-читаемый формат это .properties, а XML — это смесь французского шампанского с нижегородским квасом.

Чем же!? XML проще и писать, и читать, чем твои примеры properties.

project1.name="HelloWorld"
HelloWorld.groupId="com.mycompany"
HelloWorld.artifactId="mavenproject0"
HelloWorld.version="1.0-SNAPSHOT"
HelloWorld.packaging="jar"
HelloWorld.url="http://maven.apache.org"
HelloWorld.properties.build.sourceEncoding="UTF-8"

Это ещё хуже. Если поменяется название проекта придётся менять его во всех строках. И, кстати, нумерация проектов никуда не делась.

В .properties можно укоротить нэймспейсы или вообще свернуть

Но не сделать записи аналогичной <dependency groupId=«junit» artifactId=«junit» version=«4.8.2» scope=«test»/>

очень сильно зависит от версии парсера

А расшифровать? XML понимаемый одним парсером не понимается другими?

>json не требует какой-то отдельной схемы данных.

Да правда? Вообщето все из вышеперечисленного имеет самостоятельную ценность а для json аналогичне велосипеды только изобретают.

>.properties-файл.

На нем нельзя нормально описать иерархические без введения некоторой семантики парсера.

Но для нужд гибернейта подойдет любой формат умеющий иерархию - как раз утт то XML непринципиален.

>Я удивляюсь, почему программы до сих пор не пишут на XML,

ant/nant/xul/xaml......

project1.build.plugins.plugin1.configuration.source=«1.6»
project1.build.plugins.plugin1.configuration.target=«1.6»

По сравнению с этим XML - божественный нектар.

сравни вот с этой порнографией:

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

Вот я тебе перепишу то что ты написал как это лучше будет:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" 
    model="4.0.0" group="com.company" artifact="mavenproject0" version="1.0-SNAPSHOT" packaging="jar" name="mavenproject" url="http://maven.apache.org">

    <properties>
         <project.build.sourceEncoding>UTF-</project.build.sourceEncoding>
    </properties>

    <dependency group="junit" artifact="junit" version="4.8.2" scope="test"/>
  
    <build>
        <plugin group="org.apache.maven.plugins" artifact="maven-compiler-plugin" version="2.3.2">
            <source>1.6</source>
            <target>1.6</target>
        </plugin>
    </build>                
                      
</project>

Программа/библиотека, использующая INI и есть тот самый формальный/объектный/процедурный описатель структуры этого INI.

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

>Тем более, что XML заголовок с ненужным URL никуда не делся.

Вообщето он совсем не ненужный. Там где он не нужен - мождешь не писать.

Валидация в XML задача действительно нетривиальная. Поэтому и нужны особые, уличные валидаторы.

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

>JSON это слишком низкоуровневый формат, для полноценного использования которого придётся писать слишком много велосипедов.

в чем это проявляется?

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

А в json все тоже самое делается в одну строчку.

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

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

А сама либа для валидации json файла по xsd пишется за день.

в чем это проявляется?

Если JSON приходит извне, придётся либо писать большую проверочную процедуру на соотвествие нужному формату в императивном стиле, что в итоге будет не очень читаемо, либо изобретать DTD/XML Schema, либо не проверять и получить некорректную работу программы вплоть до injection-уязвимостей.

Если нужна нетривиальная выборка данных и производительность некритична, XPath предоставляет очень удобный интерфейс для этого. В JSON придётся либо наворачивать кучу «старых добрых» циклов, либо придётся изобретать XPath.

Если мы храним в нашем формате какой-нибудь конфиг, то в XML мы имеем кучу редакторов с поддержкой автокомплита, моментальной валидации введённого, и в итоге очень удобный текстовый редактор конфигов практически с нулевыми усилиями. С JSON придётся писать плагин к редактору, чтобы достигнуть этих целей.

Ещё можно про XSLT поговорить, но я его не люблю, поэтому не буду вспоминать. Но где то он вполне применим и его аналогов у JSON-а тоже нет.

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

У XML один стандартный формат, никаких зависимостей нет и быть не может.

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

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

В JSON придётся либо наворачивать кучу «старых добрых» циклов, либо придётся изобретать XPath.

В связи с циклами ещё можно XQuery вспомнить.

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

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

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

А сама либа для валидации json файла по xsd пишется за день.

http://www.linux.org.ru/news/opensource/1343241/page5#comment-1344764

Но где то он вполне применим и его аналогов у JSON-а тоже нет.

Все это можно изобрести конечно и будет приблизительно так же как в XML. Особенно если застандартизировать так же.

Хотя есть патологии в JSON которые не исправить - отсутствие namespaces.

Но что-то JSON-подобное можно изобрести:

@schema http://json.org/schema.aware.json
@namespace x json:with:namespaces {
  x:obj : {
    y:inner: @namespace y local:ns {
      in_y: 10,
      x:in_x: 20
    }
  }
}

Еще придумать x:include, &entity;-substitution, обложить это все json-transform, json-path, json-schema - и вполне будет такой же наборчик как и у xml технологий. Правда ключевая филка jsonа - eval в жабаскрипте накроется медным тазом - но что ж делать зато будет JSON Enterprise Edition.

или лучше даже всять e4x за основу и разработать json-подобное представление.

Правда ключевая филка jsonа - eval в жабаскрипте

Когда я последний раз использовал json, его строго настрого запрещали eval-ить, если только он не совсем-совсем из доверенного источника, потому что он может на-eval-ить что угодно.

наэвалить все что угодно может все что угодно а не только json. evalа боятся - динамические языки не использовать.

>> хрень в том, что проперти можно разбрасать и перемешать как угодно!!!

Согласен. И XML можно написать как угодно

А вот здесь пардончик, вы не можете писать XML как угодно (вполоть до порядка следования подтегов в теге) если этот XML привязан к XSD.

Кроме того, в пропертях значения у вас - тупо какие-то строки, которые никак не проверются. В то время, как в XSD вы можете задать тип значений/атрибутов - например номер, или дату или даже регулярку, и XML, привязанный к этому XSD, не даст вам ошибиться.