Суть моих возражений в том, что это не называется "решать". Это не более чем инструмент диагностики ее наличия. И если это вынести на этам компиляции — то в сущности мало что изменится.
Вот смотрите, есть apache commons lang, и она живет в версиях 2 и 3. И никаких ровным счетом проблем при этом не доставляет — потому что авторы это отработали, и назвали пакеты lang и lang3. Даже в одном классе можете использовать, удобств не будет, но работать работает.
А теперь представим, что у вас наоборот, есть две версии jar, где пакеты, классы и сигнатуры методов одинаковые, а логика методов например разная. И тут-то у нас проблема в полный рост...
А вам никто не мешает это делать практически в любой версии Java. Заводите два classloader, в одном используете одну версию, в другом — другую. Даже если пакеты и классы идентичны по названиям — это все равно работает. Вопрос немножко в другом — чтобы сделать это контроллируемо и удобно. Впрочем, OSGI это вполне удобно позволяет делать тоже.
P.S. Сорри, вон там ниже уже ответили ровно это же.
А можно показать пальцем, с какой стати и где 9-ка выдаст вам такую ошибку компиляции? Насколько я помню, версионирование и контроль версий поддерживаются для модулей, а не для jar, а во-вторых, возможность контроля на предмет только одной поддерживаемой версии одного модуля обсуждалась, и однозначного ответа, как оно в итоге будет, я лично не видел (ну т.е. были разговоры, что можно успешно получить module hell вместо jar hell).
Ну и если у вас существующий проект — то модулей в нем само собой нет, а чтобы они были — надо рефакторить. Так что в итоге все равно получается, что это не решение, а лишь инструмент, еще один.
У меня допустим в OSGI никакого jar hell в обычном смысле и не было никогда. В проекте не только можно, но и реально имеется несколько версий одного и того же, и все это работает, при одном простом условии — что вы пропишете у себя, какие именно версии зависимостей где нужны. А попросту говоря — наведете в зависимостях порядок. И да, OSGI контейнер ругнется в определенный момент, если не сможет однозначно разрешить зависимости какого-то бандла. Но опять же — это не решение, это инструмент. Оно само ничего не сделает. Оно только помогает порядок наводить.
Ну, на самом деле начиная с 8-ки уже можно (да и раньше в общем можно было, просто неудобно). Просто default_value — это должна быть лямбда, или функция.
Как вы себе сегодня представляете решение проблемы в своем проекте при помощи модуляризации JRE и разбиения rt.jar? Ну т.е. у вас две версии одной библиотеки, которые притащил maven (или вы их притащили вручную, как я выше описывал). Зато у вас rt.jar модульный. И какая связь?
Насколько я понимаю, проект Jigsaw никогда не претендовал решать проблему Jar-hell в вашем проекте. В лучшем случае это еще один инструмент, но не готовое решение — да и с какой бы стати?
Одним из источников Jar-hell, к примеру, является использование зависимостей, взятых черти где — скачанных с непонятных сайтов, без явно указанных версий, короче — разработка без использования maven/gradle/etc для управления зависимостями. И это лечится только правильной постановкой работы в своем проекте. С другими типами проблем чуть иначе — но вывод примерно тот же.
Почти не бывает такого, чтобы контейнер разворачивался из архива без настройки. Там как правило создаются такие артефакты, как JDBC пулы коннектов, JMS очереди, то есть связи, ведущие наружу. А также указываются порты, которое он будет слушать (например http). А также устанавливаются сертификаты, чтобы работал TLS. И много чего еще.
И только потом можно установить приложение, так как написано, и это лишь маленькая часть настройки.
Поэтому то, что тут написано в разделе про докер — так можно только для примитивного приложения, которое наружу не смотрит вовсе.
Вы знаете, проще найти готовый, чем спрашивать. Вот примерно тут живут примеры https://bl.ocks.org/mbostock (это конкретно Майк, сам автор). Там диаграмм — десятки в самых разных видах.
Просто линейный график — это path в SVG, он прост (и выбор тут скорее между вариантами интерполяции, т.е. строить ли ломаную, или сглаживать ее сплайном, и т.п.).
А раскрашенные диапазоны — это просто прямоугольники. Все что вам нужно — это определить их число, и вычислить размеры (с учетом масштаба, через scale), и цвета.
Ну и понять, в первую очередь, какой у вас вообще масштаб, т.е. не логарифмический ли он, например. А дальше все прямолинейно. Причем заметьте, что scale умеет масштабировать и такие экзотические вещи, например, как цвета — т.е. вы можете создать функцию, которая отображает диапазон [0,1] на [красный, зеленый]. В любой цветовой модели, ну почти. Так что цвет раскраски тоже можно рассчитать, без усилий.
Ну, тут все же вышел перебор. Посмотрите, из любопытства, на специализированные фреймворки построения диаграмм на базе d3. Многие из них, такие как c3, nvd3, и другие (я смотрел таких с десяток наверное) конкретно застряли на v3, и не могут уже годы перейти на v4. Ну т.е. понятно что это не просто — но об этом плохо подумали.
Вы о чем? Откройте d3-scale, это отдельный модуль. 22 открытых, 69 закрытых. Нормальное такое немаленькое число задач. В других — аналогично, уж поверьте.
Добавить отметки на осях позволяет модуль d3-axis. Буквально в две строчки.
Ну, это вы преувеличили :) На самом деле, это стандартный случай. Нестандартный, как обычно, может вылиться в любое число строк кода.
Например, представьте, что у вас по оси X текстовые метки. Месяцы там, или категории чего-либо. И они очень часто не влезают в ту ширину, которая им отводится между тиками. И если автор d3-axis это не предусмотрел, то… вам не повезло.
Хотя, ради объективности, надо сказать, что если элементы, из которых формируется ось, т.е. тики, текст к ним, и пр., спроектированы хорошо, то есть снабжены классами, то вы можете все же написать функцию, которая, например, повернет надписи вертикально, подвинет их по горизонтали или вертикали, лесенкой, и сделает много чего еще.
Не, Стива-то как раз можно понять, хоть как-то. Мне не нравится, что такие решения принимаются из маркетинговых по сути соображений, но он — конкурент. Ему плевать на Adobe, если они не приносят денег — ну и хрен с ними.
А тут компания сама делает все, чтобы убить свой же продукт, который сначала купила… Вот это я не пойму.
А вам зачем в штуках сайтов? Не понимаю, зачем это нужно может быть.
Я оцениваю число людей в коммьюнити, качество документации, качество кода, благо он весь открыт, как самой библиотеки, так и конкретных компонент. И это все на вполне приличном уровне. Баги есть, кудаж без них. Пожелания неисполнимые к авторам тоже есть. Скажем, они видимо живут в идеальном мире, где компонент — это лишь HTML, у меня же масса SVG, а с поддержкой namespaces у них того, сложности…
Тем не менее: 130 коммитеров у самого полимера, без библиотеки компонентов. Далеко не все из гугля, я бы сказал, что основные 10-20 оттуда, а остальные кто попало. Десятки релизов, тысячи компонент выпущено, сотнями я лично пользуюсь, написал примерно 20 своих. Среди сообщества — такие компании, известные лично мне, как Vaadin Ltd.
Это никаким боком не похоже на умирающий проект. Скорее уж на какой-нибудь Кобол, который даже если захотеть — не умрет все равно. Займет свою нишу, и будет жить вечно.
И да, я ни разу за полгода не вспомнил о Shadow DOM, не понимаю, откуда взялось ваше нежелание его видеть. Может, вы на версию типа 0.5 смотрели?
Причем, заметьте — авторы, они все на node. У них все средства разработки — это polymer-cli, bower и т.п., и все это нода. У меня ее нет, от слова вообще. Java, и все такое. И при этом я не испытываю особых неудобств, разрабатывая как приложение, так и компоненты.
Ларри купил Sun в те времена, когда в апплетах уже многие разочаровались. Так что я хоть и согласен в целом с выводами, но только вы их не по адресу. И реально сделать то, что вы хотите, вероятно станет возможным только сейчас, с выпуском модульной JVM 9. Да и то, не факт, не факт.
Понимаете, JVM же не ставится вместе с браузером. И она большая, даже по нынешним временам. А уж 20 лет назад — и подавно была.
Вот если кого стоило бы поругать — так это хозяев Adobe. Которые по сути убивают Flash уже много лет, своими руками. Им даже помошники не особо нужны в этом.
Для богатых тоже… я лично наблюдал приложение (в виде десятка excel разного назначения), где было порядка сотни тысяч строк VBA кода. И написали его простые бедные трейдеры, ни разу не программисты, математики по образованию.
И другое такое же — для оценки рисков кредитования.
Ну, на самом-то деле все обычно еще интереснее. Это у вас один пул на приложение, а если их будет несколько (а их будет — потому что некоторые фреймворки их будут создавать, не спрашивая у вас)? Ну плюс все остальное, что уже изложили...
Не могу вам ответить конкретно, но субъективные ощущения примерно такие же. Несколько лет назад тоже не закрывал вкладки никогда, и держал их по 100 штук. Были периоды, когда Firefox на этом падал, но были и периоды, когда это стабильно жило месяцами. А сейчас при 20-30 вкладках подмывает позакрывать.
Ваши 6 гигов и SSD, кстати, могут достаточно сильно менять дело.
Да он его, честно говоря, даже в области бизнес-приложений (т.е. Flex) все еще не может заменить полноценно. Т.е. там, где не нужна ни быстрая графика, ни видео стримы, ни все такое. Потому что фреймворк виджетов в Flex, и сам набор виджетов, которые там были (в том числе — и написанные пользователями) был настолько хорош уже к 2009 году, что мы и сегодня ничего подобного не имеем.
Я не очень понял, в чем вы видите разницу (CORS, если уж на то пошло, вообще появился позже, чем Flash, и в нем в каком-то виде поддерживался (crossdomain.xml, сколько я помню), так что мне кажется вы тут ошибаетесь). Ну да, границы разные. Но тут вполне было за что платить-то, разница в возможностях уж очень велика.
И кроме того, набор доступных разработчику на JS возможностей — он же тоже постоянно растет, так что границы песочницы только расширяются. Причем в частности и потому, что разработчикам не хватает возможностей, которые были в том же Flash. Добавили поддержку микрофона, веб камеры, bluetooth, геолокации, канвас, WebGL, и много чего еще. Ходят слухи, что хакеры научились майнить биткоины через браузер. Думаете, число потенциальных векторов атаки сокращается? Да ладно...
По-хорошему, бороться с дырами в плагинах можно было, причем несколькими вполне очевидными способами. Один из них даже реализован — в FF, скажем, есть механизм отключения плагинов, про которые известно, что там дырки. Ну т.е. браузер отключит ваш Flash, как только получит оповещение. И включит после обновления. Значительно быстрее, чем это сделаете вы сами.
Суть моих возражений в том, что это не называется "решать". Это не более чем инструмент диагностики ее наличия. И если это вынести на этам компиляции — то в сущности мало что изменится.
Вот смотрите, есть apache commons lang, и она живет в версиях 2 и 3. И никаких ровным счетом проблем при этом не доставляет — потому что авторы это отработали, и назвали пакеты lang и lang3. Даже в одном классе можете использовать, удобств не будет, но работать работает.
А теперь представим, что у вас наоборот, есть две версии jar, где пакеты, классы и сигнатуры методов одинаковые, а логика методов например разная. И тут-то у нас проблема в полный рост...
А вам никто не мешает это делать практически в любой версии Java. Заводите два classloader, в одном используете одну версию, в другом — другую. Даже если пакеты и классы идентичны по названиям — это все равно работает. Вопрос немножко в другом — чтобы сделать это контроллируемо и удобно. Впрочем, OSGI это вполне удобно позволяет делать тоже.
P.S. Сорри, вон там ниже уже ответили ровно это же.
А можно показать пальцем, с какой стати и где 9-ка выдаст вам такую ошибку компиляции? Насколько я помню, версионирование и контроль версий поддерживаются для модулей, а не для jar, а во-вторых, возможность контроля на предмет только одной поддерживаемой версии одного модуля обсуждалась, и однозначного ответа, как оно в итоге будет, я лично не видел (ну т.е. были разговоры, что можно успешно получить module hell вместо jar hell).
Ну и если у вас существующий проект — то модулей в нем само собой нет, а чтобы они были — надо рефакторить. Так что в итоге все равно получается, что это не решение, а лишь инструмент, еще один.
У меня допустим в OSGI никакого jar hell в обычном смысле и не было никогда. В проекте не только можно, но и реально имеется несколько версий одного и того же, и все это работает, при одном простом условии — что вы пропишете у себя, какие именно версии зависимостей где нужны. А попросту говоря — наведете в зависимостях порядок. И да, OSGI контейнер ругнется в определенный момент, если не сможет однозначно разрешить зависимости какого-то бандла. Но опять же — это не решение, это инструмент. Оно само ничего не сделает. Оно только помогает порядок наводить.
Ну, на самом деле начиная с 8-ки уже можно (да и раньше в общем можно было, просто неудобно). Просто default_value — это должна быть лямбда, или функция.
Как вы себе сегодня представляете решение проблемы в своем проекте при помощи модуляризации JRE и разбиения rt.jar? Ну т.е. у вас две версии одной библиотеки, которые притащил maven (или вы их притащили вручную, как я выше описывал). Зато у вас rt.jar модульный. И какая связь?
Насколько я понимаю, проект Jigsaw никогда не претендовал решать проблему Jar-hell в вашем проекте. В лучшем случае это еще один инструмент, но не готовое решение — да и с какой бы стати?
Одним из источников Jar-hell, к примеру, является использование зависимостей, взятых черти где — скачанных с непонятных сайтов, без явно указанных версий, короче — разработка без использования maven/gradle/etc для управления зависимостями. И это лечится только правильной постановкой работы в своем проекте. С другими типами проблем чуть иначе — но вывод примерно тот же.
Почти не бывает такого, чтобы контейнер разворачивался из архива без настройки. Там как правило создаются такие артефакты, как JDBC пулы коннектов, JMS очереди, то есть связи, ведущие наружу. А также указываются порты, которое он будет слушать (например http). А также устанавливаются сертификаты, чтобы работал TLS. И много чего еще.
И только потом можно установить приложение, так как написано, и это лишь маленькая часть настройки.
Поэтому то, что тут написано в разделе про докер — так можно только для примитивного приложения, которое наружу не смотрит вовсе.
Вы знаете, проще найти готовый, чем спрашивать. Вот примерно тут живут примеры https://bl.ocks.org/mbostock (это конкретно Майк, сам автор). Там диаграмм — десятки в самых разных видах.
Просто линейный график — это path в SVG, он прост (и выбор тут скорее между вариантами интерполяции, т.е. строить ли ломаную, или сглаживать ее сплайном, и т.п.).
А раскрашенные диапазоны — это просто прямоугольники. Все что вам нужно — это определить их число, и вычислить размеры (с учетом масштаба, через scale), и цвета.
Ну и понять, в первую очередь, какой у вас вообще масштаб, т.е. не логарифмический ли он, например. А дальше все прямолинейно. Причем заметьте, что scale умеет масштабировать и такие экзотические вещи, например, как цвета — т.е. вы можете создать функцию, которая отображает диапазон [0,1] на [красный, зеленый]. В любой цветовой модели, ну почти. Так что цвет раскраски тоже можно рассчитать, без усилий.
Ну, тут все же вышел перебор. Посмотрите, из любопытства, на специализированные фреймворки построения диаграмм на базе d3. Многие из них, такие как c3, nvd3, и другие (я смотрел таких с десяток наверное) конкретно застряли на v3, и не могут уже годы перейти на v4. Ну т.е. понятно что это не просто — но об этом плохо подумали.
Вы о чем? Откройте d3-scale, это отдельный модуль. 22 открытых, 69 закрытых. Нормальное такое немаленькое число задач. В других — аналогично, уж поверьте.
Ну, это вы преувеличили :) На самом деле, это стандартный случай. Нестандартный, как обычно, может вылиться в любое число строк кода.
Например, представьте, что у вас по оси X текстовые метки. Месяцы там, или категории чего-либо. И они очень часто не влезают в ту ширину, которая им отводится между тиками. И если автор d3-axis это не предусмотрел, то… вам не повезло.
Хотя, ради объективности, надо сказать, что если элементы, из которых формируется ось, т.е. тики, текст к ним, и пр., спроектированы хорошо, то есть снабжены классами, то вы можете все же написать функцию, которая, например, повернет надписи вертикально, подвинет их по горизонтали или вертикали, лесенкой, и сделает много чего еще.
Не, Стива-то как раз можно понять, хоть как-то. Мне не нравится, что такие решения принимаются из маркетинговых по сути соображений, но он — конкурент. Ему плевать на Adobe, если они не приносят денег — ну и хрен с ними.
А тут компания сама делает все, чтобы убить свой же продукт, который сначала купила… Вот это я не пойму.
А вам зачем в штуках сайтов? Не понимаю, зачем это нужно может быть.
Я оцениваю число людей в коммьюнити, качество документации, качество кода, благо он весь открыт, как самой библиотеки, так и конкретных компонент. И это все на вполне приличном уровне. Баги есть, кудаж без них. Пожелания неисполнимые к авторам тоже есть. Скажем, они видимо живут в идеальном мире, где компонент — это лишь HTML, у меня же масса SVG, а с поддержкой namespaces у них того, сложности…
Тем не менее: 130 коммитеров у самого полимера, без библиотеки компонентов. Далеко не все из гугля, я бы сказал, что основные 10-20 оттуда, а остальные кто попало. Десятки релизов, тысячи компонент выпущено, сотнями я лично пользуюсь, написал примерно 20 своих. Среди сообщества — такие компании, известные лично мне, как Vaadin Ltd.
Это никаким боком не похоже на умирающий проект. Скорее уж на какой-нибудь Кобол, который даже если захотеть — не умрет все равно. Займет свою нишу, и будет жить вечно.
И да, я ни разу за полгода не вспомнил о Shadow DOM, не понимаю, откуда взялось ваше нежелание его видеть. Может, вы на версию типа 0.5 смотрели?
Причем, заметьте — авторы, они все на node. У них все средства разработки — это polymer-cli, bower и т.п., и все это нода. У меня ее нет, от слова вообще. Java, и все такое. И при этом я не испытываю особых неудобств, разрабатывая как приложение, так и компоненты.
Ларри купил Sun в те времена, когда в апплетах уже многие разочаровались. Так что я хоть и согласен в целом с выводами, но только вы их не по адресу. И реально сделать то, что вы хотите, вероятно станет возможным только сейчас, с выпуском модульной JVM 9. Да и то, не факт, не факт.
Понимаете, JVM же не ставится вместе с браузером. И она большая, даже по нынешним временам. А уж 20 лет назад — и подавно была.
Вот если кого стоило бы поругать — так это хозяев Adobe. Которые по сути убивают Flash уже много лет, своими руками. Им даже помошники не особо нужны в этом.
О, да. Во младенчестве, выпустив версию 1.9.1, и благополучно смигрировав в ветку 2.х. Я тоже поржал.
Для богатых тоже… я лично наблюдал приложение (в виде десятка excel разного назначения), где было порядка сотни тысяч строк VBA кода. И написали его простые бедные трейдеры, ни разу не программисты, математики по образованию.
И другое такое же — для оценки рисков кредитования.
Ну, на самом-то деле все обычно еще интереснее. Это у вас один пул на приложение, а если их будет несколько (а их будет — потому что некоторые фреймворки их будут создавать, не спрашивая у вас)? Ну плюс все остальное, что уже изложили...
Не могу вам ответить конкретно, но субъективные ощущения примерно такие же. Несколько лет назад тоже не закрывал вкладки никогда, и держал их по 100 штук. Были периоды, когда Firefox на этом падал, но были и периоды, когда это стабильно жило месяцами. А сейчас при 20-30 вкладках подмывает позакрывать.
Ваши 6 гигов и SSD, кстати, могут достаточно сильно менять дело.
Да он его, честно говоря, даже в области бизнес-приложений (т.е. Flex) все еще не может заменить полноценно. Т.е. там, где не нужна ни быстрая графика, ни видео стримы, ни все такое. Потому что фреймворк виджетов в Flex, и сам набор виджетов, которые там были (в том числе — и написанные пользователями) был настолько хорош уже к 2009 году, что мы и сегодня ничего подобного не имеем.
Я не очень понял, в чем вы видите разницу (CORS, если уж на то пошло, вообще появился позже, чем Flash, и в нем в каком-то виде поддерживался (crossdomain.xml, сколько я помню), так что мне кажется вы тут ошибаетесь). Ну да, границы разные. Но тут вполне было за что платить-то, разница в возможностях уж очень велика.
И кроме того, набор доступных разработчику на JS возможностей — он же тоже постоянно растет, так что границы песочницы только расширяются. Причем в частности и потому, что разработчикам не хватает возможностей, которые были в том же Flash. Добавили поддержку микрофона, веб камеры, bluetooth, геолокации, канвас, WebGL, и много чего еще. Ходят слухи, что хакеры научились майнить биткоины через браузер. Думаете, число потенциальных векторов атаки сокращается? Да ладно...
По-хорошему, бороться с дырами в плагинах можно было, причем несколькими вполне очевидными способами. Один из них даже реализован — в FF, скажем, есть механизм отключения плагинов, про которые известно, что там дырки. Ну т.е. браузер отключит ваш Flash, как только получит оповещение. И включит после обновления. Значительно быстрее, чем это сделаете вы сами.