Здравствуйте, Ночной Смотрящий, Вы писали:

vsb>>У жавы очень ограниченный доступ к системному API. Ты или с жавой мало работал, или не договариваешь. Там на любой чих надо писать свою DLL-ку на JNI (на C/C++, ага). Банальный макосовский xattr (для доступа к extended file attributes) я в жаве не нашел, например.

НС>Серьезно?

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

vsb>>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно.

НС>sun.nio.ch.DirectBuffer.cleaner()?

Тогда уж sun.misc.Unsafe#invokeCleaner но этот способ в будущих ждк отрубят, и сейчас по-моему надо специальные флаги прописывать, чтобы оно работало. С "невозможно" написал некорректно, невозможно сделать "правильно", без хаков.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Кассандру в проде много кто использует, в том числе для удовлетворения требований к производительности. Более того, этот тезис был не о кассандре конкретно, а для вообще "СУБД на яве". Так что я до сих пор не понимаю какой именно тезис ты пытаешься отстоять.
НС>Я намекаю на то, что попытка этот тезис аргументировать сравнением с сиквелом, да еще и не с ним самим, а с его FTS — ну так себе.
Ну ок. Если я сравню elasticsearch c mssql fts, придирки останутся?

Здравствуйте, ·, Вы писали:

НС>>Я намекаю на то, что попытка этот тезис аргументировать сравнением с сиквелом, да еще и не с ним самим, а с его FTS — ну так себе.
·>Ну ок. Если я сравню elasticsearch c mssql fts, придирки останутся?

Останутся, но другие. Для первого это основной функционал, а для второго — сбоку припека. Хочешь сравнить эластик — сравни со сфинксом.

Здравствуйте, vsb, Вы писали:

НС>>Серьезно?
vsb>Я про стандартную библиотеку.

А это не стандартная? И в исходном сообщении ты ничего про стандартность не говорил. И звучит оно в таком раскладе уже совсем иначе — мало ли чего там в стандартной библиотеке нет.

vsb>>>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно.
НС>>sun.nio.ch.DirectBuffer.cleaner()?
vsb>Тогда уж sun.misc.Unsafe#invokeCleaner

Это хак через рефлекшен. А вот то что я привел — вполне себе публичный АПИ.

vsb> но этот способ в будущих ждк отрубят, и сейчас по-моему надо специальные флаги прописывать, чтобы оно работало. С "невозможно" написал некорректно, невозможно сделать "правильно", без хаков.

Ну так вроде тебе сказали почему. Хотя вот в дотнете сделать у MMF Dispose это не помешало.

Здравствуйте, vsb, Вы писали:

НС>>Серьезно?
vsb>Я про стандартную библиотеку. В которой, между прочим, есть нужные интерфейсы, но реализовать их никто не потрудился. Вот такой системный язык.
Оказывается потрудились. Уже доступно в 17-й версии.

Здравствуйте, Ночной Смотрящий, Вы писали:

vsb>> но этот способ в будущих ждк отрубят, и сейчас по-моему надо специальные флаги прописывать, чтобы оно работало. С "невозможно" написал некорректно, невозможно сделать "правильно", без хаков.
НС>Ну так вроде тебе сказали почему. Хотя вот в дотнете сделать у MMF Dispose это не помешало.
Потому что в дотнете оно unmanaged memory и гарантий безопасности как в яве нет.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, vsb, Вы писали:

НС>>>Серьезно?
vsb>>Я про стандартную библиотеку.

НС>А это не стандартная

JNA? нет, не стандартная.

vsb>>>>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно.
НС>>>sun.nio.ch.DirectBuffer.cleaner()?
vsb>>Тогда уж sun.misc.Unsafe#invokeCleaner

НС>Это хак через рефлекшен. А вот то что я привел — вполне себе публичный АПИ.

sun.* это внутренний API, а с включенными модулями вообще недоступен. Ну или напиши полный код, а то я тебя не очень понимаю пока. Вот пример моего кода:

        var path = Path.of("/Users/user/Downloads/ticket.pdf");
        var fileChannel = FileChannel.open(path);
        var mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_ONLY, 0, fileChannel.size());

        var b0 = mappedByteBuffer.get(0);
        System.out.println(b0);

        var theUnsafeField = Unsafe.class.getDeclaredField("theUnsafe");
        theUnsafeField.setAccessible(true);
        var unsafe = (Unsafe) theUnsafeField.get(null);
        
        unsafe.invokeCleaner(mappedByteBuffer);

        var b1 = mappedByteBuffer.get(1);
        System.out.println(b1);

vsb>> но этот способ в будущих ждк отрубят, и сейчас по-моему надо специальные флаги прописывать, чтобы оно работало. С "невозможно" написал некорректно, невозможно сделать "правильно", без хаков.

НС>Ну так вроде тебе сказали почему. Хотя вот в дотнете сделать у MMF Dispose это не помешало.

