Damn, I have no idea how that got into there. Ugh.

No worries we all make mistakes. Hope your channel gets some more views

Yes. There used to be a website called "do I need Kubernetes" it would always display "No". Kubernetes was designed to solve Google scale problems. This is a real need, but very few of us truly face it. I worked with a few companies who serve as infrastructure for other companies, in such situation downtime would mean a cascading effect that would bring down many sites. In such rare cases Kubernetes restrictions make some sense. Even in the places where it doesn't make sense it became the de-facto standard, and as such we need to know it. For better and worse.

It's the same thing. It was all packaged under a single umbrella starting with Java 9.

I would argue those are advantages. It's a matter of perspective. E.g. on microservices we have a hodgepodge of versions and features with very little standardization. No enforcement or control. A new vulnerability comes out... Our team needs to go through everything and hope that everything is clear and documented. It might be reasonable if we have an army of developers but for a more moderate team just updating the main project pom is so much simpler. It's interesting that you mention testing... Integration tests are FAR simpler with a monolith, I barely need to set stuff up to get amazing coverage. With Microservices it means I need to bring up a cloud of complexity just for a simple integration test. Then there's the test failures which are absolutely unreadable. Unit tests are simpler in Microservices but that's a bit of a misdirection because they don't cover as much.

Not twice. In this particular class the speed was about 40% faster for Hotspot but to be fair, it's an edge case. Typically you won't see such pronounced differences and this was done with the CE version of GraalVM. If you use the full performance version (which is free now but wasn't when I was making this video) performance should be MUCH better. Notice that in my latest startup I wanted to use GraalVM and ended up skipping it after a while. It has amazing benefits but the issues related to longer CI cycles and problematic testing made it less appealing. But I'm keeping my eyes open and hopefully will use it in future projects: debugagent.com/building-gdocweb-with-java-21-spring-boot-3x-and-beyond

Sure. Lets say I have n = x + y + z; With operator overloading this will be: var temp = x.plus(y); n = temp.plus(z); If the type is BigDecimal or Long then it would include an object allocation. That's two method calls and a redundant temp object. With methods I could just write: n = x.plus(y, z); Which will add all three numbers and allocate one return object. That's more efficient. This becomes more pronounced when working with vectors and complex mathematical constructs that might need significant allocations.

@@debugagent Thanks a lot for your reply. If we assume we are working we with BigDecimal, I am guessing your plus would like as follows BigDecimal plus(x,y) { var result = this.add(x); return result.add(y); } Are we not creating two new objects as well here? Sorry if I didn't quite follow your comment.

@@bharathpasham BigDecimal is indeed a less ideal example because we can't change it and can't manipulate internal state easily (although manifold does allow that). Let's take the case of Vec which is 3 different values in which case the vec plus method would be implemented as: return new Vec(x + other.x, y + other.y, z + other.z); So we'd save on an allocation and on a method call.

@@debugagent that makes sense! Thanks :)

Are you referring to things such OSGI or just informal project organization? Famously, monoliths at companies like Ebay, Amazon etc. were just divided based on layers and were difficult to maintain due to that division. OSGI garnered excitement, but I never ran into a project that actually used it for backend in all my years as a consultant. The main thing I'm talking about are standardized approaches for modularity that allow enforcing the module boundaries. These existed before but are only starting to gain awareness/traction recently.

Historic monoliths were focused on layered architecture as opposed to standalone modules (similar to microservices). A company could rearchitect their monolith to use modules in the past but there was no way to enforce that efficiently and effectively. Spring Modulith (which recently reached 1.0) is a tool that both enforces that separation and provides a lightweight event bus (instead of MOMs). That's one thing that changed. Another thing is a change in mindshare. I figure that by now we all have enough real world experience with microservices, this has shown both the problems and the advantages of that approach. My second focus here is to show how the advantages can be a part of a monolith as well and are not exclusive to a microservice architecture.

I worked with a few companies who would disagree with that assertion. I agree that in most/many cases they are the wrong choice.

@@debugagent i once fixed a company by turning their microservice architecture to monolith. They became a market leader and was bought out for $500 million. The company that bought them rebuilt the into microservives. It was dead 14 months after launch.

@@beachbum868 that's a great story 🤣 I'm generally with you on the advantages of monolith over microservices, that's a huge part of what this video is about. I think a lot of the "scale" advantages have been overblown and a lot of the disadvantages are barely discussed.

