+1 to Alexey's ideas. As for annotations, I actually can see the difference between Expirimental and NonStable. The latter means that a feature works, but its API can still be changed (in other words, no backwards compatibility guarantees). The former is just something that is under development, can't be tried out, but can't be relied on; potentially, something that can be removed completely. I'm not sure if this can be applied to any of our current situations, but as a general rule - makes sense to me.
I do not support adding the NotRecommended option though - such functionality should be just deprecated. -Val On Tue, Dec 8, 2020 at 7:41 AM ткаленко кирилл <tkalkir...@yandex.ru> wrote: > +1 for modules > > 08.12.2020, 16:02, "Andrey Gura" <ag...@apache.org>: > > Definitely agree with Alexey. Separating API declaration from > > implementation could really improve system design and avoid coupling. > > > > About extending @IgniteExperimental annotation. It doesn't look good > > to me. We should consider any API either experimental or stable. Third > > option is deprecated API. Merging API which is known in advance that > > it is unstable is a very bad idea. > > > > On Tue, Dec 8, 2020 at 3:48 PM Nikolay Izhikov <nizhi...@apache.org> > wrote: > >> Hello, Alexey. > >> > >> Think we can extend our @IgniteExperimental annotation. > >> > >> `@IgniteExperimental` - mark features that are truly experimental and > can be completely removed in future releases. > >> `@NotRecommended` - mark features that widely adopted by the users but > implemented wrong or have known issues that can’t be fixed. > >> `@NotStable` - mark features supported by community but API not stable > and can be reworked in the next release. > >> `@Stable` - mark features that are completely OK and here to stay. > >> > >> We should output notes about these annotations in the JavaDoc, also. > >> What do you think? > >> > >> > 8 дек. 2020 г., в 12:49, Alexey Goncharuk < > alexey.goncha...@gmail.com> написал(а): > >> > > >> > Igniters, > >> > > >> > I want to tackle the topic of modules structure in Ignite 3. So far, > the > >> > modules in Ignite are mostly defined intuitively which leads to some > >> > complications: > >> > > >> > - Ignite public API is separated from the rest of the code only by > >> > package name. This leads to private classes leaking to public API > which is > >> > very hard to catch even during the review process (we missed a bunch > of > >> > such leaks for new metrics API [1] and I remember this happening for > almost > >> > every SPI) > >> > - Classes from 'internal' packages are considered to be 'free for > grabs' > >> > in every place of the code. This leads to tight coupling and > abstraction > >> > leakage in the code. An example of such a case - an often cast of > >> > WALPointer to FileWALPointer, so that the community decided to get > rid of > >> > the WALPointer interface altogether [2] > >> > - Overall code complexity. Because of the lack of inter-module > >> > interaction rules, we are free to add new methods and callbacks to > any > >> > class, which leads to duplicating entities and verbose interfaces. A > good > >> > example of this is the clear duplication of methods in > >> > IgniteCacheOffheapManager and IgniteCacheOffheapManager.DataStore [3] > >> > > >> > I think we need to work out some rules that will help us define and > control > >> > both Ignite public API and module internal API which still defines a > clear > >> > contract for other modules. Some ideas: > >> > > >> > - Perhaps we can move all user public classed and interfaces to an > >> > Ignite-API module which will have no dependencies on implementation > >> > modules. This will prevent private classes from leaking to the API > module. > >> > - We need somehow define which classes from a module are exposed to > >> > other modules, and which classes are left for module-private usage. > Maybe > >> > Java's jigsaw will help us here, but maybe we will be ok with just > more > >> > strict java access modifiers usage :) The idea here is that a module > should > >> > never touch a dependent module's private classes, ever. The exported > >> > classes and interfaces are still free to be modified between > releases, as > >> > long as it is not a user public API. > >> > - A module should be logically complete, thus it may be beneficial if > >> > module name matches with the code package it provides (e.g. > configuration > >> > -> org.apache.ignite.configuration, replication -> > >> > org.apache.ignite.replication, raft->org.apache.ignite.raft, etc) > >> > > >> > Any other principles/rules we can apply to make the code structure > more > >> > concise? Thoughts? > >> > > >> > --AG > >> > > >> > [1] https://issues.apache.org/jira/browse/IGNITE-12552 > >> > [2] https://issues.apache.org/jira/browse/IGNITE-13513 > >> > [3] https://issues.apache.org/jira/browse/IGNITE-13220 >
