I'm Ken Kousen. I have entirely too much academic training (two BS degrees from MIT, an MA and a Ph.D. from Princeton, and an MS from RPI), I'm the author of six technical books about Java, Groovy, Kotlin, Android, Gradle, and Mockito, I've given talks at conferences all over the world, and I have 25+ years of experience in Java and related topics. Let me help you understand what's important in the IT world and what isn't.
"Tales from the jar side" is a pun on (1) The Far Side cartoons by Gary Larson, and (2) how Java applications are delivered as "jar" (Java archive) files. It's about my continuing Java journey. Lame, sure, but I'm committed to it now.
By the way, my last name is pronounced "cousin", like the relative, even though it doesn't look like that.
Source code is at github.com/kousen/LangChain4jChatMemory . You'll need an API key from OpenAI (set as the OPENAI_API_KEY environment variable on your system) in order to run the tests, but you're welcome to use the code however you like, given the MIT License.
hi ken , Can u pls provide a link to the long form vid. The search for his name is not giving any vids in your youtube playlist. pls help. ( BTW , your work on How to manage your boss is Awesome Thanks for doing it )
I'm trying to understand functional programming and it seems that applicative functor are used for validation as well. what is your opinion about that?
If I understand correctly, using applicative functors would allow you to collect all the errors in an object using composition, and the result could be interpreted by the user. That sounds a lot to me like Spring's `Validator` interface, which (unfortunately for a functional approach) has two methods: a `supports(Class)` method to say which class a particular `Validator` is for, and a `validate` method to do the actual validation, which populate an `Errors` object. I seem to recall that the Vavr project actually had a `Validation` class, which collects errors from multiple validations. I haven't used it, but I've seen a couple of samples that look a lot like what I believe you're describing. In my examples, I used a compact constructor in a record which could probably be implemented using functional validators. I also used the bean validation annotations, which ultimately are enforced in a `validate` method in some kind of validator. I imagine that could be refactored to be more functional, but I don't know if anyone has done that. If you hear anything, please let me know. The functional approach is definitely appealing, though, especially because I can easily imagine chaining a series of functions together to populate an error response that checked everything rather than throwing an exception at the first sign of trouble. Thanks for the question!
Thank you very much for this and all other your videos. I've just recently opened your channel - accidently came across your old presentation on Devoxx at first. Your style and presenting are amasing) One of the best mentors ever!
Great video! One question, did you choose to use Strings to represent the model type instead of using an Enum, like you did with the Voice or ResponseFormat, primarily to demonstrate the @Pattern validation method? Or was there some other reason why you preferred a String over an Enum?
Yes, that was one reason. Another is that I thought they would add new models more often. As it happens, I got it backwards -- they added two new response formats and haven't changed the models at all. Oh well. As you implied, you can go either way on that :-)
Sealed types are more about behavior than just the value. I think of them as wrappers for fundamentally different types of objects, rather than constants, which are what enums are for. Thanks for asking :-)
@@talesfromthejarside For the example given I would tend to agree for that. I disagree about sealed types being more about behaviour than value. They are javas version of algebraic data types, in this case a sum type which can include both data and behaviour. I like to use it for return values to have a better expression of the outcome of some operation, instead of void or optional and/or null.
@Mig440 Yes, I agree with all that. I oversimplified in order to answer on my phone. :-) They're about both value and behavior. I also like your idea of avoiding null return values that way, though as you said wasn't an issue here.
speaking about reactive code, have you tried Vertex? it is used with Quarkus and it looks not so bad in terms of code readability and apparently it is 3 time faster than reactive in spring boot
Not better. More efficient. 🤔 OOP foundation remain the same which make programming easier to manage. We tested these in my Data Analysis Course. The majority approved this conclusion. 😊
Excellent video with plenty detail explanation. I do have one question though: With realtime systems we used to say - stay away from new object creations as much as possible. With records you do not have an option to adjust the data other than creating a new record, like you did in the beginning. With the improved GC's and serious horsepower we have nowadays, do you think it is still better to use a DTO with getter/setter and pass that around, or use records and simply return a new instance when you do need to adjust some data. Personally I find using records great as input and output carriers, and old-school DTO's inside the app between different services/layers (old old habits die hard!). As always not a hard rule.
Yeah, that's a legitimate debate. A lot of it comes down to immutability being so useful when concurrency is involved, because shared mutable state is so hard to get right. But I understand your concern
Looks almost like Rust, nice😀One more thing that I love about records is using record patterns to deconstruct their values, e.g. case Result.Success(var astronautsByCraft) -> processor.printResults(astronautsByCraft) or case Result.Failure(var error) -> System.out.println("Error: " + error);
20:19 IMHO such a benefit in the platform is a big deal, even if I don't use the feature directly! The big story with the system-level features like virtual threads (and somewhat, with modules) is that Java is looking beyond feature-parity with C#: they are looking at Node/Javascript for areas to improve. This is true with respect to throughput metrics, start-up times, binary footprint, and release cadence (IMHO modules and cleaning up the JDK facilitates faster feature development).
I find records to be an anemic and insufficient replacement for lombok. Sure, once you consider pattern matching it's now useful, but otherwise? Nah. Virtual threads are huge. Even if you are just doing a request/response (with no meaningful concurrency control between requests) you'll scale far better. Getting the benefits of reactive w/o the learning curve shouldn't be overlooked. Its one of the rare things i think java's solution is *better* than async/await, co-routines, etc. Its essentially transparent (everything in java has an asterisk) Modules are so you can now treat logical boundaries the same as physical. i.e. all the separation of microservices but with the low price of a monolith. I'd agree it was a dollar short and a day late, but i love the idea. Kind of obnoxious things like spring modulith don't even leverage it.
Oof. I knew I overlooked something. I'm not sure what a good icon would be for that, too. :) Mostly I use the getFirst() method out a lot on lists, so I would put sequenced collections at the "Okay" level, because it does exactly what I expected. Thanks for noticing.
Great summary - agree big time with the shell rating. Never used it and not missing it either. tbh I work 99% in Spring env, so the HTTP client is pretty much optional for me. TextBlocks is a major feature in my world. Building a lot of rather large json payloads and then testing the app with that - text block is pure magic!
another thing about jigsaw is that although it supports modules AFAIK it does not support version numbering, meaning you can't specify what version you require which is one major minus, and still might give you jar hell, oracle killed java 9 as soon as they decided with their dumb money grabbing scheme of release versioning of every 6 months, no one would upgrade to a version which would be killed in 6 months, and they probably knew that.
Yeah, version numbering in modules is definitely an issue, which I think OSGI handles. I don't mind the six-month release schedule, though, or maybe I'm just used to it by now. Most companies only care about the LTS releases anyway.
@@talesfromthejarside you need to remember that when 6 months schedule was released there was NO free LTS TCK jvm's available, and java 8 LTS was declared to be end of life in a year (and afterwards it would paid) , so you had to pay up, when i saw this, i've figured it would be the end of java as no company would risk trusting them again, corretto literally saved this. not to mention breaking backwards compatibility, consider that jaxb was removed from the jvm because it was thought of as j2ee technology , buy then they went and inserted HTTP client on java 11? cause that's not j2ee? for the record i've thought about replacing our commons http client for that, but then i remembered we also used http server in our j2se server, so what's the point .
super-fun video: thank you! Some comments: (a) I also encourage everyone to read Brian Goetz' article on data-oriented programming, which combines several features into a unified idea. (b) The history of modules, as Ken surely knows, is more complicated, as the OSGi initiative (re: bundles) was getting traction circa 2010, and there were other competing ideas as well. The Java team decided to do their own spec, and _then_ start with the JDK, which took a long, long time. There was serious debate in the community over this; pundits wondered if it would ever be complete (and the OSGi camp was incensed that their work wasn't being used). Java 9 was _finally_ the end result. If the Java team had waited longer, it would have only extended the uncertainty and acrimony. I do agree that adoption and impact seems to be quite low.
Right. The way I remember it, there were members of both the OSGI and the JBoss modules teams on the committee. I think the result was good. It's just that most devs didn't realize they could upgrade and safely ignore modules if they wanted to. Thanks for the comment!
@@koncz314 well that would have meant no virtual threads. Java modules for the JDK is absolutely essential for that as has been pointed out on numerous occasions. The JDK from before was an unmaintainable mess that got reined in by modules. Modules outside the JDK needs to speed up but luckily it is happening albeit slowly. Try out avaje inject for example. No need for reflection magic to have DI. Now spring adopting moduels can hoepfully speed things up a bit. 😊
Fantastic! a question related to Data ingestion, do you have something or a link that is talking about ingesting and manipulating tabular data from csv, excel or that type of sources?
Sure! The source code is in the GitHub repository github.com/kousen/OpenAIClient, which uses the Spring framework for the implementation. Look in the package with "ollama" in the name for the vision examples. Good luck!
Unfortunately, the solution with keeping the transactional annotation did not work for me. I am probably missing something. I think I'll have to go with solution where we clean up before each test. Thanks a bunch!
Apache POI could probably do the job, but it's pretty low level. Probably depends on what you want to do. Some db drivers also can work with Excel files, IIRC
I don't think it does anything other than whatever the underlying AI tool does. Most of them don't handle that well either. But token limits keep going up and up, so maybe that won't be a serious problem for you
