My source code contained several dozen calls for the next token of a StringTokenizer object. My first solution used a loading class to load the objects' data from a flat file. This article charts this evolution from runtime reflection to active code generation. Over time, the novelty faded to reveal the complexity and risk of runtime reflection. Initially a dynamic, reflection-based program was far more attractive than a simpler approach. Originally, I intended to demonstrate a solution using reflection during runtime for data marshaling. A solution using reflection, which I'll describe here, often requires less coding, and updates itself when changes are made to the target Java class. Coding a load procedure is often tedious and subject to frequent updates and rewrites due to changes to the source data or the target Java class. Anyone who has dealt with a large system using XML has encountered this problem. To further complicate the situation, the same problem may crosscut the system's breadth. Now, what if the target Java classes for the data change on a weekly basis? A straightforward solution still works, but you must continually maintain the loading procedures to reflect any changes. The problem is simple enough: load data from a file into an object's fields. Data marshaling (pulling data from an outside source and loading it into a Java object) can utilize the benefits of reflection to create a reusable solution.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |