Dear Java Community, For some time we at ZeroTurnaround have been working on decreasing development turnaround time. Our flagship product, JavaRebel, has more or less solved the problem of reloading all changes made to Java code on-the-fly. However, this is not enough. Java frameworks use configuration files, annotations and other methods to configure themselves. This is where JavaRebel loses its effect as configuration is always cached somewhere and usually not reloaded until the application is redeployed. This can be overcome by tighter integration with these frameworks. With the release of JavaRebel 1.1 M1 we finally have full support for annotation reloading. We have also released an open source SDK that can be included in any open source project. The SDK will trigger registered listeners when the classes are reloaded allowing custom handling to occur. The integration is then just a matter of reloading configuration in development mode. Using the annotation reloading and the SDK we have so far succeeded in integrating with Google Guice and Stripes Framework. Now almost all changes made to the applications using those frameworks are reloaded instantly. In addition to that Ignacio Coloma grabbed the SDK almost before its release and integrated the Loom web framework during the weekend. All three integrations took less than a day's work. It is our belief that providing such integration will greatly benefit the whole of the Java community. It is not unlikely that one day JavaRebel-like functionality will make it to the JVM and the users will be able to benefit from the integration without using a third-party product. Until then we invite you to help us define an open API for the class reloading and implement the integration for the framework you like, use or develop. If you are a developer or a user of a Java framework of some sort and you would like to see the on-the-fly reloading in that framework happen you need to step up and make some noise in the community. We will continue investing into integration with frameworks, but we are limited by the frameworks that we know or our clients demand. To facilitate the exchange of ideas and information we have setup a community mailing list and a Google Code project. Both framework developers and users are welcome to join and discuss what can be done to further improve Java development turnaround time. To support this vision we are now giving free JavaRebel licenses to all open source developers. Cheers, ZeroTurnaround Team

If you want more support from open source projects you might want to think about opening up your library. It's a huge PITA to even think about doing stuff with closed-source proprietary technologies when doing day to day work......and it's not going to be long before someone else figures out how to discard classloaders to reload classes and creates an open source alternative.. At least you could position yourselves to take advantage of your current market lead. (somehow? I suck at business stuff)

Had all the frameworks had PROGRAMMATIC CONFIGURATION instead of annotation-hell and xml-hell, JavaRebel life would be much easier. Take a look here: http://www.mentaframework.org/ Also take a look what Martin Fowler said about that back in 2004: http://forum.mentaframework.org/posts/list/160.page Plus: Guice uses PROGRAMMATIC CONFIGURATION for its modules. It uses injections JUST for the marking what property will receive what.

Guice uses PROGRAMMATIC CONFIGURATION for its modules. It uses injections JUST for the marking what property will receive what.

Correction: ... it uses ANNOTATIONS just to mark the properties that will receive a component through injection.

Ummm...Yeah. He also used to program in java back then too. Times have changed my friend...

..Also take a look what Martin Fowler said about that back in 2004:

http://forum.mentaframework.org/posts/list/160.page

Plus:

Guice uses PROGRAMMATIC CONFIGURATION for its modules. It uses injections JUST for the marking what property will receive what.

The problem is not that configuration is made through XML or annotations or plain java code. The problem is when configuration is loaded and cached, without some way of reloading it in runtime. If the configuration in java code is executed once, just to build an internal representation, this is no different from XML configuration. What would make a difference is if the framework had some sort of 'development mode', in which it re-reads the configuration on each request, thus always catching changes. I think Rails does something like this for its classes, and so does Facelets and Velocity with their template files (XML and text files).

I think Rails does something like this for its classes, and so does Facelets and Velocity with their template files (XML and text files).

Mentawai does that since 2005. It uses a different classloader to force a full reload of the ApplicationManager.class on every request. I was very happy for sometime, until I discovered that instanceof does not work when a different classloader was used to load a class. THIS SUCKS! Yes, you heard me correctly. User loaded with classloader 1 is not instanceof of User.class loaded with classloader 2. Something like that... :-)

Mentawai does that since 2005. It uses a different classloader to force a full reload of the ApplicationManager.class on every request. I was very happy for sometime, until I discovered that instanceof does not work when a different classloader was used to load a class.

THIS SUCKS! Yes, you heard me correctly. User loaded with classloader 1 is not instanceof of User.class loaded with classloader 2. Something like that... :-)

If you think this sucks, I really question your understanding of how the Java classloader works (which in turn, makes me question the implementation of Mentawai...). You might want to use more moderate words and try to articulate your objections more carefully. -- Cedric

Had all the frameworks had PROGRAMMATIC CONFIGURATION instead of annotation-hell and xml-hell, JavaRebel life would be much easier.

I don't see how that would make any difference at all. The problem is nothing to do with how the configuration/metadata information is provided. It is to do with the fact that frameworks need to cache that information between requests (or performance will be kaka). "Programmatic" configuration does not solve this problem at all.

"Programmatic" configuration does not solve this problem at all.

BTW it really doesn't. If you read our account of Guice conversion, then only the bindings specified by annotations were reloaded, the ones that were configured programmatically could not be reloaded at all. So this is not a magic solution to any problems, it's just a more flexible approach to configuration beneficial in some cases.

Hi Gavin! It is a pleasure to have you here in this discussion.

A perfect example of something that should *not* be expressed in imperative code.

I don't see why it cannot be expressed through programmatic configuration. Hibernate programmatic configuration may be unreadable and verbose, but that's probably because it was not done with the end-user in mind, like you said yourself. Take a look in this configuration: (more about this here: http://recipes.mentaframework.org/posts/list/21.page)

bean(Carro.class, "Carros") .pk("id", DBTypes.AUTOINCREMENT) .field("name", DBTypes.STRING) .field("year", DBTypes.DATE) .field("motorId", "motor_id" /* = NAME IN THE DB */, DBTypes.INTEGER);

Through programmatic configuration you can scale down (less verbose) as much as you want. Not to mention the other benefits such as: IDE integration, refactoring, auto-complete, auto-compile, more flexibility and power (IFs, loops, methods, variables, etc.), javadoc, possibility to use dynamic language, etc. Java code is more natural and joyful then XML or Annotation "code" in my humble opinion. But Hibernate was a bad example, I must agree. I am not up for this battle. :-) But all the majority of web frameworks out there are abusing the use of XML and now annotations. I think Struts2 is the best example.

The Hibernate XML *is* a DSL.

I may have expressed myself incorrectly here. XML is not a programming language. It is a metadata language. It may be a DSL as you say, but it is static, you are not able to compile it, you are not able to do a loop, method, if, etc. I am looking for a programming language to do my configuration for the many reasons I stated above, plus it is more natural and joyful for the Java programming.

If you think this sucks, I really question your understanding of how the Java classloader works

Feel free to help us understand the Classloader, Cedric. I really did not know about the instanceof problem and it looks weird to me. It may be theoretical right for user instanceof User be FALSE when the User class was reloaded and the user was not reloaded, but that's weird. It looks like JavaRebel solved this annoyance and they may be able to talk more about this.

I don't see how that would make any difference at all.

That will make a big difference if you are using a dynamic/scrypting language. Because with Programmatic Configuration it is very easy to use a scripting/dynamic language. Mentawai supports out-of-the-box BeanShell and Groovy. When you configuration is described in a dynamic language in a file, it is very easy to detect that the file has changed, clear all my configuration (hey, this is code and data-structures), and re-execute the new file again. As simple as that, no classload problems or anything. Now the problem comes when you want to reload a Java Class file, in this case the ApplicationManager.class. When I studied this a couple of years ago (please say if things have changed) there is NO WAY to remove a loaded class once it is loaded. The only way to force this (hack!) is to use a different classloader. But using a different classloaders introduces other problems, such as the instanceof problem. I think JavaRebel exists because of this.

don't see why it cannot be expressed through programmatic configuration. Hibernate programmatic configuration may be unreadable and verbose, but that's probably because it was not done with the end-user in mind, like you said yourself.
Take a look in this configuration: (more about this here: http://recipes.mentaframework.org/posts/list/21.page)

bean(Carro.class, "Carros")
.pk("id", DBTypes.AUTOINCREMENT)
.field("name", DBTypes.STRING)
.field("year", DBTypes.DATE)
.field("motorId", "motor_id" /* = NAME IN THE DB */, DBTypes.INTEGER);

Through programmatic configuration you can scale down (less verbose) as much as you want. Not to mention the other benefits such as: IDE integration, refactoring, auto-complete, auto-compile, more flexibility and power (IFs, loops, methods, variables, etc.), javadoc, possibility to use dynamic language, etc. Java code is more natural and joyful then XML or Annotation "code" in my humble opinion.

You are resorting to method chaining, which is just a fancy way of sending several consecutive messages to the same object. It may look concise, but, hell? Why are you sending so many messages? Doesn’t it make you wonder?
Is not natural to describe something by using imperative constructs. Because metadata influences behavior, but metadata is not behavior in itself. With annotations you take the burden of initialization out of the shoulders of your developer. The metadata is there, right where it belongs, The IDE can see the annotations and doesn’t have to wonder where the hell you put all your strange initialization code.
The problem I see with your “programmatic configuration” is that it can only be verified at runtime. An XML can be verified by the IDE simply by validating it against a XSD. For example, what happens if you forget to send the pk message? What happens if you send it twice with conflicting definitions?

The Hibernate XML *is* a DSL.

I may have expressed myself incorrectly here. XML is not a programming language. It is a metadata language. It may be a DSL as you say, but it is static, you are not able to compile it, you are not able to do a loop, method, if, etc. I am looking for a programming language to do my configuration for the many reasons I stated above, plus it is more natural and joyful for the Java programming.

If you think this sucks, I really question your understanding of how the Java classloader works

Feel free to help us understand the Classloader, Cedric. I really did not know about the instanceof problem and it looks weird to me. It may be theoretical right for user instanceof User be FALSE when the User class was reloaded and the user was not reloaded, but that's weird. It looks like JavaRebel solved this annoyance and they may be able to talk more about this.

You fail to see that a language doesn’t need to be expressed in terms of a series of instructions, and that’s why you deny that XML can be a programming language. It’s nothing only of theoretical importance. Understanding how a classloader works is the bare minimum if you want to write a decent framework. This behavior that sucks for you is critical for JSE security.

Thanks for your comments Marcos Eliziário! They are really honest and sincere! We will be considering them...

I've been wondering for years why this is so little used. I remember the good old EJB 1.0 where XML-Hell was non existant and the EJB were configured with - yes - Java Classes. I found that approach natural, easy, low impact and without a media break. The whole EJB deployment model has never really justified putting the configuration in XML files. And it has not made deployment any easier or faster as well. Yet it has been done. And the answer for the problem "It is hard to manage the configuration" has been "We create even more configuration" (Microcontainers, Annotations). It's really like fighting bureaucracy with more bureaucracy. :-).

