Hi! Responses inline.
On 2016-08-01T00:08:11 +0100 Neil Bartlett <njbartl...@gmail.com> wrote: > > Be aware that this level of sandboxing will require you to enable Java 2 > Security, which adds a performance overhead to any application. Since this is > a game, you might not want to pay that penalty. Why do you need this… what’s > the worst that could happen? The overhead in JDK 9 seems to be roughly 4-5%: https://www.youtube.com/watch?v=8W_8Vp6IVE0#t=38m15s I think I can probably live with that (I'm more likely to be GPU and I/O bound than I am CPU-bound). The reason for sandboxing is really the same reason for sandboxing anywhere: People running the game will be running third party modifications that are likely totally untrustworthy. The worst that can happen is that someone slips some hostile code into a modification that installs malware, trashes the user's files, etc. I'm not sure anyone has demonstrated a JVM sandbox escape that doesn't require some level of elevated privileges (such as overriding serialization, accessing private members via reflection, loading native code, or subverting access checks), so I feel like enabling security with an empty set of permissions is the right thing to do. > It’s “normal" to deliver your whole application as bundles. What’s sauce for > the goose is sauce for the gander. Of course you can write your application > outside OSGi and only use OSGi for the “external plugins”, but why would you > do this? At this point, I'm not sure why I would or why I wouldn't. I guess it comes down to how much of a pain OSGi turns out to be to develop against. It has a good reputation, so I'm optimistic. I suspect the idea to use OSGi only for the plugins is rooted in the idea that if OSGi turns out to be bad, I've not tied the entire application to it and can simply replace the parts that use it. > Also you don’t really need to interact with the OSGi APIs, either in the core > application or the plugins. You will need to touch OSGi APIs in management or > “plumbing” code, e.g. where you need to download, install or update plugins… > but aside from that, you should avoid them as much as possible. Use the > Declarative Services annotations to write your code as Components with > injected dependencies. Right. I think the service APIs were the main issue so if they can be avoided via annotations, then that seems good. > > Is there a common way to engineer > > libraries such that they can use if available but not actually require > > OSGi services to work? > > Yes. If you write Components with Declarative Services, they only depend on > the annotation library at build time and will still be compatible with a > non-OSGi runtime. You can hide dynamics from them by using the static policy > for references. > I've not heard of the "static policy for references". Is there something I should be looking at specifically? M
pgpIVXT6drBq0.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
