M
marcus
We all know that "Compile once, run anywhere" is a fantasy, because
there are too many cases where the version of the JVM cannot be known at
compile time. I was considering somewhat of a paradigm shift in the
concept of JVM versioning vs compiler versioning, and would like to know
if this has been discussed before.
Consider a language addition, such as Calander object or Event
Listeners, which caused pretty major changes between 1.1 and 1.2. I am
imagining it would be possible to include a compiler directive, similar
to "-target 1.1.8" which would cause the compiler to include alternative
code to perform the additional functions under older JVM's, and use a
run-time test to determine which code to use. In this way many
additional language features would be accessable, albiet in a possibly
less efficient form, to an older JVM. I am imagining a sort of
compiler-generated package of "1.1.8 extensions" which would contain the
additional layer of indirection.
a) Not every feature could be made accessably this way -- what ratio
could and what are the benefits?
b) Alternative code could be written once and sanitized, rather than
version-creep work-arounds being hacked out under deadlines by armies of
coders around the world.
c) Could scope and security issues be reasonably addressed without
rebuilding the entire package hierarchy?
d) With modern distribution technologies code bloat is not so worrisome
to me as OS bloat. The code might be bigger, but hardly slower except
in the case where the JVM would be slower anyway.
Thoughts?
there are too many cases where the version of the JVM cannot be known at
compile time. I was considering somewhat of a paradigm shift in the
concept of JVM versioning vs compiler versioning, and would like to know
if this has been discussed before.
Consider a language addition, such as Calander object or Event
Listeners, which caused pretty major changes between 1.1 and 1.2. I am
imagining it would be possible to include a compiler directive, similar
to "-target 1.1.8" which would cause the compiler to include alternative
code to perform the additional functions under older JVM's, and use a
run-time test to determine which code to use. In this way many
additional language features would be accessable, albiet in a possibly
less efficient form, to an older JVM. I am imagining a sort of
compiler-generated package of "1.1.8 extensions" which would contain the
additional layer of indirection.
a) Not every feature could be made accessably this way -- what ratio
could and what are the benefits?
b) Alternative code could be written once and sanitized, rather than
version-creep work-arounds being hacked out under deadlines by armies of
coders around the world.
c) Could scope and security issues be reasonably addressed without
rebuilding the entire package hierarchy?
d) With modern distribution technologies code bloat is not so worrisome
to me as OS bloat. The code might be bigger, but hardly slower except
in the case where the JVM would be slower anyway.
Thoughts?