I have an XML file that has certain properties and mappings defined in it. These properties change very rarely. I don't want to reload and evaluate the properties/mappings every time I call use my jar file. Is there any way I can pre-compile my XML file into an object, so that the XML values get stored in the object? Whenever I change the XML file, if ever, I just need to recompile it once.
+2
A:
After you've read your XML data into an object you could write it to a file using Serialization and check next time, before you load your XML source whether it has been changed (by comparing their timestamps). In cases the XML source hasn't changed you could simply restore the configuration object by de-serialization from the file system.
stacker
2010-10-04 13:51:11
Thanks... this seems to be the best approach once I measure the difference in load times.
Raze2dust
2010-10-04 15:50:40
+2
A:
You could just use a Java file to define these properties and mappings to begin with. No need to mess with XML if you aren't going to take advantage of loading changes to it without recompiling.
ColinD
2010-10-04 13:52:01
You mean create a class with all fields final? But even "final" objects are evaluated at runtime if they are not primitive type right?
Raze2dust
2010-10-04 15:24:52
Yes, that's basically what I mean. String literals will not be "evaluated at runtime" either. That said, if you're worrying about the overhead of creating a map or whatever data structures you need to create for this thing, you're grasping at premature optimization straws. Several times a minute is not a lot, and I feel like you're trying to optimize based on your perception of what will or won't be fast without actually measuring.
ColinD
2010-10-04 15:32:21
Thank for the warning about premature optimization. I do tend to do that quite often... yes, I guess I should measure the times first. Actually I can also use the java.util.Properties framework for this. Is properties better than xml file performance-wise?
Raze2dust
2010-10-04 15:54:47
I can't really comment on the performance of properties vs. XML files. Like I said, I think just storing the data directly in the Java file makes the most sense... you're going to recompile when you change this stuff anyway and you also get to avoid the overhead of reading another file (be that an XML file, properties file, or a file that you serialized the object to). Then there's stuff like type-safe configuration, not having to parse numbers and booleans from strings, etc.
ColinD
2010-10-04 16:05:08
+1
A:
This might not be regarded as the best practice in the world... but if you're wanting to do this outside of any particular framework, you can always just use plain vanilla Java serialization. It's exactly what you're talking about... storing an object to disk (or whatever) and restoring it to memory later. Check out this tutorial if the subject is unfamiliar.
Steve Perkins
2010-10-04 13:52:33
+2
A:
Couple a questions that might help you find an approach are:
- How big is your XML file?
- How long does it take for you to parse it and turn it into an object?
- Is it prohibitive to have this process (load + parse + convert to object) every time your library loads?
Spring does exactly this; you configure the context with XML and when you boot your application it loads, parses and creates the objects according to your configuration. I've been dealing with big XML files in Spring and I can say it's pretty fast - and considering it's only done once, at boot, it's hardly ever a problem.
Spring also has an alternative in which your configuration is actual code, but I'm guessing you want to stick to XML configuration.
Another approach is having a tool to read the XML, convert it to an object and then storing this object to a file using object serialization. You can then load this file as a de-serialized object.
brunodecarvalho
2010-10-04 13:53:35
My xml file is actually quite simple and small.. about 200 nodes including attributes.. should I still look at Spring as an option? (I know nothing about spring as of now)
Raze2dust
2010-10-04 15:21:26
Spring's a whole new (awesome) beast with a totally different purpose altogether; I just mentioned it and how it works as an example ;) If it's such a small file, I would definitely go with loading+parsing+converting-to-object (also know as cached configuration) when your library initializes. Anything else would be overkill for very little performance gain.
brunodecarvalho
2010-10-04 15:46:44
Just make sure you're not parsing the XML file every time you need some info from it!
brunodecarvalho
2010-10-04 15:48:55
Of course.. you mean parse it only for that one instance of the main class and redo the parsing every time the main class is called (20-30 times a minute)? (I am gonna test it out with a profiler now, but just in case you have an idea about the threshold after which serialization is a good idea..)
Raze2dust
2010-10-04 15:57:49
I mean load the file *only once*. As soon as your application boots up, you read the XML, convert it into an Object (e.g. MyAppConfiguration) and from there on - for the lifetime of the your application inside the JVM - you'll always use that MyAppConfiguration instead of reading from the file.
brunodecarvalho
2010-10-04 16:07:02
Unless, of course, your configuration is expected to change during application runtime (is this the case?).
brunodecarvalho
2010-10-04 16:08:58
@brunodecarvalho: I'm under the impression that his application is not a long-running one. Rather, it's bootstrapped and run many times per minute.
ColinD
2010-10-04 16:20:09