xappymah

Возможно, вам стоит посмотреть на проект Excelsior JET.

Он позволяет статически скомпилировать Java-приложение из байткода в оптимизированный нативный (машинный) код.
Иными словами, на входе подаете свое Java-приложение, на выходе получаете бинарник, как если бы вы скомпилировали бы какой-нибудь сишный код.
При этом, для работы скомпилированного приложения уже не нужны class-файлы (за исключением некоторых случаев), таким образом декомпилировать уже нечего.
Конечно, бинарник можно дизассемблировать и понять логику каких-нибудь локальных кусков, но восстановить из этого исходный код - это непосильная задача.

Собственно, прямых ссылок не буду давать, чтобы совсем не наглеть, учитывая, что я один из инженеров, работающих над этим проектом :)
Вместо этого дам ссылку на доклад моего коллеги на JavaZone на тему JET'а и AOT-компиляции Java-приложений в целом:
https://vimeo.com/181905276

В целом, на мой взгляд, чтобы вникнуть в основы языка при наличии минимального опыта программирования, подходят все трое (Эккель, Хортсмэн, Шилдт).

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

docs.oracle.com/javase/tutorial/

И, конечно же, с определенного момента положить себе в закладки и Javadoc Java SE API:

docs.oracle.com/javase/7/docs/api/

Вы можете попробовать запустить Eclipse под каким-нибудь профилировщиком (например YourKit) — с его помощью вы сможете подробно увидеть, что именно потребляет память.

Кстати, насколько «много» памяти имеется в виду?
Возможно стоит просто отрегулировать параметры вашей JVM, чтобы ограничить размер потребляемой памяти и участить вызовы GC

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

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

Вообще говоря такое невозможно (подразумевается невозможность ввиду бесконечно огромной трудоемкости). Если быть более точным, то ваш вариант перекомпиляции сводится к полному анализу дизассемблированного кода и, получив точный алгоритм работы, переписыванию его на ассемблере под другую архитектуру (под другую комбинацию ОС-процессор).
По опыту скажу, что даже на высокоуровневых языках переписывание кода под другую архитектуру может оказаться затруднительным. А делать это на уровне ассемблерного кода — даже врагу не пожелаешь.

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

Сессии в любом случае нужно создавать снаружи и передавать объектам, чтобы не перегружать объекты тем функционалом (создание интернет-сессий), для которого они не предназначены.

Далее, в данном конкретном абстрактном случае логичнее использовать одну сессию. По крайней мере не вижу причин создавать вторую.

В качестве расширения своего предыдущего предложения — оптимизация для сужения множества поиска.

Откинем булевские атрибуты, считая их целочисленными для универсальности.
Имеем атрибуты A1, A2… An. Каждый из этих атрибутов имеет некоторый диапазон значений.
Для каждого атрибута разбиваем соответствующий диапазон на k_i кусков, каждый из которых обозначим через Ai_1, Ai_2...Ai_k_i.

Далее, имеем множество всех объектов ALL с упомянутыми атрибутами.
Возьмем атрибут A1 и разобьем множество ALL на непересекающиеся подмножества ALL_A1_j, где 1 <= j <= k_1, такие, что ALL_A1_j содержит объекты, у которых значение атрибута A1 находится в диапазоне A1_j.

Далее, с каждым этим подмножеством производится аналогичное разбиение по атрибуту A2. Потом каждое подмножество разбивается по значениям атрибута A3 и так далее до An.

Таким образом имеется дерево разбиения множества ALL по диапазонам значений всех атрибутов.

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

После этого делается обход по дереву разбиений в глубину: то есть, начиная от корня ALL идем в ALL_A1_k1, из которого в ALL_A1_k1_A2_k1 и так далее, пока не получим некоторое подмножество объектов, из которых линейным образом отбираются нужные, после этого возвращаемся на шаг назад и идем дальше.

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

Как один из вариантов оптимизации поиска: факторизация всех объектов по булевским аттрибутам. То есть объекты делятся на непересекающиеся группы с различными комбинациями булевских параметров.
Имеется массив с количеством элементов, равным количеству групп.
Каждая группа объединяется в список и за голову цепляется за соответствующий элемент массива.

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

Сами списки можно также факторизовать по какому-нибудь часто-используемому атрибуту (потребуется набор индексов, для нахождения соответствующих фактор-групп) или просто отсортировать.

Но все приведенное выше является не более чем оптимизацией поиска. В худшем случае все равно будет линейное время.

(кстати, а чем линейная сложность автора не устраивает?)

Насчет того, что нужно для разработки под андройд, сказать ничего не смогу, но вот для освежения знаний могу порекомендовать Oracle Java Tutorials: download.oracle.com/javase/tutorial/index.html

Дорога одна — в сервисный центр.
Помню у меня тоже однажды ноут начал перегреваться и ничто не помогало.
После смены системы охлаждения — вновь покой и порядок.

Пока никак — плагинов для фара для NRG файлов еще нет (по крайней мере хоть как-то популярных).
ИМХО, в частности это из-за того, что NRG формат является закрытым.

Если здесь A != 0, то тогда я лучше не буду изучать C# :)

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

Могу предложить Okular — KDEшный просмотрщик.
Достаточно простой, поддерживает закладки, нормально открывает как djvu, так и pdf

После размышления понял оптимальный способ умножения. Немного похоже на способ с логарифмами выше, но более точный (без плавающих запятых и прочего).

Сначала посчитать примерный суммарный порядок числа, который получится после умножения, складывая количество цифр в каждом числе после самой первой (для 1000 -> 3, для 32132 -> 4. В сумме — 7).

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

И так далее.
В худшем случае, конечно, получится полное перемножение, но это будет fallback :)

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