"Mechanicznie generowane" pliki źródłowe java w kodzie źródłowym Java

Question

Podczas przeglądania kodu źródłowego Java, znalazłem kilka nietypowych plików, głównie związanych z ByteBuffer s w pakiecie java.nio, które miały bardzo niechlujny kod źródłowy i zostały oznaczone etykietą This file was mechanically generated: Do not edit!.

Pliki te zawierały również duże porcje pustych linii (niektóre nawet w środku javadocs (!!?)), Prawdopodobnie w celu uniemożliwienia zmiany numerów linii. Widziałem także kilka dekompilatorów java, takich jak procyon-decompiler, które mają opcję zachowania numerów linii, ale wątpię, aby tak było, ponieważ umieszczanie pustych wierszy przed ostatecznym wyróżnieniem niczego nie zmienia.

Oto kilka z tych plików (nie mogłem znaleźć żadnych linków do nich w Internecie i nie piszę ich, ponieważ nie chcę łamać żadnych praw autorskich, ale można je znaleźć w folderze src.zip korzeń folderu instalacyjnego JDK):

• java.nio.ByteBuffer
• java.nio.DirectByteBufferR
• java.nio.Bits
• java.nio.BufferOverflowException

byłbym ciekaw:

• Które narzędzie generowane te pliki?
• Dlaczego narzędzie zachowuje numery linii tak samo? Czy to ułatwia debagowanie (stacktraces)?
• Po co używać narzędzia do ich generowania, podczas gdy wszystkie inne klasy są programowane przez ludzi?
• Dlaczego narzędzie wstawiało puste linie losowo w nawiasach, przed ostatecznym wyróżnieniem, czy nawet w javadocs?

Answer 1

pewnie nie może odpowiedzieć na wszystkie pytania, ale niektóre tła jest:

W Makefile w http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/make/java/nio/Makefile, są one generowanie różnych plików źródłowych Java z tego samego pliku szablonu przez jakiś preprocesor:

... 
$(BUF_GEN)/CharBuffer.java: $(X_BUF_TEMPLATE) $(GEN_BUFFER_SH) 
    $(prep-target) 
    @$(RM) $@.temp 
    TYPE=char SRC=$< DST=$@.temp $(GEN_BUFFER_CMD) 
    $(MV) $@.temp $@ 
$(BUF_GEN)/ShortBuffer.java: $(X_BUF_TEMPLATE) $(GEN_BUFFER_SH) 
    $(prep-target) 
    @$(RM) $@.temp 
    TYPE=short SRC=$< DST=$@.temp $(GEN_BUFFER_CMD) 
    $(MV) $@.temp $@ 
... 

$(X_BUF_TEMPLATE) dotyczy X-Buffer.java.template, który jest źródłem wpisywanych bufory jak CharBuffer, ShortBuffer i jeszcze więcej.

Uwaga: Adresy URL mogą ulec zmianie w przyszłości. Przepraszamy również za odniesienie do Javy 7 - w języku Java 8 zmodyfikowali system kompilacji, nie znalazłem do tej pory odpowiednich plików Makefile.

Które narzędzie wygenerowało te pliki?

GEN_BUFFER_SH/GEN_BUFFER_CMD wreszcie odnosi się do genBuffer.sh, więc skrypt, który tworzy te pliki jest http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/make/java/nio/genBuffer.sh.

Po co używać narzędzia do ich generowania, podczas gdy wszystkie inne klasy są programowane przez ludzi?

nie mam odpowiedzi autorytatywny dla tego konkretnego przypadku, ale zwykle używasz narzędzia generowania kodu

• jeśli chcesz stworzyć wiele podobnych klas/metod, które różnią się tylko w niektóre szczegóły, ale które są na tyle subtelne, że nie można używać ustalonych mechanizmów, takich jak generyczne parametry lub metody (prawdopodobnie w tym przypadku, ponieważ bufory są generowane dla typów pierwotnych, których nie można używać z genericami)
• jeśli potrzebujesz tworzyć złożone algorytmy z dużo prostszej reprezentacji (jak generowanie parsera s z gramatyki).

Dlaczego narzędzie zachować numery linii są takie same? Czy to ułatwia debagowanie (stacktraces)?

Zgaduję: tak, jego zachować numery linii w śledzić stos, tak aby pasowały do ​​plików szablonu. Inne narzędzia, takie jak preprocesor C, działają podobnie.