Menu
▾
▴
springframework-developer
|
From: Nicolas De L. <nic...@ca...> - 2006-06-20 07:25:56
|
Hello guys, I've looked at new script support and sounds great for quick design or prototyping "edit source code, hit refresh and get the result", BUT it requires to learn yet another langage. I can agree that "grrovy is great" or "bsh is java like" or any other enthousiastic comment on scripting languages, but my development team has lots of junior java developers and my hierarchy has lot's of old schools men that will make very difficult to accept a "script" language as a valid technology. I'm looking for a way to code scripted spring beans as 100% Java source code, using full IDE support, so that developer doesn't have to know some class is used a scripted bean and some other as compiled code. My first think comes to JSP that are runtime compiled (an re-compiled) by the container. It would be great to have a similar support for java code to be "runtime re-compilable". When the code gets fine, it can be classicaly compiled into a .class and pakaged into the app, by simply changing the spring context. Looking at the way tomcat (jasper) compiles JSP, it seems it uses a custom classloader to load the runtime-compiled .class. My experience with classloaders is limited so I can say if it would be easy, but here is how I'd see this : a FactoryBean creates a proxy for the bean interface and delegates invocation to a "runtime-compiled" class in a child classloader. Hot recompilation requires the bean to be stateless, but this sounds an aceptable constraint if I can code my web controlers or business services by a quick code/test/code. Thanks for any suggestion to make this a reality. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. |
|
From: Niklas T. <ni...@tr...> - 2006-06-20 07:46:06
|
Nicolas De Loof wrote: > Hello guys, > > I've looked at new script support and sounds great for quick design or > prototyping "edit source code, hit refresh and get the result", BUT it > requires to learn yet another langage. > I can agree that "grrovy is great" or "bsh is java like" or any other > enthousiastic comment on scripting languages, but my development team > has lots of junior java developers and my hierarchy has lot's of old > schools men that will make very difficult to accept a "script" language > as a valid technology. > > I'm looking for a way to code scripted spring beans as 100% Java source > code, using full IDE support, so that developer doesn't have to know > some class is used a scripted bean and some other as compiled code. My > first think comes to JSP that are runtime compiled (an re-compiled) by > the container. It would be great to have a similar support for java code > to be "runtime re-compilable". When the code gets fine, it can be > classicaly compiled into a .class and pakaged into the app, by simply > changing the spring context. > > Looking at the way tomcat (jasper) compiles JSP, it seems it uses a > custom classloader to load the runtime-compiled .class. My experience > with classloaders is limited so I can say if it would be easy, but here > is how I'd see this : a FactoryBean creates a proxy for the bean > interface and delegates invocation to a "runtime-compiled" class in a > child classloader. Hot recompilation requires the bean to be stateless, > but this sounds an aceptable constraint if I can code my web controlers > or business services by a quick code/test/code. > > Thanks for any suggestion to make this a reality. > > Nico. Janino, http://www.janino.net/, is a small footprint Java compiler. It's mostly Java 1.4 compatible. Haven't used it myself yet but it looks interesting. It includes a classloader which loads classes directly from Java sources, http://www.janino.net/use.html#class_loader. Regards, Niklas |
|
From: Rob H. <ro...@in...> - 2006-06-20 08:03:24
|
This is something that Adrian and I have been discussing for some time. In theory it is entirely possible, but we have all seen enough horror at the hands of classloaders to know that it isnt entirely trivial. One interesting thing to note is that all valid Java programs are valid Groovy programs. Another area that may be of interest to many people is the ability to embed the JDT compiler from Eclipse to compile sources on the fly. In practice on the fly compilation for certain classes that are hidden behind statically compiled interfaces is not tremendously difficult. The issues arise when you start to talk about dynamically compiling the entire application and arbitrarily replacing individual pieces. This can result in some very interesting dependency issues. Rob On 20 Jun 2006, at 08:47, Niklas Therning wrote: > Nicolas De Loof wrote: >> Hello guys, >> >> I've looked at new script support and sounds great for quick >> design or >> prototyping "edit source code, hit refresh and get the result", >> BUT it >> requires to learn yet another langage. >> I can agree that "grrovy is great" or "bsh is java like" or any other >> enthousiastic comment on scripting languages, but my development team >> has lots of junior java developers and my hierarchy has lot's of old >> schools men that will make very difficult to accept a "script" >> language >> as a valid technology. >> >> I'm looking for a way to code scripted spring beans as 100% Java >> source >> code, using full IDE support, so that developer doesn't have to know >> some class is used a scripted bean and some other as compiled >> code. My >> first think comes to JSP that are runtime compiled (an re- >> compiled) by >> the container. It would be great to have a similar support for >> java code >> to be "runtime re-compilable". When the code gets fine, it can be >> classicaly compiled into a .class and pakaged into the app, by simply >> changing the spring context. >> >> Looking at the way tomcat (jasper) compiles JSP, it seems it uses a >> custom classloader to load the runtime-compiled .class. My experience >> with classloaders is limited so I can say if it would be easy, but >> here >> is how I'd see this : a FactoryBean creates a proxy for the bean >> interface and delegates invocation to a "runtime-compiled" class in a >> child classloader. Hot recompilation requires the bean to be >> stateless, >> but this sounds an aceptable constraint if I can code my web >> controlers >> or business services by a quick code/test/code. >> >> Thanks for any suggestion to make this a reality. >> >> Nico. > > Janino, http://www.janino.net/, is a small footprint Java compiler. > It's > mostly Java 1.4 compatible. Haven't used it myself yet but it looks > interesting. It includes a classloader which loads classes directly > from > Java sources, http://www.janino.net/use.html#class_loader. > > Regards, > Niklas > > > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > -- Rob Harrop VP, Technology Strategy Interface21 - Spring Services from the Source http://www.springframework.com |
|
From: Nicolas De L. <nic...@ca...> - 2006-06-20 08:39:46
|
Rob Harrop a =E9crit : > This is something that Adrian and I have been discussing for some =20 > time. In theory it is entirely possible, but we have all seen enough =20 > horror at the hands of classloaders to know that it isnt entirely =20 > trivial.=20 Isn't Spring expected to make easy those non-trivial stuff ;-) > One interesting thing to note is that all valid Java =20 > programs are valid Groovy programs.=20 I did not try groovy miself. Does this mean that I can open a .java file=20 using Spring groovy script support and get a bean ? > Another area that may be of =20 > interest to many people is the ability to embed the JDT compiler from =20 > Eclipse to compile sources on the fly. > > In practice on the fly compilation for certain classes that are =20 > hidden behind statically compiled interfaces is not tremendously =20 > difficult. The issues arise when you start to talk about dynamically =20 > compiling the entire application and arbitrarily replacing individual =20 > pieces. This can result in some very interesting dependency issues. > =20 I was expecting such restriction. I only consider the ability to change=20 service code on the fly without repackaging / redeploying / restarting=20 my webapp. I know jetty runner starts quicker than tomcat and Spring 2.0=20 has better lazy-init support, but this only make this process quicker,=20 not easier. Some of my process requires to follow a long flow in the=20 webapp, and I need to repeat it on every code change. Hot-replacing the=20 service implementation code would make it trivial. That beeing said, if you find a way to solve those=20 classloading/compiling issues for replacing arbitrary code in a running=20 app and hot-refactoring interfaces, you're welcome :-D I'll take a look at Niklas suggestion about janino classloader. Thanks. Nico. > Rob > > On 20 Jun 2006, at 08:47, Niklas Therning wrote: > =20 This message contains information that may be privileged or confidential = and is the property of the Capgemini Group. It is intended only for the p= erson to whom it is addressed. If you are not the intended recipient, yo= u are not authorized to read, print, retain, copy, disseminate, distribu= te, or use this message or any part thereof. If you receive this message= in error, please notify the sender immediately and delete all copies of= this message. |
|
From: Rob H. <ro...@in...> - 2006-06-20 10:51:51
|
On 20 Jun 2006, at 09:39, Nicolas De Loof wrote: > > > Rob Harrop a =E9crit : >> This is something that Adrian and I have been discussing for some >> time. In theory it is entirely possible, but we have all seen enough >> horror at the hands of classloaders to know that it isnt entirely >> trivial. > Isn't Spring expected to make easy those non-trivial stuff ;-) Indeed! This is definitely something we are focused on. > >> One interesting thing to note is that all valid Java >> programs are valid Groovy programs. > I did not try groovy miself. Does this mean that I can open a .java =20= > file > using Spring groovy script support and get a bean ? It should - I haven't actually tried it but there should be no issues. > >> Another area that may be of >> interest to many people is the ability to embed the JDT compiler from >> Eclipse to compile sources on the fly. >> >> In practice on the fly compilation for certain classes that are >> hidden behind statically compiled interfaces is not tremendously >> difficult. The issues arise when you start to talk about dynamically >> compiling the entire application and arbitrarily replacing individual >> pieces. This can result in some very interesting dependency issues. >> > I was expecting such restriction. I only consider the ability to =20 > change > service code on the fly without repackaging / redeploying / restarting > my webapp. I know jetty runner starts quicker than tomcat and =20 > Spring 2.0 > has better lazy-init support, but this only make this process quicker, > not easier. Some of my process requires to follow a long flow in the > webapp, and I need to repeat it on every code change. Hot-replacing =20= > the > service implementation code would make it trivial. I'll see what I can do in the 2.1 timeframe for getting a JDT/Janino =20 based solution working. > > That beeing said, if you find a way to solve those > classloading/compiling issues for replacing arbitrary code in a =20 > running > app and hot-refactoring interfaces, you're welcome :-D > > I'll take a look at Niklas suggestion about janino classloader. > Thanks. > > Nico. > >> Rob >> >> On 20 Jun 2006, at 08:47, Niklas Therning wrote: >> > > This message contains information that may be privileged or =20 > confidential and is the property of the Capgemini Group. It is =20 > intended only for the person to whom it is addressed. If you are =20 > not the intended recipient, you are not authorized to read, print, =20= > retain, copy, disseminate, distribute, or use this message or any =20 > part thereof. If you receive this message in error, please notify =20 > the sender immediately and delete all copies of this message. > > > > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > --=20 Rob Harrop VP, Technology Strategy Interface21 - Spring Services from the Source http://www.springframework.com |
|
From: Nicolas De L. <nic...@ca...> - 2006-06-20 12:55:14
|
>>> One interesting thing to note is that all valid Java >>> programs are valid Groovy programs. >>> >> I did not try groovy miself. Does this mean that I can open a .java >> file >> using Spring groovy script support and get a bean ? >> > > It should - I haven't actually tried it but there should be no issues. I've made a simple test : A simple Java source can be used succesfully as a groovy script and used as scripted bean. This allows me to code on a running application ! As I use .java file from my Eclipse IDE, I have a natural restriction not to use groovy code not beeing java compatible, so I can use the same java source file as groovy bean in devs and as class in target (production) environment. My test was very simple, so I don't know if groovy may run complex java files, but this looks a very exciting solution, with high productivity in mind. That beeing said, it may be cleaner to have a "pure" java compiler/script engine to turn source java file into scripted-bean. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. |
