|Authored by: clemenstimpler on Thursday, May 24 2012 @ 04:49 PM EDT|
|The JVM relies on BSF uncertainty: What a reference is depends on its being|
observed by a lawyer.
[ Reply to This | Parent | # ]
|Authored by: PolR on Thursday, May 24 2012 @ 05:21 PM EDT|
|In patent law there is something called the doctrine of
equivalents. In constructing the term "symbolic reference" courts are not
obligated to follow the literal execution of the instruction. Of course they
could decide the literal execution is the proper one. But they are free to
[ Reply to This | Parent | # ]
|Authored by: Anonymous on Thursday, May 24 2012 @ 08:51 PM EDT|
|See that dead horse? SEE IT? Let's flippin' BEAT IT!|
This is compiler / interpretor level stuff.
Symbolic means as of or like a symbol.
Symbols are textual NAMES from source code, names of classes, interfaces,
functions / methods, variables, etc. The binary location on disk or in memory
of these things is referred to by a name for ease of use. NAMES. Another
common name for "symbolic reference" is "named reference".
The patent is supposed to be clear and concise to an individual ordinarily
skilled in the art of VMs, interpretors and compilers.
The definition given of "symbolic" that excludes numbers and mentions
names is precisely to exclude pointers, table indices, offsets, etc. As THESE DO
NOT REQUIRE RESOLVING.
"Resolving a symbol" to an individual ordinarily skilled in the art
means going into a symbol table and comparing the name you have with a list of
possible names, then getting the relative offset or index.
Once you have an offset or index to the binary location the name represents then
the SYMBOL HAS BEEN RESOLVED, the index or offset itself is a "Numeric
Reference", and is no longer symbolic.
The part that many people are tripping up over is that Oracle patented the wrong
thing, symbolic names in the instructions. They shouldn't have included that
part about being in the instructions, it doesn't flippin matter where the hell a
symbolic reference IS, you must resolve it before using it.
No bytecode or machinecode interpretor stores the actual names in the
instructions, they ALL store a pointer or index to the symbolic reference that
needs to be looked up.
However, all this symbolic crap is pointless. IMHO, Davlik DOES do symbolic
name resolution, and the patent probably meant to cover that particular symbolic
configuration where the bytecode held a numeric reference to the symbolic
reference which would be looked up... but the ignorant lawyer who filed the
patent goofed, so the patent is useless.
Despite that, even if they wouldn't have screwed up, and Davlik's numeric
reference to a symbolic reference was covered, it wouldn't matter at all because
of the requirement that the resolution be dynamically (at run time). The other
claims in the patent make it perfectly clear that they're talking about a
resolution happening while the program is actually running.
It would be furthest from ones mind, as an individual skilled in compilers and
interpretors, that this patent cover any static (non run time) symbolic
Most people arguing over symbolic are ignorant that Oracle's partially right on
this point. They're retroactively trying to fix their patent to cover the
original intended scope of symbolic reference... which IMO, is wrong, but it's
understandable, not completely out in left field like some have suggested.
Now, before you can execute instructions that have symbolic elements (symbolic
references, or placeholders for symbolic references) you need to resolve the
You can either do the name resolution at install time, load time, or during run
time. If you do the resolution any time that the program itself is not being
executed, it's not a dynamic resolution (not at run time). All other resolution
types are called "static" because the reference (numeric or symbolic)
does not change during program execution.
C code with .DLL or .SO code does its symbol resolutions all at once when the
library is loaded, BEFORE any code within the .DLL or .SO is executed. The
patent is over running the .DLL and resolving the symbolic links as you go, so
it wouldn't cover C style "dynamic linking and loading", as some have
suggested it might -- These are NOT prior art IMO, but the multitude of VM
languages and Interpreted languages that use such a technique (Perl (including
interpretors), would be prior art or illustrate that the technique is obvious /
One other thing that people get tripped up over is the fact that after Davlik
has done all the symbol name resolutions, it keeps the symbol names in a big
table inside the data file (but not in the instructions). These are totally
unneeded from an execution perspective, you could delete them and the program
would run just fine (if the programmer new to avoid reflection...)
The reason for the symbolic names being in the file is because the objects'
names can be queried at run time. You can ask an object for a list of its
method names. You can then call a method or instantiate an object by name --
This DOES perform a dynamic symbolic name resolution at run time.
HOWEVER, it DOSE NOT write over any byte code afterward to "optimize"
the next call. It's a one-off method call or object instantiation that gets
looked up each time because the contents of the name (string) may be different
each time that set of compiled instructions is executed -- There's nothing to
The '501 patent is inapplicable. Open a text document and do a search and
replace manually -- That's not simulating a reading of the text and replacing
one meaning with another (what Java's patent is over), instead that's pattern
The sky was so blue, the most beautiful azure I've ever seen.
Now, if you do simulation (understanding) of that sentence and I tell you to
replace any blue with "red" then you get this:
The sky was so red, the most beautiful red I've ever seen.
(this is what Java's '501 patent is over)
But, if you do a pattern match of that sentence and I tell you to replace
"blue" with "red" then you get this:
The sky was so red, the most beautiful azure I've ever seen.
(this is what Davlik does, and it misses ^ azure here)
Bottom line, Oracle is wrong, but most of the statements and arguments here
about the '104 patent are ridiculously ignorant of how it actually works; Saying
things like "Oracle spouting more nonsense" make you out to be a fool
-- Only a fool would make such strong statements about things they've no real
[ Reply to This | Parent | # ]