3 ms·

> For many real world applications, you'd need to load classes that isn't known at compile time (e.g., a user supplied database jdbc connector). I'm not famili

> For many real world applications, you'd need to load classes that isn't known at compile time (e.g., a user supplied database jdbc connector). I'm not familiar with some of the dev patterns here, but why not just load all the classes for the databases you want to support, from the top, and compile them all in? Is that not practical?

kjeetgill 8y ago
It just hasn't been a limitation in the jvm so libraries end up depending on those tools. A ton of stuff ends in up doing class loading, bytecode generation, dynamic serialization. The easiest off the top of my head is webapp containers like Tomcat or Jetty. As it runs your load a whole zip file with a full set of jars on the fly afterwards.
chii 8y ago
> just load all the classes for the databases you want to support you cannot distribute some connectors (e.g., the oracle connector or the mysql connector), in the case of jdbc anyway. And it's not always possible to know ahead of time the classes you want to pre-load, if your application is like eclipse with a plugin architecture which can allow users to install custom plugins.