LINUX.ORG.RU
ФорумTalks

[вещества] DE на Java

 


0

1

Как насчет того чтобы написать DE на Java? Текст далее крайне не рекомендуется читать людям со слабой психикой. Глубокое териотизирование.

Что останавливает? Это конечно же отсутствие Shared JVM. Каждая копия процесса java будет хранить код библиотеки классов. Отсюда толстота запущеных, например 50 приложений. Проверил только что. Оптимизаций никаких не произошло. Если бы такая вещь была бы реализована, то библиотека классов бы заняла может 20 МБ максимум, что даже меньше чем Gnome/KDE и после этого приложения были бы достаточно лековесными.

В принципе можно реализовать запуск остальных приложений в виде просто подгрузки из главного процесса DE необходимых классов с последующим вызовом main. Автоматически получаем Shared JVM, но нужно как-то ювелирно ограничивать классы, чтобы они не лезли к друг другу, не завершили весь DE и решить проблему синглетонов, статических переменных. Может кто-то знает как запустить классы внутри некоторой ограниченной области?

Зачем это все? Мощь фреймворков Java, вот одна причина. Даже самый большой фреймворк для C++ (и вообще нативного кода) - Qt, отдаленно не дотягивает до Java SE, не говоря уже о Hibernate, Spring. Можно еще вспомнить многочисленные проекты Apache, прекрасные фреймворки логирования, отличный SecurityManager Java (сразу фтопку SELinux/AppArmor), готовый прозрачный пакетный менеджер - Java Web Start. JWS позволил бы создать самый очевидный для обычных пользователей AppStore, запускаешь и устанавливаешь одновременно. Сюда еще можно добавить Preferences API и 100500 способ вызывать методы другого обьекта через сеть. Короче есть из чего выбрать. Еще есть интерестные вещи как OSGi, Eclipse RCP и т.д

Ко всему этому нужно добавить торт jvisualvm с возможностью полного дампа всех потоков, их состояний, их стектрейсов, состояний владения lock'ами, всех классов, всех экземпляров классов и связей между ними у любого процесса на лету, с возможностю подключения профилирования CPU и памяти у существующего и запущеного процесса.

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

Пока так, расплывчато, но в целом может быть. Вот такой вброс/не вброс. Модераторов прошу не удалять, все таки интересная теоретическая дискуссия

★★★★★

Последнее исправление: vertexua (всего исправлений: 1)

Ответ на: комментарий от Cancellor

Ну это же не то, дался им этот 3D

vertexua ★★★★★
() автор топика

А чего сразу всю ОС включая ядро на джаве не писать?

PS для изоляции классов есть classloader-ы как низкоуровневые сущности и OSGI как высокоуровневая концепция, советую ознакомиться.

Legioner ★★★★★
()

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

sol13 ★★★★★
()

Если и делать, то тогда уж надо писать shared vm, а не на нынешнем писать. Иначе будет либо костыли, либо толсто и приложения не смогут нормально общаться.

Однако смысла в этом опять же нет, потому как все существующие приложения должны жить в существующей vm.

Если сравнивать java с qt, то в qt во многом больше единообразия. На java тот же gui на разных тулкитах можно писать. А десктоп без единообразия не получится.

Ну и чисто субъективно: java уныла в своей реализации.

vkos ★★
()

Моошноо таааак стееелааать, тоооолькооо слиииишкооом быыыыстрооо раааботааать бууудееет. Да и бжжжж-бжжжж баанааальноостии мееешаааюуут.

Tark ★★
()

А видимо в майкрософте сплошные идиоты сидят, которые еще в те мохнатые времена, когда vista называлась longhorn, отказались от идеи написать все на .net и переписали к чертям все прототипы на unmanaged c++. А ведь .net обладает shared vm. И всеми плюсами жабы в придачу, кроме кроссплатформенности (которая в данном конкретном случае не особо роляет).

Nagwal ★★★★
()

>Как насчет того чтобы написать DE на Java?