Had all the frameworks had PROGRAMMATIC CONFIGURATION instead of annotation-hell and xml-hell, JavaRebel life would be much easier.

Take a look here:

http://www.mentaframework.org/

I find your habit of hijacking threads and advertising totally unrelated product very unwelcome. I do like programmatic configuration, but this thread is not the right place to discuss it, specially when you add your marketing s**t to everything you say. /Henri Karapuu

A WAR or EAR project smaller than 1000 classes on decent workstation could be recompiled and redeployed in less than 15 seconds. And when running JEE container from within IDE it happens even faster. To make it worse, I experienced a lot of problems just at deployment time: several versions of the same third-party library present at runtime simultaneously, classloaders doing not what you expect them do do, that kind of shit. So you need to recompile/redeploy often enough anyway, just to make sure problems are detected early. Considering all above, I fail to see value in that kind of product and don't understand who's in the target group.

Considering all above, I fail to see value in that kind of product and don't understand who's in the target group.

I am.

I am.

Nice to meet you :) Vendor, meet the target group; target group - vendor :D

What befuddles me is why doesn't everyone implement XML/Annotation/etc configuration on top of a programmatic configuration API.

Let me give you an example: Hibernate The authors and other people will claim it has programmatic configuration, but it is not documented, not encouraged, not mention by anyone, and there is no example or code anywhere. So It is basically the same as not existing! We receive a bunch of emails saying: "Why don't you make Mentawai support annotations?" And I just copy and past the answer: "If you want to make a library on top of Mentawai to support annotations, feel free. But the official project will not encourage this kind of configuration. We encourage, support and document the PROGRAMMATIC CONFIGURATION with Java, BeanShell, Groovy or any PROGRAMMING LANGUAGE.

Let me give you an example: Hibernate

The authors and other people will claim it has programmatic configuration, but it is not documented, not encouraged, not mention by anyone, and there is no example or code anywhere.

You picked kind of a bad example. Hibernate is very easily configurable programmatically - I have done it on multiple projects using only the supplied Javadoc and source code. "Not documented" is not the same as "not there at all", especially in open source.

Hibernate is very easily configurable programmatically - I have done it on multiple projects using only the supplied Javadoc and source code.

"Not documented" is not the same as "not there at all", especially in open source.

I did NOT say it is not there. I said and continue to believe that this is not encouraged, documented, mentioned, has no examples, etc. Using JavaDoc and the Hibernate source code to do it is very different than "very easily configurable programmatically" like you said. If you take it like that, then EVERYTHING has programmatic configuration. The same way the code is parsing the XML to configure itself, you can do it. If you want (happy) clients/customers/developers it surely does not work like that. But people are just using annotations or XML to configure Hibernate and everything else, without much complain. So nobody cares! Until people start migrating to languages like Ruby that support a DSL for configuration.

Hibernate is very easily configurable programmatically - I have done it on multiple projects using only the supplied Javadoc and source code.

"Not documented" is not the same as "not there at all", especially in open source.

I did NOT say it is not there. I said and continue to believe that this is not encouraged, documented, mentioned, has no examples, etc.

Correct, it is not encouraged. Why not? Because for almost everyone (except for people with the very exotic requirement for mappings which change dynamically at runtime), it results in a much more verbose and unreadable way of specifying a mapping. Mapping metadata is by nature static and deeply structured. A perfect example of something that should *not* be expressed in imperative code.

But people are just using annotations or XML to configure Hibernate and everything else, without much complain. So nobody cares! Until people start migrating to languages like Ruby that support a DSL for configuration.

Eh? The Hibernate XML *is* a DSL. Do you even understand the term? And, unlike a typical ruby-based DSL, it is typesafe, and can be validated and autocompleted by IDEs. Same comment goes for annotations. That's why "nobody cares".

Hi King, what do think about JavaRebel SDK support in hibernate?

Hi King,

what do think about JavaRebel SDK support in hibernate?

+1. Any web framework supporting JavaRebel would get great benefit if the persistence layer supported it too. (Not to say it would make a great difference for a JPA implementation...)

So It is basically the same as not existing!

We receive a bunch of emails saying: "Why don't you make Mentawai support annotations?"

And I just copy and past the answer: "If you want to make a library on top of Mentawai to support annotations, feel free. But the official project will not encourage this kind of configuration. We encourage, support and document the PROGRAMMATIC CONFIGURATION with Java, BeanShell, Groovy or any PROGRAMMING LANGUAGE.

