• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Does groovy break Java (philosophically)?

 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic