On Sat, Jan 11, 2020 at 8:07 PM Eric Bresie <ebresie...@gmail.com> wrote:
> I would think they might be value from the platform perspective to allow > modules to interfaced with a little external from the platform as well as > bringing in modules external to NB platform. > FWIW, there is this oldish prototype: https://github.com/apache/netbeans/pull/291 Where the intent was to allow NetBeans modules depend on JDK modules (although not on JPMS/"Jigsaw" modules in general). > Not to mention if it migrated towards a standard module mechanism it > avoids YAMS (yet another module system)...although I acknowledge the NB > historical module aspects (documentation, books, plugins, etc.) may still > have value as well. > One of many things to note here is that the JPMS does not allow so called "split packages". I.e. having two modules having package with the same name (the precise definition is a bit more complex, but this simple one should be more than enough in this case). And in NetBeans platforms, the two lowest-level modules are openide.util.lookup and openide.util. And both these have the org.openide.util package. So any attempt to convert NetBeans modules to JPMS modules will necessarily need to solve this problem. (There are some other cases like this, but these two modules are so basic, and yet so difficult to change, that I've never really thought about any other case.) Jan > > I guess this begs the question what is the means by which new JDK features > get brought in to NB IDE and Platform? > > Assume some new feature is introduced (i.e. nio, lambda, modules, etc.) in > JDK, which gets added to some existing code, requiring the dependency JDK > be added to the Netbeans build (and/or run time) infrastructure, module / > plugin dependency recompilation, repositories etc. and eventually if > functionality was deprecated (i.e. Corba, Applets, etc) then that code > would need migrated out (to plugin) or replaced with more applicable new > technologies. > > I seem to recall there being tips to identify possible JDK improvements > (like lambdas) which could be run across code bases...maybe doing so on the > NB platform and IDE would be a worth wild activity. > > I’d hate for NB to get stagnant with old (potentially depreciated) > functionality or get left behind > > Eric Bresie > ebre...@gmail.com > > On January 9, 2020 at 8:11:09 AM CST, Neil C Smith < > neilcsm...@apache.org> wrote: > > On Thu, 9 Jan 2020 at 13:53, László Kishalmi <laszlo.kisha...@gmail.com> > wrote: > > > Where there are similarities, NB modules are dynamic, Java modules are > > > static, at least as far as I know. > > > > There are some interesting OSGi / JPMS projects around, such as > > https://github.com/tjwatson/atomos - although only glanced at it. Not > > sure if it can be made to work in any useful way with NetBeans' OSGi > > integration. Interoperation would be really useful - at some point in > > the near future I'd at least like to find a way to add in libraries on > > the module path to an RCP application. > > > > Best wishes, > > > > Neil > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > >
