3 ms·
> You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such
by chrisseaton 4y ago
> You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such as reflection but a lot of defacto standard java tooling like Spring Framework would not be compatible.
But the JVM you build using your statically compilable Java subset can then run the Spring Framework or whatever.
- Macha 4y agoSure, but that subset is only "kind of Java" just like RPython or CPython code is only "kind of Python". It's like calling a C compiler a C++ or Objective-C compiler because C is a subset of those languages.
- chrisseaton 4y ago> Sure, but that subset is only "kind of Java" How restrictive do you think the subset is? It only doesn't support some features you probably never wanted to use anyway, and arbitrary reflection. I maintain 125k lines of Java that conforms to the subset rules, and to be honest I never even think twice about the fact that it's a subset.
- Macha 4y agoIsn't arbitrary reflection how Spring, Hibernate, AspectJ, every JSON library and other common libraries that you may be using directly or indirectly work?
- chrisseaton 4y agoNo they use predictable reflection, not arbitrary reflection. The subset just needs to be told ahead of time which classes you want to be able to interact with reflectively. As I say, it's not an issue for my quite-large application.