Java + Telegram (ссылка)

Примитивы в Java включают в себя 8 типов, из которых 6 относятся к численным.

Целочисленные:

1. BYTE: тип с диапазоном от -128 до 127

2. SHORT: тип с диапазоном -32768 до 32767

3. INT: один из самых популярных типов, диапазон от -2^31 до 2^31-1

4. LONG: тип с диапазоном значений от -2^63 до 2^63-1

Числа с плавающей точкой.

Куда хитрее стоит дело с числами с плавающей точкой. Тут пользователю дают 32 бита (float) или 64 бита (double), и он может тратить их на целую часть или на часть после плавающей точки. Оценить масштабность этих числе мы можем следующим образом:

Минималный "шаг" между двумя такими числами будет авен:

• Float.MIN_VALUE ~ 1.40239846e-45

• Double.MIN_VALUE ~ 4.9e-324

Максимальное число, если после запятой не будет дробных частей (те мы словно станем целочисленной переменной):

• Float.MAX_VALUE ~ 3.4e+38

• Double.MAX_VALUE ~ 1.79e+308

Резюмируя: чем более точно наше число (то есть, чем больше чисел после плавающей точки), тем меньше его абсолютное значение. Поскольку числа "до" запятой, то есть целочисленная часть, уменьшаются, увеличивается точность представления дробной части.

Булевы и Символные примитивы.

Ну и на последок - логические и символьные типы:

• boolean - имеет значение true/false

• char - символьный примитив может представлять максимум 65536 символов.

Что нужно знать о примитивах?

Основные характеристики примитивов:

• Быстры в работе

• Легковестны

Переполнение нам не друг. В крайнем случае, мы спасаемся через BigInteger/BigDecimal.

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

• Если умножить два Short, каждый из которых равен 200, то мы выйдем за границу 32768, и вместо 40000 мы получим -25536.

• Если мы умножим два Integer (которые могут покрывать 2 миллиарда), каждый из которых равен 50000, то мы получим -1794967296 вместо 2.5 миллиарда.

Вывод - заранее подумай о границах значений. Если данные не влазят ни в один из типов то BigDecimal или BigInteger придут на помощь.

Обертки примитивов. Вроде и жирненькие но необходимые.

Для каждого примитива в Java существует его обертка. Например:

• int обернут в Integer

• double в Double

• и так далее для каждого из 8 типов

Основная необходимость наличия оберток - использование их в коллекциях. Коллекции в Java, по дизайну, работают только с объектами. Такой код даже не скомпилируется:

Что дает класс обертка? Посмотрим на примере Integer

Классы-обертки в Java, такие как Integer, предоставляют ряд преимуществ и дополнительных функциональностей:

1. Конвертация типов: Методы, такие как Integer.valueOf(), предоставляют возможность конвертировать значения одного типа в другой.

2. Autoboxing/Unboxing: Обертки поддерживают автоматическую упаковку (autoboxing) и распаковку (unboxing) значений, обеспечивая плавную конвертацию между примитивами и объектами.

3. Реализация equals/hashcode: Классы-обертки переопределяют методы equals() и hashCode(), что позволяет использовать их в качестве ключей в коллекциях, таких как HashMap, где хранение и поиск элементов основаны на хэш-функции.

4. Имплементация Comparable: Классы-обертки реализуют интерфейс Comparable, что делает их подходящими для использования в упорядоченных коллекциях, таких как TreeMap.

5. Дополнительные методы: Классы-обертки предоставляют различные вспомогательные методы, такие как min(), max(), bitCount() и другие.

И так один из самых важных моментов - обертки работают из коробки для коллекций. Но есть ли минусы у них?

Недостатки оберток. Жирнота, медлительность.

Обертки инкапсулируют в себя примитивы это мы уже знаем. И как следствие мы:

• Тратим память на саму обертку, а учитывая минимальный размер слова в 64-битных операционных системах (32-битные не берем в расчет, они уходят в прошлое) - обертка просто непростительно разрастается.