А почему сразу не на Лиспе?

Nebuchadnezzar ★★★★
()
Ответ на: комментарий от anon1984

Льете воду на мельницу Oracle. Не по нашему, не по советски

Ошибаетесь, это цветы на могилу Sun. Оракакел мне не нравится. Не страшно, OpenJDK же

vertexua ★★★★★
() автор топика
Ответ на: комментарий от wfrr

Ну как вариант просто создать голое окно, и наваять нормально OpenGL тулкит. Делал, получалось, работало прекрасно, но все-же не гибко, под конкретное приложение. Не факт что получится так универсально как Swing/SWT

vertexua ★★★★★
() автор топика
Ответ на: комментарий от Nagwal

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

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vkos

Если сравнивать java с qt, то в qt во многом больше единообразия. На java тот же gui на разных тулкитах можно писать. А десктоп без единообразия не получится.

Ну лагеря то два.

IBM: Apache Foundation, Eclipse Foundation, SWT

Sun/Oracle: стандартный Java SE, Swing, NetBeans

Spring нейтрален.

Вот выбрать осталось

vertexua ★★★★★
() автор топика

Да, временами мне тоже приходит в голову такая идея. Но всё как-то не хватает решимости начать :)

drakmail ★★★★
()
Ответ на: комментарий от vkos

Ну и чисто субъективно: java уныла в своей реализации.

В силу моей работы пишу ОДИН И ТОТ ЖЕ КОД на Java и C++. Некоторый код нужно реализовать идентично, фактический ваяю тонкий фреймворк на разных языках, который еще и байндинг к другой системе. C++ бесконечно уныл в любом моменте и аспекте, это прекрасно видно, так как код почти одинаков

vertexua ★★★★★
() автор топика
Ответ на: комментарий от Legioner

Как решит проблему синглтонов сущестующего кода. Это же все должны переписать код под OSGi. И это спасает от получения экземпляра класса другого приложения путем прямого вызова Classloader и потом reflection?

vertexua ★★★★★
() автор топика

Если бы такое начали писать, какой набор библиотек/фреймворков вы бы порекомендовали в качестве первичных для этого DE? Понятное дело заставить никого нельзя, но озвучить что это например Swing, Spring, Java Web Start можно.

Я думаю что если бы Shared JVM запилили, то внедрение Spring на десктоп - это был бы гигантский шаг вперед

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Как решит проблему синглтонов сущестующего кода.

А в чём проблема?

Это же все должны переписать код под OSGi.

Кто то должен, кто то нет.

И это спасает от получения экземпляра класса другого приложения путем прямого вызова Classloader и потом reflection?

А как ты получишь ссылку на classloader другого прилоежния?

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

А как ты получишь ссылку на classloader другого прилоежния?

Есть примеры реализации такого? Чтобы один vm из которого запрещен, например выход и еще несколько убийственных операции. Ну и сразу несколько приложений с возможными несколько копий синглтонов, которые абсолютно не видят друг друга. Это интерестно, я бы пускай для себя такое написал, поэкспериментировать

vertexua ★★★★★
() автор топика
Ответ на: комментарий от Legioner

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

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Любой нормальный application server по идее полностью изолирует запущенные на нём приложения.

Legioner ★★★★★
()
Ответ на: комментарий от vertexua

Мне не нравится в нём почти всё :) Он тормозной, он включает в себя огромное количество самого разного, в чём я не вижу смысла. Он волокёт за собой огромную кучу нечитаемого XML-я.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

В третей версии очень много чего на аннотациях.

vertexua ★★★★★
() автор топика

Была уже Sun Java Desktop System. Вот только от жабы там ничего не было - у гнома логотип просто перебили на свой.

Quasar ★★★★★
()

