<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>When I wrote "stop using the module system" I'm obviously
            talking about the application itself being modular. I would
            have expected that you also believe that it would be better,
            if applications were modular. Given that I assumed from what
            you wrote that you regret the fact that modules were not
            added on day 1 (in which case there would only be modular
            apps most likely). Yet, this JEP just motivates people away
            from modules.<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I don't think this is the case. Instead I think there is a lot of
    potential for a much better story. Modules lend themselves to doing
    a lot more at build time and setting things up for simple/fast
    checks at startup (think post resolution checks).  It's not hard to
    think about fail fast if a module requires the "restricted methods
    or native code" capability that has not been granted. Combing a set
    of modules at link time also has a potentially interesting story
    when using jlink to create an application that has an initial/main
    module. In that case, you can think about checking capabilities (or
    whatever term is introduced) at build/link time.<br></div></blockquote><div><br></div><div> I'm a bit confused, because I don't think your response is related to the quoted text, but I'll try my best.</div><div><br></div><div>I was referring to the fact that it is easier to opt-out for a non-modularized app from this JEP (I mean to avoid warning now / error later), than for a modularized app which creates a perverse incentive to avoid creating modularized apps. As far as I understand Ron (what he wrote in an email sent after your email), then the current position is that he (and whoever else he represents) is not convinced that people who would modularize their application mind the additional difficulty. Since I can't exactly provide a proof to the contrary (just have my experience, which is obviously inaccessible to you), I will leave it at that for now.</div><div><br></div><div>As for "fail fast": That would be great, but that is another of my issue that - in its current state of the JEP - it is not possible, because that would require the future work section, which I consider to be too important to leave it for the undefined future (so important that I think without it this JEP carries some danger with it). And the phrasing "we may explore ways" in the JEP doesn't sound like a commitment either. This is because without fail fast behaviour what is expected from users? The assumption of the JEP that a user is unsure about the native usage within his/her app (which for example is true for me, because I had my share of nasty surprises because of it). However, this person now has to list all the modules using native using modules. How is he/she supposed to do that? Run the app, if it fails (for now prints warnings), then add the command line option, and try again until the problem stops? But even after doing so, the user can never be fully confident that the app will never have a surprise native call based on some rare to trigger condition (and rare trigger did happen to me in practice).</div><div><br></div><div>As for "link time" module choice: It is an interesting option which I actually did not consider, so I have to think about its implications more. But regardless, it does not affect the option of making opt-out from this JEP</div><div><br></div></div></div>