I am not against programmatic configuration (in fact, I think it's a sympton of a well-designed API). But your case doesn-t feel right to me. Are you promoting this kind of construct?

val.add("age", new RequiredFieldRule(), FIELD_REQUIRED_ERROR); val.add("age", new IntegerRule(18, 50), INVALID_AGE);

You notice that if I rename the field to anything else, this code breaks big time and that would not happen with annotations, right? Not to say it is more verbose.

You notice that if I rename the field to anything else, this code breaks big time and that would not happen with annotations, right?

Dude, that's a huge problem. Thanks for pointing that out! I am not sure how this works with annotations, but If I type "agi" instead of "age" I am screwed. If I am doing injection and type: setAgi(String age) instead of setAge(String age) I am screwed. So you like this: (source: http://struts.apache.org/2.x/docs/validation-annotation.html)

@Validation() public class SimpleAnnotationAction extends ActionSupport { @RequiredFieldValidator(type = ValidatorType.FIELD, message = "You must enter a value for bar.") @IntRangeFieldValidator(type = ValidatorType.FIELD, min = "6", max = "10", message = "bar must be between ${min} and ${max}, current value is ${bar}.") public void setBar(int bar) { this.bar = bar; } public int getBar() { return bar; } @Validations( requiredFields = {@RequiredFieldValidator(type = ValidatorType.SIMPLE, fieldName = "customfield", message = "You must enter a value for field.")}, requiredStrings = {@RequiredStringValidator(type = ValidatorType.SIMPLE, fieldName = "stringisrequired", message = "You must enter a value for string.")}, emails = { @EmailValidator(type = ValidatorType.SIMPLE, fieldName = "emailaddress", message = "You must enter a value for email.")}, urls = { @UrlValidator(type = ValidatorType.SIMPLE, fieldName = "hreflocation", message = "You must enter a value for email.")}, stringLengthFields = {@StringLengthFieldValidator(type = ValidatorType.SIMPLE, trim = true, minLength="10" , maxLength = "12", fieldName = "needstringlength", message = "You must enter a stringlength.")}, intRangeFields = { @IntRangeFieldValidator(type = ValidatorType.SIMPLE, fieldName = "intfield", min = "6", max = "10", message = "bar must be between ${min} and ${max}, current value is ${bar}.")}, dateRangeFields = {@DateRangeFieldValidator(type = ValidatorType.SIMPLE, fieldName = "datefield", min = "-1", max = "99", message = "bar must be between ${min} and ${max}, current value is ${bar}.")}, expressions = { @ExpressionValidator(expression = "foo > 1", message = "Foo must be greater than Bar 1. Foo = ${foo}, Bar = ${bar}."), @ExpressionValidator(expression = "foo > 2", message = "Foo must be greater than Bar 2. Foo = ${foo}, Bar = ${bar}."), @ExpressionValidator(expression = "foo > 3", message = "Foo must be greater than Bar 3. Foo = ${foo}, Bar = ${bar}."), @ExpressionValidator(expression = "foo > 4", message = "Foo must be greater than Bar 4. Foo = ${foo}, Bar = ${bar}."), @ExpressionValidator(expression = "foo > 5", message = "Foo must be greater than Bar 5. Foo = ${foo}, Bar = ${bar}.") } ) public String execute() throws Exception { return SUCCESS; } }

Validation is just one of the areas that PROGRAMMATIC CONFIGURATION shines! Since you mentioned I will post the link and let the readers decide by themselves. But feel free to come up with more arguments! Validation with interface: http://recipes.mentaframework.org/posts/list/4.page Validation with separate filter: http://recipes.mentaframework.org/posts/list/3.page

I was only saying that annotations feel like a more natural way to configure this concrete case. But since you asked for further argument: http://icoloma.blogspot.com/2007/12/validate-web-forms-using-jpa.html If you are using JPA, you should not need to specify a wide share of validations, since they are already there. Just use them.

I was only saying that annotations feel like a more natural way to configure this concrete case.

I was kind of unpolite in my response. Sorry, Ignacio. I just got too warmed up in the debate. Your page and your point are good. Annotation has the positive side effect of not requiring a property name, because it can be applied straight to the property. But IMHO it has many other negative side effects. It is static, it scatters configuration all over the place, it ties your application to the framework being used, it can be abused, it is not flexible (can you do a for loop?), etc. However your page is talking about validating your data model. I am talking about validating your WEB FORM, which can be totally unrelated with the data model.

It is static, it scatters configuration all over the place, it ties your application to the framework being used, it can be abused, it is not flexible (can you do a for loop?), etc.

Of course, you are free to complement them with alternatives, but I find it appropriate to the task at hand: both data structure and business rules can be specified at the same source file, and with JavaRebel you could modify both without a server restart. You point still holds, anyway: risk of abuse exists, and you should have means of specifying additional validations without bloating the code. The example you gave before gives me the chills :P

However your page is talking about validating your data model. I am talking about validating your WEB FORM, which can be totally unrelated with the data model.

Not exactly. My post proposes using the same annotations to generate both the database and the web tier validations.

I am.

Nice to meet you :)

Vendor, meet the target group; target group - vendor :D

LOL

A WAR or EAR project smaller than 1000 classes on decent workstation could be recompiled and redeployed in less than 15 seconds. And when running JEE container from within IDE it happens even faster.

To make it worse, I experienced a lot of problems just at deployment time: several versions of the same third-party library present at runtime simultaneously, classloaders doing not what you expect them do do, that kind of shit. So you need to recompile/redeploy often enough anyway, just to make sure problems are detected early.

Considering all above, I fail to see value in that kind of product and don't understand who's in the target group.

15 seconds is on the low side for people using Spring, Hibernate, etc. But even 15 seconds is still a pain, especially when you do it tens to hundreds of times a day. Also, if you have a site where you have to login first (like most of the sites I've built during my career) it also means you have to login, navigate to the target page, etc. Adds another few seconds, and the whole thing is just boring. Using JavaRebel means saving a bloody lot of time every day. Almost all Java developers can benefit from it.

15 seconds with losing app's state is already annoying. X minutes with losing state is a coffee or a cigarette or rss or just an unnessary context switch.

15 seconds with losing app's state is already annoying. X minutes with losing state is a coffee or a cigarette or rss or just an unnessary context switch.

What is the advantage of JavaRebel over Tomcat reloading my context when I change some class file?

15 seconds with losing app's state is already annoying. X minutes with losing state is a coffee or a cigarette or rss or just an unnessary context switch.

What is the advantage of JavaRebel over Tomcat reloading my context when I change some class file?

It doesn't reload the context. It reloads the actual individual classes, which means that all state is preserved and no time is wasted reinitializing the application. And also there is no problem with instanceof.

So all I have to say is: GREAT JOB ! :-) If I want to use JavaRebel with Mentawai framework, is that possible? What would be the license in that case?

Automatic functional testing - frameworks like actiWATE (yes with 'W' that's not at typo) - are to the rescue. Most of the sites/webapps I've built during my career were coming together with automated test suites or at least some auto-login features. The niche of hot class reloading is quite small, for now it looks just too fragile to be usable by average developer. Any framework doing some kind of AOP/proxying could possibly break it.

Automatic functional testing - frameworks like actiWATE (yes with 'W' that's not at typo) - are to the rescue.

Why does any discussion on TSS end up with people promoting their own products, no matter how relevant they are? So far there hasn't been almost any discussion relevant to the actual original post, but a LOT of Mentawai PROMOTION. There goes my hope of actually seeing some feedback...

Automatic functional testing - frameworks like actiWATE (yes with 'W' that's not at typo) - are to the rescue.

Why does any discussion on TSS end up with people promoting their own products, no matter how relevant they are? So far there hasn't been almost any discussion relevant to the actual original post, but a LOT of Mentawai PROMOTION.

There goes my hope of actually seeing some feedback...

There are a lot of discussion about a lot of topics here. Programmatic configuration, classloader, annotation, XML, DSL, etc. I think they all relate to the product JavaRebel. People tend to end up using their own choices as an example. I used Mentawai, but I also offered a lot of arguments. This is good to spicy up the discussion. The proof is that even Gavin King came here to discuss. My personal opinion is that comments like yours are what really kills a discussion.

Jevgeni, you're going too far. I would like to hear excuses for this one. I am by no means affiliated with the people/company behind actiWATE, I just found it convenient and easy to use.

Jevgeni, you're going too far.
I would like to hear excuses for this one.

I am by no means affiliated with the people/company behind actiWATE, I just found it convenient and easy to use.

If you are not affiliated I, by all means, am very sorry for implying that. It's just a very common pattern on TSS and sadly sometimes hurts people like you, who give honest advice.

The niche of hot class reloading is quite small, for now it looks just too fragile to be usable by average developer.

A niche? Fragile?

Any framework doing some kind of AOP/proxying could possibly break it.

Please check your assumptions first.

I've looked at this product in the past, and it's some very cool stuff. But considering the level of tools you get from IDEA at $249 for a personal license or myeclipse at $50, $150 for a "nice to have" feature seems steep. I'm not saying it's not cool or even worthwhile, but I think the pricing is going to limit the market penetration. Good luck though.

Times have changed my friend...

He probably moved to RoR because he was mad about all this non-sense XML-HELL and ANNOTATION-HELL. Have we heard him back in 2004, maybe not so much people would had migrated to Ruby. Mentawai heard him back in 2005. Guice undertood that, too. It is about time for the Java community to understand that programmatic configuration is more natural, joyful, powerful and flexible. Take a look in Mentawai and you may understand what I am saying. :-) Now take a look on Struts2. See how they do validation with annotations. See how they do validation with XML (with Java inside XML).

Take a look in Mentawai and you may understand what I am saying. :-)/blockquote> I might even share your sentiment, but could you promote your product/project a bit less obviously? Using both bold and caps in one post somehow doesn't get me too excited.

I might even share your sentiment, but could you promote your product/project a bit less obviously?

Sorry, I may have gotten too much excited here. But the point is still valid. IMHO, Programmatic Configuration is the way to go. I will try to hold myself next time...

IMHO, Programmatic Configuration is the way to go.

I'm not making such broad statements anymore. There are some definite areas where it seems preferable, mainly where flexibility is very important. What befuddles me is why doesn't everyone implement XML/Annotation/etc configuration on top of a programmatic configuration API.

Most of the JVM vendor support JPDA/hot method replace. So Java community should work toward making JPDA as open standard and add features to support annotation and configuration files. Having open standard specification would help all JVM vendors and other tool providers like you to focus on the implementation. Java community will have lots of options to choose from.

I pulled down the eval of JavaRebel at one point to play with it. The biggest issue I had with it was proxies. Spring etc generates proxies that are then discarded with the classloader(s), and then there's all sorts of chaos as the proxies aren't found. Is there a response to this issue?

The biggest issue I had with it was proxies. Spring etc generates proxies that are then discarded with the classloader(s), and then there's all sorts of chaos as the proxies aren't found.

Not sure what particular issue you're having, plenty of our users use Spring. If you post on the support forum, I'm pretty sure we'll resolve it.

I don't think I'm going to get much productivity boost because my code loads faster - by the time I'm writing code, I'm way past the time to make big productivity improvements :-)

I don't think I'm going to get much productivity boost because my code loads faster - by the time I'm writing code, I'm way past the time to make big productivity improvements :-)

Have you considered the productivity improvements from decreased frustration? I sure as hell was getting frustrated having to wait for the server to restart.

I think TSS is having hard times with thread hijacking, with people continuously preaching *please look my product* statements! Can we please just stay on topic? This isn't another XML vs Annotations vs whatever else? Personally, I would love to hear experiences from who already uses JavaRebel with Spring Framework and Hibernate. Can it reload classes affected by dynamic proxies(like CGLIB, or even JDK proxies)? Rgds, JV -- julioviegas.com

