I wanted to create a server that is only responsible for handling some data (something like an account server).
Because it is for a jme game i wanted to use spidermonkey for the communication, so i don’t have to use 2 different networking methods.
From a few experiments it seems that it might be possible to use spidermonkey (jme3-libraries-networking library) nearly completely on its own, but one small line makes the jme3-core library neccesary.
When creating a server (or a client too i think) it registers several classes to the serializer, wich makes sense. But it also registers the Vector3f class from the core library.
So far this seems to be the only connection between the spidermonkey and the core library that makes it neccesary to put the core library in dependancys of the project.
While it makes sense to register the most used classes this one class makes spidermonkey dependant on the core library, wich it otherwise wouldn’t be.
Just wonder if this is intended or not ?
The line i am talking about is in the Serializer.java :
[java]
public abstract class Serializer {
// …
// Registers the classes we already have serializers for.
static {
// …
registerClass(Boolean.class, new BooleanSerializer());
registerClass(Byte.class, new ByteSerializer());
registerClass(Character.class, new CharSerializer());
registerClass(Short.class, new ShortSerializer());
registerClass(Integer.class, new IntSerializer());
registerClass(Long.class, new LongSerializer());
registerClass(Float.class, new FloatSerializer());
registerClass(Double.class, new DoubleSerializer());
registerClass(String.class, new StringSerializer());
registerClass(Vector3f.class, new Vector3Serializer());
The problem is that removing the line potentially breaks every existing spider monkey application. Furthermore, it breaks it in a way that both client and server would have to be updated together for whatever app encountered the problem.
I find it a bit distasteful how the serializer does this but it seemed like a large price to pay to remove it when the only down side is an extra jar on the classpath.
Just wondering if this was realy intended. SpiderMonkey is a real nice library wich could very well be used for non jm3 applications as well to ease networking.
Not sure if this is possible, but maybe can tweak it a bit that it registers the Vector3f class if the class is there and skips it if it is not within the classpath ?
Or have a global variable you can set to “not jm3 enviroment” and then it skips that line ?
Just a thought, maybe you can think up some clever way.
@zarch said:
Try-catch on the registerClass call to catch the class not found exception :)
You’d have to convert it to use the string name of the class instead of hard coding the class reference or Serializer wouldn’t even load.
I actually kind of think Serializer is a big load of crap and every day I’m sorry I kept it when I redid the rest of SpiderMonkey. I could convert it over to do a bunch of reflection for Vector3f but I’m just not sure it’s worth it. It also means that some classpath errors would show up as network errors at runtime.
It should work unless I missed something - you would need the jme3 libraries to build the jar but once the jar has built its a runtime ClassNotFoundException error when it tries to access it.
[java]
// …
// Registers the classes we already have serializers for.
static {
// …
registerClass(Boolean.class, new BooleanSerializer());
registerClass(Byte.class, new ByteSerializer());
registerClass(Character.class, new CharSerializer());
registerClass(Short.class, new ShortSerializer());
registerClass(Integer.class, new IntSerializer());
registerClass(Long.class, new LongSerializer());
registerClass(Float.class, new FloatSerializer());
registerClass(Double.class, new DoubleSerializer());
registerClass(String.class, new StringSerializer());
try {
registerClass(Vector3f.class, new Vector3Serializer());
} catch (ClassNotFoundException ex) {
// log warning here
}
[/java]
Otherwise, the 20 other cases I’ve done similar in my life were way more complicated than needed… using Class.forName(“foo”) instead of hard references.
From the exception callstack if you don’t have the core library in your classpath it seems the serializer class loads, but throws an exception on that line when it tries to find that class. So maybe the class will load with an exception if it is just wraped in a try catch.
Guess the easiest way is to just try it out.
Edit: Otherwise it should allready throw an exception if you first access that class because of the import, shouldn’t it ?
You are welcome to try it. Having the jme-core.jar in my classpath is not such a big deal for me… and I think the total suckiness of Serializer would generally prevent SpiderMonkey from being used outside of JME.