Тред не читай - сразу отвечай.
Если единственная причина использования джавы - высокая скорость разрабодки в следствии высокого уровня абстракций, то лучше посмотреть другие аналоги по этому критерию:
Пайтон, Руби, Лисп, Хаскель, Скала etc.
Рекомендую первый язык из списка(если кто-то боится его отступов - бойтесь и дальше, вас уже не спасти), ибо есть реальные DE с хорошей производительностью и вообще не плохим результатом. Жаль что не допиливают, ибо не нужна ещё одна DE, их и так полно.

tia
()
Ответ на: комментарий от tia

Петон хорош для быстрой разработки, и для приложений, которые выполняют нересурсоёмкие задачи. DE я бы стал писать на петоне только в целях использования его как скриптового языка для аналога плазмы. Но не более того.

Quasar ★★★★★
()

Так была же вроде какая-то

/// а вот Squeak - уже давным давно сам себе как DE

yoghurt ★★★★★
()

А как аналог Shared JVM - OSGi не подойдёт? Тут и изоляция классов, и метод распространения пакетов, и управление зависимостями.

roy ★★★★★
()
Ответ на: комментарий от Quasar

>Петон хорош для быстрой разработки, и для приложений, которые выполняют нересурсоёмкие задачи.

Создатели сахарка смотрят на тебя как на… Ну в общем ты понял.

fat_angel ★★★★★
()
Ответ на: комментарий от tia

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

Нет, не это. Дело не в ЯП. Дело в платформе. Подавляющее большинство систем Gnome и KDE смешны по сравнению с тем, что уже есть на Java. Исключение составят разве что подсистемы мультимедия, кодеки, микшеры. И есть такие вещи, которые не реализованы или не реализуемы практически за счет неуправляемости кода и недоступности RTTI. А под Python не лежит такая мощь платформы и существующих фреймворков, как под Java

vertexua ★★★★★
() автор топика
Ответ на: комментарий от roy

Насколько я понимаю там нет изоляции статической памяти. Нельзя взять и сделать синглетон, а потом надеяться что несколько копий программы будут работать нормально. Или я неправильно понимаю OSGi? Еще в одной презентации по JSR-121 говорилось, что проблему нужно решать на уровне JVM и библиотеки классов, так как в бибилиотеке классов есть много моментов пересекающегося состояния даже в случае множественных класслоадеров. И оно System.exit будет запрещать?

vertexua ★★★★★
() автор топика

согласен, но

Единственный минус - посчитай сколько человеколет нужно чтобы написать эту DE и прикинь, сколько человек потребуется.


У нас в конторе по сути УЖЕ написали простенькую ОС на жаве и поддерживают ее. Но она _очень_ простенькая, а поддержка и расширение ее оказываются очень НЕпростенькими. Человек 20 только пишут код, а есть ведь еще и все остальные. Организаторам стоит это, уверяю, очень недешево, и живет только за счет корпораций которые эту хренотень используют для внутренних нужд.

stevejobs ★★★★☆
()

да был же вроде такой проект. гугли

быдлокод писать легче

вот поэтому и не нужно :)

annulen ★★★★★
()
Ответ на: согласен, но от stevejobs

ОС - на порядок сложнее продукт чем DE. DE - это все-таки какая никакая бизнес-логика, почти простой прикладной софт. А ОС на языке где нельзя без JNA сохранить три структуры в буфер подряд, это совсем другое дело

vertexua ★★★★★
() автор топика
Ответ на: комментарий от annulen

Имелось ввиду на плюсах легче писать чистейшее говно. Жабка хотя-бы в 30% случаев даст по пальцам

vertexua ★★★★★
() автор топика
Ответ на: комментарий от tia

>Рекомендую первый язык из списка(если кто-то боится его отступов - бойтесь и дальше, вас уже не спасти), ибо есть реальные DE с хорошей производительностью и вообще не плохим результатом. Жаль что не допиливают, ибо не нужна ещё одна DE, их и так полно.

ROX Desktop rocks!

annulen ★★★★★
()
Ответ на: комментарий от annulen

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

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua
public static void exit(int status)

Throws:
    SecurityException - if a security manager exists and its checkExit method doesn't allow exit with the specified status.
Legioner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.