Content deleted Content added
No edit summary |
|||
Line 15:
: I appreciate trying to make this article more readable, but with this case I disagree. The ''reason'' is apparently because the JVM spec authors don't know C, or didn't care, or because they follow the code with dozens of pages of clarifying text which then go on to explain why the format is actually not like the pseudo-C code they just presented. This example code is not even remotely close to being correct C code (or even Java code), and trying to present it as such is quite misleading. Most of the "types" are of undefined variable length (C types are always fixed length). No padding bytes are ever introduced (as C frequently does). A definite byte-order is mandated, which C can never indicate. The things which look like C arrays are stored absolutely nothing like real C arrays. Even the indicated "length" of the arrays is completely wrong in the constant_pool case due to the double-slot flaw. In fact, just about everything in the file format is so completely not like C that I wonder what in the world the writers of the specification were thinking. If a reader can't understand a table of simple file offsets and wants to pretend like they can use a C structure then they can read the spec; that's why it's listed in the references. This article is not trying to replace the entire quite-lengthy specification, it is only showing a ''flavor'' of the format. Copying large blocks of poorly-authored text verbatim from the referenced document (which shouldn't be done regardless of quality) and taken out of context (from all the clarifying text that follows) provides no extra value here, and only clutters the article and adds about a dozen ways the reader can be easily misled. - [[User:Dmeranda|Dmeranda]] 14:08, 8 November 2007 (UTC)
== Re structure and representation ==
One thing that isn't mentioned in the structure section, and is a
very convenient thing to know in practice, is the assurance from
JVMS chapter 4 that the concrete representations of various data
types in the class file are exactly the representations consumed
and produced by java.io.DataInputStream and java.io.DataOutputStream,
respectively.--[[Special:Contributions/128.210.4.213|128.210.4.213]] ([[User talk:128.210.4.213|talk]]) 22:47, 3 January 2008 (UTC)
== Re history ==
It might be very useful for the history section to summarize the
differences between class file versions in terms of which new
attributes become mandatory in 46.0, 49.0, and 50.0 (JSR202 JVMS
revised p. 126), and the opcodes to become illegal in 51.0 (p. 166).
I haven't said more because I am not sure how much would be
disclosable under the annoying EULA I had to accept before reading
JSR202, but if others think such a brief summary could be allowed,
I think it would be a valuable addition to the page. Also, footnote
1 on revised p. 96 supplies a relationship between class version
and JDK version for JDK versions 1.2 and onward.--[[Special:Contributions/128.210.4.213|128.210.4.213]] ([[User talk:128.210.4.213|talk]]) 22:47, 3 January 2008 (UTC)
| |||