4 ms·
/application only sees the most recent available version of the runtime environment that it can run against/ Please, never implement something like this. It's
by lallysingh 18y ago
/application only sees the most recent available version of the runtime environment that it can run against/
Please, never implement something like this. It's hard enough to validate an app against one set of software versions. I can't think of a single time when implying forward compatibility worked right. DLL Hell on windows, and any time your libraries got upgraded while in the middle of a dev cycle in maven, just makes things hurt.
Just let the application's metadata (e.g. jar manifest) indicate what it wants, and give it exactly that. If we want efficiency, we'll delta-encode different versions against each other. When automated testing is implemented widely enough, and well enough, for us to trust forward compatibility without human intervention, then we can go down that route.
- stcredzero 18y agoActually, what you just said is exactly what I'm thinking about. There's no need to depend on forward compatibility, and you would be able to set metadata like "Requires exactly XX.YY.ZZ" Not all applets will be as stringent as that. Also note that each applet is sandboxed with whatever version of the JRE the system it decides it needs. This gets you out of "DLL Hell." If the metadata is specified correctly, it will be as if the system were custom configured just for the applet. (Actually, there could be multiple applets, and they'd all think the world were made just for them!)