Is it a must to know Groovy to start learning Ofbiz? The one book i can find is for version 4 of ofbiz and it uses Beanshell. I don't know if later versions of ofbiz have added support for groovy.
Objective: to create workflows as necessary.
Thanks.
EDIT: Found this. From what i understand, one can use any compliant Java scripting language.However, Groovy will be supported OOTB. (Groovy is not just a scripting language, but it is one of the roles)
Later versions have added support for Groovy.
AFAIK, you can still use Beanshell if you want
No, you shouldn't, unless you want use not java but groovy to develop something - e.g, event, service - for OFBiz.
If you familiar with java, that's enough for you to read and understand the source code written in groovy, and it's enough in most case to write some simple in-line groovy script used in OFBiz.
"Know groovy", it's nice-to-have but not must to "start learning OFBiz".
Groovy is used a lot in screen actions, which is the data preparation code that is part of generating UI output. There is a lot of code in the project like this.
It can also be used to implement services and request events (used for processing input), and is a popular tool for custom extensions to OFBiz even though not used a lot in OFBiz itself.
As stated in other answers if you know Java it's easy to read most Groovy code (some closure syntax can be confusing at first), but it's worth learning about more to reduce code size and effort, and make your code cleaner and easier to maintain. In other words, Groovy has a lot of extensions beyond plain Java that are very useful, especially for business logic in applications like those built with Apache OFBiz.
As a case in point, the next generation framework based on the ideas in OFBiz (Moqui Framework, www.moqui.org) is written largely in Groovy and supports Groovy for everything whereas OFBiz also uses JUEL for expressions (and even Beanshell still in a couple places). I should note that both frameworks support a number of other scripting languages for business logic if you have other strong preferences, but it is nice to standardize on one so that developers have less to learn and can more easily work with existing business logic and (as applicable) framework code.
Related
Background: I am a contractor and have taken ownership of several projects written in Groovy with Grails and Hibernate. The original developers are no longer available, there is no documentation. I am relatively new to Groovy. Eclipse is the mandated dev tool. I have many many years of Java.
Question: given the above what tools are available to help me understand the code? This is not supposed to be a Groovy vs Java argument but how do you cope with understanding the structure of the code when Eclipse cannot reliably generate things that I would expect to see in a Java environment e.g.
call hierarchies
class diagrams
Yes, I understand that the strengths of Groovy come at a price; but I am looking to experienced Groovy devs to share some light on the approach they would take to quickly understanding an existing Groovy project.
For a UML class diagram, you may want to look at the Grails "Create Domain UML" plugin. Call hierarchies are likely only possible to determine by tracing running instances of your applications, due to the dynamic nature of groovy. The Grails profiler plugin will show you the call hierarchy at run time.
We all know that MetaProgramming is a Concept of Code == Data (or programs that write programs).
But are there any applications that use it & what are the advantages of using it?
This Question can be closed but i didnt see any related questions.
IDEs are full with metaprogramming:
code completion
code generation
automated refactoring
Metaprogramming is often used to work around the limitations of Java:
code generation to work around the verbosity (e.g. getter/setter)
code generation to work around the complexity (e.g. generating Swing code from a WYSIWIG editor)
compile time/load time/runtime bytecode rewriting to work around missing features (AOP, Kilim)
generating code based on annotations (Hibernate)
Frameworks are another example:
generating Models, Views, Controllers, Helpers, Testsuites in Ruby on Rails
generating Generators in Ruby on Rails (metacircular metaprogramming FTW!)
In Ruby, you pretty much cannot do anything without metaprogramming. Even simply defining a method is actually running code that generates code.
Even if you just have a simple shell script that sets up your basic project structure, that is metaprogramming.
Since code as data is one of key concepts of Lisp, the best thing would be to see the real applications of projects written in these.
On this link you can see an article about a real world application written partly in Clojure, a dialect of Lisp.
The thing is not to write programs that write programs, just because you can, but to add new functionality to your language when you really need it. Just think if you could simply add new keyword to Java or C#...
If you implement metaprogramming in a language-independent way, you get a program analysis and transformation system. This is precisely a tool that treats (arbitrary) programs as data. These can be used to carry out arbitrary transformations on arbitrary programs.
It also means you aren't limited by the specific metaprogramming features that the compiler guys happened to put into your language. For instance, while C++ has templates, it has no "reflection". But a program transformation system can provide reflection even if the base langauge doesn't have it. In particular, having a program transformation engine means never having to say "I'm sorry, your language doesn't support metaprogramming (well enough) so I can't do much except write code manually".
See our DMS Software Reengineering Toolkit for such a program transformation system. It has been used to build test coverage and profiling tools, code generation tools, tools to reshape the architecture of large scale C++ applications, tools to migrate applications from one langauge to another, ... This is all extremely practical. Most of the tasks done with DMS would completely impractical to do by hand.
Not a real world application, but a talk about metaprogramming in ruby:
http://video.google.com/videoplay?docid=1541014406319673545
Google TechTalks August 3, 2006 Jack Herrington, the author of Code Generation in Action (Manning, July 2003) , will talk about code generation techniques using Ruby. He will cover both do-it-yourself and off-the-shelf solutions in a conversation about where Ruby is as a tool, and where it's going.
A real world example would be Django's model metaclass. It is the class of the class, from which models inherit from and responsible for the outfit of the model instances with all their attributes and methods.
Any ORM in a dynamic language is an instant example of practical metaprogramming. E.g. see how SQLAlchemy or Django's ORM creates classes for tables it discovers in the database, dynamically, in runtime.
ORMs and other tools in Java world that use #annotations to modify class behavior do a bit of metaprogramming, too.
Metaprogramming in C++ allows you to write code that will get transformed at compilation.
There are a few great examples I know about (google for them):
Blitz++, a library to write efficient code for manipulating arrays
Intel Array Building Blocks
CGAL
Boost::spirit, Boost::graph
Many compilers and interpreters are implemented with metaprogramming techniques internally - as a chain of code rewriting passes.
ORMs, project templates, GUI code generation in IDEs had been mentioned already.
Domain Specific Languages are widely used, and the best way to implement them is to use metaprogramming.
Things like Autoconf are obviously cases of metaprogramming.
Actually, it's unlikely one can find an area of software development which won't benefit from one or another form of metaprogramming.
Does anyone have any experience with the JetBrains Meta Programming System? Is MPS better than, say, developing a DSL in Ruby?
I don't have any personal experience with MPS, but it was mentioned on the recent episode of Herding Code with Markus Völter. Here's my understanding. MPS is a projection editor which means, instead of parsing and editing text, you are directly editing the underlining language data structure. As Markus mentions, MPS allows you to define your own language but you can also introduce new language concepts into existing languages. For example, you can add a new keyword to Java in a matter of minutes. MPS blurs the lines between internal and external DSLs and, with this, you get static typing and tool support which you wouldn't get when developing a DSL with a dynamic language like Ruby.
I work for JetBrains. I led the MPS project for several years, and now I am working on another project which is also completely written in MPS. According to my experience, MPS is worth using :-)
The answer to your question depends on many things. If you have Ruby based system, or want to create a language quickly, Ruby based internal DSL might be the best choice. If you want to generate Java, and have time to learn MPS, MPS might be the best case. You might also consider systems like XText, etc, which are middle ground between Ruby based DSLs and MPS.
MPS is an interesting beast and has a very huge potential. The idea is simply fantastic:
Inside an IDE (MPS) the user defines more or less visually his DSL(s)
the IDE allows to generate not just the language itself (the runtime or what it does), but also the "tool" aka a more or less full blown IDE, that he or other users can use to edit that new language.
That being said, unfortunately at least for the actual available MPS versions, Jetbrains failed to deliver the above(at least for me) because:
- it is very very hard and complicated to use - like it would not have been made by the authors of the easy to use IntelliJ.
- there are just too many concepts and "ways" the user needs to learn before it's able to do something useful, and still one gets the feeling of tapping into the dark.
- the IDE won't generate an IDE for you but something inside MPS too, a "Cell Based Editor" only (as of this version).
I tried MPS several times (cause the concept is so wonderful and promising), but unfortunately as of this moment I wasn't able to do something useful with it.
I might be to stupid for MPS, but in the time I was just figuring out basic about MPS, I was able to deliver fully blown usable Groovy based DSL.
I'm still following MPS's evolution, and hope that one day will deliver what did initially promised, since it's such a fantastic idea.
Macros in common lisp object system CLOS can alter the syntax quite dramatically, MPS is pretty similar to ANTLR, but it comes with a graphical editor. However MPS does not appreciate code fragmenting beyond compile and runtime and hence both MPS and ANTLR convolve around static metaprogramming problems. You still can't create constructs that will accept an arbitrary number of sub-construct arguments like Monadics, eg; a list comprehension builder that takes an arbitrary number of filters and list generators. To make that possible you need to programmatically alter the raw AST. More experienced Lispers can probably point out other transformations that can't be done.
I agree that documentation has been an issue for beginners when learning MPS. This was certainly true when the previous post was written (2010). Having experienced this first-hand, and finally having succeeded in understanding the system, I wrote The MPS Language Workbench (volumes I and II) to help smooth the learning curve. Feedback I get from readers is that the books are sufficient to help you get started (Volume I) and learn more advanced aspects of the MPS platform (Volume II).
Regarding the answer to the original question. Yes, I believe MPS has key advantages compared to developing a DSL in Ruby or Groovy. The reason is that as a language designer you
Have much better control over all aspects of the language,
The languages you build with MPS can include graphical notations and user interface elements, which make them a hybrid between a user interface and a text DSL script/program,
MPS helps migrate programs as you evolve your language (e.g., refactoring or other changes to the language can propagate to the end-users of the languages, using automatic DSL script/program migrations).
You can see a good example of DSL built with MPS in the MetaR project.
We're writing a large production system in Java, and I'm considering whether or not we can write some of the components in one of the JVM-based dynamic languages. Groovy appears to be the best choice from the Java interoperability standpoint. But is the Groovy implementation reliable enough to use in production (I would assume so), and is the Groovy language specification itself stable enough so that we aren't going to have to revise our production code substantially in a year or two? What are your experiences?
Summary (5/30/09): Good comments, the sense I get is that you should be cautious in adopting Groovy for mission-critical production use, it's fine for ancillary usages like putting together test cases, and there's a middle ground where it's probably fine but do your homework first. Performance is an issue, which needs to be balanced against the increase in developer productivity. Bill and Ichorus have equally helpful answers based on Groovy use, so it was a coin toss.
Update (12/3/09): More recently I've been taking a serious look at Scala, another JVM language. It was designed and implemented by Martin Odersky, the original author of the current javac compiler and the co-designer of Java Generics. Scala is a strongly typed, but uses type inferencing to strip out a lot of boilerplate. It's a nice blend of object-oriented and functional programming. James Gosling likes it. James Strachan, the author of Groovy, likes it too. And Odersky's experience writing javac means Scala's raw performance is not far from Java's, which is impressive.
Update (4/26/11): Take a look at Groovy++, a statically typed extension of Groovy, which has performance equivalent to Java. Looks very interesting.
Edit: Here almost four years later and Groovy has become much more solid.
I can wholeheartedly recommend it for production grade projects.
I've been using Groovy to support production applications for a while and for that purpose it is stable enough. As for actually having Groovy in bona fide production code; I don't think I would do that. Groovy does too many surprising things. It has gotten much better in this regard over the past year or so, but every once in awhile I will run into a bug that is a bit difficult to track down because of the generated code (my issues seem to have revolved around scoping).
I have gotten away from Groovy (though the stuff that we use that is simple and solid is still around) and have used Python (jython implementation), which has been far more predictable in my opinion. Also, python trumps Groovy in readability.
You can write some very interesting code in Groovy with closures and operator overloading and whatnot.
These languages are used for convenience and speed on ancillary code...stuff that can be switched out on the fly if need be. None of it is in production. I don't think I would put either in production unless it was as a stopgap to get something critical out of the door in a major hurry or as a proof of concept or prototype.
And in the case of putting it in actual production, it would have to be in the most dire of circumstances and I would assign someone to rewrite it in pure Java for the next release. I am 98% sure that either would be fine in production but that 2% is too much unnecessary risk.
We've got several production apps running on Grails (using Groovy as the language). So far, no issues have resulted. As for JVM compatibility, take a look at how little the JVM byte-code has changed in the last 5 years... like 1 instruction was added, and none were made obselete.
Will new versions of Groovy come out in the next year? Yes. Will you be required to change to them? No. Though you might want to, 1.6 is a huge speed improvement.
Which brings us to the major drawback of Groovy, the speed issue. Obviously, Groovy is slower than straight Java. The current number are up to 10 TIMES slower, for certain actions. That said, is your CPU the bottleneck in your app? For us, it's mostly DB access and latency. If it's the same for you, what matter if the CPU spends 200ms processing the page request instead of 35ms?
Is that the only problem with Groovy? Nope. Dynamic languages have refactoring difficulties, since there isn't necessarily a complete class specification anywhere in the code. However, this is partially balanced by the smaller code-size which makes it easier to find the places to modify the code.
Anyway, Groovy is a perfectly fine language for production uses. Mix it with Java for your "critical" code, if you fear the reliability. That's the BEST part of Groovy... how easy it mixes with Java classes.
I'm currently exploring using Groovy for only writing unit tests. This has the effects of
Allowing the potentially tedious part of writing tests to be done in a syntax that is a bit simpler than Java.
Keeps the Groovy code out of production.
Allows a large portion of the code base to be written in a non-Java language.
Of course, we haven't started yet, but this is at least my way of attempting to introduce alternate JVM languages to our new projects (and possibly existing ones). I have the same concerns you do, and even more so around performance than stability.
Scripting languages evolve "too fast" in the aspect of syntactic features.
If you want a language for the JVM that will stay compatible for
many years,
Java is your only choice ;)
By the way, I don't think that the readability of code is
ensured by a scripting language automatically.
We used Grails/Groovy as our primary backend at my previous company, and from that experience I'd say that I would choose Groovy over Java in most circumstances I am likely to encounter, since it interoperates with Java seamlessly and is otherwise more fun and expressive. Additionally I would expect the database would almost always be the bottleneck of my application rather than language performance, and we didn't encounter any stability issues/bugs with groovy as far as I recall.
But personally it's usually not about Groovy vs Java for me in most cases -- it's about Groovy/Java + available libraries vs. other languages like Python/Jython/JavaScript/Ruby + available libraries. And there are a lot of other considerations there such as strength of community, maturity of relevant technologies for your particular application, etc. In particular, for web development, Grails was decent, but the community seemed lacking. My overall opinion is that I would use python or Node.js going forward. If I needed the JVM I'd use a jython-compatible python web development environment.
I've been playing with Groovy for a month or so. The simplicity is awesome, and the dynamic language features are really cool too. However, speed is definitely an issue. Also, the groovy console really sucks. You cannot do things that you can do e.g. in python. Every once in a while I have to restart the console, reimport, things, etc. It also keeps forgetting the values I put in the variables while in the console mode; somehow mystically they go out of scope. (Is it because of the JVM? I don't know.) I cannot come up with an example from the top of my head, but the behavior I get in the Groovy console is different from the behavior I get in the Grails console, and is different from what I get by just writing code in a script.
A few more warnings. Note that Groovy is almost, but not 100% compatible with Java. For example, this will not compile:
public class HelloWorld {
public static void main(String args[]) {
System.out.println( "Hello, world!\n");
}
}
Also take a look at How to get classpath in Groovy?
Why would I choose to use Groovy when I could use Jython or Jruby? Does the language provide any inherent advantages to make up for the fact that Jython and Jruby skills are applicable to their parent languages outside of the JVM?
Keep in mind that I purposely keeping this question generic, but if there are any advantages that exist in a particular domain, please don't hesitate to describe them.
EDIT
To clarify, If I write some code in Jruby, I can now, in some cases, move that code outside of the JVM if need be, or at the very least I have gained a better understanding of Ruby. Whereas Groovy skills are applicable only when using a language that just exists inside the JVM. Jython and Jruby have this built in advantage, what does Groovy have to make up for this disadvantage?
If Groovy doesn't have any advantages that you've found, and you would suggest just using Jython or Jruby, let me know.
Edit 2
Thanks everyone for all the answers, most of them make the same point, Groovy integrates slightly better with Java then Jython or Jruby.
Follow up
Using Netbeans 6.5 as my IDE I have found that Groovy to integrates better with Java projects then Jruby. I am not sure if lack of integration is a failing of Jruby or Netbeans. But after using it for alittle Groovy definitely seems to have a leg up.
I've done pretty extensive development in Ruby and Groovy (as well as a little Jython using Grinder as a load testing tool).
Of the 3, I prefer Groovy the most. I like the closure syntax the best and I think that it has the tightest integration in how it works with other java classes on the JVM. It's been a little while since I last used JRuby, but importing Java classes and working with the classloader in JRuby didn't feel as clean to me.
The fact that Groovy is also essentially a superset of Java means that the huge population of Java programmers out there will have a quicker uptake time in picking Groovy up over Ruby/JRuby. They can start programming it like it's Java and slowly start inserting idomatic groovy as they pick it up.
More to the point of what you're asking, I think that another advantage of Groovy is that the language that you go to when you want to optimize something is almost the exact same syntax, it's Java. If you're working in the Ruby or Python worlds, you're going to have to go to either C which is a big shift or Java, which is also quite different than those languages. Programming in Groovy tends to help keep your Java skills somewhat sharp as well.
If you have particular access to a Ruby or Python infrastructure, or a team that has familiarity with those kind of environments, then I could see choosing one of those other languages.
Really, all 3 of them are very nice languages and what you pick should depend more on the problem that you're trying to fix and the resources that you have available to you. Once you've become proficient in one dynamic language, picking up a second or a third is much easier.
I would say if you need to mix Java with Jruby/Groovy, go with Groovy. As everybody said, Groovy has tighter Java integration.
But as far as the language implementation goes, I prefer the Ruby language over Groovy, the language revolves around itself, in Groovy there are some hacks that are inherent to the implementation itself (just watch a Grails stacktrace vs. a Rails stacktrace and you'll see what I mean).
I highly recommend seeing Neal Ford's comparison of Groovy and JRuby
I think Dick Wall gave a very good summary of the differences between these three on the Java Posse podcast (#213, about 34:20 in) ...
"JRuby was designed to make programmers happy ... it's a programming language developer's choice; Python has very strong roots in simplicity and education; Groovy is aimed squarely at being the choice for Java developers ... it's a very familiar environment for Java ... with support for annotations".
In terms of moving the language outside of the JVM, I don't think the Java runtime imposes much of an overhead -- it's a simple install, and you need to set some environment variables -- but it does provide a number of benefits including a mature runtime which has been highly optimised, and a large set of libraries. The JRuby team are now reporting better performance than the native MRI. http://blog.headius.com/2008/08/twas-brillig.html
I've only had experience with Jython and Groovy. The biggest disadvantage with Jython, at the moment, is that the latest release recommended for production (2.2.1) has a feature set that "roughly corresponds to that of Python-2.2" (Jython FAQ). There is a beta implementing what I assume is Python 2.5, which is now a version behind. Don't know if the same can be said for JRuby.
I don't know why you should choose Groovy because I don't know your background. If you are a Java developer Groovy feels more similar to your current language then JRuby or Jython. Groovy combines the best of Java, the language, Java, the platform, and Ruby the language.