• Время на доступ к примитиву возрастает, так как добавляется лишний прыжок по ссылке обертки.

• Время на autoboxing/unboxing

Давайте оценим размер примитива и размер обертки для 64х битных систем:

Итак, потеря в памяти довольно высока. Минимум, мы теряем от 3 до 16 раз. И, возможно, здесь стоит отметить, что, на практике, большинство программ не постоянно хранят большие объемы данных, и в большинстве случаев созданные объекты удаляются. Кроме того, современная память относительно дешева.

Что делать, если размер памяти критичен?

Однако, если вы храните большие объемы числовых данных и эффективное использование памяти критично, у вас есть два варианта:

• Вернуться к использованию старых добрых массивов, которые поддерживают примитивы.

• Использовать библиотеки вроде FastUtil или Trove , которые предоставляют специализированные коллекции для работы с примитивами и оптимизированы для минимизации потребления памяти.

Производительность.

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

Надеюсь вам понравился разбор. Больше материалов по джаве и смежным технологиям вы можете найти в моем канале. Спасибо за внимание.

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

Какие технологии помогают анализировать код на ошибки и уязвимости?

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

• SonarQube

• FindBugs

• PMD

• SpotBugs

• Checkstyle

• Snyk

• JArchitect

• Graudit

В данной статье мы рассмотрим SonarQube и PMD.

SonarQube настройка, установка, запуск.

SonarQube - довольно популярное решение, хотя, по моему мнению, изначальные правила проверок лучше немного перенастроить. SonarQube предоставляет бесплатную версию, которая может быть запущена из-под Docker в одну команду. Все, что вам потребуется, это сервер с 2 ГБ оперативной памяти (но чем больше, тем лучше). Как настраивать и арендовать сервер я писал вот тут.

Запускаем Sonar используя Docker.

Запускаем докер одной командой:

Первый логин проходит под admin/admin

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

Процесс создания проекта и генерации токена.

Существуют разные способы интеграции с SonarQube. Самый простой — интегрировать зависимость в Maven/Gradle вашего проекта и затем выполнить одну команду в командной консоли. Ниже я постараюсь упростить процесс генерации токена и проекта до шести команд:

После выполнения всех 6 шагов у нас есть:

• Имя проекта pikabu

• Имя ключа pikabu

• имя токена

Чтобы Sonar проводил более подробную аналитику, рекомендуется установить плагины. Для этого перейдите в раздел Administration => Marketplace и выберите плагины по вашему желанию:

Настраиваем Maven и добавляем Sonar плагин.

Для настройки мавен проекта достаточно добавить плагин в pom.xml:

Теперь мы готовы к анализу нашего кода.

Напишем код с наиболее популярными ошибками в Java.

Я приведу далеко не все классические ошибки, но для оценки базовой функциональности этого будет достаточно:

Все настроено. Погнали.

Если в файле pom.xml добавлен Sonar плагин, и имя проекта, ключ и токен готовы, после сборки проекта можно запустить команду для передачи результатов в SonarQube:

Анализируем результаты

После запуска заходим в проект (в моем случае pikabu) и нажимаем Overall Code

Результаты

• Обнаружено 6 багов.

• Покрытие составляет 0% (для более точного анализа покрытия, рекомендуется интегрировать Jococo плагин).

• Выявлено 49 вонючих строк кода.

Поскольку я включил более 1000 правил (по умолчанию их всего 400), некоторые проблемы среди 49 являются просто дубликатами. Давайте рассмотрим самые важные, а именно баги:

В результате часть багов была отловлена, но некоторые например незакрытый стрим или итерация через итератор - нет.

Также можно выбрать файл и посмотреть всю аналитку:

Какие выводы можно сделать?

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

• Сонар однозначно отлавливает много багов но не все.

• Во много качество сонара определяется настроеными правилами (Quality profiles) которые затем и используются во время анализа. Подружить их все - довольно непросто.

• Слишком большое количество правил руинит весь смысл анализа.

