Если же Сomparable не присутствует, то Java использует identity hash code объектов для того, чтобы разрулить неоднозначность, чтобы определить, какой из объектов меньше какого.
Не очень понимаю, как потом что-то искать в таком дереве, если ключ - identity hash code. Всё равно придётся перебирать его полностью, чтобы найти элемент, равный по equals().
Только сверив отпечаток общего ключа. Телеграм это позволяет, но сам этот процесс требует общения Васи и Коли по какому-то каналу, до которого не доберётся Петя. Например, при личной встрече.
Интересная мысль, но в Java перестали пытаться сделать "безопасность" внутри процесса JVM, ибо всё равно получается дыряво. В Java 17 уже сделали то же самое с SecurityManager, а до этого - с апплетами, JWS и прочим подобным.
Не очень понятно, от кого защищается такая "безопасная библиотека".
Я думаю, что всё-таки задумка этого репозитория — письмо против RMS, а не обсуждение, с чего бы это вообще делать.
И лично я, даже не общаясь с автором, почему-то изначально был уверен, что его цель — совсем не борьба с дискриминацией.
Issue в чьём-то репозитории вполне могут закрываться по желанию левой пятки его владельца. В сообществе не принято так себя вести, но никаких формальных препятствий так делать нет.
Я вам больше скажу: в данном случае это даже не оттолкнёт потенциальных контрибьюторов. Тех из них, которые пришли ставить свою подпись рядом.
Моя мысль проста: надо воевать по-другому, не на их территории. Например, созданием рядом на том же гитхабе письма в поддержку противоположной стороны, что уже и сделано.
Если это не интерпретатор с циклом (а я думаю, JIT там есть), то нельзя взять и отдать коду N тиков, можно только сделать этот код таким, что он будет сам их считать. И насколько я знаю по беглому изучению этой темы, в BEAM "тиком" считается вызов функции.
Угу, половина стандартной библиотеки эрланга — NIFs, и ничего, планируются как миленькие.
Код на C будет считать "тики" только если делать это явно. Наверняка в стандартной библиотеке так и делается. Возьмите любую левую либу и она вам запросто подвесит всё.
заблокировал одно из ядер на пять минут, пока он файл до конца не вычитает
Ну во-первых, в худшем случае блокируется не ядро CPU, а поток ОС, а во-вторых, освобождать его на время IO как раз таки умеет любой нормальный рантайм с green thread'ами.
То, что BEAM при этом ещё и хорошо справляется с тяжёлыми вычислениями на CPU без ущерба для latency — это несомненно очень хорошая фича. Но и без этого можно жить. Про Go не скажу, но например в Kotlin для этого есть средства. Но да, об этом надо подумать разработчику, и да, рано или поздно он подумать об этом забудет. Но везде можно выстрелить себе в ногу, это лишь одна из возможных ошибок, при том не самая фатальная.
Я бы не стал называть подход, когда VM вставляет в код неявные проверки "не пора ли переключиться на планировщик", вытесняющей многозадачностью.
Код, выполняющийся в потоке, сам отдаёт управление планировщику, кооперативно. И если например в этом потоке в данный момент выполняется какой-нибудь код на C, ничего не знающий про BEAM, не будет никакого переключения.
Да, это позволяет снизить latency, но эти проверки не бесплатны. И разработчик не может сказать VM: "вот тут проверяй, а тут и так сойдёт".
думают, что грин-треды — это не болото, которое повиснет намертво при первом удобном случае
Я думаю, что это — инструмент, которым надо уметь пользоваться и знать его ограничения. И кстати то, что сделано в BEAM, тоже можно назвать грин-тредами.
В вытесняющую многозадачность умеет только шедулер ОС, вот только проблема в том, что он медленный. Поэтому и используются "грин-треды", которые так не умеют, зато быстрее.
ложное впечатление, будто он на самом деле проверяет список на наличие только целых чисел в нём
Но ведь это ничем не отличается от явного приведения:
final var intList = (List<Integer>) list;
Тоже создаёт "ложное впечатление, будто он на самом деле проверяет список на наличие только целых чисел в нём", ведь обычно приведение типа это делает (с массивами например).
Note: A.java uses unchecked or unsafe operations.
Похоже, опять придётся полагаться на инспекции в IDE.
Поведение идентично unchecked cast, и реакция компилятора соответствующая, так что никаких проблем нет. Предупреждения компилятора надо всё-таки читать.
Враппер обычно идёт вместе с проектом. На Linux и macOS можно обращаться напрямую. На Windows — вызывать вместо враппера bat-файл.
А чем по-вашему принципиально отличается sh-скрипт gradlew для Unix-подобных ОС и gradlew.bat для Windows?
А долгая сборка обычно вызвана не Gradle, а тем большим объёмом работы, которая делается при сборке типичного Android приложения. При сборке руками в лучшем случае будет то же самое. Сам Gradle уже давно не тормозит.
Если не свызываться с Android, всё работает быстро и стабильно.
И с Java 8 только один из них правильный
Не очень понимаю, как потом что-то искать в таком дереве, если ключ - identity hash code. Всё равно придётся перебирать его полностью, чтобы найти элемент, равный по equals().
Только сверив отпечаток общего ключа. Телеграм это позволяет, но сам этот процесс требует общения Васи и Коли по какому-то каналу, до которого не доберётся Петя. Например, при личной встрече.
Интересная мысль, но в Java перестали пытаться сделать "безопасность" внутри процесса JVM, ибо всё равно получается дыряво. В Java 17 уже сделали то же самое с SecurityManager, а до этого - с апплетами, JWS и прочим подобным.
Не очень понятно, от кого защищается такая "безопасная библиотека".
А что, специализация на фронтенде или бэкенде ставит на человеке как "софтверном инженере" крест?
Странное противопоставление, как по мне. Описанное в статье больше похоже на фуллстека.
Я думаю, что всё-таки задумка этого репозитория — письмо против RMS, а не обсуждение, с чего бы это вообще делать.
И лично я, даже не общаясь с автором, почему-то изначально был уверен, что его цель — совсем не борьба с дискриминацией.
Issue в чьём-то репозитории вполне могут закрываться по желанию левой пятки его владельца. В сообществе не принято так себя вести, но никаких формальных препятствий так делать нет.
Я вам больше скажу: в данном случае это даже не оттолкнёт потенциальных контрибьюторов. Тех из них, которые пришли ставить свою подпись рядом.
Моя мысль проста: надо воевать по-другому, не на их территории. Например, созданием рядом на том же гитхабе письма в поддержку противоположной стороны, что уже и сделано.
В блок лист, конечно же, мы же не расисты
Ну как бы ожидаемо, что людям, собирающим подписи за свою позицию, нет никакого дела до противоположной стороны. Не согласны — пишите своё письмо :)
А есть ли смысл использовать AES-256? 128 уже не считается устойчивым?
Не нашёл ответа на вопрос в статье. А вот ожидаемый холивар в комментах нашёл.
О, точно, можно же так делать. Да, получилось бы плохо.
Ох уж эти промахи прошлого.
Интересно, что мешало в BAOS переопределить
write(byte[])
так, чтобы он не мог кидать исключение.И интерпретатор, и JIT — это часть VM.
Если это не интерпретатор с циклом (а я думаю, JIT там есть), то нельзя взять и отдать коду N тиков, можно только сделать этот код таким, что он будет сам их считать. И насколько я знаю по беглому изучению этой темы, в BEAM "тиком" считается вызов функции.
Код на C будет считать "тики" только если делать это явно. Наверняка в стандартной библиотеке так и делается. Возьмите любую левую либу и она вам запросто подвесит всё.
Ну во-первых, в худшем случае блокируется не ядро CPU, а поток ОС, а во-вторых, освобождать его на время IO как раз таки умеет любой нормальный рантайм с green thread'ами.
То, что BEAM при этом ещё и хорошо справляется с тяжёлыми вычислениями на CPU без ущерба для latency — это несомненно очень хорошая фича. Но и без этого можно жить. Про Go не скажу, но например в Kotlin для этого есть средства. Но да, об этом надо подумать разработчику, и да, рано или поздно он подумать об этом забудет. Но везде можно выстрелить себе в ногу, это лишь одна из возможных ошибок, при том не самая фатальная.
Я бы не стал называть подход, когда VM вставляет в код неявные проверки "не пора ли переключиться на планировщик", вытесняющей многозадачностью.
Код, выполняющийся в потоке, сам отдаёт управление планировщику, кооперативно. И если например в этом потоке в данный момент выполняется какой-нибудь код на C, ничего не знающий про BEAM, не будет никакого переключения.
Да, это позволяет снизить latency, но эти проверки не бесплатны. И разработчик не может сказать VM: "вот тут проверяй, а тут и так сойдёт".
Я думаю, что это — инструмент, которым надо уметь пользоваться и знать его ограничения. И кстати то, что сделано в BEAM, тоже можно назвать грин-тредами.
В вытесняющую многозадачность умеет только шедулер ОС, вот только проблема в том, что он медленный. Поэтому и используются "грин-треды", которые так не умеют, зато быстрее.
Но ведь это ничем не отличается от явного приведения:
Тоже создаёт "ложное впечатление, будто он на самом деле проверяет список на наличие только целых чисел в нём", ведь обычно приведение типа это делает (с массивами например).
Поведение идентично unchecked cast, и реакция компилятора соответствующая, так что никаких проблем нет. Предупреждения компилятора надо всё-таки читать.
Да, но это всё равно не совсем работает (см. https://habr.com/ru/post/332730/).
В условиях, когда Telegram не использует TLS, тащить x509 смысла немного. SSH например тоже работает напрямую с ключами.
А чем по-вашему принципиально отличается sh-скрипт
gradlew
для Unix-подобных ОС иgradlew.bat
для Windows?А долгая сборка обычно вызвана не Gradle, а тем большим объёмом работы, которая делается при сборке типичного Android приложения. При сборке руками в лучшем случае будет то же самое. Сам Gradle уже давно не тормозит.
Если не свызываться с Android, всё работает быстро и стабильно.