|
Authored by: Anonymous on Saturday, April 21 2012 @ 11:36 AM EDT |
Just look at the GNU LGPL clause that specify how much
header code is fair
use (the 10 line rule which makes LGPL
useless for some heavily inlined
libraries).
[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Sunday, April 22 2012 @ 02:02 AM EDT |
That's a viable observation, but things are not exactly that way. For example,
if you have a mixed Scala/Java project with mutual dependencies between Scala
and Java source code, then Scala compiler receives both Scala and Java files on
input. It can NOT compile Java code though (typically javac is later called
separately by Makefile, receiving as input Java source code and bytecode
produced by Scala compiler). The trick is - Scala compiler performs just partial
parsing of Java source files, extracting class and method signatures -
basically, the API of the Java part of the project (or third party library).
Notice that with this approach, one could feed Scala compiler with Java files
that contain no implementation code at all; only class/method signatures are
used. And then the resulting program could be used with any implementation of
that Java code, provided that it has compatible (not even necessary same)
class/methods signatures.
Alternatively, Scala compiler could extract the API info of Java based part of
the project (or Java libraries) from already compiled class files (provided you
can get them before compiling Scala code). And Java compiler works exactly the
same way with regard to third party Java libraries (including Java SE standard
API). Bytecode is not text file already, but principle is exactly the same - all
that compiler cares about is the library programming interface/API, while the
actual implementation code is not even parsed from bytecode - for purposes of
compiling it is sufficient to have library classes where all the implementation
code is replaced with do-nothing statements, or stubs returning bogus values.
Then, again, at runtime you could use any implementation or version of the
library, as long as API is compatible.[ Reply to This | Parent | # ]
|
|
|
|
|