Тулза от того же коллеги - https://news.ycombinator.com/item?id=46025223

С неймингом у него явные проблемы.

Пытаемся с ним бутстрепнуть java в #ix, он дотягивает, с помощью clode и codex, jikes (https://github.com/daveshields/jikes, очень старый компилятор java, который написан не на java, как все остальные, а на с++), до уровня java 6, или, если получится, 7.

У #java очень хорошие тесты, которые интегрированы в agent loop, поэтому, возможно, идея не такая дикая, как кажется.

Будни #bootstrap

Тем временем, начал повторять цепочку из https://bootstrappable.org/projects/java.html

"In Guix the #Java bootstrap begins with Jikes, a Java compiler written in C++. We use it to build a simple version of GNU Classpath, the Java standard library. We chose version 0.93 because it is the last version that can be built with Jikes. With Jikes and this version of GNU Classpath we can build JamVM, a Java Virtual Machine. We build version 1.5.1 because it is the last version of JamVM that works with a version of GNU classpath that does not require ECJ. These three packages make up the bootstrap JDK"

pg:home# /ix/...ne0-bin-jamvm/bin/jamvm \
     -Xbootclasspath/p:/ix/...Vn5-bin-gnu-classpath-93/share/classpath/tools.zip \
     gnu.classpath.tools.jar.Main --help
!Main.Usage!

!Main.OpMode!:
  -c                     !Main.Create!
  -x                     !Main.Extract!
  -t                     !Main.List!
  -u                     !Main.Update!
  -i !Main.FileArg!      !Main.Index!

!Main.OpMods!:
  -f !Main.FileArg2!             !Main.ArchiveName!
  -0                             !Main.NoZip!
  -v                             !Main.Verbose!
  -M                             !Main.NoManifest!
  -m !Main.ManifestArgName!      !Main.ManifestName!

!Main.FileNameGroup!:
  -C !Main.ChangeDirArg!      !Main.ChangeDir!

!Parser.StdOptions!:
      --help                          !Parser.PrintHelp!
      --version                       !Parser.PrintVersion!
  -J!ClasspathToolParser.JName!       !ClasspathToolParser.JArgument!

Совершенно потрясающее ощущение, когда компилятор из 2008 года компилирует код из 2006 года, все это запускается в VM от 2007 года, и это, в итоге, начинает РАБОТАТЬ!

pg:home# /ix/store/.../bin/jamvm -jar /ix/store/.../share/ecj-bootstrap.jar
Eclipse Java Compiler v_686_R32x, 3.2.2 release
Copyright IBM Corp 2000, 2006. All rights reserved.

 Usage: <options> <source files | directories>
 If directories are specified, then their source contents are compiled.
 Possible options are listed below. Options enabled by default are prefixed
 with '+'.

Штош, у меня есть Eclipse #Java Compiler!

Самое интересное, что у него получилось.

За две недели его "джуны" (клода и кодекс, в режиме "критика") сумели сделать из компилятора java 1.4 компилятор "почти" java 1.7.

Я его ставлю в цепочку #java #bootstrap, и цепочка успешно завершается.

С одной стороны, это круто (очень!), потому что в одно рыло за две недели такой объем работ не проделать.

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

Ну и доставляет тот факт, что этот компилятор жрет до 30G памяти в пике, что делает его непригодным для промышленного использования. Наверное, потому, что управление памятью в С++ - сложно.

Вот код - https://github.com/7mind/jopa, вот deep dive to JOPA - https://github.com/7mind/jopa/blob/main/EXPLANATION.md

#AI

Будни #bootstrap

Продолжаю собирать #java, уже настоящую openjdk, в виде icedtea (порченое редхатом openjdk, чтобы оно хоть как-то собиралось):

Done with parallel compiles: /ix/build/VQEWVWXLpdRDv7B6T8uSq6/src/openjdk-boot/jdk/make/java/java
rm -f /ix/build/VQEWVWXLpdRDv7B6T8uSq6/src/openjdk.build-boot/lib/currency.data
/ix/build/VQEWVWXLpdRDv7B6T8uSq6/src/bootstrap/jdk1.6.0/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -jar /ix/build/VQEWVWXLpdRDv7B6T8uSq6/src/openjdk.build-boot/btjars/generatecurrencydata.jar -o /ix/build/VQEWVWXLpdRDv7B6T8uSq6/src/openjdk.build-boot/lib/currency.data.temp \
  < ../../../src/share/classes/java/util/CurrencyData.properties
