1) Given how you started I was expecting a sponsor ad at the beginning 2) I like the xckd quote 3) Now that the screen size gets reduced when you say unpopular stuff, u'r a real UA-camr
Second time I look to this video, first time without knowing anything about SPI, second time after writing some SPI and everything is clear now. Will use this approach both to modularize our code and to provide a plugin system in order to give third parties a way to extend our software. Just fat jar will be OK for plugins (shading is not needed) as each plugin will have its own class loader. Thanks again for this video !
When you write a plugin with dependencies and decide to package it as a fat jar (or a directory of jars), I guess that the Plugin interface must not be included in the packaging, we should use a "provided" scope for this dependency ?
I work on a team that (among others) builds Smithy tooling for our org, so we deal with Smithy validators regularly (as a user, knowing how they get loaded can also be useful for troubleshooting IDE setup or whatnot). I imagine you could use SPI to e.g. allow users of an educational website to upload additional exercise packs, but there are non-negligible security concerns in allowing arbitrary byte code to be uploaded for execution. Still, for desktop/CLI apps, plugins distributed by trusted authorities this might be suitable (let's say you're Adobe and some of your partners provide plugins for your app). Scala compiler plugins work in a similar way, although it's not actually SPI - there's an xml/properties file (Scala 2/Scala 3) at a standard location with the FQN of the plugin class.
Reflection is good and bad is the same way, good to be dynamic and horrible in terms of performance perspective, for who understand the Proxy Pattern knows that is the core of Spring. BUT I strongly recommend take a look about JIT vs AOT.
I spent a lot of time editing this one so I hope y'all like it 😄
What was your favorite part?
The amount of effects is balanced. So I like it a lot.
1) Given how you started I was expecting a sponsor ad at the beginning
2) I like the xckd quote
3) Now that the screen size gets reduced when you say unpopular stuff, u'r a real UA-camr
@@TonioGela89 ...but before we get to that part, a word from our sponsor, VMWare...
Nice video, really liked it
Second time I look to this video, first time without knowing anything about SPI, second time after writing some SPI and everything is clear now. Will use this approach both to modularize our code and to provide a plugin system in order to give third parties a way to extend our software. Just fat jar will be OK for plugins (shading is not needed) as each plugin will have its own class loader.
Thanks again for this video !
When you write a plugin with dependencies and decide to package it as a fat jar (or a directory of jars), I guess that the Plugin interface must not be included in the packaging, we should use a "provided" scope for this dependency ?
Excelent video. Where do you use this in real-world scenarios?
I work on a team that (among others) builds Smithy tooling for our org, so we deal with Smithy validators regularly (as a user, knowing how they get loaded can also be useful for troubleshooting IDE setup or whatnot).
I imagine you could use SPI to e.g. allow users of an educational website to upload additional exercise packs, but there are non-negligible security concerns in allowing arbitrary byte code to be uploaded for execution. Still, for desktop/CLI apps, plugins distributed by trusted authorities this might be suitable (let's say you're Adobe and some of your partners provide plugins for your app).
Scala compiler plugins work in a similar way, although it's not actually SPI - there's an xml/properties file (Scala 2/Scala 3) at a standard location with the FQN of the plugin class.
Reflection is good and bad is the same way, good to be dynamic and horrible in terms of performance perspective, for who understand the Proxy Pattern knows that is the core of Spring. BUT I strongly recommend take a look about JIT vs AOT.