why does lwjgl use dynamic class loading to create the os-dependent implementation of the Sys class?
http://svn.sourceforge.net/viewvc/java-game-lib/trunk/LWJGL/src/java/org/lwjgl/Sys.java?revision=2701&view=markup lines 110-135:
110 private static SysImplementation createImplementation() {
111 String class_name;
112 switch (LWJGLUtil.getPlatform()) {
113 case LWJGLUtil.PLATFORM_LINUX:
114 class_name = "org.lwjgl.LinuxSysImplementation";
115 break;
116 case LWJGLUtil.PLATFORM_WINDOWS:
117 class_name = "org.lwjgl.WindowsSysImplementation";
118 break;
119 case LWJGLUtil.PLATFORM_MACOSX:
120 class_name = "org.lwjgl.MacOSXSysImplementation";
121 break;
122 default:
123 throw new IllegalStateException("Unsupported platform");
124 }
125 try {
126 Class impl_class = Class.forName(class_name);
127 return (SysImplementation)impl_class.newInstance();
128 } catch (ClassNotFoundException e) {
129 throw new RuntimeException(e);
130 } catch (IllegalAccessException e) {
131 throw new RuntimeException(e);
132 } catch (InstantiationException e) {
133 throw new RuntimeException(e);
134 }
135 }
this would ease obfuscation of the application and lwjgl. this is afaik the only place where lwjgl uses dynamic class loading.
boing? noone?
I assumed someone else would know what you are asking about ;D
would anyone with cvs access mind to change this to
110 private static SysImplementation createImplementation() {
111 SysImplementation sys;
112 switch (LWJGLUtil.getPlatform()) {
113 case LWJGLUtil.PLATFORM_LINUX:
114 sys = new org.lwjgl.LinuxSysImplementation();
115 break;
116 case LWJGLUtil.PLATFORM_WINDOWS:
117 sys = new org.lwjgl.WindowsSysImplementation();
118 break;
119 case LWJGLUtil.PLATFORM_MACOSX:
120 sys = new org.lwjgl.MacOSXSysImplementation();
121 break;
122 default:
123 throw new IllegalStateException("Unsupported platform");
124 }
125 return sys;
126 }
I'm thinking that there is a reason for the reflection - might be an old leftover tho...
I think it was caused by Cas wanting to exclude certain stuff for a Jet custom build of LWJGL. I guess this is fairly obsolete due to the open sourced JVM and the maturity of alternatives like gcj.
- elias
I've fixed this in SVN now.
- elias