Вобщем для расчета значение математического выражения - его надо вычислить. Никакие брутфорсы скорее всего не помогут. Выражение может потребовать расчетов функций. И их надо провести. Как - это уже другой вопрос но ясно что не в строках.
rar имеет консольный тул. Его можно вызвать как то так $ rar -l <namefile>
И проанализировать листинг. Там скорее всего напротив каждого шифрованного файла будет какая-то пометка или символ.
Автору - неприлично спрашивать такой вопрос совсем не подготовившись.
Linux быстрее создает процессы (fork()). Это особенно видно при работе с консольными тулзами. И с теми-же тулзами которые портированы под Windows к примеру. Это одна причина. И вторая - это файловая система. Linux/Ext4 обычно менее затратная в обслуживании огромного количества мелких операций чем Windows/NTFS. Например проверка атрибутов безопасности в Linux - это проверка битовой маски. В Windows - чуть больше действий.
Ко всему конечно могут быть и другие различия в имплементации java под Windows которых я не знаю.
В топике нет проблемы как таковой. Проверки можно делать по разному. Но главной метрикой скорее всего будет - компактность кода и скорость внесения в него изменений. Из best practices. Заводите вспомогательный класс. Helper. И делаете 20+ методов.
В книге Холдена Карау - "Изучаем Spark" - глава 9 Spark SQL этому вопросу уделелено 1-2 странички. Можно почитать.
Кешировать "каким-то образом" можно "всё что угодно". Redis и прочие коробочные решения для кешей - работают
но они к технологии Spark не имеют никакого отношения. Собственно их можно советовать как универсальный
совет для любых систем которые имеют back-end. Интеграция их же со спарком это вообще отдельный вопрос.
С помощью Java Security Manager можно избирательно перекрыть приложению возможность прослушивать порты листенера, или создавать самому соединения. Но этот менеджер не различает ендпоинт и базу. Ему нужны цифры вида host:port или их комбинации и рулы разрешений на соотв действия.
Вопрос непонятен. Если CriteriaApi может получить stream произвольных объектов (UserEntity) то
к стриму всегда можно применить метод map и взять только нужый стрим полей.
C++ сегодня очень сложен как язык. Порог вхождения высок и новички часто обламывают об него зубы доходя лишь до арифметики указателей. Там - половина ньюкамеров можно выносить ногами вперед. Скорость разработки прикладного ПО под backend на Java значительно выше. Да и облачные технологии такие как Google Clound , Amazon AWS поддерживают все языки кроме С++. Вобщем если автор хочет быстрых денег - то лучше Java.
В С++ надо вырасти до седых волос чтобы представлять что-то серъезное потому-что стек С++ плотно уходит в операционную систему и железо. Невозможно знать просто С++. Надо быть немного сисадмином и железячником. Иначе в С++ делать нечего.
Не очень понятен смысл этого доклада. Вроде как it-археология еще не появилась как наука.
Java Appletts, ActiveX, Macromedia/Adobe Flash - это всё технологии которые умерли и браузеры их не поддерживают. В этом будет основная проблема при написании доклада. Некуда смотреть во время demo. Документация по ним скорее всего есть в архивах oracle.com (sun.com) надо просто искать мануалы от 90х 2000х годов на сайте производителя. Думаю что можно найти очень много старых электронных pdf книжек на эту тему.
В отличие SQL, Lisp и прочих технологий где null/nil имеет смысловую семантику и позволяет выполнять операции в Java любая попытка применить любой метод к null выбрасывает немедленный NPE. Это означает что программист ЗАБЫЛ инициалировать объект. Это грубая ошибка и самое печальное что она не чекается компиллятором. Использование Optional в стримах необходимо чтобы защитить применение map/filter от внезапного NPE.
Пример который привел автор в начале топика просто неудачен. Он не раскрывает преимуществ Optional. Смотрите статью на сайте Баелдунга. Она - более наглядная.
Выделяется память в eden space по принципу стека. Поэтому сама аллокация происходит быстро. Когда eden переполняется - запускается процедура уборки и уплотнения GC. Физические адреса объектов при этом могут изменятся. После нескольких фаз уборки выжившие объекты перемещаются в PermGen/Metaspace как постоянные. Так примерно работает lifecycle для классического gc. В новых - не знаю. Могут быть нюансы.
Данная задача не решается в рамках CrudRepository.
Архитектурно. Для крупных систем если кто-то хочет искать произвольный текст (fuzzy text search) по вводимому выражению наподобие гугло-поиска специально подключается Apache Lucene или ELK stack. В него реплицируется искомая табличка и далее уже по этой реплике выполняются все текстовые сёрчи.
Все что вы сейчас наделаете в рамках классической реляционной алгебры будет работать медленно и плохо ибо реляционная алгебра не создавалась вообще для подобных нечетких поисков.
Если писать под Windows то наверное лучше брать .Net - фреймворки. Они более нативные и как следствие
имеют богаче возможности конкретно под Винду.
Java сегмент разработки UI не захватила. Я сужу по количеству вакансий. И сегодня нужно быть очень смелым и дерзким чтобы что-то писать на десктоп под Java.
Хотя есть альтернативные направления (Android) но я к сожалению не специалист в нем и как там - не знаю.
Безсмысленно изучать в Java-технологиях всё подрят. Вы утонете. Сегодня библиотек и фреймворков настолько много что вам хватит до конца жизни. С практической точки зрения полезно изучать Spring Boot и все дочерние технологии в этом домене. Так вы с гарантией пройдете 80% собеседований. Но еще лучше открыть местную газету и почитать открытые вакансии в вашем регионе. И целенаправленно узнать что требуется.
Оба языка вполне себе годные. Но так вопрос ставить нельзя. Ценнось языка - это как ложка к обеду. Нужно брать тот который вы знаете лучше.
Чисто технически Java - более строгий язык. С точки зрения типизации. Следовательно в фазе компилляции отловит большинство ошибок который Питон не заметит. И с точки зрения перформанса. Java отстает где-то на 20% от С++ кода по скорости исполнения. Питон - во много раз медленнее. На чистой алгоритмизации. Особенно если вы не использовали никаих внешних библиотек на сях.
Сервлет - это аналог CGI. Была когда-то давно такая техника. Но в современной разработке сервлеты уже не принято использовать. Их заменяют на Rest-endpoints, GraphQL-endpoints которые отдают чистый контент в виде JSON/XML.
В Groovy и Scala есть возможность делать переносы без кавычек в каждой строке. Это так называемые multiline. В Java тоже запланирован JEP не помню в какой версии.
