Binary datafile and object creation according to binary tag ?

[loicus]

Dear all,

I am new in the world of Java, so apologies my ignorance.

I've developped a c++ code for scientific visualization (with opengl). My goal would be to convert this soft from C++ to java, because I am tired to maintain it on 3 different operating systems (Windows, Linux and MacOS). However, before trying to convert such a complex program, I would like to make sure it can be converted with no dommages for the current users.

The heart of the code is the reading of a (custom) binary file containing all the objects to be displayed in a very compact format (that I don't want to describe here). But the main thing is that while reading this binary file, I am creating objects from different class (depending on the first byfe of the chunks of data that I am reading), all these objects inherits from a common base class.
In order to initialize the objects using the "right" class, is to do a switch of the first byte and depending on the value of that byte, I initialize my object using the constructor of the right class.
What I would like to know is:
1) can I use a similar strategy in java?
2) is there a better strategy that I could use ?
--> typically I would like to have a code that find itself which constructor/object to use. That would avoid me to systematically have to add a new entry inside my "switch". At the end, I'd like to have these class as pluggins and to allow the users to define a new type of object (a new class) without having to change any part of the software code except for their simple pluggin.

Any suggestion for a way to do this properly?

Thanks in advance for your help,
Best regards,
Loic

[copeg]

Should I understand correctly, there are probably several ways to accomplish this. One way to consider is to create a factory class - from the main perspective of the program it can pass the byte value to the factory and get the newly created object in return. From the plugin perspective, this factory class can read the plugins at runtime and see which is available. Depending upon how these classes are instantiated, this factory class could have a simple HashMap, keyed with the byte and valued to a) an interface whose definition returns a new object of said class or b) a Class object which can be used to instantiate the new class via reflection - this avoids the use of a always extending switch statement and is much more dynamic when it comes to loading things dynamically at runtime.

[loicus]

very interesting strategy...
just a question... how the factory can know which are the pluggins to load? and how to actually load them?
can you point me to some documentation? or give me some keyword to google for?

Thanks,
Loic

[copeg]

very interesting strategy...
just a question... how the factory can know which are the pluggins to load? and how to actually load them?
can you point me to some documentation? or give me some keyword to google for?

Thanks,
Loic

Its all really dependent upon a lot of factors - the above is just one strategy, and it can get a lot more complex.

How I have implemented a plugin architecture in the past, is to have a plugin folder in the same directory as as the main jar...the plugin folder is read at startup, all classes added to the classpath, and the corresponding Class object (see link below) representing the class stored in memory. When a class is needed, it is instantiated using the newInstance() method (this would all be encapsulated within a Factory class). The requirement here is that all plugin classes must extend a Plugin class (or implements a Plugin interface), so it can then be cast to the appropriate type and the methods which are needed abide by a given contract (aka they must implement a given number of methods that are required by the application)

Class (Java Platform SE 6)
Trail: The Reflection API (The Java™ Tutorials)

If you google terms like "java load jar class at runtime reflection" you might find some code snippets and such to help you decide if this is the route you wish to pursue.

[loicus]

thank you!