@@debugagent I'm not aware of any advantage that methodically breaking all your code up into small chunks of http daemons dispersed randomly through a data center brings.

@@beachbum868 I have this counterpoint post where I discuss this: debugagent.com/when-should-we-move-to-microservices The TL;DR is this: * Microservices work only if you have a huge OPS team. They shift the complexity from developers to OPS and that has some advantages since OPS have some tools they can use for scale. They are more agile when things shift in production and can rearrange complex systems. * Microservices make sense when the natural data is there. E.g. when we have multiple existing systems that we need to interface with. Separating them into fault tolerant systems under our control helps. * They work well for huge teams but not for the case where people just "run off and do what they want". A good example is a stock merchant app. We need to interface with the bank API, the stock exchange etc. We can do this directly from our monolith but that would mean we need to encode a lot of logic about how the various banks and exchanges work. If something changes or breaks we might need to update that logic and redeploy. But having a smaller completely separate project that encapsulates each can mean faster release cycles. It can mean we can use ops tooling to scale up/down the specific APIs and handle shifting dynamics in a way that's seamless to other applications. It can also mean that a future feature such as a securities investment application can reuse some of these services "as-is" without modification. Just to be clear... I'm totally for monolith in 99% of the cases. But that 1% does exist. The problem is that a lot of RDD (Resume Driven Design) pushes towards bad choices to pad said resume...

I think Kubernetes some very valid use cases in the very high end.

Thanks. I think it's better in newer clips. I filmed this quite a while back.

I use Sonar (cloud or qube). It's quite a bit more than a "linter" though... Highly recommended.

Thank you!

Is that a question?

Thanks. Yes it would fall to that problem. But when someone explains something don't take it as a lecture, take it as a conversation. Ask them questions back. If they got help that's OK because they would get help at work. If they got help and didn't understand the answer enough to explain it then they won't be able to discuss it. Since this is a very abstract problem I don't think spending a lot of time on it will give them an advantage. I don't want a written report. I think this only matters with take-home exercises where a developer literally codes the solution.

I don't have any information from @SM-vg7zl on this but even if it was supported I wouldn't mix Lombok and Manifold. The potential for a midair collision here is too risky. There are so many points where they both manipulate the same data. It's just not practical. What I would like to see is a Lombok compatibility layer. Supporting some of the top annotations from Lombok, maybe even with the Lombok package for ease of porting. This seems like something fun and probably not that hard since Manifold did most of the work already.

The subject of Nullability came up in the Manifold slack and it's a bit difficult. Hopefully it can add an operator like the .? which would be great. Nullability hints will probably come to Java as part of Valhalla: mail.openjdk.org/pipermail/valhalla-spec-experts/2023-May/002276.html IntelliJ and SonarQube already detect most cases of potential NullPointerException and also detect cases of redundant null checks (e.g. value is assigned with new operator and then != null is tested).

Imho types should be non-null by default, that would already prevent some bugs from being implemented. Other languages have implemented this language feature already, like Dart and also C# 8.0 as an optional setting.

@@continuousable Kotlin's feature is problematic. First off, it doesn't map into the VM. Without that you only get the restrictions without the performance benefits.With Valhalla Kotlin might be able to truly leverage this feature, but Java developers would be able to as well... These sorts of features only solve the "low hanging fruit". Null is problematic inside data (e.g. null element in a DB or a Map) at which point it bubbles up until it reaches a variable. Uninitialized variables are the easy things to spot and fix. Sometimes Kotlin will hit this during compilation which is nice. Luckily, IntelliJ is also smart enough to show such bugs in the IDE when we write Java code (so are tools like SonarQube). But it doesn't address the truly hard to fix bugs... With Kolin we have a special notation for nullable variables. But it solves very little in terms of the truly difficult real world bugs.

@@continuousable Well, author explained that non-nullable reference types are prone to errors that hard to detect. Just because that null state is masked with some probably meaningful value. NPE signals about bug, it is not a bug itself.

I think I discussed it in one of the first videos in the series. But you're right, it's worth repeating.

No. Manifold is a compile time language extension more similar to Lombok but with a cleaner architecture and MUCH wider scope. When you write code it appears that the method was added to the existing class. This is especially cool when you start working with other Manifold capabilities such as operator overloading etc.

Thank you!

Thanks! It's a very ambitious project and as such it's a challenge to explain it. My goal is to find the various "hooks" and explain them instead of explaining the project itself. Focus on the use case rather than on the solution.