WEBVTT 00:00.000 --> 00:07.000 Okay, good morning, can I have a good morning? 00:07.000 --> 00:15.000 Can everyone in the back hear me? 00:15.000 --> 00:18.000 Okay, I did theater in high school and college. 00:18.000 --> 00:20.000 Maybe it's good for something. 00:20.000 --> 00:21.000 We'll find out. 00:21.000 --> 00:25.000 So, let's talk a little bit as I do every year, 00:25.000 --> 00:28.000 except for the years that I miss this event, which is rare. 00:29.000 --> 00:33.000 About the state of the Open JDK community, 00:33.000 --> 00:36.000 the JDK and Java. 00:36.000 --> 00:41.000 This year is coming up, as you might know, 00:41.000 --> 00:44.000 a pretty momentous year for Java. 00:44.000 --> 00:49.000 Sometime in May, I believe the 23rd of the 25th, 00:49.000 --> 00:52.000 Java will be 30 years old. 00:52.000 --> 01:03.000 And some other people here have been working on it 01:03.000 --> 01:06.000 for most of those years, which I don't know 01:06.000 --> 01:08.000 that's a sign of sickness or whatever. 01:08.000 --> 01:12.000 But anyway, so 30 years and Java is still 01:12.000 --> 01:16.000 one of the most popular programming platforms in the world. 01:16.000 --> 01:19.000 You don't believe me, you can ask Redmunk. 01:19.000 --> 01:24.000 There are many surveys of programming languages and platforms. 01:24.000 --> 01:27.000 A very degrees of believability. 01:27.000 --> 01:31.000 I think Redmunk is probably the most believable. 01:31.000 --> 01:34.000 This is their survey from June of 2024. 01:34.000 --> 01:39.000 The X-axis is a popularity rank derived from GitHub. 01:39.000 --> 01:43.000 The Y-axis is a popularity rank derived from 01:43.000 --> 01:46.000 number of tags on Stack Overflow. 01:46.000 --> 01:50.000 And there are lots of interesting languages here. 01:50.000 --> 01:52.000 Way up in the corner. 01:52.000 --> 01:54.000 You'll see Java. 01:54.000 --> 01:56.000 Next to something called JavaScript. 01:56.000 --> 01:59.000 I'm not sure what that's all about. 01:59.000 --> 02:00.000 Python, whatever. 02:00.000 --> 02:03.000 Anyway, it's way up there. 02:03.000 --> 02:06.000 And I think it's going to stay way up there. 02:06.000 --> 02:10.000 So why has Java been so extraordinarily successful 02:10.000 --> 02:13.000 over the past 30 years? 02:13.000 --> 02:18.000 One part of the answer is our relentless focus on two big goals. 02:18.000 --> 02:20.000 One is developer productivity. 02:20.000 --> 02:23.000 It's all about helping developers build and maintain large 02:23.000 --> 02:25.000 and reliable programs. 02:25.000 --> 02:28.000 Okay, yes, so we started with Applets, which we're small and flaky 02:28.000 --> 02:31.000 programs and browsers, but Java grew up. 02:31.000 --> 02:34.000 The other thing we focus on is program performance. 02:34.000 --> 02:37.000 Whether that's measured at a startup time, warm up time, 02:37.000 --> 02:40.000 latency, or throughput, or whether it's measured in space. 02:40.000 --> 02:43.000 Whether that be at the static space or dynamic space. 02:43.000 --> 02:48.000 And we focus on these goals in the face of constantly evolving program 02:48.000 --> 02:49.000 and error times. 02:49.000 --> 02:53.000 For example, mixed functional and object oriented programming. 02:53.000 --> 02:58.000 In the face of evolving application areas, big data and machine learning. 02:58.000 --> 03:01.000 Evolving deployment styles from on premise to the cloud. 03:01.000 --> 03:03.000 And of course, evolving hardware. 03:03.000 --> 03:06.000 Nowadays, it is not uncommon to have terabyte size. 03:06.000 --> 03:10.000 These deeper memory hierarchies trying to combine vector and 03:10.000 --> 03:14.000 SIMD instruction sets with regular CPU computation. 03:14.000 --> 03:21.000 And of course, deeper and more numerous process or pipelines. 03:21.000 --> 03:26.000 As important as the goals we choose are the means by which we work to achieve 03:26.000 --> 03:27.000 them. 03:27.000 --> 03:31.000 Another key to Java's success has been the fact that we take the time to 03:31.000 --> 03:34.000 think about the big picture and the long-term. 03:34.000 --> 03:37.000 Not just about, oh, we know what PR is interesting this week to add some 03:37.000 --> 03:40.000 future to the platform that, oh, my gosh, we're going to have to support that for 03:40.000 --> 03:41.000 30 years. 03:41.000 --> 03:42.000 You're kidding me. 03:42.000 --> 03:45.000 We don't act only as developers. 03:45.000 --> 03:47.000 That is people who create things. 03:47.000 --> 03:49.000 We also try to act as stewards. 03:49.000 --> 03:53.000 That is, we try to be responsible for overseeing and protecting something 03:53.000 --> 03:56.000 that is considered worth caring for and preserving. 03:56.000 --> 04:00.000 We try to preserve the past while evolving for the future. 04:00.000 --> 04:04.000 Our work is thus guided by two core values. 04:04.000 --> 04:07.000 Readability and compatibility. 04:07.000 --> 04:10.000 Readability is essential to maintainability. 04:10.000 --> 04:14.000 If you can't read the code that you wrote a month ago or that a colleague 04:14.000 --> 04:18.000 of yours wrote 10 years ago or 30 years ago, then what are you going to do when you 04:18.000 --> 04:20.000 need to fix a bug? 04:20.000 --> 04:22.000 Compatibility has many dimensions. 04:22.000 --> 04:24.000 There's technical compatibility. 04:24.000 --> 04:28.000 Those of you feel familiar with the JLS and the JVMS understand that there's 04:28.000 --> 04:29.000 source compatibility. 04:29.000 --> 04:30.000 There's binary compatibility. 04:30.000 --> 04:32.000 There's behavioral compatibility. 04:32.000 --> 04:34.000 All are important. 04:34.000 --> 04:39.000 There's somewhat odd kind of compatibility, which we've come to call migration compatibility. 04:39.000 --> 04:43.000 That's the question of, well, you have existing code. 04:43.000 --> 04:44.000 New features come along. 04:44.000 --> 04:50.000 How hard is it to take that existing code and adapt it to use the new features? 04:50.000 --> 04:54.000 The first big example of that in the Java platform was generics when we added generics 04:55.000 --> 04:57.000 in Java 5. 04:57.000 --> 05:01.000 We took great pains to make it possible for code that had adopted generics types and 05:01.000 --> 05:05.000 code that hadn't to interoperate together so that you could gradually migrate a code 05:05.000 --> 05:10.000 base to use generics rather than having to do all of it all at once. 05:10.000 --> 05:13.000 One of the big trade-offs there was we didn't get reification. 05:13.000 --> 05:14.000 But you know what? 05:14.000 --> 05:17.000 It actually worked out pretty well. 05:17.000 --> 05:21.000 Another type of compatibility is what I'll call intellectual compatibility. 05:21.000 --> 05:25.000 We don't want a new feature to require developers to throw away everything they 05:25.000 --> 05:28.000 knew and have to start all over again. 05:28.000 --> 05:30.000 New features built on existing knowledge. 05:30.000 --> 05:32.000 They don't destroy it. 05:32.000 --> 05:37.000 Preserving these values while moving the platform forward is much harder than it looks. 05:37.000 --> 05:42.000 But that is what we've been doing for 30 years and we will keep doing it. 05:42.000 --> 05:47.000 Now we used to do this at a relatively slow pace, a fairly sedate pace, a fairly 05:47.000 --> 05:50.000 sedately pace with a new release every few years. 05:50.000 --> 05:53.000 But eight years ago we changed. 05:53.000 --> 05:58.000 We switched to a rapid cadence, shipping a new release every six months, light clock 05:58.000 --> 06:03.000 work and strictly limiting the number of back ports along term support releases. 06:03.000 --> 06:07.000 Some have come to call this the tip and tail model. 06:07.000 --> 06:11.000 And I suspect you'll be hearing more about that as time goes on. 06:11.000 --> 06:15.000 This was a radical change but it worked out better than any of us at home. 06:15.000 --> 06:23.000 It resulted in less process reduced overhead, greater stability and best of all more features faster. 06:23.000 --> 06:31.000 I have colleagues I work with closely and it's entertaining sometimes to realize 06:31.000 --> 06:34.000 they don't actually know when the next release is going to ship. 06:34.000 --> 06:40.000 And that's okay because they're busy working on a feature that will ship in the one after that. 06:41.000 --> 06:45.000 So we've shipped all these releases in the last eight years. 06:45.000 --> 06:48.000 We will ship JDK 24 next month. 06:48.000 --> 06:52.000 JDK 24 will hopefully have its first release candidate next week. 06:52.000 --> 06:58.000 And the next long term support release, JDK 25 in September. 06:58.000 --> 07:01.000 Now this truly is a community effort. 07:01.000 --> 07:06.000 It's a valuable, creates this table every six months, like clockwork. 07:06.000 --> 07:09.000 And it's got lots of interesting data in it. 07:09.000 --> 07:13.000 This is a graph, oops, we're cutting off on the right-hand side. 07:13.000 --> 07:14.000 Sorry about that. 07:14.000 --> 07:19.000 The area of each box represents the number of issues resolved in the JDK mainline, 07:19.000 --> 07:25.000 not the update releases in the JDK mainline from release 11 through 24. 07:25.000 --> 07:29.000 Now this big red box is, you might guess, is Oracle. 07:29.000 --> 07:32.000 But we've got lots of contributions from others. 07:32.000 --> 07:33.000 We have red hat. 07:33.000 --> 07:37.000 Sorry, red hat, you're not red because whatever. 07:37.000 --> 07:40.000 Lots of contributions from SAP. 07:40.000 --> 07:45.000 A significant contributions from people unafiliated with any large organization. 07:45.000 --> 07:46.000 I think that's pretty cool. 07:46.000 --> 07:49.000 And then you have random, you know, lesser contributions. 07:49.000 --> 07:52.000 But still important ones from Amazon, Google, Tencent, 07:53.000 --> 07:57.000 and you can go down here and you find, like, Ozil, and Huawei, whatever. 07:57.000 --> 08:01.000 Anyway, a broad, broad base of contributions. 08:01.000 --> 08:06.000 So in terms of the releases, we have shipped in the past year. 08:06.000 --> 08:08.000 Let's see, this is 2025. 08:08.000 --> 08:10.000 Going back to 2024. 08:10.000 --> 08:14.000 A year ago at Fauston, we were about to ship JDK 22, 08:14.000 --> 08:15.000 Java 22. 08:15.000 --> 08:20.000 There were 12 gems in that release for those of you who don't know, 08:20.000 --> 08:22.000 since our JDK enhancement proposals. 08:22.000 --> 08:29.000 They're the process by which we document and explain big new features in the JDK. 08:29.000 --> 08:33.000 Or sometimes small features that are worth significant notice. 08:33.000 --> 08:35.000 So there were 12 gems here. 08:35.000 --> 08:36.000 I went through them all. 08:36.000 --> 08:41.000 The orange ones are those coming from outside of Oracle. 08:41.000 --> 08:46.000 In Java 23, JDK 23 lasts September. 08:46.000 --> 08:49.000 We also had 12 gems in a variety of areas. 08:49.000 --> 08:54.000 We'll notice some of these are marks various ranks of preview, 08:54.000 --> 08:57.000 or incubator, third preview. 08:57.000 --> 09:02.000 8th incubator for the vector API, that one's taking quite a while. 09:02.000 --> 09:05.000 Around the time we switch to the 6 month K, cadence, 09:05.000 --> 09:07.000 we also introduce the concept. 09:07.000 --> 09:09.000 Two important concepts. 09:09.000 --> 09:13.000 One is that of incubator modules, which is a place where APIs can live. 09:13.000 --> 09:15.000 They'll be distributed with the JDK. 09:15.000 --> 09:18.000 They'll be available for end users to use. 09:18.000 --> 09:21.000 But they are not a committed part of the platform. 09:21.000 --> 09:22.000 They are experimental. 09:22.000 --> 09:23.000 Please try them out. 09:23.000 --> 09:24.000 Tell us what you think. 09:24.000 --> 09:28.000 They're also preview features, which are not shipped in separate modules. 09:28.000 --> 09:31.000 These are historically mostly been used for language features, 09:31.000 --> 09:34.000 which you can't really ship in a separate module. 09:34.000 --> 09:37.000 So many language features have come in. 09:37.000 --> 09:41.000 They come in as a preview feature, which means you need to enable it in order to use it. 09:41.000 --> 09:42.000 But you can use it. 09:42.000 --> 09:43.000 It's fully specified. 09:43.000 --> 09:45.000 It's fully supported. 09:45.000 --> 09:46.000 It's there. 09:46.000 --> 09:49.000 We reserve the right to change it. 09:49.000 --> 09:51.000 Hopefully not significantly as time goes on. 09:51.000 --> 09:54.000 And eventually, preview features are either finalized or removed. 09:54.000 --> 09:59.000 And we actually have removed one that we decided was not ready. 09:59.000 --> 10:00.000 All right. 10:00.000 --> 10:03.000 So that was Java 23 and JDK 23. 10:03.000 --> 10:06.000 We were coming up, as I said, on Java 24. 10:06.000 --> 10:07.000 JDK 24. 10:07.000 --> 10:11.000 There are 24 jups in JDK 24. 10:11.000 --> 10:13.000 This was carefully planned. 10:13.000 --> 10:14.000 No, wait, no. 10:14.000 --> 10:16.000 It's a sheer coincidence, actually. 10:16.000 --> 10:19.000 But sort of an amazing number. 10:19.000 --> 10:21.000 Lots of good stuff in here. 10:21.000 --> 10:23.000 Again, I won't go through it. 10:23.000 --> 10:27.000 So I know there are probably a lot of folks in this room who don't work on the JDK itself, 10:27.000 --> 10:31.000 because you're here to find out about this out the status of Java and what's new. 10:31.000 --> 10:34.000 If you are, I'm glad you're here. 10:34.000 --> 10:41.000 And I encourage you to test out the early access releases available on JDK.java.net. 10:42.000 --> 10:45.000 Release candidate for 24 is coming out next week. 10:45.000 --> 10:49.000 And 25 is actually already available. 10:49.000 --> 10:51.000 Java 25 JDK 25. 10:51.000 --> 10:52.000 There are zero jups. 10:52.000 --> 10:56.000 So far, this release will ship in September. 10:56.000 --> 10:59.000 I could make random guesses as to what's going to be in it. 10:59.000 --> 11:01.000 But we won't know until we're done. 11:01.000 --> 11:04.000 That's another one of the great things about this process. 11:04.000 --> 11:07.000 It drives management mad, because you can't tell them what's going to be in the release. 11:07.000 --> 11:09.000 But too bad. 11:09.000 --> 11:13.000 Again, early access releases for 25 are already available. 11:13.000 --> 11:18.000 And there you will find lots of really bug fixes, small enhancements that didn't make 24, 11:18.000 --> 11:19.000 et cetera. 11:19.000 --> 11:26.000 And I expect the first step for stable values will probably come in pretty soon. 11:26.000 --> 11:27.000 All right. 11:27.000 --> 11:33.000 So let's try to look ahead a little bit at the big picture. 11:33.000 --> 11:38.000 So as I said, we're all about developer productivity and program performance. 11:38.000 --> 11:46.000 And we generally focus our work by asking, what are the pain points that people are experiencing, 11:46.000 --> 11:50.000 developers are experiencing, customers are experiencing that we can address in the platform. 11:50.000 --> 11:55.000 And we try to address them in the platform in a logical and consistent way. 11:55.000 --> 12:00.000 So I'd like to just walk through some of the things we're currently working on. 12:00.000 --> 12:06.000 And these are organized around pain points and competition and one project. 12:06.000 --> 12:15.000 So one pain point that we've been hearing about actually for 30 years is Java is too hard to teach. 12:15.000 --> 12:23.000 Public static void main open-prem string what to a freshman in computer science. 12:23.000 --> 12:24.000 You've got to be kidding me. 12:24.000 --> 12:25.000 Okay. 12:25.000 --> 12:30.000 So we're working to make that story better. 12:30.000 --> 12:32.000 The main competition here is Python. 12:33.000 --> 12:36.000 Python has been making in rows in education. 12:36.000 --> 12:40.000 You know, I think in significant part for this reason. 12:40.000 --> 12:45.000 So in project amber we're doing something we've come to call paving the on ramp. 12:45.000 --> 12:47.000 I think on ramp going on to a highway. 12:47.000 --> 12:50.000 We want that to be a much smoother experience. 12:50.000 --> 12:55.000 We want beginning programmers to be able to write, you know, hello world or a simple, you know, 12:55.000 --> 13:01.000 tell me what your name is and hello here's name and move on to bigger examples without having to type. 13:01.000 --> 13:06.000 Public static void main. 13:06.000 --> 13:09.000 Another thing we hear is Java is to do verbose. 13:09.000 --> 13:12.000 Yes, we've been hearing this for 30 years also. 13:12.000 --> 13:18.000 And see Sharpen, Kotlin and Skala have all gained some popularity in part because they are less verbose than Java. 13:18.000 --> 13:24.000 This is another pain point that amber is addressing by reducing language ceremony. 13:24.000 --> 13:29.000 By bringing concepts that have been proven in other languages such as Haskell. 13:29.000 --> 13:32.000 Java now has algebraic data types. 13:32.000 --> 13:36.000 They don't look like the algebraic data types in Haskell, but you've got records. 13:36.000 --> 13:38.000 You've got sealed classes. 13:38.000 --> 13:39.000 You've got pattern matching. 13:39.000 --> 13:43.000 Yeah, it's a little more verbose than Haskell, but all the express of power is there. 13:43.000 --> 13:47.000 And it's amazingly useful. 13:47.000 --> 13:50.000 Java starts up too slowly. 13:50.000 --> 13:51.000 Yes. 13:51.000 --> 13:52.000 Go JavaScript and Python. 13:52.000 --> 13:55.000 I'll have Java beat in this regard. 13:55.000 --> 14:02.000 In Project Lydon, we are working to do what we call selectively constrained dynamism. 14:02.000 --> 14:04.000 Java is an extremely dynamic language. 14:04.000 --> 14:09.000 It's also partly a static language, but it's much more dynamic than many people give it credit for. 14:09.000 --> 14:15.000 That dynamism is a source of power, but it's also a source of long startup time. 14:15.000 --> 14:19.000 And so we're working to improve that. 14:19.000 --> 14:23.000 Initially in Lydon, we had a concept of condensers, this condenser model, 14:23.000 --> 14:26.000 that we thought was going to be useful. 14:26.000 --> 14:33.000 It turns out that we've been able to do a lot of work on startup and warm up directly in the hotspot 14:33.000 --> 14:34.000 Java virtual machine. 14:34.000 --> 14:40.000 By taking existing components that we have, rearranging them, changing how they're used, 14:40.000 --> 14:47.000 we actually have some compelling prototype work that gets significant reductions in startup time 14:47.000 --> 14:50.000 without you having to change your program at all. 14:50.000 --> 14:52.000 And I think that's pretty cool. 14:52.000 --> 14:57.000 The first jet coming out of Lydon is actually in JDK 24. 14:57.000 --> 15:00.000 That's called the Head of Time class loading and linking. 15:00.000 --> 15:04.000 If you're familiar with how Java loads and links classes in the JVMS, 15:04.000 --> 15:07.000 it's the fairly detailed, detailed and specific process, 15:07.000 --> 15:09.000 and it all has to be done at runtime. 15:09.000 --> 15:12.000 Well, now we can do that ahead of runtime in a training run, 15:12.000 --> 15:14.000 so that you don't have to do it at runtime, 15:14.000 --> 15:18.000 and that results in significant improvements. 15:19.000 --> 15:21.000 Forads are too expensive. 15:21.000 --> 15:27.000 Yes, well, when Java first came out, it was on so-called green threads, 15:27.000 --> 15:32.000 and it's entertaining to see other programming platforms that are newer than Java. 15:32.000 --> 15:36.000 They have come out, and they have called their threading systems green threads, 15:36.000 --> 15:40.000 not for any other reason, other than the Java did in the early days. 15:40.000 --> 15:46.000 Green threads was basically a manual multiplexing of multiple threads 15:46.000 --> 15:49.000 onto one operating system thread. 15:49.000 --> 15:55.000 We fairly quickly, in the early days of Java moved on to the more logical thing, 15:55.000 --> 15:58.000 of one Java thread per operating system thread, 15:58.000 --> 16:00.000 you know, by then operating system systems, 16:00.000 --> 16:04.000 at least the unixes were getting pretty good at multi-threading. 16:04.000 --> 16:07.000 But over time, we found that well, 16:07.000 --> 16:10.000 one Java thread operating system thread is too constraining, 16:10.000 --> 16:13.000 because operating system threads are really expensive. 16:13.000 --> 16:15.000 You have to allocate, you know, a megabyte for the stack, 16:15.000 --> 16:17.000 you know, other overhead. 16:17.000 --> 16:19.000 So with loom, we have virtual threads, 16:19.000 --> 16:23.000 and we can now compete very effectively with platforms like go. 16:23.000 --> 16:27.000 The cost of a virtual thread in Java is, you know, 16:27.000 --> 16:31.000 the actual overhead, if I remember right, is three or four hundred bytes, 16:31.000 --> 16:33.000 plus whatever stack space it requires. 16:33.000 --> 16:35.000 There's no fixed allocation. 16:35.000 --> 16:37.000 You can have millions of virtual threads, 16:37.000 --> 16:39.000 and it works perfectly fine. 16:39.000 --> 16:42.000 Another cool thing in loom, 16:42.000 --> 16:46.000 is not quite finished yet, is the combination of structure 16:46.000 --> 16:49.000 concurrency and scoped values, scoped values, 16:49.000 --> 16:51.000 which are from Mr. Hayley here, 16:51.000 --> 16:55.000 are the right way to do what we used to call 16:55.000 --> 16:57.000 a thread local storage. 16:57.000 --> 17:02.000 And structure concurrency is a way of managing, you know, 17:02.000 --> 17:06.000 medium, large, enormous flocks of threads. 17:06.000 --> 17:08.000 This is something that goes, it is actually, 17:08.000 --> 17:09.000 actually cannot do. 17:09.000 --> 17:14.000 So Java is ahead of go in that regard. 17:14.000 --> 17:18.000 Another pain point, cash misses are too expensive. 17:18.000 --> 17:23.000 If you have a simple abstraction for points, 17:23.000 --> 17:24.000 it contains two doubles. 17:24.000 --> 17:27.000 Now suppose you have a really larger array of points. 17:27.000 --> 17:30.000 Is that a ray of points going to look anything like 17:30.000 --> 17:32.000 an array of points and see looks in memory? 17:32.000 --> 17:34.000 No, it's going to be an array, 17:34.000 --> 17:37.000 and each element is going to contain a pointer 17:37.000 --> 17:40.000 to a point object somewhere else in memory. 17:40.000 --> 17:44.000 Chasing all those pointers gets to be very expensive. 17:44.000 --> 17:47.000 We're trying to do any kind of serious science 17:47.000 --> 17:49.000 that the machine learning computation. 17:49.000 --> 17:52.000 So we're trying to address that in Valhalla 17:52.000 --> 17:54.000 with two features. 17:54.000 --> 17:57.000 One is value types, the ability to declare a class 17:57.000 --> 17:59.000 that does not have identity, 17:59.000 --> 18:01.000 and thus can be, for example, 18:01.000 --> 18:04.000 stack allocated to register allocated by the virtual machine 18:04.000 --> 18:06.000 and also laid out much more efficiently in memory. 18:06.000 --> 18:08.000 And no restriction. 18:08.000 --> 18:13.000 So we're going to have what some call emotional types in Java. 18:13.000 --> 18:15.000 You can write string question mark, 18:15.000 --> 18:18.000 you can write string, string exclamation point, 18:18.000 --> 18:21.000 and they will mean essentially what they mean 18:21.000 --> 18:23.000 in other languages such as Kotlin. 18:23.000 --> 18:25.000 That's kind of an interesting story. 18:25.000 --> 18:28.000 Valhalla is working on Valhalla for like 10 years now. 18:28.000 --> 18:32.000 It is Java's epic refactor. 18:32.000 --> 18:35.000 It is deep cuts in both the language and the virtual machine. 18:35.000 --> 18:40.000 And we never expected that null restriction 18:40.000 --> 18:43.000 was going to be in a central part of the story. 18:43.000 --> 18:45.000 But as we got to the peak of complexity and began 18:45.000 --> 18:48.000 to simplify things we realized, 18:48.000 --> 18:51.000 if we could only ensure that certain things were never null, 18:51.000 --> 18:54.000 then it would make the whole, 18:54.000 --> 18:58.000 all the work for the VM to lay things out in memory flat 18:58.000 --> 18:59.000 much easier. 18:59.000 --> 19:03.000 It would also make things easier to reason about by developers. 19:03.000 --> 19:05.000 So we're getting null restriction, 19:05.000 --> 19:08.000 even though that really wasn't the plan. 19:08.000 --> 19:13.000 Another thing that Valhalla is addressing 19:13.000 --> 19:16.000 is the fact that generics and primitives don't mix. 19:16.000 --> 19:19.000 Next, right now you cannot write newer 19:19.000 --> 19:21.000 ray list of int, right? 19:21.000 --> 19:23.000 That just does not work. 19:23.000 --> 19:26.000 So once we have generic specialization, 19:26.000 --> 19:28.000 you will be able to write not quite that, 19:28.000 --> 19:31.000 but something equivalent to it. 19:32.000 --> 19:35.000 And the array backing it really will be an array of ints. 19:35.000 --> 19:39.000 It won't be an array of pointers to capitalize integer objects. 19:42.000 --> 19:45.000 numeric loops are too slow. 19:45.000 --> 19:47.000 The hotspot JVM does have, 19:47.000 --> 19:50.000 it does do a certain amount of auto vectorization, 19:50.000 --> 19:53.000 but it's limited in what it can do, 19:53.000 --> 19:55.000 and it's fairly brittle. 19:55.000 --> 19:59.000 Meaning you could have some code that auto vectorizes 19:59.000 --> 20:00.000 great today. 20:00.000 --> 20:02.000 You could make a small tweak in it next week, 20:02.000 --> 20:04.000 and then it would not auto vectorize. 20:04.000 --> 20:06.000 And your performance would fall off a cliff. 20:06.000 --> 20:07.000 That's not good. 20:07.000 --> 20:09.000 So our answer to that is in project Panama. 20:09.000 --> 20:11.000 We're working on the vector API, 20:11.000 --> 20:13.000 which allows you to write explicit 20:13.000 --> 20:16.000 Cindy instructions, but in a portable way. 20:16.000 --> 20:18.000 So it's a portable API with different backends 20:18.000 --> 20:21.000 to the different Cindy architectures that we find 20:21.000 --> 20:24.000 on different processors. 20:24.000 --> 20:28.000 Using native libraries is too hard. 20:28.000 --> 20:31.000 Job the Java native interface. 20:31.000 --> 20:33.000 Actually, the Java native interface is a lot better 20:33.000 --> 20:36.000 than what came before. 20:36.000 --> 20:38.000 Those of us worked on the JDK in the very early days, 20:38.000 --> 20:41.000 the native interface was ten times harder than JNI. 20:41.000 --> 20:44.000 So JNI was a big improvement, but it's still kind of sucks. 20:44.000 --> 20:48.000 So we have replaced JNI with the foreign function 20:48.000 --> 20:52.000 and memory API from, which is also from project Panama. 20:52.000 --> 20:55.000 The FFM API went final in, 20:55.000 --> 20:57.000 I think it was JDK 23, so it's there. 20:57.000 --> 21:02.000 It's no longer in incubator preview, and you can use it. 21:02.000 --> 21:06.000 Moving right along. 21:06.000 --> 21:11.000 Using JPUs for AI is too hard. 21:11.000 --> 21:16.000 AI computation, graphics computations, machine learning computations. 21:16.000 --> 21:20.000 People want to be on GPUs, whether they're GPUs 21:20.000 --> 21:24.000 from Nvidia or AMD or Intel or whatever. 21:25.000 --> 21:26.000 That's too hard. 21:26.000 --> 21:29.000 So what we're trying to do in project Babylon 21:29.000 --> 21:33.000 is provide a way to take Java code, 21:33.000 --> 21:38.000 converted basically to high level intermediate representation, 21:38.000 --> 21:42.000 which a framework could then transform 21:42.000 --> 21:45.000 into CUDA code or spear recode or PTX code 21:45.000 --> 21:48.000 for GPU type hardware. 21:48.000 --> 21:53.000 So you will be able to write GPU computations 21:54.000 --> 21:56.000 in sort of a sub dialect of Java, 21:56.000 --> 21:58.000 have it automatically transformed 21:58.000 --> 22:01.000 into code for the GPU that you're using. 22:01.000 --> 22:06.000 People sometimes ask, well, what is Java doing about AI? 22:06.000 --> 22:09.000 When is Java going to have built in automatic differentiation? 22:09.000 --> 22:11.000 We need that for machine learning. 22:11.000 --> 22:14.000 And the answer is, we're not going to have that 22:14.000 --> 22:16.000 in the Java platform, but we focus on in the platform 22:16.000 --> 22:20.000 is things that only we can do in the platform. 22:20.000 --> 22:25.000 In fact, the bottom five features here 22:25.000 --> 22:27.000 will all help AI applications. 22:27.000 --> 22:29.000 They will make it possible to interact 22:29.000 --> 22:32.000 with native code, AI libraries, native code, 22:32.000 --> 22:35.000 linear algebra libraries, such as lists. 22:35.000 --> 22:37.000 They will enable you to interact with GPUs 22:37.000 --> 22:40.000 and we've already got some compelling prototypes 22:40.000 --> 22:45.000 of, for example, code that can manipulate 22:45.000 --> 22:48.000 Linux machine learning models and both train them 22:48.000 --> 22:51.000 and execute them in Java. 22:51.000 --> 22:54.000 So again, if you're here because you're interested in Java, 22:54.000 --> 22:55.000 that's great. 22:55.000 --> 22:57.000 If you're interested in Java, you're not working on Java. 22:57.000 --> 22:59.000 Please go to JDK.gov.net. 22:59.000 --> 23:04.000 We have really access fields of 23 or 24 and 25 23:04.000 --> 23:07.000 along with other interesting stuff. 23:07.000 --> 23:09.000 And that's all I have. 23:09.000 --> 23:11.000 We have four minutes, should we take questions 23:11.000 --> 23:14.000 or just move on, your choice. 23:14.000 --> 23:17.000 Anybody want to ask something in your choice? 23:17.000 --> 23:19.000 It must be interesting. 23:30.000 --> 23:32.000 It kind of tends. 23:32.000 --> 23:37.000 And if you look, you'll have, like, 23:37.000 --> 23:42.000 you'll have a child. 23:42.000 --> 23:45.000 And I personally, in a comfortable place. 23:45.000 --> 23:49.000 Yeah, I mean, these are my people. 23:49.000 --> 23:51.000 We're all here. 23:51.000 --> 23:55.000 All right. 23:55.000 --> 23:56.000 Thank you. 24:02.000 --> 24:04.000 Thank you.