Верно, краеугольный камень OSGi - свой загрузчик классов для каждого 'модуля'. Поэтому, даже одноименные классы из разных модулей - это разный код в JVM.
И, приложение, реализованное на базе OSGi - проще конструировать/сопровождать, чем в концепции JAR hell, пусть, даже с использованием модулей Java.
OSGi не так прост, как кажется. Стандарт OSGi настолько широк, что включает, например, спецификацию XML парсера... А вот, короткая статья про ECF, реализацию спецификации удаленных OSGi-сервисов: http://samolisov.blogspot.com/2011/06/eclipse-indigo-ecf.html
OSGi, говорят, использовался для создания встроенных систем (в частности, для автомобилей BMW). Если интересно - посмотрите перевод книги "OSGi and Equinox. Creating Highly Modular Java Systems". http://vfedorov.info:7070/OSGiEquinox/ В ней, в качестве примера - приложение GPS трекера. wiki книги спросит пользователь/пароль, соответственно ответить: anybody/123123
Да, помимо прямого выполнения, в JVM имеет место быть профайлер ). Конечно, он не успевает отработать на 'коротком' тесте.
Вообще, байт-код не должен вводить в заблуждение - такую композицию можно рассматривать как вынесенный наружу внутренний язык компилятора (в некоторых проектах его называют IL0).
Как ни странно, не представляю, а имел широкий опыт. (вообще то работать начал тогда. инженера заработал еще за 3 года до диплома института:) В целом - там, где кто-то сверху 'понимал', что ''надо" - всё было OK (это про гос. предприятия). Про процессоры снежного Бантустана, это - 'байка', её услышал 18 лет назад, в ту пору лаборатория Бабаяна перекупалась интелом, у Sun.
Можно предположить: да, процессор сам по себе ничего не значит, даже если его сделать. Но для всего остального - надо поднимать не приподъемное...
Бабаян, говорят, в 90е обращался к Ельцину по поводу производства отечественного процессора. Но что толку говорить с вегетарианцем о мясе...
В 1998 году, за 4 месяца была в компьютерном журнале широкая статья об информатизации. Много чего интересного было в той статье, и об упрощении тех. операций, где 2 стадии производства заменялись 3мя, задействовались дополнительно неквалифицированные люди, падала безработица, и квалификация труда (30е годы прошлого века), а так же, автор статьи ясно описал дефолт, за 4 месяца до его реализации...
Постоянно об этом 'думают', но, похоже не те головы.
Это не только 'у нас'. В блоге британского девелопера есть Сатья, не такая большая, но в точку. Он рассуждает о проблеме свободного доступа к 'творчеству', сравнивает с врачами, которых в 30х годах прошлого века ограничили в 'простом' доступе а 'телу', ввели жёсткий контроль, чтоб 'ветеринар' не лечил человека.
Так как именно из-за этого и появляется, проблема, что прежде всего надо разбираться в 'чужом коде'. Программы есть, их эксплуатируют, они Легаси по многим параметрам, но заново переписать их руководство не дает. А когда перепишешь, по немногу, починяя параллельно вдруг найденные проблемы, так и на пенсию пора...
(если есть интерес, то представлю ещё пару из переведенных книг по проектам Eclipse Foundation: https://vfedorov.info/EMFwiki/; https://vfedorov.info/XtextXtendWiki/. Перевод книги по EMF - попытался предоставить издательству. Отказались: "так как у оригинала мал рейтинг продаж на amazon"...)
(в GEF есть функционал dot-file -> 'graph', но он, по-моему барахлит, так как не все примеры предоставленного проекта вывелись им корректно. Определенно, есть возможность - визуализировать граф минуя dot-файл)
Ура!!! (кроме шуток). Python и был для этого создан. Автор языка-инструмента обслуживал море хостов университета. Его заставила окружающая действительность упростить себе жизнь...
Определенно, (за себя пишу) - никто не докапывается. Просто у каждого свой тезаурус (карата сопоставлений <слово,понятие>), из-за разной окружающей действительности. Таким образом, каждая ветка комментариев выливается в процесс фиксации смысла, понятного каждому читателю.
PS: приятно было ознакомиться с Вашим мнением (суждением).
Вполне. В одной из книг, возможно Фаулера - есть звонкая цитата: "Научившись писать, мало кто становится писателем". Соответственно, быстрое освоение языка новичками (во всех смыслах IT) - нисколько не прославляет язык.
PS: Ничего против питона не имею. Просто, из-за нехватки ресурсов (бывает, и знаний;) его используют даже как скриптовый язык управления внутри продукта (в том приложении мне пришлось реализовать для питона встроенный отладчик. Это было элементарно).
Уважаемый Vladimir, согласен. Про НУ, это да - амбициозное заявление. Даже с 'натяжкой', отнеся C к низкому уровню, остальное - не катит ни в какие ворота. Предположим, если это всё компилируемые языки - значит НУ ;). ('натяжечка' C: 1. это связано с историей его возникновения - для того, чтоб уменьшить мытарства с ассемблерами; 2. на заре, для простеньких наборов машинных команд, и не изощренных компиляторов - легко можно было предсказать итог компиляции кода C в команды CPU).
В конце XX века, IBM интегрировал свои дистижения, и, 'родил' Eclipse. ( как это получилось - см. здесь, но там не про desktop: https://vfedorov.info/GEFwiki/Wiki.jsp?page=GEF%20Preface%20%28GEF%29 (user/pwd: anybody/123123) Отжившие свой век AWT/Swing - в Eclipse заменен на SWT/JFace. В основе SWT - нативный код на C (для каждой платформы linux/win/mac|32|64 - надо предоставлять соответствующую сворку. Издержки однако :)
Галопом, по европе - тут: https://betacode.net/10177/ - "Какую платформу я должен выбрать для разработки приложений Java Desktop?", вопрос ведь в этом?
Кстати, после 17 лет 'кувыркания' в кодах от Eclipse-консорциума, мое обращение к C# & WPF - навеяло симбиоз Java & GWT (это ужасней). Конечно, для данной реализации концепции решения, следует отдать должное инструментарию Microsoft. Однако под Linux они его не затащили! ;)
Достаточно сложно вхождение в Eclipse (не в IDE) - без методологии изучения потребуется больше времени. Для относительно 'легкого' знакомства, без блуждания по www - несколько ссылок (спасибо Ларсу Фогелю!!!):
В списке отсутствует 'язык' для Б3-34, и всеми любимый Fortran ;). Кстати, в стандарте фортрана присутствует полная поддержка ООП (довелось в 2003м писать тесты, для покрытия кода компилятора intel...).
А-а-а, использовать под разработку на android? Да, проблематично. Давненько пробовал пару раз... Бросил. Да и разработка на C/C++ - не нативно и коряво там (не для этого его заточили). Не так 'гладко', как, скажем для Java. Хотя и для Java - строит в памяти AST всех открытых одновременно проектов, и если исходников море - может привести к деградации... А тормоза при первой загрузке IDE - удручают, особенно под Windows, который усугубляет проблему антивирусом (1й старт - 45сек., 2й старт - 5сек.).
Всё верно. Однако, можно пойти дальше - создать 'свой язык'. Конечно, просто так, без причин - это абсурдно. Но, если есть требования, предпосылки, то порой продуктивней работать с кастомизированным, специфичным языком (DSL), чем создавать надстройки на языке 'общего назначения'. (язык может служить только лишь для описания данных, как CSS). Как сделать 'свой' DSL, см. https://vfedorov.info/XtextXtendWiki/
user: anybody
password: 123123
Технологически (есть инструменты, кодовая база), в "нише Eclipse", - можно создать графический DSL, или объединить и графическую нотацию и текстовую (и много другого). На эту тему есть тонны материала, дело за малым - решить вопрос внедрения в массы. (Eclipse - это не IDE)
Найдите соответствующие опции JVM, реально для интерпретации, и запустите ваш class ('байт-код') - можно будет очень-очень долго ждать (но это будет 'выполнение байт-кода').
В современных JVM давно по умолчанию JIT. И ещё не поленитесь реализовать 'прогрев' теста, там есть профайлер. Удачи...
Верно, краеугольный камень OSGi - свой загрузчик классов для каждого 'модуля'.
Поэтому, даже одноименные классы из разных модулей - это разный код в JVM.
И, приложение, реализованное на базе OSGi - проще конструировать/сопровождать, чем в концепции JAR hell, пусть, даже с использованием модулей Java.
OSGi не так прост, как кажется.
Стандарт OSGi настолько широк, что включает, например, спецификацию XML парсера...
А вот, короткая статья про ECF, реализацию спецификации удаленных OSGi-сервисов:
http://samolisov.blogspot.com/2011/06/eclipse-indigo-ecf.html
OSGi, говорят, использовался для создания встроенных систем (в частности, для автомобилей BMW).
Если интересно - посмотрите перевод книги "OSGi and Equinox. Creating Highly Modular Java Systems". http://vfedorov.info:7070/OSGiEquinox/
В ней, в качестве примера - приложение GPS трекера.
wiki книги спросит пользователь/пароль, соответственно ответить: anybody/123123
Да, помимо прямого выполнения, в JVM имеет место быть профайлер ). Конечно, он не успевает отработать на 'коротком' тесте.
Вообще, байт-код не должен вводить в заблуждение - такую композицию можно рассматривать как вынесенный наружу внутренний язык компилятора (в некоторых проектах его называют IL0).
Доброго времени.
Как ни странно, не представляю, а имел широкий опыт. (вообще то работать начал тогда. инженера заработал еще за 3 года до диплома института:) В целом - там, где кто-то сверху 'понимал', что ''надо" - всё было OK (это про гос. предприятия). Про процессоры снежного Бантустана, это - 'байка', её услышал 18 лет назад, в ту пору лаборатория Бабаяна перекупалась интелом, у Sun.
Можно предположить: да, процессор сам по себе ничего не значит, даже если его сделать. Но для всего остального - надо поднимать не приподъемное...
Бабаян, говорят, в 90е обращался к Ельцину по поводу производства отечественного процессора. Но что толку говорить с вегетарианцем о мясе...
В 1998 году, за 4 месяца была в компьютерном журнале широкая статья об информатизации. Много чего интересного было в той статье, и об упрощении тех. операций, где 2 стадии производства заменялись 3мя, задействовались дополнительно неквалифицированные люди, падала безработица, и квалификация труда (30е годы прошлого века), а так же, автор статьи ясно описал дефолт, за 4 месяца до его реализации...
Постоянно об этом 'думают', но, похоже не те головы.
Почти ни о чем.
Научившись писать, писателем мало кто стал. Так и с программированием - владение языком != программист.
Посетите коды Eclipse,
загляните в реализацию Servlet...
Это не только 'у нас'. В блоге британского девелопера есть Сатья, не такая большая, но в точку. Он рассуждает о проблеме свободного доступа к 'творчеству', сравнивает с врачами, которых в 30х годах прошлого века ограничили в 'простом' доступе а 'телу', ввели жёсткий контроль, чтоб 'ветеринар' не лечил человека.
Так как именно из-за этого и появляется, проблема, что прежде всего надо разбираться в 'чужом коде'. Программы есть, их эксплуатируют, они Легаси по многим параметрам, но заново переписать их руководство не дает. А когда перепишешь, по немногу, починяя параллельно вдруг найденные проблемы, так и на пенсию пора...
Для входа на чтение:
user: anybody
password: 123123
(если есть интерес, то представлю ещё пару из переведенных книг по проектам Eclipse Foundation: https://vfedorov.info/EMFwiki/; https://vfedorov.info/XtextXtendWiki/. Перевод книги по EMF - попытался предоставить издательству. Отказались: "так как у оригинала мал рейтинг продаж на amazon"...)
Интересный инструмент, предоставляющий возможность наглядно выяснить топологию данных.
PS: как вариант - реализовать визуализациюю в IDE. На базе GEF. См. 'адаптированный' под последний Eclipse перевод (user: anybody; password: 123123):
https://vfedorov.info/GEF4wiki/Wiki.jsp?page=Getting started with GEF
(в GEF есть функционал dot-file -> 'graph', но он, по-моему барахлит, так как не все примеры предоставленного проекта вывелись им корректно. Определенно, есть возможность - визуализировать граф минуя dot-файл)
Молодцы! (что WB 'родили и пестовали'.)
Успехов.
Ура!!! (кроме шуток). Python и был для этого создан. Автор языка-инструмента обслуживал море хостов университета. Его заставила окружающая действительность упростить себе жизнь...
Определенно, (за себя пишу) - никто не докапывается. Просто у каждого свой тезаурус (карата сопоставлений <слово,понятие>), из-за разной окружающей действительности. Таким образом, каждая ветка комментариев выливается в процесс фиксации смысла, понятного каждому читателю.
PS: приятно было ознакомиться с Вашим мнением (суждением).
Не разочаровывайтесь ;), ведь в стандарте Java нет понятия 'функция', соответственно и механизма для манипуляции ими. Или есть?
Вполне. В одной из книг, возможно Фаулера - есть звонкая цитата: "Научившись писать, мало кто становится писателем". Соответственно, быстрое освоение языка новичками (во всех смыслах IT) - нисколько не прославляет язык.
PS: Ничего против питона не имею. Просто, из-за нехватки ресурсов (бывает, и знаний;) его используют даже как скриптовый язык управления внутри продукта (в том приложении мне пришлось реализовать для питона встроенный отладчик. Это было элементарно).
Уважаемый Vladimir, согласен. Про НУ, это да - амбициозное заявление. Даже с 'натяжкой', отнеся C к низкому уровню, остальное - не катит ни в какие ворота. Предположим, если это всё компилируемые языки - значит НУ ;). ('натяжечка' C: 1. это связано с историей его возникновения - для того, чтоб уменьшить мытарства с ассемблерами; 2. на заре, для простеньких наборов машинных команд, и не изощренных компиляторов - легко можно было предсказать итог компиляции кода C в команды CPU).
В конце XX века, IBM интегрировал свои дистижения, и, 'родил' Eclipse. ( как это получилось - см. здесь, но там не про desktop: https://vfedorov.info/GEFwiki/Wiki.jsp?page=GEF%20Preface%20%28GEF%29 (user/pwd: anybody/123123) Отжившие свой век AWT/Swing - в Eclipse заменен на SWT/JFace. В основе SWT - нативный код на C (для каждой платформы linux/win/mac|32|64 - надо предоставлять соответствующую сворку. Издержки однако :)
Галопом, по европе - тут: https://betacode.net/10177/ - "Какую платформу я должен выбрать для разработки приложений Java Desktop?", вопрос ведь в этом?
Кстати, после 17 лет 'кувыркания' в кодах от Eclipse-консорциума, мое обращение к C# & WPF - навеяло симбиоз Java & GWT (это ужасней). Конечно, для данной реализации концепции решения, следует отдать должное инструментарию Microsoft. Однако под Linux они его не затащили! ;)
Достаточно сложно вхождение в Eclipse (не в IDE) - без методологии изучения потребуется больше времени. Для относительно 'легкого' знакомства, без блуждания по www - несколько ссылок (спасибо Ларсу Фогелю!!!):
https://www.vogella.com/tutorials/SWT/article.html
https://www.vogella.com/tutorials/EclipseDialogs/article.html
https://www.vogella.com/tutorials/EclipseRCP/article.html - это уже 'тяжелая артиллерия'
https://www.vogella.com/tutorials/EclipseWindowBuilder/article.html - это Window Builder (однозначно к нему кто-то от Borland приложил руку ;) (кстати, одним из 9ти отцов-основателей консорциума Eclipse - является Borland)
В списке отсутствует 'язык' для Б3-34, и всеми любимый Fortran ;). Кстати, в стандарте фортрана присутствует полная поддержка ООП (довелось в 2003м писать тесты, для покрытия кода компилятора intel...).
А-а-а, использовать под разработку на android? Да, проблематично. Давненько пробовал пару раз... Бросил. Да и разработка на C/C++ - не нативно и коряво там (не для этого его заточили). Не так 'гладко', как, скажем для Java. Хотя и для Java - строит в памяти AST всех открытых одновременно проектов, и если исходников море - может привести к деградации... А тормоза при первой загрузке IDE - удручают, особенно под Windows, который усугубляет проблему антивирусом (1й старт - 45сек., 2й старт - 5сек.).
В целом, Eclipse - это монстр (на 2018 год, в консорциуме - 465 млн. строк opensource кода различных проектов). Причины появления Eclipse - см. тут: https://vfedorov.info/GEFwiki/Wiki.jsp?page=GEF%20Preface%20%28GEF%29
anybody/123123
Всё верно. Однако, можно пойти дальше - создать 'свой язык'. Конечно, просто так, без причин - это абсурдно. Но, если есть требования, предпосылки, то порой продуктивней работать с кастомизированным, специфичным языком (DSL), чем создавать надстройки на языке 'общего назначения'. (язык может служить только лишь для описания данных, как CSS). Как сделать 'свой' DSL, см. https://vfedorov.info/XtextXtendWiki/
user: anybody
password: 123123
Технологически (есть инструменты, кодовая база), в "нише Eclipse", - можно создать графический DSL, или объединить и графическую нотацию и текстовую (и много другого). На эту тему есть тонны материала, дело за малым - решить вопрос внедрения в массы. (Eclipse - это не IDE)
Найдите соответствующие опции JVM, реально для интерпретации, и запустите ваш class ('байт-код') - можно будет очень-очень долго ждать (но это будет 'выполнение байт-кода').
В современных JVM давно по умолчанию JIT. И ещё не поленитесь реализовать 'прогрев' теста, там есть профайлер. Удачи...