Does Java 22 Kill Build Tools? - Inside Java Newscast #63
HTML-код
- Опубликовано: 25 июл 2024
- #Java 22 brings multi source-file execution to the platform. It allows us to run programs consisting of multiple source files and even dependencies with just a simple `java` command. For experienced developers, this will make exploration and experimentation simpler but it's a real game changer for people just learning Java or even just to program: They can now write Java code from single to multiple source files and even add dependencies before they need to consider an IDE or build tool.
JEP 458: openjdk.org/jeps/458
~~~ Chapters ~~~
0:00 Intro
1:24 Launching Multiple Source Files
3:10 Launching With Dependencies
3:44 Compilation Odds & Ends
4:42 But... Why?
6:34 Outro
Tags: #Java #Java22 #OpenJDK 
Наука
I actually think this is a huge change for the tutorial/beginner/basics part of the java community. Makes applications easier and less overwhelming for beginners to run. IDEs are often introduced (too) early to reduce overwhelm in the building/compiling process of files.
That's what I'm scared when first time learning C#. With dotnet, I even don't know how to compile a single .cs file and run it. And someone told me to setup a project first, but what is a project, why I should do that, I just want to run my hello world code!!!
so do you propose to start learning programming without IDE, like from notepad without assistance in syntax, highlighting tools and imports? how offen you run java code from console? just useless.
@@ITksh-zp1ob For learning purpose, I think the best way is a single file and a single button to run. I can just create a single text file and write code with vscode and press F5 to run when I'm learning C/Cpp/Java.
@@dragondove6197 so it is not needed in prod or for work purposes, does not solve business needs and have no business value. ok
@@ITksh-zp1ob yes, we are talking about beginners. For business eveyone uses build system. But for beginners, there is no java beginner's lesson started from maven, that will scare newbies
Multiple Java files with the java command is a great addition that will make running small prototype programs more convenient. Awesome! 🎉
It won't kill build tools
However, it will make poorly structure legacy projects run better and it will make bad managers feel good about themselves about their decision that build tools are just waste of time.
But those same legacy projects won't be affected until 2040, because they are still running Java 1.4.2 and the migration to Java 1.5 is still scheduled in 2025
This is some corporate MNC experience talking!
Man, that's bleak. 😳 But even in that world, it's probably a good thing that the poor people who have to maintain those no-build-tool projects will have another option to run them - even if only by 2040.
Can't wait for them to migrate to Java 8 by late 2030. 😂
Build tools are just a waste of time
@@bororobo3805ahhh, yes - the good old days when you had to code it all in machine code starting with BIOS 😁
I spent the worst 3 weeks of my life understanding maven in my first job because it was an integral part of the introduction materials they provided, this was the answer. This is what someone learning Java needs in order to have a better learning experience. Thanks
java becoming new starter friendly 😄 this was unexpected, after all years
Maybe in the future and with a few modifications, Java could be used as a scripting language in Linux.
This is a good change, but the reason i use gradle (and before that maven) is mainly to automatically fetch and install dependencies in a reproducible manner, and to automate the jlink and jpackage setup for exporting application packages. Building a native installer for a java applications feels more cumbersome than it should be right now.
Great work! I remember writing scripts early on with the -cp option.
I dont know If somebody brought this up, but this ist huge when it comes to serverless/cloud computing. I think this is a smart move for java to stay relevant.
This definately reduces the reliance on maven/gradle and forcing the programmer into a com.example. folder structure for a project that won't be published anywhere. It will go well with Makefiles
This is actuslly a grat festure that will help a lot beginners and students with all the extra configuration introduced by tool chains
This is a fantastic change and a first step in being able to build Java _with Java,_ instead of with XML/Groovy/Kotlin (ie, completely different languages)
I was surprised by how quickly it executed a Java command.
Then you haven't tried graalvm binary format yet
@@lufenmartofilia5804 I tried and "Hello world" compilation takes few minutes on my PC and required 8+ Gb of RAM
@@lufenmartofilia5804 yeah, while you're perfectly right about the speed, but the case here is you can run straight from source, without the extra compilation step, and that's the main benefit here. Speed is just added bonus.
Granted it would be fun to also have the option to do "native-image hello.java" :)
Finally java arrived to 2024 modern software development. Really nice feature for prototyping and exploring
The problem maven(or gradle) solves is not using that jar in that folder on runtime, it is to put the right jar required to that folder on build time to run your program on runtime. if you want to be the one who put that required jar to the correct folder then turn back and use Ant.
very useful!
Will it also solve the problem of maven clean install not cleaning the target folder?
If you want to clean after install then you should use "mvn install clean" instead. Maven executes phases in requested order. Aaand you can even do "mvn clean install clean" to be extra clean ;)
Haha, Nicolas you're killing it definitely in this one, with the clown shell and the music… Well done.
Glad you liked it! My desktop PC has the matching 🎪-shell. 😁
Which ide and icon theme he is using
A build tool right in the JDK would be cool though, like Go and Rust do. Having something like "[tool] package" download dependencies, compile a modular project, and build a jlink image containing only the modules I actually reference.
I agree, at least for a simple tool. I don't think it needs to be feature complete but a way to at least get dependencies and build artifacts would be really nice. I think a good line to draw is their publication - that and everything related to it could be left to Maven and Gradle.
I agree. Installing rust gives you a lot of things (a build tool, a code formatter, the Rust Book, the API documentation) enough to play with on an air plane without Internet.
wow. i was actually looking for something like this. i need to test my gradle plugin. i don't want to write in shell or bat. so went for single source java. but now its getting complicated. this is huge thing.
rn, i am planning to create e2e gradle sourceset and it calls gradlew again...
If you're already working with Gradle, you could leverage Groovy which is great for precisely things like that.
Cool! What next, proper REPL? 😊
Dear God thank you. I remember java 8 classpath horrors still to this day
This is neat, but why does this toll the bell for Maven and Gradle?
I feel java have solution of every problem thank you
Huge!
What about a shebang line? Can it do that?
That works with a single source file since Java 11 (nipafx.dev/scripting-java-shebang/) but not with multiple source files. I think that makes sense because a project with multiple files isn't really a script.
This is a good news
This is extremely nice for beginners in Java. I love this change. But having compile errors show up even after program has started executing main is controversial to say the least.
Why did java not have these basic features in the first place? It always takes me 10+ tries to figure out how to compile a simple java project (every time I try to do it without an IDE)and another 10 to run it.
Would definitely have been nice to have this from day 1. But the same is true for enums, generics, lambdas, modules, virtual threads, etc. Can't have everything on day 1, though, and better late than never.
Ah, then maven, gradle are not just a build tool, they are dependency managing tools also. So, I guess they are still needed for a very long time.
No, this does not kill build tools. The build tools are very complex that manage dependences from many versions of jars, modules, etc. Let call it "dependences managers" to have working lightweight applications, frameworks or libraries instead of giant bundles.
Lightmode? I am appauled!
I like your nails matching your t-shirt :)
This is awesome, especially for scripting.
I see no Ant and SBT in the thumbnail :(
It's already too busy, sorry. 🤷
@@delabassee ☹️
I didn't heared a word after 4:11
Was it the game or the food? 😅
@@nipafx the food looks amazing :)
@@static-m-s It tasted great, too. 😁
With this features. Java 22 programm can be work like Nodejs.. where nodejs put packages in node_modules. 😄
Why does he look like Danilo Gallinari?
You should ask Danilo, he came half a decade later!
No.
what a ridiculous click-baity question to ask 😛
💯
Just want to point out this comment: "That you can run into compile errors during runtime, which we might not be used to"
Eh for every intellij user out there.
Eclipse is capable to run programs with compiler errors and as long as you don't run into the compiler error line (not function but actual line) you are totally fine.
And every eclipse user has the ability to fuck over any Intellij user. We are just nice enough to not do that. XD
not bad. but adoption rate for newer Javas is still horrible, and younger devs generation is not picking it up. worth trying J22 vs Python hackathons to reach that audience with such new features
Gradle can die any day.
yeah, good luck downloading the dependency tree one by one.
TBF i'm not adreassing the feature, which is cool and long overdue - it's the obvious clickbaity claim in the title that i'm after. Why the F can't Java ecosystem just stay mature and serious 🤦
Because the playful clickbait means that twice as many people get to watch the video and hear the news. I think that's worth the 80 seconds suspense it took to resolve the tension.
@@nipafxeh, yeah i get it... it just makes me sad to see such tactics used in this area, that's all
@@zoladkow May I ask where on RUclips you saw the video when you clicked to watch it?
@@nipafxyeah, no problem, sorry it took so long tho' - it's in my subscription feed. And, otherwise, while i get usual suggestions for Java topics in general (ie. Spring, Graal, etc) I don't get them for this Java channel. But luckily my subscriptions are manageable enough, so I don't miss anything even with a few days of break.
Also, Nic, my soft skills are terrible, but I realize how I may come across in my comments - just wanted to say I don't have anything against you personally. I see what you are doing and I get why you are doing it and I think it's on the right level. And I know i am not the target audience.
My issue is (beside myself, duh!) that this channel mixes different topics and delivery styles. I worked with Java since, oh a few years, and I feel attached. While it might be unfounded i expect some seriousness from the source of it. I prefer concise and to-the-point information delivery. I can be psyched about new great stuff on my own without a show or hype - i think i'm good with just plain text. But talks with some deeper insight from architects behind it all is what I especially like.
so Java is turned into an interpreted language, which the detractors have for 25 years claimed it is as an argument for how slow and bad Java is.
Java has always been a (partially) interpreted language: All code that the JIT didn't yet get its hands on runs in a bytecode interpreter. This addition doesn't change that - the JVM still interprets bytecode before JIT kicks in. All that changes is that you don't need to explicitly create that bytecode with javac anymore. Instead, the Java launcher will compile in memory.
So, at the end of the day, under the hood which is the difference between javac helloworld.java - java helloworld and java helloworld.java?
That you will have a class file in disk.