jmonkeyengine
jmonkeyengine copied to clipboard
jMonkeyEngine
DesktopAssetManager bad naming
DesktopAssetManager is a misnomer. It’s included in jme3-core and used both on desktop and mobile platforms.
What about renaming it to DefaultAssetManager?
It can't just be renamed. Some apps create their own or have extended it and they would break.
At best, we'd have to deprecate it and have an upgrade path... but given that it's just a naming issue, I wonder if it's worth the trouble.
I thought it might be fine to target it for v3.4 (that lets breaking changes go in?)
Technically it's nice to deprecate things first. Otherwise, what you end up with is just people using 3.3 forever and never upgrading because "it breaks a bunch of stuff and I don't have time to fix it all at once". Nicer if they can deal with some warnings over time.
Plus, this is a "we just don't like the name anymore" issue... which we decided in a few minutes without looking back at the history to make sure it's even correct. Maybe it's a bug that android is using DesktopAssetManager now? I'd have to do a lot more research personally before I was willing to rubber stamp this change because my memory says different things than the reality that I'm being presented.
There is no technical reason to change other than a little confusing for folks diving in deep.
It is also confusing if using in a server application, since it is not a desktop application.
What about renaming it to
DefaultAssetManager?
I think yeah, and another approach may be creating DefaultAssetManager as a common interface at the jme3-core and deprecate the DesktopAssetManager at the jme3-core and migrate it to jme3-desktop and for android, create a new AndroidAssetManager that also extends the DefaultAssetManager, by doing this, we are not going to break anything and we can have android in a separate implementation process so it's easier to target android-only changes and desktop-only changes... What do you think ?
That sounds generally okay, but perhaps more complex than is necessary. Do you anticipate any Android-only changes?
That sounds generally okay, but perhaps more complex than is necessary. Do you anticipate any Android-only changes?
For now i don't, but for later may be, i think there might be changes for the manager in future, i fear there are still parts of the engine that uses reflection and are mandatory on android for example Class.forName("Foo"), Is this accounted as reflection, because internally it's ? if so we need to change the registerLocator() code for android and ..etc, i haven't debugged that DesktopAssetManager on android yet, the debugging logs will be our helpful tool though, it will show a blacklist calls with a denied access, tho everything will work fine, until you try to publish on google play.
it will show a
blacklist calls with a denied access, tho everything will work fine, until you try to publish on google play.
I tested and debugged this today, and fortunately it didn't show up a reflection call problems, i have looked back to android developer docs and it seems i have interpreted somethings wrong, sorry, it's my fault, you can continue your discussion here or on forums, i have no anticipated android changes for this.