Сообщение Re[4]: Причины популярности java от 20.05.2022 12:58
Изменено 20.05.2022 13:02 vsb
Re[4]: Причины популярности java
Здравствуйте, scf, Вы писали:
vsb>>Ещё есть забавный прикол
scf>Это всё сделано не просто так. Java по дизайну кросплатформенна, поэтому странно от неё ожидать поддержки специфичных для платформы вещей. DLL в 21 веке никто не пишет, они либо написаны до нас, либо JNA позволяет вызвать нативный метод из длл без возни с плюсами.
Да я не спорю, просто я не считаю, что жаву можно называть системным софтом. Системный софт, по крайней мере в моём понимании, это софт, который работает с системой. С конкретной системой. И это как бы антитезисно самому понятию кроссплатформенности. Как можно написать кроссплатформенный докер? Ничего общего в контейнерном API между линуксом и виндой нет, а в макоси понятия контейнеров даже нет. Системный софт можно писать либо на C, либо на языке, из которого очень легко вызывать код на С, например C++. И, да, я в курсе, что докер на го написан, и считаю это ошибкой.
scf>MappedByteBuffer невозможно закрыть из клиентского кода, т.к. тогда память, на который он ссылается, будет деаллоцирована и другие потоки, работающие с этой памятью, могут крашнуть jvm.
Это отмазки. Разыменование нулевой ссылки не крашит jvm, могли бы и тут что-нибудь придумать. А если не смогли — значит и нефиг делать кривой API. Кому надо — пусть через JNI пользуют, на свой страх и риск. В принципе по ссылке выше уже всё написано — делайте unmap и помечайте память специальным образом, кто в неё будет обращаться, тот получит sigsegv, а дальше уже обработчик сигнала преобразует это в JVM exception. 2 файла на одну память мапить не нужно, у нас 64 бита, виртуальных адресов хватит для всего. Ну а GC пусть уже при сборке снимает эту метку памяти.
scf>Что касается сокетов — много ли в плюсах кросплатформенных, быстрых, асинхронных сетевых библиотек, поддерживающих HTTP(S) полноценно, со всеми плюшками? И которыми можно пользоваться без содрогания.
Я по жаве больше, какие там в плюсах библиотеки, я не знаю. Я бы посмотрел в сторону nginx и apache httpd, есть ли там какая-то выделенная сетевая часть, которую можно вытащить и заюзать как библиотеку. По-моему в апаче есть. Но может есть и более удачная библиотека. Это для сервера, для клиента точно знаю, что libcurl хорош.
vsb>>Ещё есть забавный прикол
scf>Это всё сделано не просто так. Java по дизайну кросплатформенна, поэтому странно от неё ожидать поддержки специфичных для платформы вещей. DLL в 21 веке никто не пишет, они либо написаны до нас, либо JNA позволяет вызвать нативный метод из длл без возни с плюсами.
Да я не спорю, просто я не считаю, что жаву можно называть системным софтом. Системный софт, по крайней мере в моём понимании, это софт, который работает с системой. С конкретной системой. И это как бы антитезисно самому понятию кроссплатформенности. Как можно написать кроссплатформенный докер? Ничего общего в контейнерном API между линуксом и виндой нет, а в макоси понятия контейнеров даже нет. Системный софт можно писать либо на C, либо на языке, из которого очень легко вызывать код на С, например C++. И, да, я в курсе, что докер на го написан, и считаю это ошибкой.
scf>MappedByteBuffer невозможно закрыть из клиентского кода, т.к. тогда память, на который он ссылается, будет деаллоцирована и другие потоки, работающие с этой памятью, могут крашнуть jvm.
Это отмазки. Разыменование нулевой ссылки не крашит jvm, могли бы и тут что-нибудь придумать. А если не смогли — значит и нефиг делать кривой API. Кому надо — пусть через JNI пользуют, на свой страх и риск. В принципе по ссылке выше уже всё написано — делайте unmap и помечайте память специальным образом, кто в неё будет обращаться, тот получит sigsegv, а дальше уже обработчик сигнала преобразует это в JVM exception. 2 файла на одну память мапить не нужно, у нас 64 бита, виртуальных адресов хватит для всего. Ну а GC пусть уже при сборке снимает эту метку памяти.
scf>Что касается сокетов — много ли в плюсах кросплатформенных, быстрых, асинхронных сетевых библиотек, поддерживающих HTTP(S) полноценно, со всеми плюшками? И которыми можно пользоваться без содрогания.
Я по жаве больше, какие там в плюсах библиотеки, я не знаю. Я бы посмотрел в сторону nginx и apache httpd, есть ли там какая-то выделенная сетевая часть, которую можно вытащить и заюзать как библиотеку. По-моему в апаче есть. Но может есть и более удачная библиотека. Это для сервера, для клиента точно знаю, что libcurl хорош.
Re[4]: Причины популярности java
Здравствуйте, scf, Вы писали:
vsb>>Ещё есть забавный прикол
scf>Это всё сделано не просто так. Java по дизайну кросплатформенна, поэтому странно от неё ожидать поддержки специфичных для платформы вещей. DLL в 21 веке никто не пишет, они либо написаны до нас, либо JNA позволяет вызвать нативный метод из длл без возни с плюсами.
Да я не спорю, просто я не считаю, что жаву можно называть системным софтом. Системный софт, по крайней мере в моём понимании, это софт, который работает с системой. С конкретной системой. И это как бы антитезисно самому понятию кроссплатформенности. Как можно написать кроссплатформенный докер? Ничего общего в контейнерном API между линуксом и виндой нет, а в макоси понятия контейнеров даже нет. Системный софт можно писать либо на C, либо на языке, из которого очень легко вызывать код на С, например C++. И, да, я в курсе, что докер на го написан, и считаю это ошибкой.
scf>MappedByteBuffer невозможно закрыть из клиентского кода, т.к. тогда память, на который он ссылается, будет деаллоцирована и другие потоки, работающие с этой памятью, могут крашнуть jvm.
Это отмазки. Разыменование нулевой ссылки не крашит jvm, могли бы и тут что-нибудь придумать. А если не смогли — значит и нефиг делать кривой API. Кому надо — пусть через JNI пользуют, на свой страх и риск. В принципе по ссылке выше уже всё написано — делайте unmap и помечайте память специальным образом, кто в неё будет обращаться, тот получит sigsegv, а дальше уже обработчик сигнала преобразует это в JVM exception. 2 файла на одну память мапить не нужно, у нас 64 бита, виртуальных адресов хватит для всего. Ну а GC пусть уже при сборке снимает эту метку памяти. Может эта отмазка была актуальна, когда 32-битные системы использовали, современную жаву оракл под 32 бита по-моему даже не пытается собирать.
scf>Что касается сокетов — много ли в плюсах кросплатформенных, быстрых, асинхронных сетевых библиотек, поддерживающих HTTP(S) полноценно, со всеми плюшками? И которыми можно пользоваться без содрогания.
Я по жаве больше, какие там в плюсах библиотеки, я не знаю. Я бы посмотрел в сторону nginx и apache httpd, есть ли там какая-то выделенная сетевая часть, которую можно вытащить и заюзать как библиотеку. По-моему в апаче есть. Но может есть и более удачная библиотека. Это для сервера, для клиента точно знаю, что libcurl хорош.
vsb>>Ещё есть забавный прикол
scf>Это всё сделано не просто так. Java по дизайну кросплатформенна, поэтому странно от неё ожидать поддержки специфичных для платформы вещей. DLL в 21 веке никто не пишет, они либо написаны до нас, либо JNA позволяет вызвать нативный метод из длл без возни с плюсами.
Да я не спорю, просто я не считаю, что жаву можно называть системным софтом. Системный софт, по крайней мере в моём понимании, это софт, который работает с системой. С конкретной системой. И это как бы антитезисно самому понятию кроссплатформенности. Как можно написать кроссплатформенный докер? Ничего общего в контейнерном API между линуксом и виндой нет, а в макоси понятия контейнеров даже нет. Системный софт можно писать либо на C, либо на языке, из которого очень легко вызывать код на С, например C++. И, да, я в курсе, что докер на го написан, и считаю это ошибкой.
scf>MappedByteBuffer невозможно закрыть из клиентского кода, т.к. тогда память, на который он ссылается, будет деаллоцирована и другие потоки, работающие с этой памятью, могут крашнуть jvm.
Это отмазки. Разыменование нулевой ссылки не крашит jvm, могли бы и тут что-нибудь придумать. А если не смогли — значит и нефиг делать кривой API. Кому надо — пусть через JNI пользуют, на свой страх и риск. В принципе по ссылке выше уже всё написано — делайте unmap и помечайте память специальным образом, кто в неё будет обращаться, тот получит sigsegv, а дальше уже обработчик сигнала преобразует это в JVM exception. 2 файла на одну память мапить не нужно, у нас 64 бита, виртуальных адресов хватит для всего. Ну а GC пусть уже при сборке снимает эту метку памяти. Может эта отмазка была актуальна, когда 32-битные системы использовали, современную жаву оракл под 32 бита по-моему даже не пытается собирать.
scf>Что касается сокетов — много ли в плюсах кросплатформенных, быстрых, асинхронных сетевых библиотек, поддерживающих HTTP(S) полноценно, со всеми плюшками? И которыми можно пользоваться без содрогания.
Я по жаве больше, какие там в плюсах библиотеки, я не знаю. Я бы посмотрел в сторону nginx и apache httpd, есть ли там какая-то выделенная сетевая часть, которую можно вытащить и заюзать как библиотеку. По-моему в апаче есть. Но может есть и более удачная библиотека. Это для сервера, для клиента точно знаю, что libcurl хорош.