5 ms·

OSGi and Java Modules would like a word. Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don'

OSGi and Java Modules would like a word. Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don't tell me Java isn't popular... It may be the new COBOL, but it's still mainstream.)

lemmsjid 3y ago
Good show for mentioning that. If it becomes commonplace for popular runtimes and languages to be able to load modules and their dependencies at that level, then a lot of arguments for service encapsulation go away. I think in these discussions, a lot of times people are taking past one another. If I start putting a JRE-targeted application together, I know I can eventually reach for isolated modules if I follow good internal practices, whereas if I'm in Python land it's pretty unattainable.
- smaudet 3y ago
  AWS Lambdas and OSGI invocations are the same thing! (Except one costs you money and one doesn't, guess which one is easier to use).
lmm 3y ago
> OSGi and Java Modules would like a word. OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.
- pjmlp 3y ago
  Java modules are doing alright since Java 9, are the foundation for Java's linker and code stripping on AOT, while Eclipse keeps using OSGi just fine.
  - slowmovintarget 3y ago
    That's right. OSGi predated the Java Module system, and in many cases, informed its design. I think it's unfortunate that when they were including the Module system into Java, they didn't just import OSGi whole. OSGi has an in-VM service registry which allows late binding of "services" by interface. This means you can do a lot of sophisticated mixing and matching of capabilities with OSGi, including the ability to load and use incompatible versions of the same library (if need be) in different parts of your code. More than a decade ago, I built an app server system that used an OSGi base for server-side products and agent systems. I even had a flavor of JBoss running on OSGi (with dramatically faster start up times) before JBoss went OSGi on its own. But now my teams do their work in Node. Isolation is by process, hopefully, maybe, and we're right smack back in version hell.
    - pjmlp 3y ago
      So many "modern" things in cloud are just relearning Java application servers (and .NET) by people that never used them.
  - lmm 3y ago
    > Java modules are doing alright since Java 9 Can you actually use them to use two different versions of library C in the same application yet though? > Eclipse keeps using OSGi just fine Wasn't the impression I had the last time I tried to fix a bug in an eclipse plugin that touched on the OSGi parts. The codebase felt like a ghost town and I couldn't find any documentation for how it all worked or anyone who knew about it.
    - davidalayachew 3y ago
      > Can you actually use them to use two different versions of library C in the same application yet though? Nope, this is functionality that Java (and thus, the module system) does not (yet) provide.
- davidalayachew 3y ago
  > Java Modules is the one that can't actually provide that functionality yet, right? You are correct. As of now, Java Modules have no way to disambiguate versions of the same dependency. This is intentional and by design. As far as Java is concerned, each class is uniquely identified by ModuleName.PackageName.ClassName. So, if there are 2 versions of the same class that have the same identifier, Java will give you an error at compile/link/run-time. And if you try to be clever and slap a number at the end of the module name (in hopes of side-stepping this), Java will throw a warning at you, saying that you are likely trying to misuse modules by trying to use them to do dependency management.
smaudet 3y ago
To be fair the problem is that its not baked into the language. If you have to do X,Y,Z to get A done, then you'll do X,Y,Z. If your language gives you a shortcut and now you can get away with X,Y then you'll drop Z. And even if your language doesn't give you those shortcuts, if Cool Language lets you do just X or X,Y, you'll naturally want to use Cool Language. So, its a losing game... KISS is great when applied correctly, but you have to be able to know the level of complexity you'll actually need for the problem at hand, and it is so so very easy to over or under engineer something...
marwis 3y ago
Your dependencies might be tied to different JVM versions. Less likely but happened few times, especially during 8 to 9+ transition. You would've been stuck with your entire system on Java 8 for ages. Also JNI won't be isolated which occasionally might be a factor (more likely for stability). On the other hand one could make colocated multi-process services to work around this while avoiding all the other complexities of microservices.
davidalayachew 3y ago
> OSGi and Java Modules would like a word. Hold on - the way you are phrasing this implies that Java Modules allow you to solve the version problem mentioned above. As in, your comment implies that Java Modules have a concept of version, and thus, allow you to pick the correct version of a dependency when defining relationships. Java Modules explicitly DO NOT have that ability. In fact, the creators of modules went out of their way to discourage the idea of using modules this way. They literally introduced a warning that flags your module if you add a number at the end of it - specifically so that they can discourage the concept of introducing versions into the module system. The way Java Modules (and Java Classpath before it) works is like this - if you have a module ABC, then that is the only version of ABC as far as Java is concerned. The correct version should be decided upon and provided, but once you hand that version over to Java and press compile/link/run/etc, the concept of version is not existent anymore, as far as Java is concerned. To better explain this, every Java class has a unique identifier -- the module name + the package name + the class name. That's it. So, if I have version 1 of ModuleName.PackageName.ABC and version 2 of ModuleName.PackageName.ABC, there is no way for Java to disambiguate them, and thus, will throw a compilation/linking/runtime error, saying that you have 2 versions of ABC. And to further expand on the warning point above, some clever developers tried to work around this by putting the version number in the name somehow (for example, module name = ModuleName1). To firmly discourage this behaviour, the Java developers who made modules released the abovementioned warning, so that this problem could be nipped in the bud. To summarize, dependency versioning is a problem that Java (currently) does not attempt to solve. It's considered an extra-linguistic concern that is left to the ecosystem to solve (which you should interpret it to mean, they're letting Maven/Gradle/etc deal with this problem (for now)). Finally, a few members of the Java team are giving some thought to maybe dealing with this problem in the language, maybe with a build tool. There is absolutely 0 confirmation that this will even be given serious effort, let alone released as a feature/tool. But the problem is definitely being considered by some members of the Java Team. In fact, a user on this site (pron) may be able to give some helpful context on this. This is my first comment on this site, and I don't know how to use it, so someone else can try and link him.

lemmsjid 3y ago

Good show for mentioning that. If it becomes commonplace for popular runtimes and languages to be able to load modules and their dependencies at that level, then a lot of arguments for service encapsulation go away. I think in these discussions, a lot of times people are taking past one another. If I start putting a JRE-targeted application together, I know I can eventually reach for isolated modules if I follow good internal practices, whereas if I'm in Python land it's pretty unattainable.

smaudet 3y ago
AWS Lambdas and OSGI invocations are the same thing! (Except one costs you money and one doesn't, guess which one is easier to use).

lmm 3y ago

> OSGi and Java Modules would like a word. OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.

pjmlp 3y ago
Java modules are doing alright since Java 9, are the foundation for Java's linker and code stripping on AOT, while Eclipse keeps using OSGi just fine.
- slowmovintarget 3y ago
  That's right. OSGi predated the Java Module system, and in many cases, informed its design. I think it's unfortunate that when they were including the Module system into Java, they didn't just import OSGi whole. OSGi has an in-VM service registry which allows late binding of "services" by interface. This means you can do a lot of sophisticated mixing and matching of capabilities with OSGi, including the ability to load and use incompatible versions of the same library (if need be) in different parts of your code. More than a decade ago, I built an app server system that used an OSGi base for server-side products and agent systems. I even had a flavor of JBoss running on OSGi (with dramatically faster start up times) before JBoss went OSGi on its own. But now my teams do their work in Node. Isolation is by process, hopefully, maybe, and we're right smack back in version hell.
  - pjmlp 3y ago
    So many "modern" things in cloud are just relearning Java application servers (and .NET) by people that never used them.
- lmm 3y ago
  > Java modules are doing alright since Java 9 Can you actually use them to use two different versions of library C in the same application yet though? > Eclipse keeps using OSGi just fine Wasn't the impression I had the last time I tried to fix a bug in an eclipse plugin that touched on the OSGi parts. The codebase felt like a ghost town and I couldn't find any documentation for how it all worked or anyone who knew about it.
  - davidalayachew 3y ago
    > Can you actually use them to use two different versions of library C in the same application yet though? Nope, this is functionality that Java (and thus, the module system) does not (yet) provide.
davidalayachew 3y ago
> Java Modules is the one that can't actually provide that functionality yet, right? You are correct. As of now, Java Modules have no way to disambiguate versions of the same dependency. This is intentional and by design. As far as Java is concerned, each class is uniquely identified by ModuleName.PackageName.ClassName. So, if there are 2 versions of the same class that have the same identifier, Java will give you an error at compile/link/run-time. And if you try to be clever and slap a number at the end of the module name (in hopes of side-stepping this), Java will throw a warning at you, saying that you are likely trying to misuse modules by trying to use them to do dependency management.

smaudet 3y ago

To be fair the problem is that its not baked into the language. If you have to do X,Y,Z to get A done, then you'll do X,Y,Z. If your language gives you a shortcut and now you can get away with X,Y then you'll drop Z. And even if your language doesn't give you those shortcuts, if Cool Language lets you do just X or X,Y, you'll naturally want to use Cool Language. So, its a losing game... KISS is great when applied correctly, but you have to be able to know the level of complexity you'll actually need for the problem at hand, and it is so so very easy to over or under engineer something...

marwis 3y ago

Your dependencies might be tied to different JVM versions. Less likely but happened few times, especially during 8 to 9+ transition. You would've been stuck with your entire system on Java 8 for ages. Also JNI won't be isolated which occasionally might be a factor (more likely for stability). On the other hand one could make colocated multi-process services to work around this while avoiding all the other complexities of microservices.

davidalayachew 3y ago

> OSGi and Java Modules would like a word. Hold on - the way you are phrasing this implies that Java Modules allow you to solve the version problem mentioned above. As in, your comment implies that Java Modules have a concept of version, and thus, allow you to pick the correct version of a dependency when defining relationships. Java Modules explicitly DO NOT have that ability. In fact, the creators of modules went out of their way to discourage the idea of using modules this way. They literally introduced a warning that flags your module if you add a number at the end of it - specifically so that they can discourage the concept of introducing versions into the module system. The way Java Modules (and Java Classpath before it) works is like this - if you have a module ABC, then that is the only version of ABC as far as Java is concerned. The correct version should be decided upon and provided, but once you hand that version over to Java and press compile/link/run/etc, the concept of version is not existent anymore, as far as Java is concerned. To better explain this, every Java class has a unique identifier -- the module name + the package name + the class name. That's it. So, if I have version 1 of ModuleName.PackageName.ABC and version 2 of ModuleName.PackageName.ABC, there is no way for Java to disambiguate them, and thus, will throw a compilation/linking/runtime error, saying that you have 2 versions of ABC. And to further expand on the warning point above, some clever developers tried to work around this by putting the version number in the name somehow (for example, module name = ModuleName1). To firmly discourage this behaviour, the Java developers who made modules released the abovementioned warning, so that this problem could be nipped in the bud. To summarize, dependency versioning is a problem that Java (currently) does not attempt to solve. It's considered an extra-linguistic concern that is left to the ecosystem to solve (which you should interpret it to mean, they're letting Maven/Gradle/etc deal with this problem (for now)). Finally, a few members of the Java team are giving some thought to maybe dealing with this problem in the language, maybe with a build tool. There is absolutely 0 confirmation that this will even be given serious effort, let alone released as a feature/tool. But the problem is definitely being considered by some members of the Java Team. In fact, a user on this site (pron) may be able to give some helpful context on this. This is my first comment on this site, and I don't know how to use it, so someone else can try and link him.