<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Attila,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Good response! I can further address this.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">That said (ending on a provocative note lol), I am <b><u><i>1000000% onboard for the idea of Java entering into the build tool world and offering their own build tool</i></u></b>. 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 :/<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you for your time!</div><div class="gmail_default" style="font-family:monospace">David Alayachew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 3, 2023 at 3:11 PM Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com">attila.kelemen85@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">CC <<a href="mailto:4evnyuij@gmail.com" target="_blank">4evnyuij@gmail.com</a>> ezt írta (időpont: 2023. okt. 3., K, 17:36):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div name="messageBodySection">
<div dir="auto">Hi,<br>
<br>
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?<br>
<br>
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.</div></div>
</div>

</blockquote></div></div>
</blockquote></div>