VinVega

В каждой ide есть свои способы подключения артифактов. Я чаще использовал maven-based project.
И чтоб добавить кастомную зависимость я ее устанавливал в локальный maven folder.

$ mvn install:install-file ....

И после этого библиотека была видна как group:artifact:version coordinates.

Для хрома
F12 дальше по картинке

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

Я бы ничего из этого не читал сейчас. Лучше время на практические навыки потратить. Вот потом, с годом-двумя реального опыта очень полезно. Потому что будет не просто чтение, а переоценка своего опыта. Я дулал вот так, а умная книга говорит что надо было по другому. Стоит об этом поразмыслить.

Вариант раз: Портится. У меня лампа накаливания (или может просто горячая светодиодная?) была и в один день лампа прислонилась (или просто приблизилась?) к монитору. Теперь у монитора оплавился уголок. (на самом деле он размяк, а я его ещё из интереса пальцем нажал)
(без шуток так и было, могу даже фото показать. Монитором всё ещё пользуюсь)

Вариант два: Портится. У меня в настольную лампу вкручена УФ-лампа. Она постоянно светила на экран и теперь у экрана странная цветопередача. (А это уже выдуманный случай)

Если вы не такой как я, то проблем быть не должно.

Докину 5 коп.

Я думаю что никто такую задачу вобщем-то не ставит. И никогда не поставит. Тут не то что Java
а я прошу прощения Cobol не могут никак заменить. Языку - уде более 50 лет возраста.
И хотя проблема касается в основном США, но это просто пример того что код живет очень долго.
У джунов уже седые бороды отрасли :)

Язык Rust вобщем-то создавалася как язых обще-системного программирования с правильным
механизмом управления памятью. И уже если ему и где-то конкурировать - так это там где нужен
отклик (игры или реал-тайм приложения).

Сильные стороны Java сегодня - это большой репозитарий библиотек на все случаи жизни.
Статистика по maven https://mvnrepository.com/ заявляет что 35 миллионов артифактов
имеется в наличии. Можно наверное найти любой драйвер или парсер или любую
либу поддержки сетевых протоколов. Большая часть из них проверена временем.
Production ready. Можно ли говорить о production-ready для Rust - библиотек я не знаю.
Пускай знающие отпишут.

Java - машина с развитым рантаймом. Рефлексия позволяет делать позднее инстанциирование
компонентов через конфиги. И этим очень сильно пользуются во фреймворках. Фактически
если проводить сравнительные анализы Rust и Java - мы встанем перед дилеммой - чем заменить
механику рефлексии в Rust? Создавать рантайм? Но это противоречит идеям системного программирования
или все таки принять как факт что Spring и ему подобные фреймворки принципиально нельзя
воспроизвести в языке статической компилляции таком как Rust.

Если-бы я сравнивал этот язык (Rust) - то ставил бы ему в одну весовую категорию Nim, Zig и прочие
языки "пост-плюсового" периода. И в качестве задач я-бы ставил - разработку игр и драйверов
для операционок. Вот там и тестируйте.

Самому финтеху не всегда нужен рилтайм. Иногда - даже вообще не нужен. В батч-джобах биг-даты
и python нормально работает. Специфика своя там. А критичные части бигдаты (Apache Arrow, Databricks Photon)
- и так переписаны на сях чтобы быстринько search + join работал. В стриминге биг-даты - тоже вобщем-то
CPU не сильно критичен. Там и Node и C# тоже годится в качестве языков. Вобщем задачи - I/O bounded.

Раст же вроде планируется как замена С/С++ и является более низкоуровневым.
Ему прямой путь в системное программирование. А финтех это немного другое

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

Кроме Java в финтехе вообще много разных языков используется. Даже такая экзотика как Haskell и F# бывает.

Могу сказать, что сейчас работаю в большой корпорации и мы как раз пишем на Rust штуки, которые отвечают за работу с платёжными системами.

Раньше примерно то же самое писалось на плюсах.

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

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

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

Нет. У них разные области применения. Java проектировалась именно как предельно простой и лёгкий для восприятия язык, максимально препятствующий выстрелу в ногу. Никогда этим параметрам не будет соответствовать язык одновременно пригодный к системному программированию. И это не учитывая тот фактор, что инвестиции в переписывание всего финтеха с Java на Rust потребуются больше, чем планетарный ВВП.

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

Да, может и, вероятно, заменит. Уступает очень крутой кривой обучения на старте

Можно (через редактирование манифеста), но он будет "мутный", размытый. Если софт не поддерживает HiDPI, значит он не поддерживает HiDPI.

1 или 2.

"Java. Библиотека профессионала", Хорстманн.

Алгоритмы брать не надо. Седжвик вообще писал не про Java а только про алгоритмы.
У него - целое семейство книг такого вида. Сначала Алгоритмы на С. Потом на C++ И потом Java. Он по сути портировал исходники. Какой толк вам в таком портировании?

А Хорстман, Эккель - вполне себе норм.