New candidate JEP: 458: Launch Multi-File Source-Code Programs

[David Alayachew]

Hello Attila,

Good response! I can further address this.

I think that the person that you are responding to raises a good point --
at first glance, this JEP seems to address the problem exhaustively -- just
find the Main.java, and all classes that it depends upon should get
compiled. You may need to add a few files/directories/regexes-like-*.java
onto that list, but it should be fine, right? Why do we need a build tool
after all? This strategy can scale pretty far.

The reason why a build tool is important and valuable to include is because
a build tool handles the work of letting 2 codebases work together when
they can't just point to each other's "latest version". If Project A is on
V14 and depends on V6 of Project B, but Project B is on V22, you don't want
to try touching that sort of effort WITHOUT a build tool. That would get
ugly VERY FAST.

It is this problem that a build tool was created to solve -- it allows
projects to depend on other projects without conforming to each other's
build tempo. Project B can pump out features as fast as it wants to, but as
long as V6 of Project B is available to Project A, then B and A are not
slowing each other down. THAT is what a build tool gives you. It allows you
to easily specify and grab V6 of Project B. And more specifically, Project
A can catch up to Project B at their own tempo, if they ever even do. This
"gradual migration" should be very familiar to Java developers who were
around for Java 5's generics and Java 8's lambdas.

This JEP (and really, Java in general) does not attempt to solve this
problem. This versioning and organization problem is left firmly in the
courts of build tools. A build tool does the work of gathering and
organizing THE CORRECT VERSIONS of each dependency. But once that is down,
Java (facilitates and enables) efficiently compiling and running the
pre-gathered and organized sources.

So, a project that does not (and won't soon need to) care about dependency
versioning likely doesn't need a build tool at all. Or more specifically,
unless there is a significant or frequent amount of dependency version
management, you can get by without a build tool just fine. But once you
need to manage that problem at scale, a build tool is the proper solution.

The only other reason to have a build tool is if other projects will want
to have YOUR PROJECT as a dependency. They are usually already depending on
a build tool, and thus, the most convenient way for them to grab your
dependency is by having your dependency be in the build ecosystem. The most
convenient solution (for them) is for you to configure your project to use
the mentioned build tool, so that your project is easy to add as a
dependency.

That said (ending on a provocative note lol), I am *1000000% onboard for
the idea of Java entering into the build tool world and offering their own
build tool*. I don't like any of the existing options and I think Java
would do a way better job of supporting this. Modules feel like a tacked on
after thought for most of these build tools, whereas Java themselves make
it feel like a first class feature that was there from the beginning. I
feel like if Java tried, they could soundly beat all these other tools and
offer a great solution that would do a way better job of feeding the
ecosystem over what currently exists. If only it was worth the effort :/

Thank you for your time!
David Alayachew

On Tue, Oct 3, 2023 at 3:11 PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> I don't think that fear is warranted, because you have to package any
> non-trivial application anyway, in which case you will have some kind of
> build (not to mention that compiling it has obvious benefits anyway). And
> if somebody wants to use it in a home project for his/her own purpose, then
> I don't see anything wrong with that. As far as I can see this just opens
> up some extra possibilities, if you want to leave some code editable after
> deployment (for the same reason you might want a single file).
>
> CC <4evnyuij at gmail.com> ezt írta (időpont: 2023. okt. 3., K, 17:36):
>
>> Hi,
>>
>> I’m not sure if the advantage of launching several source files will
>> encourage even using a build tool at all. A beginner might see this feature
>> given to them as something to make their beginning steps easier, but why
>> switch at that point? The mechanism compiles everything for them when
>> needed, and libraries can be specified over the classpath anyway. Why
>> switch to a proper build tool?
>>
>> I find the limitation of a single source file to be quite good, as it
>> encourages using the appropriate technology for creating larger scale
>> applications.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231003/8e9c393c/attachment.htm>