Java: как написать быструю программу?

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

емнип rambler

> Прикольная идея... Надо её подумать и попробовать в task order пропихнуть...

Результат подумывания отпиши пожалуста на ЛОРе в development.

>Как жавовский менеджер памяти справится с большим количеством массивов размером в десятки-сотни мегов?

Тысячи их? В десятки-сотни мегов? Это десятки-сотни гигабайт оперы. У тебя столько есть?

>> Прикольная идея... Надо её подумать и попробовать в task order пропихнуть...

>Результат подумывания отпиши пожалуста на ЛОРе в development.

А оно разве реализовано иначе? По моему в линуксе при вызове malloc() мапится кусок на вершине кучи, а после вызова free() все 4 Кб страницы покрывающие кусок освобожденной памяти просто размапливаются. При этом результат malloc() всегда растет.

> Результат подумывания отпиши пожалуста на ЛОРе в development.

Я её даже попробую! Почему-то мне кажется, что наши классы позволяют это легко реализовать, так как почти все большие new делаются через одно место. :-) Я туда просто 10^12 прибью гвоздями и всё! Начальник из отпуска вернётся, а у меня матрицы из sparse в dense превратились! :-)

> Тысячи их? В десятки-сотни мегов? Это десятки-сотни гигабайт оперы. У тебя столько есть?

Не тысячи. Несколько десятков. Просто если памяти много, то и массивы пропорционально вырастут, но их количество сильно не изменится, скорее всего.

>Каким-то образом инфа из сессии попадает в общий для всех сессий объект. Например, была дырка в какой-то веб-почте, когда в какое-то поле по умолчанию проставлялся емейл другого чувака (из прошлой сессии).

Ну это уже следствие того что все сессии работают с одной БД. Тут помог бы Fine-Grained Access Control когда каждый юзер работает с своим срезом данных, но так делать какую-то долбаную вебпочту никто не будет.

> А оно разве реализовано иначе?

Я имел в виду версию std::vector без переаллокации, чтобы указатели не инвалидировать. Причем иметь много (например, тысячи) таких растущих векторов.

> Ну это уже следствие того что все сессии работают с одной БД. Тут помог бы Fine-Grained Access Control когда каждый юзер работает с своим срезом данных, но так делать какую-то долбаную вебпочту никто не будет.

И тут мы вспоминаем, что TaintedString(user_id, "asdf") для практики вполне бы хватило...

>> Результат подумывания отпиши пожалуста на ЛОРе в development.

>Я её даже попробую!

Попробовал. Во время работы прога делала 17 раз new double[1e+11] и 20 раз new int [1e+11]. top показывал в поле VIRT вопросик, а в поле RES 60m в максимуме. Прога выдаёт правильный результат. Правда, что-то она много векторов выделяет, надо будет подебажить...

http://jscience.org/api/org/jscience/mathematics/structure/VectorSpace.html не? Не то?

По-настоящему разреженные матрицы у тебя хранить так не получится. Только если там заполненные места хорошо группируются в страницы по 4К.

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

Мои по-настоящему разреженные матрицы хранятся тоже по-настоящему. Просто я сделал так, что память под них теперь запрашивается огромными кусками, которые.

У нас используется приближённое LU разложение и вот тут и начинается основная логика с переаллокациями, так как заранее не известно, скока будет ненулей в результирущих в L и U. А с большими new переаллокаций нету, быстрее работает.

> Во время работы прога делала 17 раз new double[1e+11] и 20 раз new int [1e+11].

Достаточно прикольно выделить 17 раз по 800 ГБ :-) интерсно, ява на х86_64 так умеет?

>При наличии же такового каждый класс автоматически становится интерфейсом

Ненене. Чем меня бесит с++, что он умеет почти всё, и почти всё плохо. Интерфейсы и классы - это разные вещи, и смешивать их не надо. Множественно наследование классов и множественное наследование интерфейсов понятия почти ортогональные.

>> Ну это уже следствие того что все сессии работают с одной БД. Тут помог бы Fine-Grained Access Control когда каждый юзер работает с своим срезом данных, но так делать какую-то долбаную вебпочту никто не будет.

>И тут мы вспоминаем, что TaintedString(user_id, "asdf") для практики вполне бы хватило...

Единственный более-менее надежный способ ограничить доступ к каким-либо данным это использовать пермишены, так чтобы у левой аудитории они просто не читались. Остальное - костыль по эффективности сравнимый с перехватом DOS-прерывания для скрытия директорий C:\MSDOS, C:\AUTOEXEC.BAT, C:\CONFIG.SYS & С:\DOOM.

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

ОК, тогда замени TaintedString на StringWithPermissions

> Чем меня бесит с++, что он умеет почти всё, и почти всё плохо.

Согласен. Ява же не умеет почти ничего, и что умеет -- умеет так себе.

> Интерфейсы и классы - это разные вещи, и смешивать их не надо. Множественно наследование классов и множественное наследование интерфейсов понятия почти ортогональные.

Ну расскажи, в чем разница.

> StringWithPermissions

