A versus comparison between JMX and reflection makes little sense, because they're both very different technologies.
The only way in which reflection relates to JMX is that both the JMX Server and JMX clients can make use of reflection, for instance to publish an MBean's methods (in case of the JMX Server).
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
jacob deiter wrote:Both Technologies Intention is accesing resource at Run-time??.
Can I Say JMX use Reflection to modify any classes at run time??
Regardless, your original question was "when to use one over [the] other"? These two APIs do different things -- there is no choosing one or the other. You use the API that you need, which means that you can use both, if you need both.
JMX popped up 6 years ago and is dying now although it is part of Java 5. I do not see real substance in JMX.
Like Portlet, it is becoming history. You can see how a nice simple Java API has been messed up through all kind of
"Knowing is not enough, you must apply... Willing is not enough, you must do."
Todd Jain wrote:JMX popped up 6 years ago and is dying now although it is part of Java 5.
JMX has been around for more than 6 years. In fact, JMX has been included in all the application servers -- Tomcat, Weblogic, JBoss, Websphere -- as far back as 10 years (although I may wrong on the accuracy here). And with the exception of Tomcat (which I think has less than 100 MBeans), these application servers have been highly instrumented via JMX (Some with more than 300 MBeans that monitor and manage various parts of the system).
[EDIT: In thinking about it more, I think 10 years is probably too high. Its likely a bit less.]
Todd Jain wrote:Like Portlet, it is becoming history. You can see how a nice simple Java API has been messed up through all kind of "elegant" frameworks.
Just because an API is not used as much doesn't mean that it is becoming history. Monitoring and management is needed -- even though most application are not really that concerned with it. In fact, you can make the same argument about JMS, JTA, JDBC, JNDI, etc. These are needed APIs -- and like JMX, there isn't anything coming down the pike that is replacing it.
Todd Jain wrote:How does Java do management and monitoring before JMX?
How did you access a database before JDBC? How did you get to the messaging system before JMS? etc. Don't think of JMX as just a service -- it can be thought of as a standard.
With JMX, instead of having yet another API, companies simply choose JMX, and release a bunch of MBeans. Now, you can argue that a bunch of MBeans is yet another API, but there is a standard to introspect an MBean, a standard to handle notifications. Properties. etc. And there are third party products that will attach to any mbean server, and tell you what is there -- allowing you to monitor, call methods of, do analysis, workup fancy charts, etc., of any MBean.