In the 1st idea if everything is static you don't need lookup listeners perhaps, you don't need module.install, etc. Probably doesn't gain you much except realise NetBeans would work without our specific module system.
The 2nd ides is about compiling at runtime. If an user never touches a feature it remains source code on disk. The stuff that gets used gets compiled at first module load by the module system. Many modules are simple and just need javac and the dependencies JARs in the classpath, it might work. Also not a big feature but it might make things interesting. What if fixing a small bug is just applying a .patch to the IDEs own source code which will get recompiled on restart? Odd, right? --emi ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 21 July 2018 10:59 AM, Geertjan Wielenga <[email protected]> wrote: > Cool thought experiments. It would be interesting to explore -- although I > > wonder how much real performance gains there'd be with the first approach, > > i.e., one of the best features of NetBeans is its modularity, if we were to > > explore dropping that, or creating some kind of distribution without that, > > would we gain anything -- and if that would be performance, would that be > > significant enough to warrant all the work involved? The second approach is > > basically what we have right now in Apache NetBeans Git, i.e., the 9.0-vc3 > > tag can be cloned by anyone and then built from scratch. > > Gj > > On Sat, Jul 21, 2018 at 9:10 AM, Emilian Bold < > > [email protected]> wrote: > > > I've been wondering the other way: what if we rip out all the module > > > > system and have a single fat JAR for NetBeans? How much can we optimise if > > > > we know there will be no runtime module enable/disable, no layer changes, > > > > no global services showing up, etc? > > > > How many plugins do users really install? What if they generally install 0 > > > > modules? > > > > On the other side of the spectrum: could we perhaps distribute most > > > > modules are source code and compile on the fly? What if we have a small > > > > binary bootstrap and the obvious dependency on javac and just make the > > > > whole release a big source tar? Would certainly make 'convenience binaries' > > > > a thing of the past. > > > > --emi > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > > On 14 July 2018 2:35 AM, Laszlo Kishalmi [email protected] > > > > wrote: > > > > > Well this question is to Jaroslav Tulach mostly. > > > > > > From Java 9 there are three modularization system in Java. OSGI, > > > > > > NetBeans and Java's JigSaw. > > > > > > My question is could NetBeans be ported on JigSaw? What would we gain > > > > > > form that movement (if any), and what would be the pain points. > > > > > > I'd even would like to see a deep analysis on this topic on Jarda's blog. > > > > > > Thank you in advance! > > > > > > Laszlo Kishalmi > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > For further information about the NetBeans mailing lists, visit: > > > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