Кстати, это было бы вполне реально, если бы от String можно было сделать потомок String<OfThisUser>, причем фактически после стирания типов финальность String не нарушилась бы. Т.е. JVM это позволяет. Интересно, позволяет ли ява.

>Ну расскажи, в чем разница.

Между классами и интерфейсами? Ну вроде как все знают... Между наследованиями - тоже буду не более чем К.О.

>Ява же не умеет почти ничего, и что умеет -- умеет так себе.

Не, то что умеет она умеет очень неплохо. И то что она имеет служит в ней по назначению. Единственное, за что её можно немного поругать в этом смысле - это нерантаймовые дженерики, но иначе было действительно никак.

>Согласен. Ява же не умеет почти ничего, и что умеет -- умеет так себе.

Ну, напиши SweetHome 3D на C/C++ с загрузкой по сети и работой как обычное приложение с той же скоростью и теми же удобствами GUI на всех системах без перекомпиляции.

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

>ОК, тогда замени TaintedString на StringWithPermissions

Недоступность данных пользователя A для пользователя B должна гарантироваться архитектурой. Костылесипеды надо отбрасывать сразу - все равно это работать не будет.

> Между классами и интерфейсами? Ну вроде как все знают... Между наследованиями - тоже буду не более чем К.О

Вопрос был об этом:

> Множественно наследование классов и множественное наследование интерфейсов понятия почти ортогональные.

Хочется подробнее услышать об ортогональности... и да, можно и от К.О.

Я же продолжаю утверждать, что никакой ортогональности нет.

> Недоступность данных пользователя A для пользователя B должна гарантироваться архитектурой. Костылесипеды надо отбрасывать сразу - все равно это работать не будет.

Не ясно, почему один код (вероятно, Написанный Гениальными Программистами Санок) назван архитектурой, а другой -- StringWithPremission<ThisUser> -- костылисипедами.

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

> на всех системах без перекомпиляции.

C JIT-перекомпиляцией при каждом запуске. // FIXED

>C JIT-перекомпиляцией при каждом запуске. // FIXED

C JIT-перекомпиляцией при каждом запуске только того байткода, который реально востребован. //FIXED-2

>> Недоступность данных пользователя A для пользователя B должна гарантироваться архитектурой. Костылесипеды надо отбрасывать сразу - все равно это работать не будет.

>Не ясно, почему один код (вероятно, Написанный Гениальными Программистами Санок) назван архитектурой

Под архитектурой я понимаю сторадж. Например, на ОС Linux если пользователь B попытается открыть файл пользователя A то он получит Permission Denied. Но произойдет это потому что сисколл вернул ошибку а не потому что все программы проверяют владельцев тех файлов которые они открывают и не дают открывать чужие.

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

Подход "на каждого юзера сайта - по mysql юзеру" интересен. Но есть другой вариант подхода -- с помощью системы типов компилятора фактически доказывается, что данные пользователя не утекают на сторону. Для чего и надо сделать class StringWithPermission<User> extends String.

Даже если пользователь В не имеет доступа к закрытым данным пользователя А, то наша, неверно написанная программа может скопировать закрытые данные пользователя А в открытые. И права мускуля тебе здесь не помогут. StringWithPermission может помочь, породя ошибку типизации.

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

>Подход "на каждого юзера сайта - по mysql юзеру" интересен.

В mysql Fine-Grained Access Control'а нету.

>Но есть другой вариант подхода -- с помощью системы типов компилятора фактически доказывается, что данные пользователя не утекают на сторону. Для чего и надо сделать class StringWithPermission<User> extends String.

Все равно при передаче во внешний фреймворк будет происходить срезка и все доп. барахло сверху пропадет. Смысла никакого нет.

> В mysql Fine-Grained Access Control'а нету.

Даже если пользователь В не имеет доступа к закрытым данным пользователя А, то наша, неверно написанная программа может скопировать закрытые данные пользователя А в открытые. И права мускуля тебе здесь не помогут.

> Все равно при передаче во внешний фреймворк будет происходить срезка и все доп. барахло сверху пропадет. Смысла никакого нет.

Возможно что не всегда так все плохо (например если внешний фреймворк функционален), но в целом да -- яву могила исправит. В языке, где было бы можно String-у задать виртуальный оператор +, этот оператор у StringWithPermission мог бы вычислять пересечение прав. Т.е. сложение двух приватных данных одного пользователя допускать, сложение приватного+общедоступного делать приватным, сложение двух общедоступных строк разных пользователей делать общедоступным, а сложение двух приватных разных пользователей делать недоступным или кидать исключение.

> В mysql Fine-Grained Access Control'а нету.

Там нету понятия sensitive data!

Например, емейл юзера в веб-почте -- это приватно? Раз он уходит как обратный адрес письма -- значит не приватно. А раз не приватно, то он может показываться любому пользователю... вот и приходим к тому самому багу.

>> В mysql Fine-Grained Access Control'а нету.

>Даже если пользователь В не имеет доступа к закрытым данным пользователя А, то наша, неверно написанная программа может скопировать закрытые данные пользователя А в открытые. И права мускуля тебе здесь не помогут.

1. Пишешь свой реалм для сервлет-контейнера 2. В сервлете ничего не знаешь про текущего пользователя вообще. Он приходит уже готовый, из реалма. И в БД чужих данных тоже нет, они отфильтрованы FGAC. 3. ????? 4. PROFIT

>Например, емейл юзера в веб-почте -- это приватно? Раз он уходит как обратный адрес письма -- значит не приватно. А раз не приватно, то он может показываться любому пользователю... вот и приходим к тому самому багу.

Ты не понимаешь суть FGAC. Там каждый пользователь работает со своим срезом данных в БД. Пользователь A не может получить данные пользователя B никаким селектом.

> Ты не понимаешь суть FGAC. Там каждый пользователь работает со своим срезом данных в БД. Пользователь A не может получить данные пользователя B никаким селектом.

Ты в -надцатый раз рассказываешь то, что я знаю, и уклоняешься от основного вопроса. Что мешает неправильно написанной программе на яве при подаче хитро подготовленных данных грубо говоря прочитать хэш пароля юзера и приписать его к какому-то (общедоступному на чтение) полю БД, например хранящему текст поста? Класс StringWithPermission помешал бы, но он невозможен.

>Что мешает неправильно написанной программе на яве при подаче хитро подготовленных данных грубо говоря прочитать хэш пароля юзера и приписать его к какому-то (общедоступному на чтение) полю БД, например хранящему текст поста?

То что хэша пароля там не будет. Нигде. Авторизация произвидится реалмом извне, и программа к процедуре авторизации не имеет никакого отношения. Она вообще ничего не знает про пароли.

>Класс StringWithPermission помешал бы, но он невозможен.

Помешал бы как растянутая папиросная бумага летащему лому.

> Лучше его вычислять однако через что-то типа DBMS_SQL передав хранимой процедуре список колонок и опции.

Чем лучше?

>Множественно наследование классов и множественное наследование интерфейсов понятия почти ортогональные.

А собственно что тут объяснять? _Реализация_ вообще не одно и тоже что наследование - это разные вещи, мы ничего не наследуем от родителя - мы только реализуем некоторое API. В джаве есть _реализация_ многих интерфейсов, которая проста и понятна. Теоретически, можно добавить и множественное _наследование_, и сильно усложнить (достаточно вспомнить виртуальное наследование в С++). А можно оставить только множественное наследование, но убрать множественную реализацию (что будет выглядить очень странно). То есть одно без другого существует, просто возможно выглядит глупо. По-этому я и говори "почти" ортогональные.

Тогда я повторю, то, с чего все началось -- вместо идеи "на каждый класс по интерфейсу" предлагается подход "каждый класс одновременно и интерфейс". Чем этот подход плох (при наличии множественного наследования)?

З.Ы. "Сложно" само по себе не аргумент.

> Помешал бы как растянутая папиросная бумага летащему лому.

Ты еще поэзию тут напиши.

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

>> Лучше его вычислять однако через что-то типа DBMS_SQL передав хранимой процедуре список колонок и опции.

> Чем лучше?

Тут возможен еще один вариант -- в отдельном сгенеренном boilerplate файле иметь все 2000 вариантов запросов, и мне он нравится. В частности, будет гарантия, что все эти варианты синтаксически корректны, БД может запросы скомпилировать и не парсить каждый раз, какая-то тулза для аудита может их аудитить и т.д.

> Тут возможен еще один вариант -- в отдельном сгенеренном boilerplate файле иметь все 2000 вариантов запросов,

Спасибо, но у меня есть анализировалка со сводной таблицей эдак на 30 колонок (если group by по всем или не по чему), это сколько вариантов получится? Полный перебор возможных сосотяний тут выглядит избыточным.

> В частности, будет гарантия, что все эти варианты синтаксически корректны

Написать генератор, генерящий синтаксически корректные запросы, вполне реально.

> Спасибо, но у меня есть анализировалка со сводной таблицей эдак на 30 колонок (если group by по всем или не по чему), это сколько вариантов получится?

1Г

> Написать генератор, генерящий синтаксически корректные запросы, вполне реально.

Написать. А потом из этих 30 колонок одна переименуется...

>предлагается подход "каждый класс одновременно и интерфейс".

Если в этом классе будет реализация - это _плохо_. Потому что зачастую моя реализация не имеет _ничего_ общего с их, и это хорошо, что мне ничего не навязывается. Если делать классы, где все методы чисто абстрактны - непонятно зачем выкидывать интерфейсы.

То что я реализую несколько интерфейсов - естественно. А вот то, что я наследую внутреннюю структуру нескольких классов может быть сложным (как в С++), да и нужно значииительно реже.

> 1Г

Спасибо, не надо. > Написать. А потом из этих 30 колонок одна переименуется...

Если в системе метаданных о базе при этом не изменяться -- то дело не в генерации скл...

>Подскажите, пожалуйста, книгу, в которой написано, как писать быстрые программы на Java.

Все книги, которые нужно прочитать, чтобы писать быстрые програмы на Java, собраны здесь http://thepiratebay.org/torrent/4750277