lsFusion 4

События в 1С это не более чем триггеры в СУБД.

Речь не о том, что ваши события хуже.
В 1С много полезных объектов, которые много упрощают разработку алгоритмов.
Впрочем «хозяин - барин».

Владимир 123

Но реализация как раз простая - индекс по порядку в LAST (MAX - частный случай LAST, где порядком выступает само значение). Индекс это как правило 2-3 дерево (в современных субд), которое обновляется за логарифм (то есть за константу). Соотвественно достаточно определить разрезы в которых идет изменение, и при удалении считать из индекса.

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

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

Ну вот, а как же автоматическая инкрементальность? Текут абстракции, да? :)

В 1С много полезных объектов, которые много упрощают разработку алгоритмов.

Интересно было бы сопоставить функциональность объектов lfusion и 1С … /не для шельмования конечно/.

Владимир 123

Тут фокус, что при изменении H1.L, нужно найти все Item у которых Item.H = H1 и для них вызвать события изменения до, потом изменить L и вызвать события изменения после. Я честно не понимаю, как это сделать, тем более прозрачно (чтобы была «общая библиотека»).

Зачем искать все? Если нужны события, то модель данных реализуется с учетом этого, и при изменении H1.L будет событие об изменении L, которое в свою очередь инициирует событие об изменении Item.H. Можно также реализовать модель так, чтобы в событии было полное имя свойства, то есть чтобы пришло не просто событие об изменении H, а об изменении H.L.

Ну и вообще хочется посмотреть как этот ваш EventAggregator будет маппиться на SQL (чтобы выполнять все там).

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

Причем тут computer science? Если не заниматься теоретизированием (как с монадами), в той же java, лямбда это не более чем анонимный класс с одним методом. До 8 java так все и делалось, было чуть больше кода не более. Зато не раздувался язык.

При том, что это классы синтаксический сахар, а не лямбды. :) Да, анонимный класс это аналог лямбд, но вы зачем-то еще вспомнили о макросах в C и eval, что вообще мимо.

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

Вообще его созданием должен / может управлять администратор (!) или даже сама платформа (типа как в СУБД подсказывать у вас не хватает индекса), но никак не разработчик (он собственно статистики использования может не знать). Задача разработчика сказать что он хочет получить, а как проблемы платформы.

Ну вот, а как же автоматическая инкрементальность? Текут абстракции, да? :)

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

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

Зачем искать все? Если нужны события, то модель данных реализуется с учетом этого, и при изменении H1.L будет событие об изменении L, которое в свою очередь инициирует событие об изменении Item.H.

Ну так для этого и надо найти все Item (причем по хорошему по индексу по H, если он есть).

Можно также реализовать модель так, чтобы в событии было полное имя свойства, то есть чтобы пришло не просто событие об изменении H, а об изменении H.L. Как вариант, надо реализовать для EventAggregator интерфейс INotifyPropertyChanged. Клиентский код будет ждать событие об изменении свойства Value и уже далее сам решать что делать: сохранить это значение в базу, в журнал или просто отобразить на экране.

А можно увидеть это вживую в виде абстрактной библиотеки (чтобы не 256 строк кода было). А то сейчас как в анекдоте получается, «я стратег, а не тактик» :) Потому как в lsFusion это одна строка.

При том, что это классы синтаксический сахар, а не лямбды. :) Да, анонимный класс это аналог лямбд, но вы зачем-то еще вспомнили о макросах в C и eval, что вообще мимо.

Так я так и не понял вы за синтаксический сахар или против. Ведь это же новый синтаксис надо учить, а это же так трудно.

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

Интересно было бы сопоставить функциональность объектов lfusion и 1С … /не для шельмования конечно/.

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

Если кто-либо разработает технологию лучшую чем WWW, то не факт, что ее «на руках будут носить» …
К объектам 1С многие разработчики «привыкли» /функциональность их неплохая/ и конечно /к сожалению/ многие в ШТЫКИ принимают все новое.

ИМХО вам конечно необходим цикл статей о методологии разработки, объектах, … вашей платформы.

PS: Также желательно наличие небольших examples к каждому объекту.

Владимир 123

Вообще его созданием должен / может управлять администратор (!) или даже сама платформа (типа как в СУБД подсказывать у вас не хватает индекса), но никак не разработчик (он собственно статистики использования может не знать). Задача разработчика сказать что он хочет получить, а как проблемы платформы.

Сначало вы обещаете полную автоматизацию и инкрементальные вычисление, а потом говорите, что для этого надо администратора привлекать…

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

Какая же это инкрементальность, если надо ко всей коллекции обращаться?

Ну так для этого и надо найти все Item (причем по хорошему по индексу по H, если он есть).

А зачем? Вы же говорите про инкрементальность: у нас должен быть доступен только текущий результат, старое и новое значение Item. Если у вас есть доступ ко всем Item в коллекции, то это читерство. :)

А можно увидеть это вживую в виде абстрактной библиотеки (чтобы не 256 строк кода было). А то сейчас как в анекдоте получается, «я стратег, а не тактик» :) Потому как в lsFusion это одна строка.

sumAggr.ValueChanged += (sender, args) => { store.Save(args.Value); };
sumAggr.ValueChanged += (sender, args) => { log.Info(args.Value); };
sumAggr.ValueChanged += (sender, args) => { display(args.Value); };

Так я так и не понял вы за синтаксический сахар или против. Ведь это же новый синтаксис надо учить, а это же так трудно.

Я «за», но в разумных пределах. Уж точно сахара в виде TCP (HTTP, XML, JSON etc.) в самом языке не должно быть.

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

Интересно и как это сделать?

Сначало вы обещаете полную автоматизацию и инкрементальные вычисление, а потом говорите, что для этого надо администратора привлекать…

Администратора если и надо привлекать, то только для оптимизации производительности. Ровно как и в SQL, когда пишешь запрос, а платформа (СУБД) выживает из него максимум. Но вообще автоматическое построение индексов следующий шаг. Хотя в принципе и сейчас можно включить пессимистичный режим, строить индексы для всех GROUP LAST скажем.

Какая же это инкрементальность, если надо ко всей коллекции обращаться?

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

А зачем? Вы же говорите про инкрементальность: у нас должен быть доступен только текущий результат, старое и новое значение Item. Если у вас есть доступ ко всем Item в коллекции, то это читерство. :)

Инкрементальность не подразумевает крайности (либо максимально эффективно, либо никак). Как и выполнение запросов например. Есть полутона (то есть доступ не ко всей коллекции, а только ее части). Но опять таки это не проблема разработчика, а проблема платформы и / или администратора.

sumAggr.ValueChanged += (sender, args) => { store.Save(args.Value); };

А можно целиком код увидеть, а не отдельные отрывки?

Я «за», но в разумных пределах. Уж точно сахара в виде TCP (HTTP, XML, JSON etc.) в самом языке не должно быть.

Ну вопрос что разумные пределы у всех разные. Но я честно говоря этой языкофобии не понимаю. Если язык LL из известной группы скажем C или SQL, лично мне его понять проще, чем интерфейс в виде методов структур данных.

Интересно и как это сделать?

Ну например так:

x(INTEGER a) {
}
y(INTEGER a) {
}

runF(STRING func) { // передаем функци
   EVAL func + '($1)' PARAMS 4; // вызываем функцию с параметром 4
}

test() {
   runF('x');
   runF('y');
}

С макросами похоже.

Инкрементальность не подразумевает крайности (либо максимально эффективно, либо никак). Как и выполнение запросов например. Есть полутона (то есть доступ не ко всей коллекции, а только ее части). Но опять таки это не проблема разработчика, а проблема платформы и / или администратора.

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

А можно целиком код увидеть, а не отдельные отрывки?

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

