Right now the com.jme package has a dependancy on two things that would be nice to remove:
- com.jmex.awt: We have a method for creating a canvas via the DisplaySystem. It would be nice to get rid of the necessity to bundle jmex-awt.jar with jme regardless of whether you are using awt stuff. Locally I've changed the DisplaySystem to not have getCurrentCanvas (instead putting an Object field in RenderContext for the contextHolder key) and createCanvas now returns an Object. This means that you have to cast to a Canvas when you use it. Thoughts?
- sun.misc.Service: This is an internal, non standard class. The functionality is moved to ServiceLoader in Java1.6, so I'd vote for switching to that, but it would mean tying ourselves to java 6. Thoughts?
1. com.jmex.awt: We have a method for creating a canvas via the DisplaySystem. It would be nice to get rid of the necessity to bundle jmex-awt.jar with jme regardless of whether you are using awt stuff.
As far as I remember, jme-awt.jar is not needed if not using canvas. If you're trying to call createCanvas without jme-awt.jar it just throws an exception saying it can't find some class/method.
Locally I've changed the DisplaySystem to not have getCurrentCanvas (instead putting an Object field in RenderContext for the contextHolder key) and createCanvas now returns an Object. This means that you have to cast to a Canvas when you use it. Thoughts?
But Canvas is an AWT class? This means it's included in the JRE so there's no need to avoid it. You only have to avoid using stuff in the jme-awt.jar.
2. sun.misc.Service: This is an internal, non standard class. The functionality is moved to ServiceLoader in Java1.6, so I'd vote for switching to that, but it would mean tying ourselves to java 6. Thoughts?
I don't see much reason in doing that.. I think any dependencies on those sun classes should be removed, as that places the requirement that only Sun's JRE could be used(?), so you can't compile to native code with GCC for example. If you want to use alternative implementations of the displaysystem/renderer you could pass those to the constructor, e.g: DisplaySystem.setImplementor(LWJGLDisplaySystem.class).
The reason I did not return a Canvas was because it was awt and there has in the past been a push to not tie the core to awt (although there is plenty still there.) This was for folks who wanted to use Java -> exe builders and wanted to leave out the bulk that is awt. I'll just go ahead and make it Canvas for now.
irt the requirements for the jme-awt jar, if I did not include it in various things like webstart apps, etc. I got problems (class not found) when it instantiated classes that referenced jmex awt classes (even if I was not using those classes.) ymmv I suppose, but it still seems in bad taste to have hard references between com.jme and com.jmex
irt the sun.misc.Service usage, this was proposed/donated a long time ago in the forums. I'm not married to it though. shrug
Momoko_Fan said:
2. sun.misc.Service: ...
... you could pass those to the constructor, e.g: DisplaySystem.setImplementor(LWJGLDisplaySystem.class).
That's not the same. The use case for the service locator is to allow adding a new display system to the classpath and have it loaded automatically. Neither jME nor the application should be required to know the class name. We should ask if someone uses it. If yes, we/he could replace it by a config file and load those file with ClassLoader.getResources...
There was no mention of alternative implementation of the DisplaySystem existing anywhere… Except for that one JOGL binding that wasn't complete. I don't think it's much a problem if somebody is using it, this is jME2 so you have to expect major changes.
we/he could replace it by a config file and load those file with ClassLoader.getResources...
Yes, that's one option to go about.
irt the requirements for the jme-awt jar, if I did not include it in various things like webstart apps, etc. I got problems (class not found) when it instantiated classes that referenced jmex awt classes (even if I was not using those classes.) ymmv I suppose, but it still seems in bad taste to have hard references between com.jme and com.jmex
I just checked the jme-awt jar.. Perhaps it would be possible to seperate it? E.g move the canvas stuff to the main jME jar (and change jmex->jme), then put the jmedesktop and applet stuff in another jar(s).
The reason I did not return a Canvas was because it was awt and there has in the past been a push to not tie the core to awt (although there is plenty still there.) This was for folks who wanted to use Java -> exe builders and wanted to leave out the bulk that is awt. I'll just go ahead and make it Canvas for now.
I see, but if people want to compile to exe they could remove those parts that use AWT, that's why it might be best to concentrate all usage into a few methods in the DisplaySystem and the JMECanvas stuff.