Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Does groovy break Java (philosophically)?

 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm familiar with a number of languages including Scheme which has Lambda expressions. Those lambda expressions are consistent which the principles of what Scheme is (namely lambda calculus).

As I look at closures in groovy they seem, well, out of place. Sure, code as a first class object does make sense. However, it seems to totally run roughshod over the security principles inherent in Java, from dynamically altering classes to not respecting scope.*

Then we have dynamic typing, totally breaks the type checking provided by Java (I suppose this is also a security issue).

So doesn't groovy break Java?

I understand that Java code works in groovy and that not all groovy code runs as pure Java. I'm not asking a mechanical question, but rather a philosophical one.

--Mark


*On the issue of scope, in a lambda expression you create a new frame which is it's own context (in fact, I think it creates an actual new frame on the stack). A closure seems to have a global context.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Break" sounds a bit overstated to me. Groovy allows you to violate a lot of rules that Java would normally enforce, for better or worse. But it's not like your existing Java code just stops functioning.

I look on this much like I look on reflection. Reflection can allow you to access private data (unless forbidden by the security manager). One can look on access modifiers as "broken" in that sense - yet they still work fine for plenty of applications. It's up to people who use reflection to use it responsibly. I think many Groovy features are like that. If you turn a bunch of rookie programmers loose on a Groovy project, they can probably do more damage than they could on a Java project. On the other hand if you turn a group of responsible coders on the same project, they may well be more productive.

As for "A closure seems to have a global context" - can you elaborate on that?
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:

As for "A closure seems to have a global context" - can you elaborate on that?


In scheme when you create a lambda expression ("closure"), the variables there only have context within that expression, and the code itself only has access to whatever the calling code had access to. In grails this (particularly the latter, not 100% certain about the former) does not seem to be

--Mark
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Herschberg:
As I look at closures in groovy they seem, well, out of place. Sure, code as a first class object does make sense. However, it seems to totally run roughshod over the security principles inherent in Java, from dynamically altering classes to not respecting scope.*


Are you aware of the fact that there is a proposal to add closures to Java 1.7?


Then we have dynamic typing, totally breaks the type checking provided by Java (I suppose this is also a security issue).


I wouldn't say that it totally breaks the type checking. As far as I know, Groovy is still a strongly typed language (in contrast to old-school C++). It's just that the type checks don't happen at compile time.

Regarding it being a security issue, I'm not sure why it would be. And as far as I know, Smalltalk (also a dynamically typed language) was traditionally used for domains such as banking, which aren't known for their lax security.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Mark H]: In scheme when you create a lambda expression ("closure"), the variables there only have context within that expression, and the code itself only has access to whatever the calling code had access to. In grails this (particularly the latter, not 100% certain about the former) does not seem to be

So far that sounds like a description of how things work in Groovy, as far as I know,. Except for the final "does not seem to be". Can you give an example where a closure in Groovy/Grails references something it shouldn't?

Useful details: Groovy closures referencing external variables.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic