Відео

how about this one *_new File("path").mkdir();_*

i need this cup)

What is a factory method?

i’m so confused

Q: Differences between an interface and an abstract class? A: Just use golang instead of dino-java

É muito interessante o formato de apresentação dos vídeos... 😍

After the explanation, I still fail to understand the point of this

Use interfaces as a communication contract, designed to decouple your code from particular implementations. This way you can switch a certain service or layer for another easily, you just have to honor the contract

Is that Jose Paumard? This guy's course on completablefuture landed me my current job. Thanks Jose!

I thought they were the same thing

Module import will be good fro scripting and shell related usage. Just yesterday, I was showing to my kids on jshell where they wanted to calculate #days to birthday, and I had to import time, time.format, time.unit packages 😑 when I know it's all related to time. This would solve, but have to wait an year.

Modules aren't used because they not useful to developers. They only really make sense in the JDK. If they had formalized dependency management on the other hand... Like why write import module in a script when I still have to somehow get that module into my class path???

Only monsters use star imports in checked-in code. Monsters!

Was really interested in that JEP once I saw it, like how it seems and will definitely try it out.

I've seen simple projects bloated with interfaces for the sake of abstraction. Yet they no more than 1 implementation 😅.

Wow Nicolai. You really promoting your own book on a IJN episode? Quite gauche.

In Java, there are 3 levels of mandatory granularity: 1. Project (Gradle or Maven), 2. package, 3. class/interface/record. Everything is a member of all 3. In C/C++, on the other hand, there is no mandatory granularity, so you can create one giant mess, unless you impose strict guidelines. So, what happened, in my opinion, is that Java developers just consider these 3 levels of granularity plenty, especially if they come from C/C++, which is often the case.

White theme code editor, that's blasphemy

I’m not really that interested in the imports section. It’s collapsed, it’s autosorted, it’s autocleaned, it’s autogenerated. If IDE wishes to use module imports, I’ll let it. If not, no big deal.

Don't want to start any controversies, but to me - it looks like JDK community is doing same thing C++ community was (and still is) doing with their implementations - reinventing bike, but making it so, that it has squared wheels. I think, just like C++, JDK does not know what it wants to be and simply adds whatever features it can, which makes Java lose its identity. It's as if there was a huge leap between JDK6 and 8 and then between 8 and 17 and then from there - everything is pretty much either "syntactic sugar", or features that 99% of developers do not use, or will not use. Yes - all these things are cool and all, but like modules - not practical. For modules, in particular, I think they would end up just dissapearing in several LTS iterations as no major platforms are using them. Guy, who commented here about - "wrong time-wrong place" (aka should have been part of JDK7) was spot on, in my opinion. For imports, kind of same thing. I don't even remember the last time I have imported anything. My IDE does that for me automatically. The only thing I need to do each time I install it is to configure after how many imports it should replace each import from a same package with '*'. In coporation I have been working - many people had common opinion, that in near future Java and JDK will only be used in major corporations as startups, mid-sized companies and etc look elsewhere (Go, Rust, etc...)

valhalla, day 3168

Most accessors are just boilerplate that accomplishes nothing over plain public fields. When you do need to have control over mutability, synchronization, constraint checking, derived value computations, etc. - sure custom accessor logic makes sense. The pervasive norm of “prefer accessors over public fields” doctrine, comes from the issue with API evolution. If you were to evolve underlying storage, add constraint checks, do copies, etc, you can’t without breaking callers. The pervasiveness of accessors is just an archaism of the Java. It’s completely unjustifiable lack of immutable collection interfaces, and lack of computed properties. All of the things you don’t have to deal with in languages from more than two decades ago. And the pace at which java evolves isn’t giving much hope as well (project Valhalla anyone?)

Back in school I was taught to use StringBuilder if using alot of concat, learned something new

This can potentially lead to spaghetti code.

Why not bring JEP 477 to all Java source files instead of just implicitly defined classes? It seems easy enough to make sure that code that compiled in Java 22 remains unaffected by the automatic module import, but perhaps I'm missing a corner case.

That’s nice, I wish I could import more flexibly like I can in Kotlin, Scala, or Rust. Renaming imports, renaming subsets, importing subsets, with sub-namespaces.

don't get or see any benefits, IDE is hiding imports, what the deal with add something by double click and choose right one? I am 14 y in backend developing, lot of projects behind and nowhere modules were applied. useless for servers.

1. Make piblic fields in the language 2. Insist you always must use private fields

Java modules got caught in a chicken and egg scenario: The demand isn't there because the major frameworks don't support it yet, but.. the major frameworkds don't support it yet cause there is no demand. We use star imports currently in production code, and honestly it's fine. your IDE knows where your types are from and will happily show you whenever it becomes relevant, we'l probably start using this

Unpopular opinion: Java module system should have released during Java 7 timeframe, so adoption would have been great. It got release at wrong time where everyone was busy with micro-services/docker/cloud.

Stream API such as map / filter / flatmap are very useful but not exist in Iterable. I think that is the usecase.

Maybe I miss something here, but as you stated in the beginning, many Java developers are using explicit imports for each type they’re using within a compilation unit. I wouldn’t feel comfortable importing all of a module compared to explicitly documenting what is needed. Sure, prototyping is fine with it, but where would I benefit from the module system in production?

Power of the WORA 🔥

I don't immediately think this will make a difference to adoption. I was enthusiastic about the module system when it was announced... until I saw it. Fine for library builders, a PITA for everybody else. I've literally never seen it used in projects anywhere, ever.

Too much coffee will kill you.

💯

Also default methods

I learnt that interfaces where used because a class can extends only one other class, but can implements multiple interfaces.

Abstract class can carry a state, as mentioned in the video; but not the interface. Also interface methods can be overridden but not abstract classes. These 2 key points are good enough to use abstract instead of interface if your case needs internal states and unmodifiable logics (final methods)

I would prefer an interface because of multiple inheritance

That's one of the questions where you think: man that's a stupid question And then you are at complete loss for words to wring out an explanation

Had this one once a time.

TIL Java Modules in Real Life are a PITA

Sir please don't use BGM..also improve the audio quality so that we can clearly grasp knowledge which is given by you..

As for me, building custom runtimes or native images entails so much overhead which moreover infilters the operation procedures, that it makes using java in greenfield cloud-native environment look more and more unattractive compared to other languages like Golang etc. Yes, the latter one and its libraries have not been as mature nor versatile as those for Java, but easy to write, build, deploy & operate, has a small memory footprint and starts fast.

The class diagram seems wrong. Set is not extending SequencedCollection.

How can i look all questions?

Thank you .. but could you please please please mute the background music as it is distracting and irritating. The music is unnecessary for this type of content. Content itself is great but the music makes it feel like when you are studying for an exam and you hear blast of TV noise coming from the other room.Thanks again

Can we create our own marker interface?

or just use NodeJs 😄