Я же теперь снова Java программист. И вот, не прошло и пары месяцев в этой роли, как я узнал новую мелочь. Оказывается, a = a && x и a &= x это не совсем одно и то же.

&= называется Compound Bitwise & assignment operator, и, как и другие бинарные операторы, он не «ленив», т. е. правая часть всегда вычисляется, вне зависимости от значения левой. Это отличает его от логического &&, который проигнорирует правую часть, если левая false.

Поэтому, если я напишу так

boolean a = false;
a = a && compute();

то compute() не будет вызвана. А если так

boolean a = false;
a &= compute();

то будет.

Overriding — переопределение — когда подкласс подсовывает свою реализацию метода вместо реализации в суперклассе. При вызове метода выбирается наиболее «специфическая» реализация, то есть реализация в подклассе, если она есть, приоритетнее реализации в суперклассе. В Java выбор выполняемого метода при переопределении происходит динамически (в рантайме) и не зависит от того, каким типом объявлена ссылка на объект:

public class TestOverriding {
    
    private static class Parent {
        String getName() { return "Parent"; }
    }

    private static class Child extends Parent {
        @Override
        String getName() { return "Child"; }
    }

    public static void main(String[] args) {
        Parent child = new Child();
        // Prints "Child"
        System.out.println(child.getName()); 
    }
}

Overloading — перегрузка — объявление методов (или конструкторов) с одинаковыми именами, но разными сигнатурами. Пример — все конструкторы любого класса, если их больше одного. В Java выбор имплементации при перегрузке происходит статически (во время компиляции) и не зависит от типа объекта в рантайме:

import java.util.Collection;
import java.util.HashSet;
import java.util.Set;

public class TestOverloading {

    static void classifyCollection(Collection<?> c) {
        System.out.println("Collection");
    }

    static void classifyCollection(Set<?> s) {
        System.out.println("Set");
    }

    public static void main(String[] args) {
        Collection<?> c = new HashSet<Object>();
        // prints "Collection"
        classifyCollection(c);
    }
}

Бывает, видишь в логе исключение, а стек трейса у него нет (он пустой):

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException

Одна строка и всё.

Это происходит, когда программа кидает очень много таких исключений. Сначала они генерируются как надо, с заполненным стек трейсом, и полностью попадают в лог. Потом виртуальная машина решает, что раз такие ошибки происходят очень часто, имеет смысл оптимизировать генерацию этих исключений (см. JIT). Тогда-то у них и пропадает стек трейс.

Поэтому когда вы у себя такое видите и не можете понять, откуда эти исключения вылетают, имеет смысл промотать лог назад (очень далеко назад, как правило) и поискать в том месте, где они впервые появились. И/или можно выключить эту оптимизацию с помощью следующего аргумента JVM

-XX:-OmitStackTraceInFastThrow

Если интересно, можно сымитировать подобную ситуацию простой программой:

public class Main2 {
 public static void main(String... args) {
  for (int i = 0; i < 1000000; i++) {
   try {
    int x = 0 / 0;
   } catch (Exception e) {
    if (e.getStackTrace().length == 0) {
     System.out.println("i=" + i);
     throw e;
    }
   }
  }
 }
}

У меня, например, цикл заканчивается на 12288-й итерации.

Мне не совсем понятна философия этой оптимизации. Да, исключения действительно “тяжёлые”. Но на то они и исключения, что должны происходить редко. И если в вашей программе они выкидываются очень часто, вы явно что-то делаете не так, и плохая производительность — это не главная ваша проблема. Ваша проблема в том, что вы не читали Item 57: Use exceptions only for exceptional conditions из Effective Java Блоха.

Может быть, кто-нибудь из читателей может объяснить?

В Guava есть аннотация VisibleForTesting. Её описание из кода библиотеки:

Annotates a program element that exists, or is more widely visible than otherwise necessary, only for use in test code.

То есть предполагается, что этой аннотацией мы будем отмечать методы и поля, которые, по идее, должны были быть private, но для тестов были сделаны package-private или public.

По поводу этой аннотации я хотел бы сказать, что она, ИМХО, не нужна.

В случае, когда член нужен тесту из другого пакета, и его поэтому пришлось сделать public, это совсем другая проблема и никакие аннотации тут уже не помогут. Так что рассуждать будем о private полях, которые были сделаны package-private для тестов.

Так вот, нет ничего плохого в package-private членах. Они по-прежнему остаются недоступными для клиентов из других пакетов (это самое главное, потому что их обычно большинство). Для клиентов из того же пакета: сам факт того, что некоторое поле, метод или конструктор имеет ограниченную видимость, должен настораживать разработчика не хуже аннотации. Конечно, наверняка найдётся кто-нибудь, кого это не остановит от доступа к члену или методу не по назначению. Но, ей-богу, оно того не стоит:

До:

@VisibleForTesting
static final double AVOGADROS_NUMBER = 6.02214199e23;
@VisibleForTesting
static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
@VisibleForTesting
static final double ELECTRON_MASS = 9.10938188e-31;

После:

static final double AVOGADROS_NUMBER = 6.02214199e23;
static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
static final double ELECTRON_MASS = 9.10938188e-31;

И ещё. Описание к аннотации намекает, что некоторые члены могут быть не только раскрыты, но и созданы исключительно для тестирования. Так вот, я не Кент Бек, конечно, но вроде бы:

1. продакшн код не должен испытывать никаких структурных изменений, сделанных исключительно для тестирования;

2. если некоторый класс ну никак не протестировать без введения туда новых членов, то скорее всего беда с качеством кода. За подробностями можно обратиться к «Чистому коду».

А ещё я иногда вижу такое:

/* package */ class SomeClass implements SomeInterface  {

Для кого этот комментарий вообще?

Несогласные призываются в комменты.

Статья Мартина Фаулера Public versus Published Interfaces. В целом ничего очень нового или исключительно интересного, но заставила задуматься, почему различие public-published на уровне языка реализовано далеко не во всех языках.

Суть:

Публичный интерфейс, public interface — методы класса, которые могут быть использованы любыми другими объектами.

Опубликованный интерфейс, published interface — то, чем пользуются внешние клиенты нашей, например, библиотеки. Они вызывают методы и наследуются своими классами.

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

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

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

Тут относительно недавно пробегали две статьи, в которых авторы затрагивали тему анализа хеш-функций с целью определить, какая лучше: Заметки о реализации hashCode() в Java и Changes to String internal representation made in Java 1.7.0_06 (перевод). В обеих статьях анализ проводился очень простой: генерировалось большое множество объектов нужного типа, для них вычислялись хеш-коды и среди хеш-кодов искалось количество коллизий (совпадений).

Я считаю, что такой анализ недостаточно хорош. Главное применение хеш-функций в Java — это в основанных на хешировании коллекциях, куда объекты складываются, распределяясь по ячейкам (бакетам, bucket) согласно своим хеш-кодам. Количество ячеек ограниченно, поэтому чтобы определить, в какой из них место объекту, берётся остаток от деления хеш-кода этого объекта на количество ячеек, которое из соображений производительности выбирается из степеней двойки. Так вот, равномерность распределения объектов по бакетам играет решающую роль в производительности коллекции, а значит очень важно, помимо количества коллизий, анализировать и её.

Легко показать, что малое число коллизий хеш-функции не всегда коррелирует с равномерным распределением объектов внутри хеш-таблицы. Достаточно взять любую хорошую хеш-функцию f(x) и получить из неё новую: h(x)=2*f(x). Количество коллизий у новой функции будет ровно таким же (для простоты забудем про переполнение), но при этом все её значения будут чётными, и распределение получится очень неравномерным.