Are Groovy 1.x (from http://groovy.codehaus.org) and Groovy++ (from http://code.google.com/p/groovypptest) two separate languages or are they two parts of just one language? Why or why not?
The answer to your question is provided on the Groovy++ website. It's the second sentence on the page you linked to!
Groovy++ is statically typed extension of Groovy programming language.
Groovy++ is an extension to Groovy. It builds on to Groovy, adding true static typing in some or all classes. The goal is performance and other improvements. Again, the page you link to has a complete description.
Recently, Groovy has really improved it's performance, and with the addition of Java 7's invokeDynamic, performance may soon be almost as fast as Groovy++/Java (the difference being mostly negligible).
On a software architectual point of view Groovy++ may be an extension of Groovy.
But if you look at language level: What happens if you use dynamic method invokation and annotate that class with #Typed? The compiler will complain about the unkown methods.
I think Groovy++ is a new language because a #Typed annotated Groovy Class does not allow dynamic calls like a not annotated Groovy Class. It changes the sematic of your code.
Groovy++ is a subset of Groovy.
Formally Groovy++ is just Groovy library. Groovy++ even have not any special syntax and uses Java-annotations.
But in fact Groovy++ is Groovy dialect (not new language of course).
#Peter Groovy++ forbids some Groovy libretys (as I have understood, by reasons of good code style).
But, Groovy++ provides many semantic extensions such as very complex types inference system, traits, extension methods, functional programming library, etc.
Because of this, I think what Groovy++ isn't just "subset of Groovy" as you have told.
Related
As I understand, the 2 frameworks are both static that injects monitor codes into class codes. So, what is the difference?
ASM is a framework/library which provides you an API to manipulate existing bytecode and/or generate new bytecode easily.
AspectJ, on the other hand is a language extension on top of the Java language with it's own syntax, specifically designed to extend the capabilities of the Java runtime with aspect oriented programming concepts. It includes a compiler/weaver, which can either be run at compile time or run-time.
They're similar in the sense that both achieve their goals by bytecode manipulation of existing bytecode and/or generating new bytecode.
ASM is more general in the sense that it doesn't have an opinion about how you would want to modify existing bytecode, it just gives you an API and you can do whatever you want with it. AspectJ, on the other hand, is more specific, more narrow scoped, it only supports a few predefined AOP constructs, but it gives you an interface (the aspectj language) which is much easier to work with if you can fit within those constructs it provides you with.
For most use-cases I've seen, AspectJ is more than enough, but in those rare cases where it wouldn't, ASM can be a good alternative, but you'll need more programming work to achieve similar results.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Kotlin and Groovy look as very similar languages with very similar features if we compile Groovy statically. Which features, apart from null safety, Kotlin has that are missing in Groovy?
Kotlin is a JVM language, which IMO is trying to improve on Java in features and conciseness, while remaining imperative and static. Groovy has a similar concept except decided to go dynamic. As a result, a number of language features will be similar.
Here are some differences I'm aware of
Static vs Dynamic: Since Groovy was designed as a dynamic language, and #CompileStatic, while a great annotation (I use it a lot), was added later. Its feature feels a bit bolted on, and it does not enforce people to code in a static manner. It's not usable everywhere (e.g. my Spock tests seem to fail to compile with them). Sometimes even with it on Groovy still seems to have some odd dynamic behaviour every now and then. Kotlin is 100% Static, and dynamic is not an option.
There are a number of other features that is has though. I'd recommend you look at the reference, and you may spot a few more e.g. https://kotlinlang.org/docs/reference/
Data classes - concise with a copy function (a bit like case classes in Scala)
The null safety check you mentioned (which is a big pro)
The ability to destruct items. val (name, age) = person
Higher-Order Functions, defined like "fun doStuff(body: Int -> T)): T". Which are much better than the groovy Closures IMO. (very similar to Scala's)
Type checks and smart casts are nice: https://kotlinlang.org/docs/reference/typecasts.html
Companion Objects, in the same way Scala also tries to remove static methods from classes, Kotlin tries the same thing.
Sealed Classes to restrict inheritance (again Scala has something similar)
The "Nothing" subtype, where everything is a supertype of it. (another crucial concept in Scala).
when expressions for basic pattern matching: https://kotlinlang.org/docs/reference/control-flow.html
As you can see it does borrow from other languages other than Groovy. They have attempted to cherry pick a number of great features in an attempt to make a good language. Naturally Groovy has its own goodness. I've only focused one what Kotlin has and not visa-versa
Another plus is, being made by an IDE maker, the compiler is very quick and has great IDE support. Not saying Groovy does not have good support, but my current project does take a long time to compile, and refactor method always assumes you are coding in a dynamic fashion.
I'd recommend you try out the Koans to get a feel for them to see which features of the language you like and how it compares to groovy (https://github.com/Kotlin/kotlin-koans).
Kotlin designed as statically typed language, with great type system and other benefits of statically typed language. Groovy - in first place is a dynamically typed language, and only then - statically.
When you enable compile static in groovy you get just java with syntax sugar. On other side - Kotlin, in their type-system, have two types of references: nullable and nonnullable, so you can write code with less NPEs. If you are asking about only one feature - that's it.
Second great feature of Kotlin - it doesn't do any implicit conversions, on other hand - groovy implicitly converts double to bigdecimal and so on.
But kotlin has a lot other features, like smart casts, ADT (doc), type-safe builders, zero-cost abstractions and finally great IDE support.
Also i'm not sure about quality of Groovy's type-inference(in closures for example we need additional annotations, meh), but in Kotlin type-inference work's like a charm, without any annotations in every peace of language.
So statically typed compilation in Kotlin - first class citizen, in Groovy - not.
i recently came to know that groovy++ have been released, what is the major difference is in Groovy and Groovy++?
From the groovy++ page http://code.google.com/p/groovypptest/
Groovy++ is statically typed extension of Groovy programming language. Additionally to all goodies of standard Groovy it adds a lot of functionality
compile time checking of code
as fast as Java performance of compiled code
easy mixing of statically and dynamically typed code
very powerful type inference
tail recursion traits (interfaces with default implementation)
extension methods (compile time categories)
standard library of utilities for functional programming, concurrency and distributed computing (early prototype stage)
There is a good article on what Groovy++ brings to Groovy here. It includes benchmark results, so you can see the performance difference vs. Groovy and straight Java.
Groovy++ is an extension to the core Groovy 1.x language. You drop the GroovyPP.jar file into the Groovy library directory, add #Typed in front of the package keyword in your code, then run your code just as you would in core Groovy. It infers the types, AND runs faster!
I'm writing my master thesis, which deals with AOP in .NET, among other things, and I mention the lack of support for replacing classes at load time as an important factor in the fact that there are currently no .NET AOP frameworks that perform true dynamic weaving -- not without imposing the requirement that woven classes must extend ContextBoundObject or MarshalByRefObject or expose all their semantics on an interface.
You can however do this with Java in the JVM thanks to ClassFileTransformer:
You extend ClassFileTransformer.
You subscribe to the class load event.
On class load, you rewrite the class and replace it.
All this is very well, but my project director has asked me, quite in the last minute, to give him a list of frameworks (and associated languages) that do / do not support class replacement. I really have no time to look for this now: I wouldn't feel comfortable just doing a superficial research and potentially putting erroneous information in my thesis.
So I ask you, oh almighty programming community, can you help out? Of course, I'm not asking you to research this yourselves. Simply, if you know for sure that a particular framework supports / doesn't support this, leave it as an answer. If you're not sure please don't forget to point it out.
Thanks so much!
EDIT: #ewernli
I'm asking about (2).
In C# you can indeed emit code at run-time and create new classes dynamically, but they are new classes, they do not replace an existing class. What I'd like to do is to transform the class at load-time, like you can do in Java with the ClassFileTransformer.
About modifying a method's signature: yes, you're right. I should have mentioned that in my case I don't want to modify the class' interface, but rather the content of its methods.
Your answer was really helpful. Thank you :)
Are you asking about (1) true class replacement at run-time, or (2) facilities to transform the class when it's loaded or (3) languages which support dynamic class loading ?
Java support dynamic class loading with ClassLoader, transformation with ClassFileTransformer, but no true class replacement.
I'm not sure for C#, but I think you can emit code at run-time and create new class dynamically, so you can achieve (3) and probably (2).
True class replacement is mostly supported only by dynamic language, e.g. Smalltalk, Ruby, I guess Python and a few others. This requires the transformation of the instances of the class to match the new shape. They usually initialize the new fields to nil if the class changes.
AFAIK, dynamic languages ported to the JVM make extensive hacking of ClassLoader to support class replacement at run-time. For JRuby, see A first taste of invoke dynamic to get more pointers how they do it now, what's problematic and how the upcoming invokedynamic might help.
This is not offered in statically typed languages because of the complication with the type system. If a method signature change in a class, other existing classes already loaded might not necessary comply with the new method signature which is not safe. In java you can however change a method as long as the signature is the same using the Java Platform Debugger Architecture.
There have been some attempt to add this feature to Java, and/or statically typed languages:
Runtime support for type-safe dynamic Java classes
Supporting Unanticipated Dynamic Adaptation of Application Behaviour
A Technique for Dynamic Updating of Java Software
This paper provide a general overview of related problems
Influence of type systems on dynamic software evolution
Not sure exactly if that address you initial question, but these pointers might be interesting for your thesis anyway.
The Java language doesn't support class file replacement. The JVM exposes the feature via the classes you mention. Therefore all languages which have been ported to the JVM can take advantage of it.
Erlang supports hot code swapping, and if you are looking also for theoretical frameworks that model dynamic class updates, you can take a look at the Creol language (interpreted).
Objective-C's runtime library supports dynamic construction and registration of classes, lazy method registration and "method swizzling" by which method implementations can be switched at runtime. Previous versions supported "Class swizzling" by which a class could be substituted for another at runtime, but now method swizzling is used instead. Here's the reference doc.
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.