Personally, I would love to hear experiences from who already uses JavaRebel with Spring Framework and Hibernate. Can it reload classes affected by dynamic proxies(like CGLIB, or even JDK proxies)?

Easy enough to answer, since the company I work for uses almost exclusively Spring/Hibernate. And everyone here uses JavaRebel and is very happy. Technical answer is yes. JDK proxies will reload full (i.e. you add a method to a proxied class and you can call it on a proxy). CGLib proxies will not let you call added methods on proxies as of yet, but we're working on it for the 1.1 M2 release.

CGLib proxies will not let you call added methods on proxies as of yet, but we're working on it for the 1.1 M2 release.

So you work for JavaRebel?

So you work for JavaRebel?

Yes. Though not so much for, as on. I wasn't hiding it, the post itself is from my name.

I think TSS is having hard times with thread hijacking, with people continuously preaching *please look my product* statements! Can we please just stay on topic?

Stay on topic with what? arguments pulled from thin air? I much prefer references to aspects in real products or projects commercial and opensource alike - they are real things which can be examined and used to judge concepts. PS: unfortunately it seems like modus operandi in IT - stay ignorant of other achievements and solutions and promote own idea no matter what.

I think TSS is having hard times with thread hijacking, with people continuously preaching *please look my product* statements! Can we please just stay on topic?

Stay on topic with what? arguments pulled from thin air?

I much prefer references to aspects in real products or projects commercial and opensource alike - they are real things which can be examined and used to judge concepts.

PS: unfortunately it seems like modus operandi in IT - stay ignorant of other achievements and solutions and promote own idea no matter what.

Clapping my hands for you Konstantin!

I do like programmatic configuration, but this thread is not the right place to discuss it, specially when you add your marketing s**t to everything you say.

I don't agree with you but I respect your opinion. Thanks for the compliment!

Stay on topic with what? arguments pulled from thin air?

I much prefer references to aspects in real products or projects commercial and opensource alike - they are real things which can be examined and used to judge concepts.

PS: unfortunately it seems like modus operandi in IT - stay ignorant of other achievements and solutions and promote own idea no matter what.

This is not what the thread is about. I do not have anything against talking about concrete products, but if they don't have anything in common with this thread I would much rather discuss about them elsewhere.

We use JavaRebel with a fairly typical Spring and Hibernate web application, developed in eclipse on Tomcat using the WTP plugins. It rocks. Before JavaRebel, every time a class file changed, tomcat would reload the context and Hibernate would grind for 10 seconds or so reloading its config. With JavaRebel, classes reload as fast as you can refresh your browser window. It saves us an enormous amount of time each day. They have a demo: you might as well give it a shot, as you can get it configured in a couple minutes. Plus, 150 bucks is a steal! It pays for itself in no time. full disclosure: I don't work for JavaRebel, or know anyone that does. Just a satisfied customer.

Just a satisfied customer.

+1 I use JavaRebel for two weeks with Tomacta 5.x, Spring 2.0, Hibernate 3.1, Sun JDK1.6 and IntelliJ 7. I have only problems with IntelliJ's debugger (often can't match the source code line numbers, also with the JavaRebel plugin). I hope that will improve. Can't live without it anymore.

Just a satisfied customer.

+1

I use JavaRebel for two weeks with Tomacta 5.x, Spring 2.0, Hibernate 3.1, Sun JDK1.6 and IntelliJ 7.

I have only problems with IntelliJ's debugger (often can't match the source code line numbers, also with the JavaRebel plugin). I hope that will improve.

Can't live without it anymore.

Forgot: I had to increase the JVM Perm size (-XX:PermSize=256m).

I have only problems with IntelliJ's debugger (often can't match the source code line numbers, also with the JavaRebel plugin). I hope that will improve.

That is also open sourced now, so if anyone wants to improve it source is here: http://code.google.com/p/zt-oss/.

At the moment, the most important integration for me would be with GWT hosted mode shell. I'm able to start the hosted mode shell so that JavaRebel starts, but it does not seem to pick any class changes (nothing happens, and no errors are printed). I can use -noserver and external app server for the server side of things (and JavaRebel works ok with the app server), but it would be great to have instant reloading also for the client side (hosted mode shell). Thanks, /Henri Karapuu

At the moment, the most important integration for me would be with GWT hosted mode shell.

We were working on this and basically made a patch that made it possible. Perhaps if someone makes enough fuss it will be accepted to the GWT. You can read discussion here: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/1edeb4f7f461ddab/840626bbc5629b7e?hl=en&lnk=st&q=javarebel#840626bbc5629b7e Alternatively we could produce a build on http://code.google.com/p/zt-oss/, like the rest of the stuff.

We were working on this and basically made a patch that made it possible. Perhaps if someone makes enough fuss it will be accepted to the GWT.

If i understood correctly john raised concern that the patch would brake native javascript, and because of this the patch was not accepted? The reason was not explicitly clear, so i might have misunderstood. But if that indeed was the reason, it means that waiting and pushing won't help, instead you'd need to make new patch which does not brake the boys' toys .. ;) /Henri Karapuu

Well it boiled down to the fact that user interest was low. We produced a proof-of-concept patch for users to test but it did not get much attention. We'll get back to it once the interest rises and we find testers with real applications.

Well it boiled down to the fact that user interest was low. We produced a proof-of-concept patch for users to test but it did not get much attention. We'll get back to it once the interest rises and we find testers with real applications.

Okey thanks for the heads up. Based on that thread's comment about recent patch for improving refresh speed i recompiled GWT svn trunk and indeed refresh speed is now so fast (~1-2 seconds) that need for JavaRebel is greatly reduced, for this particular use. Anyway thanks to both of you for your exceptionally fast responses & and keep up the great work. /Henri Karapuu

Based on that thread's comment about recent patch for improving refresh speed i recompiled GWT svn trunk and indeed refresh speed is now so fast (~1-2 seconds) that need for JavaRebel is greatly reduced, for this particular use.

You have to understand that GWT apps are essentially stateless at the moment. Therefore they can just dump the classloader and reconstruct the page. It is likely that JavaRebel would not improve the situation much for this particular use case. If the apps will get bigger and start integrating directly with the business layer the turnaround will grow.

You have to understand that GWT apps are essentially stateless at the moment.

Um.. i'm full time GWT developer, and the app i'm working on definitely has state :)

Therefore they can just dump the classloader and reconstruct the page.

The host page *contains* the application, so reconstructing page is conceptually analogous to reloading entire webapp, which is exactly what you try to avoid. The only difference is that with latest svn-only versions and using -noserver option GWT hosted mode refresh is 'fast enough', while webapp reloading generally is not. Anyways, this is mostly "for the record" and it might well be that we are only disagreeing in terminology. Or at minimum we are agreeing that JavaRebel is significantly cooler than sliced bread, but for this particular use it is not as important as for other uses. /Henri Karapuu

Or you can just use convention over configuration and minimize the amount of configuration you need to do (whether declarative or programmatic). Take a look at grails to see how it does validation with no annotations/xml crap. Example:

Class Person { String firstName String lastName String email static constraints = { firstName(blank:false) lastName(blank:false) email(blank:false, email:true) } }

Take a look at grails to see how it does validation with no annotations/xml crap.

Did you read what this thread is about???

Did you read what the discussions about it?

Take a look at grails to see how it does validation with no annotations/xml crap.

Did you read what this thread is about???

Actually the question is for you, did you read the topic yourself, did you read the discussions that followed ?????????????? I bet you didn't. If you opt for convention over configuration you reduce the amount of configuration in your framework/library and you alleviate the problem of reloading code changes which is what the original post is all about.

http://grails.codehaus.org/GORM It is how Grails handle ORM. It is built on top of Hibernate with zero configuration. Oh and Benz Town Citizen, in case you don't get it...GORM solves the problem of configuration reloading (which is what the article is about).

http://grails.codehaus.org/GORM

It is how Grails handle ORM. It is built on top of Hibernate with zero configuration.

Oh and Benz Town Citizen, in case you don't get it...GORM solves the problem of configuration reloading (which is what the article is about).

That's an interesting point, how solves GORM the configuration reloading problem?

Oh and Benz Town Citizen, in case you don't get it...GORM solves the problem of configuration reloading (which is what the article is about).

I didn't get it either from your message. Are you saying that Grails applications can alter hibernate mappings on-the-fly, without restart? /Henri Karapuu

Oh and Benz Town Citizen, in case you don't get it...GORM solves the problem of configuration reloading (which is what the article is about).

I didn't get it either from your message.

Are you saying that Grails applications can alter hibernate mappings on-the-fly, without restart?

/Henri Karapuu

Yes. GORM does not use annotations or configuration files for hibernate mapping. All the configuration is done in the source code itself using convention. In some rare cases if you have advanced/complex needs not supported yet by convention you may switch to xml or annotaions configuration, but for most needs there is no configuration at all. GORM is built using Groovy, a dynamic language with both static and dynamic typing. This allows a lot of magic to happen behind the scenes. As an example, this is how you would define a bi-directional one-to-many relationship:

class Author { static hasMany = [ books : Book ] String name } class Book { static belongsTo = Author Author mainAuthor String title }

Thats it. No annotations, no xml configuration. By using hasMany and belongsTo convention GORM was able to avoid any configuration. And the best part is any changes are done to the source code directly. Domain Classes are re-mapped to the database at runtime. I must say however that sometimes an occasional application restart is required if you made a change to your domain class that will change the underlying database as the re-mapping process at run time doesn't always go smoothly. But at least grails put configuration directly in the source code itself (no annotations or XML). You can read more about GORM here: http://grails.codehaus.org/GORM And this is how you can use GORM outside of Grails: http://grails.codehaus.org/GORM+-+StandAlone+Gorm More about class reloading: http://docs.codehaus.org/display/GRAILS/Auto+Reloading

class Book { static belongsTo = Author Author mainAuthor String title }

Thanks for the detailed reply. But to be honest, i don't see any advantage in using static instance field instead of annotations. Why do you prefer this style?

Domain Classes are re-mapped to the database at runtime.

Now, thats interesting. How the hell you do that, and why this is not pushed back to hibernate core? :/ Also, do you know if it would be possible to use this GORM thingy as standalone, from application that is otherwise Java? Thanks, /Henkka Karapuu

Domain Classes are re-mapped to the database at runtime.

Now, thats interesting. How the hell you do that, and why this is not pushed back to hibernate core? :/

+1 That's amazing! Anybody knows, how they do that?

They don't. Changes to domain classes, and consequently Hibernate mapping, will trigger a re-configuration of the SessionFactory.

They don't. Changes to domain classes, and consequently Hibernate mapping, will trigger a re-configuration of the SessionFactory.

