Java: Is reflection bad for AOP situations?

Question

Imagine the following situation:
1. Consume a 3rd party WSDL, out comes thousands of classes.
2. There's an opportunity to optimize performance by using a custom paralleled implementation.
3. Wsdl class structure has consistent naming convention: [RecordType][CrudAction]
4. Use Java Reflection to create type-less functions taking advantage of naming convention patterns
5. Result would reduce all possible implementations of wsdl class base by a factor of what would otherwise be needed to iterate through all [RecordTypes] and [CrudAction] possibilities. P = A * B becomes P = A + B

I've read several sources that it's bad to use reflection, or that it has a very specific type of problem. Was Java Reflection intended to solve for this type of problem? FWIW, this feels like a hacky aspect-oriented programming solution to help scale interfacing to a large 3rd party class base. The Spring framework is also available, however, this could help lower overhead.

Answer 1

There are two fundamental things about reflection that can make it bad.

• Reflection can break protections like private.
• Reflection can cause performance problems.

These perfectly valid concerns are used by some shops as excuses to swear off ever using reflection. This is wrong. Reflection is a powerful tool that should be used wisely.

For example, a class that has been carefully designed to create immutable objects can be quietly defeated with reflection. This makes reasoning about how the code behaves difficult. When you know there is no reflection used in the code base you can look at only the class to know that it is immutable. Once reflection is on the table you have to read all the code in the code base to know how immutable it is.

You must weigh all that against the benefit you're going to get by using reflection to help you consume this WSDL. Following such rules makes reasoning about the code easier.

My advice: use it narrowly. Create an isolated space to use it where it's walled off from the rest of your code, and forbid its use where you don't have a real good need for it. If someone suspects reflection is causing an object to behave oddly, don't make their effort to find the cause an epic journey through the code base. Make it obvious where the problem is.

As for performance, there are real issues but mostly I've been surprised how fast aspect oriented solutions are. Don't let fear keep you from trying ideas. Get a profiler to tell you where your real problems are.

Of course the real problem of using reflection here is it gives you the power to consume a WSDL so poorly designed that you need these kinds of shenanigans to consume it. But how else are you going to let your foot shoot it self in the foot?

Answer 2

Basically what it comes down to here is that you are asking is it's a good idea to generate a ton of statically defined classes and then use reflection to avoid referencing them in a static way. Assuming there's no other reason you need these class definitions, it's not clear why you would want to generate classes in the first place.

If you want to work with XML using dynamic approaches, there are a number ways to accomplish that in Java. Here are three:

• DOM - Easy to understand. Heavy memory footprint and a little sluggish
• SAX - Very fast and low memory requirements. A little awkward for a lot of Java developers
• Stax - A balance between usability and efficiency.

There's no requirement that you map XML structures to types. And even if you do want to, there's nothing that requires you to make your structures one-to-one with the XML schema. For example, if you want to map a lot of schema-types to a single Java type based on a reliable naming convention and consistent structure, SAX could be a great choice for that.