А я ответил, что это плохая реализаия, т.к. валит всю виртуальную машину при попытке обращения к отмапленной памяти. Разыменование null-а не валит, например.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Я намекаю на то, что попытка этот тезис аргументировать сравнением с сиквелом, да еще и не с ним самим, а с его FTS — ну так себе.
НС>·>Ну ок. Если я сравню elasticsearch c mssql fts, придирки останутся?
НС>Останутся, но другие. Для первого это основной функционал, а для второго — сбоку припека. Хочешь сравнить эластик — сравни со сфинксом.
Ну сравни, посмеёмся. Например, elasticsearch в проде используют на порядки больше, чем сфинкс. А если ещё Solr добавить, то сфинкс и в микроскоп не видно, типичный legacy.

Господи, они фильтруют атрибуты и возвращают только те, которые начинаются на "user."

            List<String> attrNames = list(fd, MIN_LISTXATTR_BUF_SIZE);
            return attrNames.stream()
                    .filter(s -> s.startsWith(USER_NAMESPACE))
                    .map(s -> s.substring(USER_NAMESPACE.length()))
                    .toList();

Системный язык, блин.

Здравствуйте, vsb, Вы писали:

vsb>Господи, они фильтруют атрибуты и возвращают только те, которые начинаются на "user."
Ну так user-defined атрибуты

Здравствуйте, ·, Вы писали:

НС>>Ну так вроде тебе сказали почему. Хотя вот в дотнете сделать у MMF Dispose это не помешало.
·>Потому что в дотнете оно unmanaged memory и гарантий безопасности как в яве нет.

Оно и в яве unmanaged. В дотнете, по крайней мере, Memory<T> есть, а в джаве только JNI.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Потому что в дотнете оно unmanaged memory и гарантий безопасности как в яве нет.
НС>Оно и в яве unmanaged.
Это неверно.

НС>В дотнете, по крайней мере, Memory<T> есть, а в джаве только JNI.
Тоже пилят: https://docs.oracle.com/en/java/javase/17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/MemorySegment.html

Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, ·, Вы писали:

S>·>Cassandra, Kafka, h2database, куча их.

S>Хеллоуворлдных СУБД всяких прикола ради даже на бейсике полно написано. Только вот в проде никто не юзает, если есть требования к производительности.

требования к производительности
http://h2database.com/html/performance.html
Честно, ни в одном языке(кроме си ) не видел такого количеств СУБД на самом ЯП.
Пользовал h2 и derby, проблем никогда не было,
в отличии от ms sql который любит базу помечать как испорченную и не вывозит, если оперативы меньше чем сама база.
Так что не знаю, не пробовал не значит что ничего нет.

Здравствуйте, ·, Вы писали:

НС>>·>Потому что в дотнете оно unmanaged memory и гарантий безопасности как в яве нет.
НС>>Оно и в яве unmanaged.
·>Это неверно.

Верно.

НС>>В дотнете, по крайней мере, Memory<T> есть, а в джаве только JNI.
·>Тоже пилят: https://docs.oracle.com/en/java/javase/17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/MemorySegment.html

Ну пусть пилят. В дотнете то давно напилено.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Это неверно.
НС>Верно.
С чего ты взял? Обращения к MappedByteBuffer в java — безопасны.

НС>>>В дотнете, по крайней мере, Memory<T> есть, а в джаве только JNI.
НС>·>Тоже пилят: https://docs.oracle.com/en/java/javase/17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/MemorySegment.html
НС>Ну пусть пилят. В дотнете то давно напилено.
Это стандартный API, а так direct buffers там доступны давным давно.

Здравствуйте, ·, Вы писали:

НС>>·>Это неверно.
НС>>Верно.
·>С чего ты взял? Обращения к MappedByteBuffer в java — безопасны.

Это не managed pool, это unsafe кусок памяти.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Верно.
НС>·>С чего ты взял? Обращения к MappedByteBuffer в java — безопасны.
НС>Это не managed pool, это unsafe кусок памяти.
С т.з. публичного API — обращение к нему безопасно. А как оно там устроено вунутре — детали имплементации. В шарпе ошибки с Unmanaged memory роняют всё непредсказуемо.

Здравствуйте, ·, Вы писали:

·>С т.з. публичного API — обращение к нему безопасно. А как оно там устроено вунутре — детали имплементации. В шарпе ошибки с Unmanaged memory роняют всё непредсказуемо.

Ничего там непредсказуемо при работе с MMF не роняется, не переживай. Точно так же все завернуто в safe обертку.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>С т.з. публичного API — обращение к нему безопасно. А как оно там устроено вунутре — детали имплементации. В шарпе ошибки с Unmanaged memory роняют всё непредсказуемо.
НС>Ничего там непредсказуемо при работе с MMF не роняется, не переживай. Точно так же все завернуто в safe обертку.
Вот эта переменная не volatile. Значит thread может писать в закрытый другим тредом аксессор до порчи хз какого адреса памяти. Чудес не бывает.
Понимаю, индусне в микрсофте плевать на такие мелочи, но java заботится о безопасности.

Здравствуйте, scf, Вы писали:

scf>Что касается сокетов — много ли в плюсах кросплатформенных, быстрых, асинхронных сетевых библиотек, поддерживающих HTTP(S) полноценно, со всеми плюшками? И которыми можно пользоваться без содрогания.

В кути вобще не задумывался об этом