Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Attila Kelemen]

I can't tell exactly how many native usages there are, because not
everything we potentially need to integrate with I'm aware of. However, I
still have a decent idea on what I can reasonably expect, and my assessment
tells me that there would be at least 2 (though one of them is split into
many parts, but probably could be merged together, but that is something
I would need to do most likely knowing its maintainers), and maybe 3, I
can't really see more. Though I have to admit that I have been surprised in
this regard that some libraries are using native for nonsensical reasons.
Anyway, the main issue is political. If I push other people for
modularization, then I will have to battle a lot where every extra reason
just makes it more likely that I can't push through with modules
(especially if it can be argued that - in theory - you can never be sure
that your otherwise perfect (lol) application will not break under rare
circumstances).

I have no problem building the JDK at home and I do have experience with
its codebase (I did implement string interpolation for myself in it before
templated strings were proposed to play with the code), but I can't do that
on these internal projects.

And yes, probably properly structuring the code (which in part is legacy)
is more effort than messing around with flags, but given my experience how
arguments go, this will be just put into an additional independent issue
category giving it a lot more weight, and if it ever breaks something for
someone, I'm 100% that I will be hated for it, and I'm not a JDK developer
to be so used to be hated on :)

As for additional module benefits: I am anxiously waiting for something
that would move the world towards being modular, because so far modules are
barely used (even for new projects). One thing the JDK could improve in
this area is if it provided benefits for big libraries, because currently
it offers very little, since a library (who has no control over its users)
cannot have any trust in "exports" at all (and it must expect to be on the
CP in general), even though libraries would greatly benefit from "exports".
It would be nice, if the library could choose to mark itself as requiring
to be used as a module even if put into the classpath (in which case it
would be moved out from the unnamed module). Then maybe large libraries
would start to take it more seriously which could even give a push to
better tooling support (at least to avoid duplicating redundant information
between the build and module-info).

Ron Pressler <ron.pressler at oracle.com> ezt írta (időpont: 2023. szept. 4.,
H, 19:15):

>
>
> > On 4 Sep 2023, at 17:07, Attila Kelemen <attila.kelemen85 at gmail.com>
> wrote:
> >
> > So, the problem is that these people are unlikely to be very keen to
> modularize their app in the first place, and giving them an extra thing to
> point at (and people are very quick to find excuses), and my experience is
> that such an excuse potential will make my goal of convincing people a
> *lot* more difficult.
>
> Let’s make this more concrete, then. How many JNI libraries are used by
> the application? (We may be able to offer a source repo soon with the
> change that you can try, if you don’t mind building the JDK, and test the
> experience).
>
> The benefits from modules, most of which — maintainability and the
> possibility for robust security — stem from the integrity offered by strong
> encapsulation, are very powerful, but I admit they’re not easy for many to
> see. While writing a new modularised application is quite easy,
> modularising an existing large codebase is often not an easy task at all.
> Before the application can be modularised, its architecture has to be made
> modular — i.e. it must not make use of split packages and it must not have
> circular dependencies —and many codebases aren’t (the JDK wasn’t). The work
> required can easily dwarf the JNI flag to the point of making it
> insignificant. In such situations, maybe the codebase reaches a point where
> people realise they cannot easily move forward without modules (as the JDK
> had realised) or people understand the benefits they gain, which,
> admittedly, is not always easy because the benefits all involve future
> evolution or unknown vulnerabilities. But in other situations, modularising
> a large, existing, codebase may or may not be worth it. When you write new
> code, we suggest that you might as well modularise (even if you don’t
> understand the benefits) because it costs very little, and you may thank
> yourself for doing that later. Similarly, if you have a straightforward
> library, as that’s not hard, and will make life easier for you and your
> future users. But we’re not telling people that they should work to
> modularise all of their old applications, certainly not if they’re not
> happy to do it. The feature is there for new code and for those who really
> want it; in the future modularised applications may even enjoy other
> benefits. Modularising the JDK has helped the Java ecosystem a lot, but for
> old, large, complex applications your mileage may vary. In other words, we
> can’t and don’t tell people that the work required to modularised a large
> old application is always worth it.
>
> — Ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230904/3e1a6b74/attachment-0001.htm>