Начинаю понимать

[ufm]

почему я нелюблю джаву не зная даже её синтаксиса. Это, видать до меня флюиды доходят.

Читаю документацию. Еще даже ни до чего серьёзного не дошёл, а уже два прекрасных момента.
1. Юникод в комментариях.
\\ c:\user\ufm
не скомпилируется.

2. Разница между && и & для boolean. Это вобще за гранью добра и зла - умудриться вырыть такую западню на ровном месте.
    static boolean test1() {
        System.out.println("test1");
        return false;
    }
    
    static boolean test2() {
        System.out.println("test2");
        return false;
    }
   public static void main(String[] args) {
       System.out.println(test1() && test2());
   }

В этом случае программа напечатает test1 и false. А если && заменить на &, то напечатает test1, test2 и false. Здравствуй поиск непонятной ошибки из-за тривиальной опечатки.

Comments

[juan_gandhi]

В си то же самое.

[ufm]

Да мне как-то всё равно что там в portable assembler происходит.

Впрочем - на счёт засадыс комментарием я сомневаюсь, а проверять - лень.

[chabapok]

Насколько понимаю, так как вам хотелось бы - можно, но перформанс просядет существенно.

Дело в том, что для логических && действует оптимизация, и если оптимизатор видит, что дальше считать нет смысла - он дальше и не считает. Это позволяет не вызывать некоторые функции, которые могут работать долго. Грубо говоря, у вас в test2 может быть цела куча кода, который надо исполнять, чтобы получить результат.
В простом случае "для теста" вы туда можете поставить sleep (но sleep не грузит проц, хотя и выдерживает паузу).

Для побитовых операций побитовые И, ИЛИ, И-НЕ выполняются для каждого бита. И это выполняется одной командой процессора над регистрами соответствующей битности.
И суть в том, что если такую же оптимизацию, которая действует для логических операций, применить для побитовых, то это придется программно проверять каждый бит, и если хоть 1 не совпал - то такую оптимизацию отменять. Раз в 100 это замедлит код точно.

А что было бы, если бы так как вам хочется было только для типа boolean, а для остальных типов было бы так, как есть сейчас? Наверное, так сделать можно бы было - но это было бы нелогично. Это дополнительное правило, которое надо бы было помнить. Вообще, это не аргумент, конечно. Разработчиков не остановила логика, что System.out.println('\u002a') можно - а System.out.println('\u000a') нельзя. Вот это действительно бред.

Так что думаю, обозначенная особенность не должна вас вообще волновать.

[ufm]

"Как мне хотелось-бы" не повлияет на производительность совсем. Просто надо запретить побитовые операции у типа boolean за безсмысленностью.
Честно, я не вижу юзкейса для побитовых операций у boolean.

Зачем побитовые операции у других типов и почему они себя ведут так как ведут - объяснения не требует.

Впрочем, понятно что "поздняк метаццо", никто не будет это менять. Это надо было думать при проектировании языка.

[chabapok]

Облажались сановцы...
Да, согласен. Это надо было запретить.

[vit_r]

"Если вместо + написать -, то результат будет совершенно другой. А разница всего в одной палочке!"

[ufm]

Ты не совсем прав. Разница между "+" и "-" как минимум в том, что эти две операции дают принципиально разный результат. Который достаточно легко отловить тривиальными тестами. Да и видно его будет, скорее всего, сразу.

Подлянка с & и && для boolean состоит в том, что обе операции дают _одинаковый_ _правильный_ результат. Но с разными побочными эффектами. На которые можно нарваться, а можно - не нарваться. А можно нарваться сильно позже совершенно не ожидая этого.

[vit_r]

Это разные операции. То, что они обозначаются похоже, ни о чём не говорит.

Где-то ошибка вылезает, когда вместо одного знака ставят два. Где-то когда вместо запятой точку. Где-то когда плюс путают с минусом.

Если где-то в формуле будет за плюсом почти всегда 0, то тоже "А можно нарваться сильно позже совершенно не ожидая этого."

[ufm]

Для типа boolean это _одинаковые_ операции.

Кстати, в go догадались для boolean не делать операцию &.