Error: time is more than 10 years from present: 1420063200000
java.lang.RuntimeException: time is more than 10 years from present: 1420063200000
   at build.tools.generatecurrencydata.GenerateCurrencyData.makeSpecialCaseEntry(GenerateCurrencyData.java:287)
   at build.tools.generatecurrencydata.GenerateCurrencyData.buildMainAndSpecialCaseTables(GenerateCurrencyData.java:226)
   at build.tools.generatecurrencydata.GenerateCurrencyData.main(GenerateCurrencyData.java:157)
   at java.lang.reflect.VMMethod.invoke(Native Method)
   at java.lang.reflect.Method.invoke(Method.java:327)
   at jamvm.java.lang.JarLauncher.main(JarLauncher.java:50)
make[5]: *** [Makefile:346: /ix/build/VQEWVWXLpdRDv7B6T8uSq6/src/openjdk.build-boot/lib/currency.data] Error 1

В этот момент я остановился, и заплакал.

Сука, почему вообще кого-то ебет, насколько старый файл участвует в сборке?!?

Штош, у меня теперь есть настоящая openjdk, ну, sort of:

pg:home# ../hotspot/outputdir/linux_amd64_compiler2/product/gamma
Using java runtime at: /ix/build/ZTejNJErcdJHO2zHaNUZ72/src/openjdk.build-boot/j2sdk-image/jre
OpenJDK 64-Bit Server VM warning: No monotonic clock was available - timed services may be adversely affected if the time-of-day clock changes
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000000008c9f2d, pid=3319070, tid=140576357940024
#
# JRE version:  (7.0_171-b02) (build )
# Java VM: OpenJDK 64-Bit Server VM (24.171-b02 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 2.6.13
# Distribution: Custom build (Fri Dec  5 16:08:17 UTC 2025)
# Problematic frame:
# C  [exe+0x6c9f2d]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid3319070.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#
Aborted

Пашкина jopa пошла по рукам:

https://www.linkedin.com/posts/jalal-hussain-7656951a_java-compilertech-cplusplus-activity-7398427889374941184-omvH/

https://discuss.haiku-os.org/t/jopa-java-compiler-in-c/18395

https://xn--r1a.website/javatg/2077

#java

#prog

Для #java есть JEP 401: Value Classes and Objects (Preview). Value-объекты в данном случае — это объекты, у которых отсутствует идентичность. Это полезно, поскольку для многих классов, которые просто объединяют несколько полей вместе для удобства (например, LocalDateTime, или условной Point в графическом движке), наличие идентичности, отличной от совокупности значений, не имеет большого смысла.

На практике идентичность у объектов Java существует из-за того, что под них выделяется память в куче и, соответственно, у них есть уникальный адрес. Отсутствие такой идентичности позволяет генерировать более разумную реализацию оператора ==, а также делать то, что в JEP называется "heap flattening": изменение представление объекта, ссылки на который вместо хранения адреса выделенной памяти хранят значения полей объекта.

Всё это звучит хорошо, но, к сожалению, данная идея страдает от существующих элементов дизайна Java.

Первая — это повальная нуллабельность. Даже value-классы должны иметь возможность быть null, и это означает, что даже для сжатого представления один бит в ссылке должен отводиться под null-флаг. Как пишут сами авторы, массив из Integer, например, может хранить значения прямо в ссылках, но так как численные значения Integer занимают 32 бита и ещё один бит должен отводиться под null-флаг, на практике значения элементов массива будут занимать минимум по 64 бита. Это всё ещё выигрыш по сравнению с тем, что есть сейчас, поскольку это позволяет избежать индирекции на указателях и выделения 64 бита на заголовок каждого объекта в куче, но это всё ещё расточительно. Авторы явно признают эту проблему, и в разделе про дальнейшую работу есть ссылка на Null-restricted value class types JEP, но это пока лишь черновик.

Вторая проблема (которая, справедливости ради, была неочевидна индустрии на момент создания Java) — это отсутствие отслеживания алиасинга/перекрытия ссылок. В JEP авторы пишут:

Heap flattening must maintain the integrity of data. A flattened reference must always be read and written atomically, or it could become corrupted. On common platforms, this limits the size of most flattened references to no more than 64 bits.

Иными словами, выгоды от избегания аллокаций коснуться только очень маленьких объектов — особенно с учётом обязательного null-флага и паддинга под него. Но тут вообще стоит задать вопрос: зачем в принципе стоит требование атомарности обновлений ссылок? Атомарность нужна для того, чтобы избежать разрыва значений при одновременных обновлениях. Соответственно, если одновременных доступов нет, атомарность не требуется! Если бы в Java был механизм, который позволяет удостоверять, что доступ к значению уникален и остаётся уникальным в течение всего времени, пока значение остаётся достижимым (по крайней мере, для записи — многопоточное чтение безопасно и без атомарных операций), можно было бы использовать неатомарные операции для обновлений и избежать таким образом ограничений на размеры value-объектов. Можно считать это ещё одним примером к Fixing the next 10000 aliasing bugs, где инвариантом выступает целостность данных, и плюсом в копилку преимуществ отслеживания алиасинга для различных языков программирования.