Well configuring session factory is the only thing that really takes time in bootstrapping hibernate. If it is still configured monolithically i don't see much advantage here? Would some Grails user care to step in and elaborate? /Henri Karapuu

They don't. Changes to domain classes, and consequently Hibernate mapping, will trigger a re-configuration of the SessionFactory.

That's correct. Grails will dynamically reconfigure SessionFactory at run time.

They don't. Changes to domain classes, and consequently Hibernate mapping, will trigger a re-configuration of the SessionFactory.

Well configuring session factory is the only thing that really takes time in bootstrapping hibernate. If it is still configured monolithically i don't see much advantage here? Would some Grails user care to step in and elaborate?

That's correct. Grails will dynamically reconfigure SessionFactory at run time.

Well, that's not so amazing...

It's sad that Gavin King doesn't respond, as hibernate really needs some improvement with it's startup time (see also).

I make bold to say EJB/JEE is heading towards the bus stop MS left years back(yes you read that right). As a long time .Net/COM+ developer who had to migrate to J2EE because of the EJB hype, I find it funny that most developers on the J2EE platform can't just see that the current J2EE spec sucks!A test of the ease of use of any product/frameworks/whatever is the relative ease with which a new user can get an app up and running.The whole array of confusing specs,frameworks,APIs that one has to learn to implement the simplest functionality in J2EE is at best annoying.My current impression of a J2EE project now is it really gives you the feel of an academic exercise.What with over-engineered APIs and frameworks in the name of OOP purism, ardent refusal to implement complementary technologies from competitors(why were the JSR guys afraid of including the .Net style delegate in the specs when they picked on annotations?),proliferation of crappy specs and a mountain of frameworks/APIs/specs to learn just to get one single thing done. The good news for me is that SpringSource has finally caught the hint-I don't have to know the raw details before I use it- and hopefully they are on the right track.The real trick is the container does the plumbing and I do my bizlogic. The current offers by SpringSource as of release 2.5 are on the right track(IMO), but what is lacking is a managed host container- an appserver/container for hosting managed services that a managed bean subscribes to at runtime or programmatically. MS got AOP-style development right a long time ago thru COM+, it's all about context and interception. Think of a scenario where JDBC connections,JMS resources,or about any resource to be used in application code can be configured for use by ALL apps running in the container without using local XML descriptors for each app or at worst minimal declarative resource acquisition thru DI via annonations.And this can even be done from a management console-u should be able manage services used by a deployed bean thru a console! The only dependency would be on the service client libraries referenced in the calling code-which can either be 1.auto-generated( by the container) JARs containing service interface definitions and the necessary proxy/stub pairs 2.auto-generated( by the container) WSDL files that can be run thru a tool to generate the necessary proxy/stub pairs 3. Or even better- a service-invocation framework(can't elaborate on this now) All this if u have'nt guessed it requires a managed framework or a managed container not a suite of over-engineered specs that only looks good on paper. PS: If u have'nt realised it, MS has done it again-LINQ.It's called "ORM for the real world". Long live entity beans and JPA!

I make bold...

Why do you post the same message on four different threads???

I make bold...

Why do you post the same message on four different threads???

Cos this is my first post on a TSS thread and I felt like letting the whole wide world know about it.Sorry if I violated any *posting* ethics. What do u think of LINQ compared to Hibernate or JPA?

I make bold...

Why do you post the same message on four different threads???

Cos this is my first post on a TSS thread and I felt like letting the whole wide world know about it.Sorry if I violated any *posting* ethics.

What do u think of LINQ compared to Hibernate or JPA?

I'd love to have LINQ. LINQ's database support is not yet mature, it only supports SQL Server. What do you think about JavaRebel? Is there something comparable in the .net world?

Is there something comparable in the .net world?

Yes. But first you have to realize that deployment is much, much less of a problem in the .NET world. Basically a website or a web application can be deployed by copying to the server. No packaging, deployment descriptors, anything. Just copy. For some project types you will copy just assemblies, for other types (such as websites) you may choose to deploy the page source and take advantage of the seemless compilation on the server (IIS). Then to answer your question: When you copy new assemblies, or edit the configuration file, the server recognize this and starts a new appdomain with the newly deployed/edited files and at the same time stops dispatching requests to the old appdomain, effectively "draining" it. When it has no more outstanding requests the appdomain is unloaded. On a website individual pages are actually compiled to seperate assemblies. These do not trigger a unload/load of the appdomain but do activate the newly edited pages. This is not exactly the per-class loading of JavaRebel; rather the .NET unit is assembly. But it fully serves the same purpose. If you develop directly against the IIS server (which you rarely do since Visual Studio has a built-in server) you *never* have to stop/start the server or applications to test your stuff. You just refresh the browser or re-request from the web service. This is a built-in feature of IIS since ver. 6. If you use in-process session storage you may experience loss of session data when the appdomain cycles. If that's a concern you will typically configure your app to use the built-in state server; which will preserve session state across even restarts of the IIS server. The configuration file is xml based but also has a distinctive OO feeling to it: It sports inheritance of configuration settings from higher up the hierarchy. basically the machine may have a config file, the IIS server instance, the site root and each directory. At any level in the hierarchy a config file only needs to override the settings you don't want to inherit. The entire schema is extensible by custom "sections". Sections may also specify an external file; but because it is referenced from the main config file the server will also observe those for any updates. You might say that the machine/IIS instance files configure the "convention". Only when you want to deviate from the convention do you need a config file; and then you only need to specify the "deltas".