Если язык LL из известной группы скажем C или SQL, лично мне его понять проще, чем интерфейс в виде методов структур данных.

Для добавления бизнес-функций менять язык? Вы это можете, а сами пользователи?

Ну например так:

EVAL func + ‘($1)’ PARAMS 4

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

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

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

Код чего конкретно вы хотите увидеть?

Абстрактной библиотеки, чтобы там можно было прописать лямбды (то что вы делали с простым суммированием) с тем же уровнем выразительности (1-5 строк):

sumX(X x) = GROUP SUM z(h(Item i)) IF ys(i) = x MATERIALIZED;

Persistent, инкрементально, без проблемы N+1 (ну или простым языком чтобы работало в жизни хотя бы на средних объемах)

Для добавления бизнес-функций менять язык? Вы это можете, а сами пользователи?

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

Хотя мне кажется мы из пустого в порожнее переливаем.

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

Ну строго говоря этим антипаттерном в SQL пользуются очень часто, если runF не может быть вызвана извне (и параметр туда не может придти скажем из поля ввода).

Что касается лямбд, то основное их использование - передача функций в качестве параметров. Соответственно в контексте EVAL передается строка с именем функции (своего рода ссылка, но через глобальный реестр имен). Там конечно еще замыкание важная вещь, но EVAL’ом это тоже можно делать.

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

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

Абстрактной библиотеки, чтобы там можно было прописать лямбды (то что вы делали с простым суммированием) с тем же уровнем выразительности (1-5 строк): sumX(X x) = GROUP SUM z(h(Item i)) IF ys(i) = x MATERIALIZED;

Теперь понял. Так подойдет?

Expression<Func<IFusion, int, int>> sum =
    (fusion, x) => fusion.GetTable<Item>().Select(item => item.H.Z).Where(z => z == x).Sum();

IFusion fusion = new Fusion();

fusion.AddFunc(sum, materialized: true);
fusion.AddConstraint(sum, (result) => result < 5);

Описание интерфейса и модели:

public interface IFusion
{
    IQueryable<T> GetTable<T>();
    void AddFunc<TSource, TResult>(Expression<Func<IFusion, TSource, TResult>> func, bool materialized = false);
    void AddConstraint<TSource, TResult>(
        Expression<Func<IFusion, TSource, TResult>> func,
        Expression<Func<TResult, bool>> constraint
    );
}

public class FusionTableAttribute : Attribute {}

[FusionTable]
public class Item
{
    public SubItem H { get; set; }
}

[FusionTable]
public class SubItem
{
    public int Z { get; set; }
}

Persistent, инкрементально, без проблемы N+1 (ну или простым языком чтобы работало в жизни хотя бы на средних объемах)

Это все вопросы реализации, и на всех платформах будут решаться одинаково. Да, у вас есть готовая реализаця, а на .Net нет, но мы же за выразительность языка говорим.

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

Зачем добавлять операторы, если можно просто добавить функции? :) Кстати, я не припомню, чтобы в Lisp были операторы, даже если и есть такое понятие, то по сути это теже функции.

Ну строго говоря этим антипаттерном в SQL пользуются очень часто, если runF не может быть вызвана извне (и параметр туда не может придти скажем из поля ввода).

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

Что касается лямбд, то основное их использование - передача функций в качестве параметров. Соответственно в контексте EVAL передается строка с именем функции (своего рода ссылка, но через глобальный реестр имен). Там конечно еще замыкание важная вещь, но EVAL’ом это тоже можно делать.

Но зачем всё это? Когда есть мейнстримовые языки, в которых функции уже first-class citizens.

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

Инкрементальность это количественное свойство. А именно сложность обновления результата по сравнению с его пересчетом. Если у вас пересчет n, а обновление log n (а не 1 как вы почему то считаете) инкрементальность очень высокая. Так вот с использованием индекса инкрементальность очень высокая.

Теперь понял. Так подойдет?

