If I have to name one language that I thoroughly enjoy programming in, it has got to be Groovy. I work with it almost on a daily basis although the platform for my day job doesn’t require it. Personally, I love groovy for the obvious reasons and also for the not so obvious reason – It has some sentimental value to me since I have been following this language since its inception.<\/p>\n
That said, one of the things that surprised me while using groovy was its Private<\/em> modifier. It seems groovy completely ignores its mere presence. I am used to the unavailability of privates<\/em> in javascript for a pretty long time and so I religiously follow naming conventions to separate private from public assets. I have never used similar naming conventions for groovy because I thought the concept of private existed. Unfortunately, I was wrong. Let us dive into a few short examples to see what I mean…<\/p>\n This is a typical POGO. firstName<\/em> is private by default. Public Setters and Getters<\/em> are generated automatically at compile time. When the caller uses this property, he will actually be using the public Setter or Getter instead of directly accessing the field. Typical groovy stuff…<\/p>\n On the flip side, if you don’t want groovy to generate the Getters and Setters at compile time, then you should modify the field using a private keyword as shown in the snippet below.<\/p>\n Now, groovy won’t generate the Getters and Setters for firstName<\/em>. But if you run the above code, you will be surprised to see that the field is still accessible. The caller is able to set and get the firstName<\/em>.<\/p>\n I thought maybe groovy is probably not suppressing the Getter and Setter generation due to some bug and that is the reason why this field is still accessible. But that is not the case, as you can see in the next example. In this snippet, you can see that I use groovy’s “.@” syntax to access the field directly and the field is still accessible. <\/p>\n Then I tried private methods. No surprise there, since I got used to the surprise by now. Yes, the private methods are also directly accessible. <\/p>\n Thank god though. There was some silver lining. Java classes aren’t able to access all of these private fields, properties and methods. It is only the other groovy scripts that are able to access it. The example below will demonstrate the same. <\/p>\n After some googling, I found a few jira issues here<\/a>, here<\/a> and here<\/a>. <\/p>\n After going through these links, it looks like this was a bug in groovy from the beginning, but nobody bothered to fix it because for such a dynamically and reflectively capable language private<\/em> is just a documentation anyways. <\/p>\n","protected":false},"excerpt":{"rendered":" If I have to name one language that I thoroughly enjoy programming in, it has got to be Groovy. I work with it almost on a daily basis although the platform for my day job doesn’t require it. Personally, I love groovy for the obvious reasons and also for the not so obvious reason – It has some sentimental value to me since I have been following this language since its inception. That said, one of the things that surprised me while using groovy was its Private modifier. It seems groovy completely ignores its mere presence. I am used to... \r\nclass User {\r\n String firstName;\r\n}\r\n\r\ndef user = new User()\r\nuser.firstName = \"John\"\r\nprintln user.firstName\r\n<\/pre>\n\r\nclass User {\r\n private String firstName;\r\n}\r\n\r\ndef user = new User()\r\nuser.firstName = \"John\"\r\nprintln user.firstName\r\n<\/pre>\n\r\nclass User {\r\n private String firstName;\r\n}\r\n\r\ndef user = new User()\r\nuser.@firstName = \"John\"\r\nprintln user.@firstName\r\n<\/pre>\n\r\nclass User {\r\n private String firstName;\r\n private String name() {\r\n firstName;\r\n }\r\n}\r\n\r\ndef user = new User()\r\nuser.@firstName = \"John\"\r\nprintln user.name()\r\n<\/pre>\n\r\nclass User {\r\n private String firstName;\r\n}\r\n\r\nclass UserTest {\r\n public static void main(String args[]) {\r\n User user = new User();\r\n System.out.println(user.firstName); \/\/ compile error\r\n System.out.println(user.getFirstName()); \/\/ compile error\r\n System.out.println(user.name()); \/\/ compile error\r\n }\r\n}\r\n<\/pre>\n
Continue reading...<\/a>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16,15],"tags":[],"class_list":["post-162","post","type-post","status-publish","format-standard","hentry","category-groovy","category-modern-languages"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/posts\/162","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/comments?post=162"}],"version-history":[{"count":21,"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/posts\/162\/revisions"}],"predecessor-version":[{"id":811,"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/posts\/162\/revisions\/811"}],"wp:attachment":[{"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/media?parent=162"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/categories?post=162"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gmarwaha.com\/blog\/wp-json\/wp\/v2\/tags?post=162"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}