I am a little bit ashamed, but I didn't knew that since version 6, Java supports wildcards in classpath definitions. It is not that important nowadays when everyone is using build tools and IDEs, but still, it is nice that it exists. I guess for me it would be hugelly usefull some 10 years ago.
More information at http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html
Sunday, June 20, 2010
When Greasemonkey scripts run?
Recently I found one interesting thing about Greasemonkey. I was moving my scripts from JQuery to plain Javascript and changed $(document).ready() to window.onload() and my script stopped to work. After investigating a while I found that $(document).ready() is called also AFTER document is loaded and window onload obviously only when onload event is fired. This is interesting feature by itself, but I was surprised that Greasemoneky code is called only after document is loaded. Somehow I was not thinking about it this way with many many years of onload usage.
Anyway this is great, because my Greasemonkey scripts looks much cleaner without these unnecessary callbacks - just plain logic.
Anyway this is great, because my Greasemonkey scripts looks much cleaner without these unnecessary callbacks - just plain logic.
Tuesday, June 15, 2010
Spring Roo with GWT
I tried Spring Roo recently and there are my comments about it.
Spring Roo is a tool that automates application development and configuration. It is like Maven, but Maven automates project setup and development tasks, and Spring Roo automates application development and tools integration.
Good:
1) Great idea. No doubt it is really good idea to speed up setup and scaffolding of java application. As most of them use the same set of technologies (Maven, Hibernate, JPA, Spring, Struts, jQuery, Selenium, AspectJ, JUnit) and if you have to configure everything by your own it can easily take hours (I wonder if there is competition for fastest java project setup like: fastest Maven+Struts+Spring+JPA, fastest Ant+Spring MVC+Spring+JPA). There is defenitely no need to be so.
2) Fast. No need to do it manually.
3) No dependency. At one point, there were already prebuilt setups in form of application servers, but then you have lifetime dependency on application server. With Spring Roo there is no dependency - you can loose it any time. This is also great feature. In contrast, Grails is another great tool, but also creates dependency.
Improvements:
1) Configurable tools. It is already there at some point, but what I mean it is like to have ready setups for different tools. Like setup Spring+Struts+Hibernate+Ant+jQuery application, or another setup Spring+Maven+Spring MVC+Hibernate+GWT.
2) Aspects overuse. There is one funny approach to entity files: it creates one aj file for every use case for specific. Like there is one aj file for toString method, one aj for persistence operations, one aj for properties, one aj for setters and getters, one aj for @Configurable annotation. Total 5 files per entity. I have never worked with such approach, but it looks strange to me. It is good if it at least could be configured.
Conclusion:
It is great idea. I would be totally happy if there would be tool that can create ready setup with some example stubs where I just have to pick necessary tools, like:
and it generates typical helloWorld with this info. I am happy. If it can create some entities - it is totally great.
Unfortunately, I don't think that Spring will support much of rival tools like Struts, Guice, JBoss, etc. And it will make it 99% less usefull for most users.
Spring Roo is a tool that automates application development and configuration. It is like Maven, but Maven automates project setup and development tasks, and Spring Roo automates application development and tools integration.
Good:
1) Great idea. No doubt it is really good idea to speed up setup and scaffolding of java application. As most of them use the same set of technologies (Maven, Hibernate, JPA, Spring, Struts, jQuery, Selenium, AspectJ, JUnit) and if you have to configure everything by your own it can easily take hours (I wonder if there is competition for fastest java project setup like: fastest Maven+Struts+Spring+JPA, fastest Ant+Spring MVC+Spring+JPA). There is defenitely no need to be so.
2) Fast. No need to do it manually.
3) No dependency. At one point, there were already prebuilt setups in form of application servers, but then you have lifetime dependency on application server. With Spring Roo there is no dependency - you can loose it any time. This is also great feature. In contrast, Grails is another great tool, but also creates dependency.
Improvements:
1) Configurable tools. It is already there at some point, but what I mean it is like to have ready setups for different tools. Like setup Spring+Struts+Hibernate+Ant+jQuery application, or another setup Spring+Maven+Spring MVC+Hibernate+GWT.
2) Aspects overuse. There is one funny approach to entity files: it creates one aj file for every use case for specific. Like there is one aj file for toString method, one aj for persistence operations, one aj for properties, one aj for setters and getters, one aj for @Configurable annotation. Total 5 files per entity. I have never worked with such approach, but it looks strange to me. It is good if it at least could be configured.
Conclusion:
It is great idea. I would be totally happy if there would be tool that can create ready setup with some example stubs where I just have to pick necessary tools, like:
create helloWorld --with spring, struts, hibernate, hypersonic, junit, jquery, selenium, jpa, rest, etc.
and it generates typical helloWorld with this info. I am happy. If it can create some entities - it is totally great.
Unfortunately, I don't think that Spring will support much of rival tools like Struts, Guice, JBoss, etc. And it will make it 99% less usefull for most users.
Subscribe to:
Posts (Atom)