Ну уже ближе. Только там не getTable а другой expression должен быть, платформа потом сама подставляет таблицы и разбивает на union в зависимости от физмодели / условия запроса. Ну и с параметрами там все же сложнее.

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

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

Вы по моему плохо понимаете сложность такой реализации. Она практически не уступает скажем сложности реализации коммерческих SQL серверов (как архитектурно так и алгоритмически)

Но зачем всё это? Когда есть мейнстримовые языки, в которых функции уже first-class citizens.

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

Конфигурации 1С является одной из реализаций деревьев.
Ссылки как раз и являются ветвями дерева.
Как у вас?

Владимир 123

Скорее всего ни как, так как проект акцентирован на разработку эффективных алгоритмов работы с данными.

В целом - интересный проект.

Владимир 123

Ну уже ближе. Только там не getTable а другой expression должен быть, платформа потом сама подставляет таблицы и разбивает на union в зависимости от физмодели / условия запроса. Ну и с параметрами там все же сложнее.

Вызов GetTable нужен чтобы получить интерфейс IQueryable (IQueryable и Expression – основные интерфейсы linq), на который уже «навешиваются» необходимые методы. Во что транслируется данное выражение, уже зависит от linq-провайдера.

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

А библиотека для java была? Интересно посмотреть, как там это выглядело. Java на данный момент менее выразительна, чем шарп, но и там люди делают подобные вещи jooq, speedment.

Вы по моему плохо понимаете сложность такой реализации. Она практически не уступает скажем сложности реализации коммерческих SQL серверов (как архитектурно так и алгоритмически)

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

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

Нельзя рассматривать SQL в отрыве от движка СУБД. SQL – это просто язык. У MS для SQL Server была реализация протокола сериализации linq без промежуточного sql, но почему-то они не стали ее развивать.

А библиотека для java была? Интересно посмотреть, как там это выглядело. Java на данный момент менее выразительна, чем шарп, но и там люди делают подобные вещи jooq, speedment.

Ну надо понимать что это было 10 лет назад (когда LINQ еще не уверен что вообще существовал) и выглядело это мягко говоря не очень (там параметры маппились по номерам, а не именам для большей лаконичности):

https://github.com/lsfusion/platform/blob/0efc0924679ff65f739388050584e1b00605ac08/platform/tmc/src/main/java/tmc/VEDBusinessLogics.java

(один из очень ранних коммитов 2008 года)

Но даже если бы часть логики (в данном случае свойств) и удалось бы натянуть на синтаксис linq expressions непонятно зачем это надо. В конечном итоге это все равно было бы сильно менее выразительно, чем tailor made грамматика, при этом в лучшем случае получили бы немного больше вистов от .net разработчиков (которых хорошо если 5% в мире).

Нельзя рассматривать SQL в отрыве от движка СУБД. SQL – это просто язык

Странная формулировка, а Java в отрыве от JVM можно рассматривать? В той же Java экосистеме Java это и язык и платформа (и это логично на мой взгляд). Но в любом случае не совсем понял, как это относится к тому что я написал.

Но даже если бы часть логики (в данном случае свойств) и удалось бы натянуть на синтаксис linq expressions непонятно зачем это надо.

Ну хотя бы, чтобы eval в языке не было. :)

Но в любом случае не совсем понял, как это относится к тому что я написал.

Написано к тому, что ценен не sql, а движок базы. Если бы sql заменили на linq, то разработчики бы только выиграли. Посмотрите возможности декомпозиции запроса, которые предоставляет linq2db. А в это время в sql клеят строки…

Ну хотя бы, чтобы eval в языке не было. :)

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

Написано к тому, что ценен не sql, а движок базы. Если бы sql заменили на linq, то разработчики бы только выиграли. Посмотрите возможности декомпозиции запроса, которые предоставляет linq2db. А в это время в sql клеят строки…