Двигаемся дальше. PMD анализатор кода.

Sonar не является чем-то уникальным. Давайте рассмотрим другое бесплатное решение - PMD. Кстати, правила PMD могут быть скачены и запущены в Sonar, но с первой попытки у меня это не получилось из-за проблемы с соответствием версий PMD/SONAR/JAVA.

Ставим PMD

Чтобы поставить PMD достаточно скачать с их сайта pmd-dist-7.0.0-rc4-bin.zip и распаковать. Затем добавить в PATH bin папку и запусить команду:

В команде C:\cleancode является папкой проекта где лежит ваш Java код. Результатом работы будет созданный report.html. Вот результаты его работы:

И так результаты PMD мне зашли. Он нашел почти все проблемы, часть которых Sonar пропустил (точнее тысяча правил которые я подключил из стандартных наборов).

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

interface SomeInterface {

int SOME_THING = 11;

int foo();

}

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

interface SomeInterface {

default int foo() {

System.out.println("foo");

}

}

Также Амбала может иметь и статические методы, а обращаться к ним можно также как и к статическим методам класс

interface SomeInterface {

static int foo() {

System.out.println("foo");

}

}

public static void main(String[] args) {

SomeInterface.foo();

}

Шли годы и у Амбалы появились дети (jdk 9), они уже умели делать свои методы приватными и эти приватные методы могут быть как статическими так и нет.

Также к Амбале приехали родственники из Ифрики, оказалось, что они не содержат ни методов ни полей. "Как так получилось" - спросил Василий: "Что они умеют делать???".

Родственники рассказали Василию про таинственный полиморфизм: когда пустые интерфейсы используются, для пометки класса, реализующий этот интерфейс, чтобы использовать после этот класс в качестве реализации методов

interface Printable { }

class SomeClass implements Printable {

private int magicNumber = 3;

public int getMagicNumber() {

return magicNumber;

}

@override

public String toString() {

return String.valueOf(magicNumber);

}

}

public class Main {

public static void main(String[] args) {

var someClass = new SomeClass();

print(someClass);

}

public static void print(Printable printable) {

System.out.println(printable);

}

}

Суть в том, что тема интерфейсов оказалось гораздо интереснее чем я думал.

P.S помимо прочего веду телеграмм-канал и буду рад если поддержите IT-литературу.

В чем суть и различие?

JDK (Java Development Kit) - включает в себя Java Development Tools и среду выполнения Java - JRE (Java Runtime Environment).

JDT (Java development tools) - включают в себя около 40 различных инструментов: javac (компилятор), java (лаунчер для приложений), javap (java class file disassembler), jdb (java debugger) и др.

JRE - это пакет всего необходимого для запуска скомпилированной Java-программы. Включает в себя виртуальную машину JVM и библиотеку классов Java Class Library.

Резюмируем. Есть JDK для ведения разработки, которое содержит JRE и интсрументы разработки (тот же компилятор и дебаггер). Дальше сам JRE содержит какую-то JVM и библиотеку непонятных классов

Непосредственно JVM

JVM (Java Virtual Machine) - программа предназначенная для выполнения байт-кода. Благодрая которой, Java может работать на всех платформах. Раньше программы писали под определенную платформу, а теперь можно написать на Java и работать программа будет везде. Собственно JVM существует масса как комерческих, так и с открытым исходным кодом. А для чего пишется столько различных JVM? Нуу... Чтобы на какой-нибудь операционке работало быстрее, так же можно написать свою JVM для каких-либо своих целей

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

А что за байт-код? Когда мы компилирует программу мы получаем на выходе файлы с расширением .class. Это и есть файлы с байт-кодом

Есть вопрос гораздо интереснее, а как это файлы JVM находит? Что за сущность, которая говорит JVM: "О смотри что нашел, тебе нужно?". Сие носит название как Class loader

Class Loader

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

Загрузчики:

1) Bootstrap classloader загружает основные библиотеки Java, расположенные в папке <JAVA_HOME>/jre/lib. Этот загрузчик является частью ядра JVM, написан на нативном коде (C, C++). Когда JVM загружает классы из rt.jar, она не выполняет все этапы проверки, которые выполняются при загрузке любого другого класс-файла т.к. JVM изначально известно, что все эти классы уже проверены. Поэтому, включать в этот архив какие-либо свои файлы не стоит, в отличие от наших классов, их JVM проверяет

2) Extension classloader загружает код в каталоги расширений (<JAVA_HOME>/jre/lib/ext, или любой другой каталог, указанный системным свойством java.ext.dirs). Если нужно, чтобы какой-то класс загружался каждый раз при старте Java машины, можешь скопировать исходный файл класса в эту папку, и он будет автоматически загружаться

3) System classloader загружает код, найденный в java.class.path, который сопоставляется с переменной среды CLASSPATH. Это реализуется классом sun.misc.Launcher$AppClassLoader.

Загрузчик классов выполняет в строгом порядке:

1) загрузка - находит и импортирует двоичные данные для типа.

2) связывание - выполняет проверку, подготовку и (необязательно) разрешение.

3) проверка - обеспечивает правильность импортируемого типа.

4) подготовка - выделяет память для переменных класса и инициализация памяти значениями по умолчанию.

5) разрешение - преобразует символические ссылки из типа в прямые ссылки.

6) инициализация - вызывает код Java, который инициализирует переменные класса их правильными начальными значениями.

Немного о проверке корректности .class

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

Так при загрузке класса:

1) происходит чтение класс-файла, т.е проверка корректности формата

2) создается представление класса в Constant pool (Meta space, область памяти для такого рода делов)

3) грузятся супер-классы и супер-интерфейсы. Если они не будут загружены, то и сам класс не будет загружен

Загрузчик классов написан на Java. Поэтому возможно создать свой собственный загрузчик классов, не понимая тонких деталей JVM. У каждого загрузчика классов Java есть родительский загрузчик классов, определенный при создании экземпляра нового загрузчика классов или в качестве системного загрузчика классов по умолчанию для виртуальной машины

И это не все

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

JIT (just in time) - компилятор, который использует интерпретатор когда увидит функцию, использующую несколько раз. Т.е. интерпретатор видит повторяющийся код => отдает его на съедение JIT, а после использует сразу скомпилированный код от JIT (нативный код) и ему не нужно заново компилировать байт-код

Области тьмы (памяти)

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

1) Heap (куча) - создается при запуске и работает пока программа не завершится. В ней хранятся объекты доступные для всех потоков из всех участков программы (не нужные объекты чистит сборщик мусора). Может быть фиксированного размера и определяться по мере выполнения программы

2) Run-Time Constant Pool - область хранения класса или интерфейса в рантайме. Хранит информацию о классе, константы (числовые литералы, ссылки на методы и поля)

3) Native Method Stacks - стеки для поддержки нативных методов, написанных не на Java

4) Java Virtual Machine Stacks - стек для потоков, т.е. каждый поток имеет свой стек. Стеки могут быть как фиксированного размера, так и динамически изменяться

5) Program Counter Register (PCR) - каждый поток имеет такую область памяти, в ней хранится адрес инструкции на которой поток завершился, чтобы потом начать с этой инструкции

Frame - новый frame создается каждый раз, когда вызывается метод. Frame уничтожается, когда завершается вызов метода. Соответсвенно раз фрэйм создается для создания метода, каждый фрейм имеет свои константы, локальные переменные. А фрейм, который выполняетсяв данный момент называется текущим, т.к. работать может только один фрейм во всей программе.
Каждый frame содержит ссылку на run-time constant pool для поддержки динамического связывания метода. Динамическое связывание загружает классы по мере необходимости. Позднее связывание методов и переменных вносит изменения в другие классы, которые метод использует с меньшей вероятностью нарушить этот код.

Почитать о том как я проходил собеседования, об IT и жизни можешь в этом телеграмм-канале