From dev-return-4504-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Sun Apr 1 20:15:26 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id E6F32180675 for ; Sun, 1 Apr 2018 20:15:25 +0200 (CEST) Received: (qmail 26411 invoked by uid 500); 1 Apr 2018 18:15:24 -0000 Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list dev@groovy.apache.org Received: (qmail 26386 invoked by uid 99); 1 Apr 2018 18:15:24 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Apr 2018 18:15:24 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id A3444180146; Sun, 1 Apr 2018 18:15:23 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id Wi4Pj65TjR80; Sun, 1 Apr 2018 18:15:21 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id D32945F23D; Sun, 1 Apr 2018 18:15:20 +0000 (UTC) Received: from [192.168.1.4] ([89.14.130.138]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MWSwU-1f175I0OCo-00XckT; Sun, 01 Apr 2018 20:15:18 +0200 Subject: Re: new MOP under Java9 module system findings To: MG , dev@groovy.apache.org, dev@groovy.incubator.apache.org References: <3d869294-595c-5e7e-fb5e-ebc43a6c67dc@gmx.org> From: Jochen Theodorou Message-ID: Date: Sun, 1 Apr 2018 20:15:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0p17sRjE4kv9/+0ODUfkaM57iVr3dJK0rerwjTper3hKqP68sdO dCDM51gb3aePoKxzJlAMgas3gw75GGKq95Wvx1Hus9MmXILnjr5RkGOt+2179P0USLiWXPe 3tKjfl4axucaYd8mDRx2rhOCSn4apr+jrAduudGsZdGH1Mb908/P/RA7u6pvbClrq8UWam/ rP3FdyqG1o8/6ctW2Dizg== X-UI-Out-Filterresults: notjunk:1;V01:K0:bAzJpMpi3wk=:Vs/0/Gj0/NFh7aI2fg5cl3 6WdCzxRT7G21NmIbTw0fwNrDXSh/50km6i/lQTRQZfL4U7dqzt8jtnkPJKEHUjC6ev46AXAXs Fd/MsLhGSzzZwZ5ZR5QDjFVT+56YKLZvibXH/6eiWWPZk6nrS9Qqv+AWwCmB/hKEVbY4JslW/ iHPXX7f1wyXQmbbqD+NLWkO2OTd1xM5fwyF1gk76WmTYB9NUJnlh6G9+8oEL+MYkmnxwbVQM/ CoSFJdDFby8ju4D9R0+/Dt4mYLmBiDZwCqQc6Z8ky7VEWihxgkPA7HlouneFcur3yoLQSrlWo p1z5XRoO+yPnTF/6xELWbMyCeNDvp97xu9sOM81TF+/JuODblZG3wygLKbmUiBYJdIiAnKovv SmLBdgm8XSNGdx5fYsevIc2WEzzNKYBk6mLWz0aaSJnuhbvalo5feHgTM4sdg0am8q2GZTM9G VT/m32en41VRhAGylEPN+38eUeFrcl7ANXcifSMeRBdArwhBljm5qytOtpY5igo7GBOKskRC2 CfbJpkUe11v8qQxxi0VPGIteWCt5LLRXuNgo3IzRZdNZHLazNZSL+pzf+uOsZqIG5scvWUAkE RXoF+TGN9aKNPCO+K3G5F5+CrTgq/wGqSyCzlJVdRae9wLKzqvyxPCvDtVOasf9h0H/NDNo0Z MbpmSNps5vkGch8sgINzLMgLgDDBAJ49wk6H3WLMgcJeokfL1LYa6udSBpyU8iPdhLCJCkIq3 BGN89R1YXFH2mmX/NrjTJFFMSVMozLs9eRLK4qqY8zv1iaMzAe2INWaVba0DHbKMFyWJsUXCi nEp8MVa0Pga7HPR8yEzrKK65YhpWlwDzemn3aY1KLM5I5gIiJw= On 01.04.2018 19:58, MG wrote: > Hi Jochen, > > I just thought about some post by another project I read some time back > (alas I can no longer remember which project exactly) which used Groovy > as its scripting language, but switched to a lesser, more restrictive > scripting option, because they needed to make the scripting more secure, > which, according to the post, could not be done using Groovy "because of > all the reflection Groovy uses". So I was wondering if changes at a > fundamental level in Groovy seem unavoidable, if it would make sense to > also keep the security aspect in mind ? In my opinion that project is wrong, because the security manager mechanisms provide enough protection. The problem is that rarely anyone can use a security manager properly. Anyway... Groovy won't be able to do any call Java cannot do in principle in this version. That is not because of keeping security in mind, that is more because of the module system, that enforces this > Of course you cannot be everything to everyone, even if Groovy comes > close, but if e.g. reflection usage inside a Groovy script could be > prohibited (afair that was one of the problems the post cited) within > the new, Java 9 module approach, that could conceivably make sense... My approach does not use setAccessible anymore, which is the problematic part when using reflection. bye Jochen