From dev-return-30344-archive-asf-public=cust-asf.ponee.io@geode.apache.org Mon Nov 26 22:06:08 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 D3017180647 for ; Mon, 26 Nov 2018 22:06:07 +0100 (CET) Received: (qmail 61120 invoked by uid 500); 26 Nov 2018 21:06:06 -0000 Mailing-List: contact dev-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list dev@geode.apache.org Received: (qmail 61097 invoked by uid 99); 26 Nov 2018 21:06:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Nov 2018 21:06:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id D38A3C02EE for ; Mon, 26 Nov 2018 21:06:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.999 X-Spam-Level: * X-Spam-Status: No, score=1.999 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id x7kfRK_c_Zka for ; Mon, 26 Nov 2018 21:06:03 +0000 (UTC) Received: from mx0a-00296801.pphosted.com (mx0a-00296801.pphosted.com [148.163.150.38]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 48FBF60CF3 for ; Mon, 26 Nov 2018 21:06:03 +0000 (UTC) Received: from pps.filterd (m0114581.ppops.net [127.0.0.1]) by mx0a-00296801.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wAQL5qG7032619 for ; Mon, 26 Nov 2018 21:06:02 GMT Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com [209.85.167.200]) by mx0a-00296801.pphosted.com with ESMTP id 2nxw8f9p5h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 26 Nov 2018 21:06:02 +0000 Received: by mail-oi1-f200.google.com with SMTP id r131so6170311oia.7 for ; Mon, 26 Nov 2018 13:06:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=69Jyv22bz8SK6pivd/BkHh/xAHcMEl7m5V9NslgJHpY=; b=D0CsXTzM5vOLeCrlrlxVDrot8dRuX+3AQko0t7aMtw9jp0iG22vC4I25gB+deAXmD5 2vHeBAsahOPdlObeBLyowwC7jBIq6B0jywQaICTPUQJijcq9HBVxJ/Y0lfHtPt9T3SHn 7+BbQlvtizek6o1WCehpftRI3V9nv9/redO3TaD78H768L08KEZdy2oUyEaK/SHB6fiK Wnbn/upLN9CE3CfiyL5KsbohwUER8Uws9ZIzXg8XoT49h1UrgeP2BYy1UEFXpZr3HKr4 AgzwQ0WVboBDRAgEDa5ykaz8dxt6ECA31cALAKgqdzd11BQB2h661CGnIQPeq+v+/vcc qTJg== X-Gm-Message-State: AA+aEWZ9E3NwxHQDL6GE3UXuMgGn8NMJ9CAwk3QUw0ElHIbLxhs/XOI9 4h4sF1h9UBqUzzS/bdjUi4oywnfEBDabG7EE5c4EC2e8rv2FZPXpGxDTuNueVa7BWZkJfIZT7px 157FTF4PY2fcbEUSeCwCjZTntJmQMxCuRZPY32wbAs+YCcvRZwjvB4hE= X-Received: by 2002:a9d:1c84:: with SMTP id l4mr16857475ota.60.1543266360980; Mon, 26 Nov 2018 13:06:00 -0800 (PST) X-Google-Smtp-Source: AFSGD/UDxFAuYnJijcSfr4Afo9sZ/SO1AeBRHbPOcEQ6e9tqKi92QivAsoL98Xo58Thg3qdLHxwv47aTgX68jAwOeE0= X-Received: by 2002:a9d:1c84:: with SMTP id l4mr16857462ota.60.1543266360700; Mon, 26 Nov 2018 13:06:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Galen O'Sullivan" Date: Mon, 26 Nov 2018 13:05:49 -0800 Message-ID: Subject: Re: [DISCUSS] Geode packages mustn't span Jigsaw modules To: dev@geode.apache.org Content-Type: multipart/alternative; boundary="0000000000003949a3057b97b39b" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-26_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811260180 --0000000000003949a3057b97b39b Content-Type: text/plain; charset="UTF-8" > > If you want to > maintain an API as internal, then you should properly protect that API with > the appropriate *Java* access modifiers (private, package-private and > protected). > Hopefully modules will allow us to do this better, by restricting which *classes* are visible outside the module. However, Java doesn't have a concept of submodules, which means there's no way to make org.apache.geode.cache.tier.sockets visible to org.apache.cache or org.apache.cache.tier without also being visible to everything. We can't make InternalCache (for example) only visible to our own code without declaring it package-private and putting (effectively) all of Geode in the same package. Adding a method to > an interface, is an API breaking change. > I don't agree with this. If a new method is added, old API works just fine, and unless I'm mistaken (and I may be), any code that used the old interface should be able to use the new interface without issues. Galen On Mon, Nov 26, 2018 at 12:13 PM John Blum wrote: > *> Most of these are in internal packages, which means we can change the > package of these classes without breaking users.* > > I don't agree with this. > > Some functionality in Geode required by an application, or framework, is > only available in an "internal" package, unfortunately. This has to do > with the fact that many interfaces in Geode were not well designed. > > In general, and as a general rule of thumb, anytime you change a method > name or method signature, it is an API breaking change. Adding a method to > an interface, is an API breaking change. Removing methods from an > interface is (potentially) an API breaking change. Changing a type is an > API breaking change. There are several other examples. Any class/method > (dare I say field of a class) that is not "properly protected" is part of > your API, regardless if we deem it be "internal" only or not, and > (possibly) will affect users. > > I think any level of modularity (and maturing) is pointless without 1) > first, having well defined contracts/interfaces between functional areas > (based on concerns) and 2) using appropriate access modifiers and cleanly > delineating APIs/SPIs from implementations/providers. > > -j > > > > On Mon, Nov 19, 2018 at 5:21 PM Dan Smith wrote: > > > I think we can actually fix most of these issues without geode-2.0. Most > of > > these are in internal packages, which means we can change the package of > > these classes without breaking users. The only concerning one is > > org.apache.geode.cache.util, which is a public package. However, the > > AutoBalancer is actually still marked @Experimental, so we could > > technically move that as well. Or maybe deprecate the old one and it's > > associated jar, and create a new jar with a reasonable package. JDK11 > users > > could just avoid the old jar. > > > > I have been wondering for a while if we should just fold geode-cq and > > geode-wan back into geode-core. These are not really properly separated > > out, they are very tangled with core. The above package overlap kinda > shows > > that as well. But maybe going through the effort of renaming the packages > > to make them java 11 modules would help improve the code anyway! > > > > -Dan > > > > > > > > > > On Mon, Nov 19, 2018 at 5:03 PM Owen Nichols > wrote: > > > > > To package Geode as Java 11 Jigsaw module(s), a major hurdle is the > > > requirement that packages cannot be split across modules. > > > > > > If we simply map existing Geode jars to Modules, we have about 10 split > > > packages (see table below). Any restructuring would potentially have > to > > > wait until Geode 2.0. > > > > > > A workaround would be to map existing packages into a small number of > new > > > modules (e.g. geode-api and geode-internal). Existing jars would > remain > > > as-is. Users making the transition to Java 11 /w Jigsaw already need > to > > > switch from CLASSPATH to MODULEPATH so the inconvenience of a > different > > > naming scheme for Geode-as-modules might be acceptable (however, once > > > module naming and organization is established, we may be stuck with it > > for > > > a long time). > > > > > > Thoughts? > > > > > > Is it even possible to rearrange all classes in each package below > into a > > > single jar? Is doing so desirable enough to defer Java 11 support > until > > a > > > yet-unplanned Geode 2.0, or perhaps to drive such a release? > > > > > > Or, is it satisfactory to fatten Geode releases to include one set of > > jars > > > for CLASSPATH use, plus a different set of jars for MODULEPATH use? > > > > > > > > > Package > > > Jar > > > org.apache.geode.cache.client.internal > > > geode-core-1.8.0.jar > > > geode-cq-1.8.0.jar > > > geode-wan-1.8.0.jar > > > org.apache.geode.cache.client.internal.locator.wan > > > geode-core-1.8.0.jar > > > geode-wan-1.8.0.jar > > > org.apache.geode.cache.query.internal.cq > > > geode-core-1.8.0.jar > > > geode-cq-1.8.0.jar > > > org.apache.geode.cache.util > > > geode-core-1.8.0.jar > > > geode-rebalancer-1.8.0.jar > > > org.apache.geode.internal > > > geode-connectors-1.8.0.jar > > > geode-core-1.8.0.jar > > > geode-cq-1.8.0.jar > > > geode-lucene-1.8.0.jar > > > geode-wan-1.8.0.jar > > > org.apache.geode.internal.cache.tier.sockets.command > > > geode-core-1.8.0.jar > > > geode-cq-1.8.0.jar > > > org.apache.geode.internal.cache.wan > > > geode-core-1.8.0.jar > > > geode-wan-1.8.0.jar > > > org.apache.geode.internal.cache.wan.parallel > > > geode-core-1.8.0.jar > > > geode-wan-1.8.0.jar > > > org.apache.geode.internal.cache.wan.serial > > > geode-core-1.8.0.jar > > > geode-wan-1.8.0.jar > > > org.apache.geode.internal.protocol.protobuf.v1 > > > geode-protobuf-1.8.0.jar > > > geode-protobuf-messages-1.8.0.jar > > > > > -- > -John > john.blum10101 (skype) > --0000000000003949a3057b97b39b--