Wanted to get some clarification on JavaCompiler and Reflection

Question

Hello,
I am working on building a modular, dynamic framework for web apps. The idea is highly reflection driven controllers and DAO's (no real news here, everyone does this, I was just giving some background).
One of the pieces I wanted to build was a dynamic search criteria object to pass to the DAO, used to filter collections coming back from the persistence layer. I wanted these to be runtime compiled so they would change with any changes to their corresponding data transfer object(I have written many of these, they are repetitive, and that means that they are a good candidate for a program to write for me). I settled on this because I needed to be able to fill the objects with data, and it seemed like the best way to me(I think an enum could also have worked, but I have not used these much and runtime compilation just sounds so neat).
So I have the service built to dole out the dynamic search criteria objects, and I have them compiling with all dependencies satisfied, and that all looks good.
Then I hit the hitch, a runtime class - MyDynamicSearchCriteriaObject is used in the following manner MyDynamicSearchCriteriaObject.class.getMethods(), causing a serious failure(one that is not caught by Exception), and the program just fails.
So from what I have seen, this is due to the fact that reflection information on the classpath is stored at jvm startup in memory, and any runtime loaded class cannot be reflected on with the standard API (it looks like javassist is built just for this, but I have not fiddled with it much yet). I just wanted to get any thoughts anyone has on this, is my analysis way off base, is this how it works, is there some way to trigger a runtime refresh of the reflection structure (I doubt this would ever work due to the different classloaders).
My other question is this, if you cannot reflect on runtime classloaded classes, then they will only ever really be of value if they implement a compile-time-known interface. This would allow for dynamic implementations of a given interface via runtime compilation, but not use of the runtime loaded class by it's own type definition(via reflection).
I am a little new to all of this, this is my first stab at building such a framework, so any thoughts, help, or clarification are greatly appreciated!
Thanks,
Scott

Answer 1

Scott_Taylor wrote:
So I really have one core question here, do you really want to understand, or do you just want to dazzle me with your credentials (which I am not impressed with at all, I find people who flaunt their credentials generally do so because it is all that they have)?
You were obviously attempting to 'educate' me as to the benefits of code generation. That has nothing to do with your problem nor does it have anything to do with me, since obviously I am quite familar with why one would actually use code generation.
I will answer though, one last time.
And I still have no idea what you are talking about.I must be crazy or something, since there is probably nothing in the programming world that you could not understand, right? Generally, when you don't understand you probe with questions so you can understand. Unless you are looking to be dismissive, in which case, why even answer?
First there are many things that I don't understand. And which I freely admit. For example GUIs. And embedded programming. And business domains such as natural gas exploration.
However we are not discussing one of those topics. But rather we are discussing a code generation and, apparently, SQL/data dynamic expression creation. And those are in fact topics that I know a great deal.
Any compilation of that is only going to provide a minimal gain when compared to the database hit itself.I really don't understand this, and it leads me to believe we are not understanding each other. I am not compiling sql, consider this:
Collection<C> list = myNeatDAO.search(Object someDTOSearchCriteria);This searchCriteria object is what I am trying to dynamically compile, again, not for performance in any way, rather to avoid writing code that is 100% based on another class (a class which may change over time). The formation of the query (whether sql or hql or whatever) is handled via reflection on the search criteria and a parameterized class in the DAO subclass's definition:
class MyNeatDAO<SomeDTO> extends AbstractDAOImplementation{}So we compare the classes and form some kind of query in the DAO. This is pretty standard stuff. I think where the wires are crossed is that you are 1)not reading attentively (if you had you would know that I marked this complete many posts ago) and 2) are not understanding the goal of the code.
You got part of it correct in that someone isn't reading carefully and that someone doesn't understand.
Myself I understand your problem several posts ago.
What you failed to understand that you are attempting to create a system that I have already done so. Several times. It never required runtime compilation.
Perhaps I wasn't clear before. Hopefully this will make it clearer.
1. Given a system of DTOs that exist as compiled units (they could even be created at runtime.)
2. A solution can be built which allows for full expression creation for queries based on those DTOs.
3. That solution does NOT require runtime compilation.
4. That solution does NOT require changes for future DTOs changes (which would seem obvious given that it can support DTOs compiled at runtime.)
>
Code generation is dependent on code patterns. That is true whether
one shot or ongoing. Nothing else.
Runtime functionality on the other hand is driven by user requirements.
Code generation is a tool to achieve that and nothing else.I have two thoughts here.
First, if you have a clear, unwavering requirement(or pattern) based purely on some other single class, how does it make sense not to automate that? Why would I want to write what is basically a near copy of the original dto each time? Not only does this increase development time (basically paying a developer to do a job a monkey could do), but it also increases modification time later when the true requirements are either discovered or the original communicated requirements change. If this single class is runtime compiled based on the dto, if you change the dto, the change to the corresponding search criteria class is automatic and perfect. There is no debug time, it just works since you are not writing it and introducing errors. The drawback is that you lose control over that class, which in this case does not create a major problem.
Again you failed to read "attentively". Why do you think that I myself would have been using code generation since before java existed?
Did you not understand that I have in fact been doing it? Or did you not understand that "before java" means that I have been doing it for a long time?
I didn't bother mentioning it before but I also worked on a system which used runtime compilation extensively. Matter of fact one of the expression engines that I created was used in that system. However there was no need for that engine to be compiled at runtime.
My second thought is that code generation is a tool to meet customer requirements, just like anything else in the software world. There are internal and external customers, and their needs must be balanced. The tool is in the box, and I am going to use it as I see fit. If you think this is wrong or off base, please express this in a useful way, I have laid my cards on the table pretty clearly (I think), if you see something glaring, explain what is wrong, don't just spew dismissive one-liners. That only makes me believe that you can't explain what is wrong(I have seen this a lot with programmers, they don't answer in a clear manner because they can't), and that you just want to be condescending, which I find a little sad. Consequently, this leads me to believe that you probably can't back up anything you are saying, and I may miss a very valid point since you never expressed it in any clear manner.
You have written customer requirements that state explicitly that the system must have a SQL/data query system in place that is compiled at runtime?
Unusual requirements. Most requirements would be along the lines of "call center employee must be able to enter customer last name or phone number or both"