AspectJ is a very important and useful tool for me.
AspectJ has been very useful for me while programming in Java (programming language), and I still think it'd be useful in Groovy and Scala programming. However, some of the things that I did with AspectJ is "obsolete" with introduction of Groovy and Scala. Take a look at Java bean getter/setters: it's fun to use AspectJ to solve that problem, but the problem doesn't exist at all in Groovy and Scala. You just use native support or add i.e. @BeanProperty to Scala beans.
AspectJ can be used in Java to implement mixins... but Scala and Groovy has its own integrated way for doing mixins/traits. I saw AspectJ as an alternative programming language! And I guess I was abusing AspectJ for things not at its core goals.
I was using AspectJ for two things: micro-structural aspects (traits, etc.) and for cross-cutting concerns aka Aspect-Oriented Programming (AOP).
Now, the micro-structural aspects are what bugs me here. Traits/mixins, getter/setters, PropertyChangeListener support can be done in AspectJ, but I think it's an abuse of AOP to implement something that Java didn't have. It's not AOP, it's fixing a programming language!
You can do the above pretty easily in Scala, natively. For example, Eclipse ScalaModules enhances OSGi BundleContext with RichBundleContext.
Cross cutting concerns aka AOP is a more valid reason to use AspectJ. Things like security, logging, Data-Context-Interaction pattern, and other macro-infrastructural aspects.
I'm not sure yet how AspectJ fares with Groovy and Scala classes. I know AspectJ deals with bytecode, not Java source, so I hope AspectJ weaves Groovy/Scala classes just fine.
AspectJ aspects are also written in Java programming language, which in some way feels backwards. (come on, enhance Scala classes using Java code? Shouldn't it be the other way around?) With @AspectJ annotation style aspects, it's possible to write Groovy/Scala aspects too, though I'm not sure about its practicalness or convenience.
If you're not familiar yet with Scala I strongly recommend Programming Scala: Scalability = Functional Programming + Objects.
Do you think AOP or Scala matters for you?
Showing posts with label Scala Development. Show all posts
Showing posts with label Scala Development. Show all posts
Monday, March 22, 2010
Is Java (Programming Language) Dead?
After exploring through Scala and Groovy... I'm wondering if the Java (as Programming Language) is dead?
Scala is superior to Java in all if not more ways. Scala's static typing system is way more advanced than Java. Taking type safety to the extreme, even with Java's strength in strong typing, Scala beats even Java itself in this department.
To learn more about Scala, get the book Programming Scala: Scalability = Functional Programming + Objects.
Groovy is a very good dynamically typed programming language. Groovy has strengths and weaknesses compared to Scala. I tend to think Scala and Groovy as complementary, not competition. Scala is more suited to replace Java programming language itself (the lower-level stuff) and Groovy is good for higher-level ones or for scripting purposes. Although that's a very rough distribution, the goal is to use the best tool for the job.
I recommend reading Groovy in Action
book for more learning resources on Groovy.
The only things blocking mainstream Groovy and Scala usage are: overhead, Java integration, tooling, and integration with libraries.
I'm not worried about overhead since it solved itself as time pass. Nowadays, nobody complains Windows Vista or Windows7's Aero UI is "too slow". Or that there are not enough WAP websites for their iPhone. Or that Eclipse RCP is too bloated and should reduce footprint under 10 MB. So I still think overhead is a problem but can be solved by applying the solution at the right problems.
Java integration is being worked on. Groovy can already create Java stubs so you can develop Java sources (or Scala source) with Groovy sources smoothly, with full code completion, javadocs, etc. even before the Groovy sources are compiled to classes. I don't think Scala has this stub creation functionality yet, but you can use Scala .class files just as you would in Java. So you can compile a mixed project of Java, Scala, and Groovy sources as one.
Tooling is the most important here, and it being the most visible weakness of both Scala and Groovy. However, things are doing very well today compared to a few years ago. Groovy support for Eclipse IDE has official support from SpringSource/VMware. Scala Eclipse IDE Plugin is pretty good too, and development of Scala language itself is rapid (as of this writing Scala is at Scala 2.8 beta version).
Integration with libraries is very important, aka with Spring, OSGi, JPA, Java EE, and the like. Fortunately this is also not something to be worried about, as very few libraries/frameworks explicitly require you to use the Java programming language. All they need are .class-es, and Scala produces them just fine. You can use any and all sorts of Java libraries from Scala, so there's no barrier of entry at all. Aside from JSP, some so-called "Java libraries" are not even Java language at all!
Don't believe me? Take a look at JSF 2.0. It mainly consists of annotations (i.e. @ManagedBean), Unified EL (which is yet another programming language, NOT Java!) and XML (that is, Facelets and namespaced JSF component libraries).
What do you think?
Scala is superior to Java in all if not more ways. Scala's static typing system is way more advanced than Java. Taking type safety to the extreme, even with Java's strength in strong typing, Scala beats even Java itself in this department.
To learn more about Scala, get the book Programming Scala: Scalability = Functional Programming + Objects.
Groovy is a very good dynamically typed programming language. Groovy has strengths and weaknesses compared to Scala. I tend to think Scala and Groovy as complementary, not competition. Scala is more suited to replace Java programming language itself (the lower-level stuff) and Groovy is good for higher-level ones or for scripting purposes. Although that's a very rough distribution, the goal is to use the best tool for the job.
I recommend reading Groovy in Action
The only things blocking mainstream Groovy and Scala usage are: overhead, Java integration, tooling, and integration with libraries.
I'm not worried about overhead since it solved itself as time pass. Nowadays, nobody complains Windows Vista or Windows7's Aero UI is "too slow". Or that there are not enough WAP websites for their iPhone. Or that Eclipse RCP is too bloated and should reduce footprint under 10 MB. So I still think overhead is a problem but can be solved by applying the solution at the right problems.
Java integration is being worked on. Groovy can already create Java stubs so you can develop Java sources (or Scala source) with Groovy sources smoothly, with full code completion, javadocs, etc. even before the Groovy sources are compiled to classes. I don't think Scala has this stub creation functionality yet, but you can use Scala .class files just as you would in Java. So you can compile a mixed project of Java, Scala, and Groovy sources as one.
Tooling is the most important here, and it being the most visible weakness of both Scala and Groovy. However, things are doing very well today compared to a few years ago. Groovy support for Eclipse IDE has official support from SpringSource/VMware. Scala Eclipse IDE Plugin is pretty good too, and development of Scala language itself is rapid (as of this writing Scala is at Scala 2.8 beta version).
Integration with libraries is very important, aka with Spring, OSGi, JPA, Java EE, and the like. Fortunately this is also not something to be worried about, as very few libraries/frameworks explicitly require you to use the Java programming language. All they need are .class-es, and Scala produces them just fine. You can use any and all sorts of Java libraries from Scala, so there's no barrier of entry at all. Aside from JSP, some so-called "Java libraries" are not even Java language at all!
Don't believe me? Take a look at JSF 2.0. It mainly consists of annotations (i.e. @ManagedBean), Unified EL (which is yet another programming language, NOT Java!) and XML (that is, Facelets and namespaced JSF component libraries).
What do you think?
Subscribe to:
Comments (Atom)