А я строго говоря не защищаю SQL. То что его уже давно пора было «проапгрейдить» вопросов нет. Но имхо linq не самый лучший вектор развития в этом плане. Лямбды все же не самый очевидный механизм (это по опыту объяснения людям без опыта IT и существующего lsFusion синтаксиса и лямбд). Плюс linq покроет только малую часть этого «new SQL».

Ну и опять таки тот же linq далеко не стандарт в области. Даже в «области .Net». А сам .Net далеко не стандарт в области IT. То есть опять-таки непонятно зачем «натягивать сову на глобус». Язык все равно получится менее выразительным, чем подогнанный под парадигму, а выигрыша ноль по сути.

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

Ну, в C# нет eval и при этом он отлично скриптуется.

Ну и опять таки тот же linq далеко не стандарт в области. Даже в «области .Net». А сам .Net далеко не стандарт в области IT. То есть опять-таки непонятно зачем «натягивать сову на глобус». Язык все равно получится менее выразительным, чем подогнанный под парадигму, а выигрыша ноль по сути.

Еще раз, linq – это вариант реализации функциональной парадигмы в C#, которая должна по вашему мнению поставить мозги программистам на место. Но при этом оказывается, что ваш язык по факту базовые вещи и не поддерживает. Зачем вы вообще функциональное программирование в контексте своей системы упоминаете?

Ну, в C# нет eval и при этом он отлично скриптуется.

Не совсем понял, к чему эта ссылка. Функционал, который нужен, это чтобы можно было сформировать код на C# и выполнить его на сервере приложений (также как например администратор может написать / сформировать строку на SQL и выполнить его на сервере БД).

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

Да, строго говоря это не functional, а function-level программирование: https://en.wikipedia.org/wiki/Function-level_programming

Но у них есть очень много похожего. Прежде всего чистота функций (хотя функциональное программирование это формально не требует но очень поощряет). И соответственно людям привыкшим к functional программированию на чистых функциях гораздо проще понять function-level программирование, чем тем кто привык к классическому structural программированию.

Ну и общий тезис, что человеку незнакомому ни с одним из них function-level проще понять, чем structural (так как математика 9-й класс все дела).

Жалко Бакус недавно умер :(. Порадовался бы старик первому продакшн-ready языку основанному на его идеях :).

Не совсем понял, к чему эта ссылка.

Вы говорили про интерпретатор, так вот, он возможен и без eval в языке.

Функционал, который нужен, это чтобы можно было сформировать код на C# и выполнить его на сервере приложений (также как например администратор может написать / сформировать строку на SQL и выполнить его на сервере БД).

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

Да, строго говоря это не functional, а function-level программирование: https://en.wikipedia.org/wiki/Function-level_programming

Ну и общий тезис, что человеку незнакомому ни с одним из них function-level проще понять, чем structural (так как математика 9-й класс все дела).

Не буду спорить, так как не знаю, что может быть в голове у человека, незнакомого со структурным и функциональным программированием. :)

Но представители у function-level знатные: J, К, Forth. :)

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

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

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

Но представители у function-level знатные: J, К, Forth. :)

На самом деле сюда можно по факту SQL добавить (у него очень много общего с function-level). Собственно lsFusion строится поверх него («превращая» таблицы с ключами в функции) и тем самым делает его полноценным «function-level» языком.

А статьи на хабре нет …

Так еще не вторник вроде. Но не бойтесь не убежит никуда. Выпустим в ближайшее время.

Или что конкретно вы имеете ввиду?

Имел в виду проблемы безопасности, как не дать лишней функциональности. Административные затраты на настройку песочницы будут высоки.

Но если это надо только для администраторов или внедренцев, то проблем нет.

Но если это надо только для администраторов или внедренцев, то проблем нет.

Ну понятно, что не для пользователей (во всяком случае не рядовых). Хотя на самом деле в том же JasperReports, такая runtime-компиляция кода для Java-выражений тоже используется. Но там конечно через одно место сделано и очень часто какие-то проблемы возникают с разными версиями Java / OS и classpath’ами.

https://habr.com/ru/company/lsfusion/blog/536898/