On Sun, Jul 22, 2018 at 7:18 PM Emilian Bold <[email protected]> wrote:
> 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. Create a maven project that depends on every NetBeans module. Then use my maven-merge-dependencies maven plugin (on Github, part of Giulius) to try it ( unlike the assembly plugin, it will concatenate META-INF/services files and merge properties files under META-INF). Probably the result would violate lots of assumptions, but with some work.... I recall from performance work over a decade ago that the biggest win was putting everything on the boot class path. Any such jar will do better if the classes are ordered in load-order. -Tim > > 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 > > > > -- http://timboudreau.com
