Вопрос непонятен. Если 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 не помню в какой версии.
