 Hello, developers! My name is Matt Raebel and today I'd like to show you how to convert a J-Hipster application to use Spring Native with GrawLVM and startup in milliseconds. Let's get it up! This screencast is based on a blog post that I published back in March and recently updated in April called Introducing Spring Native for J-Hipster. Serverless, full stack, made easy. And if you click on this GitHub icon, it'll take you to a repo on GitHub called AusZero Full Stack Java Example. So this is a previous example that I posted on an AusZero blog and I've taken it and converted it for this blog post. And if you click on the raw button here, it'll give you a nice ASCII doctor look and feel. I have an ASCII doctor plugin here that makes it easy to toggle on and off. And so again, we're going to convert a J-Hipster app that already exists to use Spring Native. And instead of starting in seconds on the JVM using native GrawLVM binary, you can start in milliseconds. So let's get it up! We're going to need Node 14, Java 17 with GrawLVM, and Docker Compose. And if you're on Windows, you may need to install the Windows subsystem for Linux. Or if you're a savvy Windows developer, you can probably figure out what the commands need to be. And so this is all based on work that Josh Long and I did back in September 2021, as well as December 2021, where we basically took a bunch of J-Hipster apps, modified them so they would work with GrawLVM. And then we took those findings and turned it into the J-Hipster native blueprint. So you can find that on GitHub at J-Hipster, Generator J-Hipster native. And a lot of this work was done by Marcelo Shima. He's a very prolific developer that just does amazing things on J-Hipster. He made it. So all you need to do is, you know, install this blueprint, and then generate an app, and then you can build it. And I did want to point out that this is in the Spring Native branch demo-native.adoch, if you want to follow along with these instructions yourself. So let's do that by cloning this GitHub repo here. This is, you know, a previous J-Hipster app I created. So if you want to see how I created it, please go to the Osteo blog and read all about it. And we'll start by cloning the repo. I'm going to do this in my downloads directory into J-Hipster native. So I am on a Mac M1 Max and GrawLVM22.1 just came out. So it works on the M1. Before that, it didn't work. So things will be fast when I build it, which is quite nice. And then we'll install J-Hipster 781 and the J-Hipster native blueprint. Now back to our instructions here. We're going to remove all the existing project files and regenerate them. And that's because the J-Hipster native is more of a when you start your application rather than a module, which is something that J-Hipster uses to modify the existing behavior of an application. So we're in this J-Hipster native directory. We'll start with RM-RF star. So there's nothing in there now. But neat trick is there's still a bunch of dot files in there. So there's this dot urc JSON, which has all the J-Hipster settings for this application. And there's also a dot J-Hipster directory, which contains all the entities for this application. So we can run J-Hipster native with entities. So that'll use those entities that we've already created. And there is no caching support currently in Spring Native. So that's why we disable the cache provider here. And no enable hibernate cache. You can see that only took, you know, a minute and 20 seconds. So pretty fast in this M1, of course, how long it takes will depend on your hardware, your internet speed, all that kind of stuff. In the previous tutorial on the OsZero blog, I basically created a photo gallery or Flickr2 clone as I like to call it. And what it does is it basically allows you to upload photos, but then it reads the data from the photos. So you don't have to enter in height, width, where it was taken, all that kind of stuff, and what data was taken on. So we're going to restore that behavior, because we just wiped out all the customized code that we did in this J-Hipster app. So these get checkout commands will restore the modifications that we made for the most part. And then we're going to need to make a few other modifications. So I'm going to open up Intel J for that. Once that's loaded, you can look in the commit window and see all the files that have changed while we only need to restore the behavior in a few of them, because those are the only ones I customized. The other files that changed are probably because it's a newer version of J-Hipster that's being used. We can actually, you know, compare here and see that the old version is 731. And now we're at 781. The first thing is to modify the application dev, just because I didn't want to have fake data when you first loaded up the app. So we're restoring faker there. All right, same as these instructions on the left. And then in pom.xml, we're going to want to restore the library for drew notes image parsing. So if we just scroll down here, it's way down at the bottom. There we are. We'll take that one. And you'll see it actually added a number of dependencies, right, for spring native. That's actually the only one. The other ones are just J-Hipster changes. So that spring native that got added. And then we'll need to modify the create photo and photo resource. So again, if we look at the commit window and go down to photo resource, or go up to photo resource. And we're going to want to restore this behavior of setting the photos metadata. And you'll see the signature changed there a bit. So we'll go ahead and leave that as well. And then we do need to change because the signature did change for exception in J-Hipster, we're going to have to add a few more here. And we'll also want those imports, right? So restore those imports. Then we have that, and then we can add this method here. And all the other changes in this file were made by the J-Hipster native plugin to add IDs to path variables or names to path variables. And then we'll need to install the react libraries that I added in the previous tutorial. So in the previous one, I did use react photo gallery. That one doesn't work with react 17. So I changed to use react photo album, and we do need to make some changes there. So if we open up this photo TSX, go back to the project view, instead of importing the gallery code, we'll want to import the photo album code. So that's this right here. And then instead of gallery, I get in photo album, so search for gallery, and then just replace it and everything else works without any code changes. So that's pretty slick, you know, good for react components. And then in photospect.ts, there's a Cypress test that will fail. So we want to look for height, and then remove these three, or these four. And then for the Flickr2 app, that made a bunch of modifications where the J-Hipster native one did to add all these native hints for various classes that are being used in this application. This is for micrometer. This is actually for JPA, surprisingly. And then a bunch of liquid based classes. And then these are the ones we need for drew nokes library. And how I discovered these was basically by, you know, building the app, running it, seeing the air. So it's kind of painful to do, but happily or nicely, I did it for you. And then you'll need to reload your Maven changes here to get those drew nokes libraries to import properly. And then this native hint right here loads all the car sets or char sets, however you like to say it, because without it, you'll get this exception when you try to upload a photo. Okay, and so now you can install Grawl VM. So grab this and you'll need SDK man. So if you go to SDK man.io, you can install it. And I have it installed here, I can do SDK version. And then I can do SDK list Java. And you'll see I already have Grawl VM installed, local only, and it says it's installed right here. So what I can do, let's see if it's the default version, Java version here, doesn't look like it. So SDK install Java. And it should, it's already installed so SDK default Java. And now we're using that version. All right, so all looks good there. And then we can use Maven to build the project. So MVNW package, P native, profile prod, and then skip the test. And this is because spring native doesn't support Machito yet. So it might in the future, but at this point in time, it does not. And while that's building, I can show you how Jay hipster by default, when you choose OOF for authentication uses key cloak. So if we were to look at source main Docker key cloak, you'll see how it uses Docker compose to pull in key cloak 610 at the time of this writing. And then, you know, it imports existing realms and users for Jay hipster. So credentials and apps are already set up. So you don't have to do any work. And that just makes it easier for everyone. Right. And if you want to, you know, run it and have access outside of local host, you might need to tweak these ports right here. So you can start key cloak up. But one thing I want to let you know on the M one is it doesn't work by default. So I actually have a script that I use called build key cloak Docker. And you set the version right here, I found this on Stack Overflow. So if you search for like, you know, M one max and, you know, key cloak and why doesn't it work, you'll find this instructions, it basically clones, you know, key cloak containers, goes into the server. And then what this does is it builds a local key cloak image on the M one that uses, you know, arm 64, MD 64, it gets on 64. And so then, you know, it'll actually work and start up. So even though if you don't do this, what happens is you'll start up key cloak, it just won't work. It looks like it should work, but it won't. So that's why I did it that way. And then I have an alias called run, that actually runs this command that starts all the Docker containers that will be needed by this application. So I'm going to run that and that'll start up key cloak and Postgres. Since we're running in production, we'll need Postgres. And if you weren't running with a production pro file, it would just use H two. And so that's what J hipster has configured. So you'll see that took about two minutes and 20 seconds to complete. If you were on an Intel MacBook or Linux, times may vary, right, could be up to four minutes. I'm not sure. But I have noticed that the M one is twice as fast as other Intel Macs. So that's pretty nice. We'll exit out of this one and clear up here and make sure that key cloak and Postgres are running. And now we can get off to the races with target native executable. That's the name of it. And you'll see, wow, that started in, you know, a second, right, or 1036 milliseconds. Let's let's try canceling it. Sometimes it takes control. See a couple times. And now we're down to 508 milliseconds. Try it one more time. See if we can get a little faster. 553. So it's about a half a second, which is pretty awesome. Then if we click on, you know, local host 8080 here, we can sign in, it'll take us to key cloak, when we're all signed in and Chrome doesn't like I'm using admin admin, which is smart. Thanks, Chrome. Appreciate it. And, you know, if you were to look at the whole app, you could see there's entities in here. And you could, you know, add a new photo, you'll see that the photos are hidden, right by default. So put up the old 66 bus. His name is Hefe. And save it. And boom, now it's in there, right? He sure is pretty. All right, so that's all working. And now I'd like to show you how to use octa. So with octa, you can just use the octa CLI and install it from CLI to octa.com. And then you can run octa apps, create J hipster. As for the name, I'll just say J hipster native, accept the default callbacks, or redirect your eyes, creates a new application and creates the role admin and role user group, which J hipster expects, and then adds those two groups claim. So when you log in, it actually has those role admin and role users assigned to your user through OIDC. And now we can just source that file. And again, target native executable takes a little longer because it does have to make a network hop right out to connect to octa just to get the issuer. But then if we sign in, boom, we're going to octa for login now, which is pretty slick and all of our data should be there. Right. And then the last one is, well, what if we want to use OS zero. So these are the instructions for, you know, octa apps, create J hipster, and then you source the octa.env. If you're on Windows and you're just using the regular command line, you'll want to change the values in this file to use or the lines in this file to set instead of export. So let me just clear that. And then we'll cat the file. So you can see it says export spring security, all that. So just change those to set, and then rename it to octa.bat, and run it. And it'll set all those environment variables for you. And then make sure to add, you know, star dot env to your get ignore so you don't check in your client secrets. And you can do something very similar with house zero. It does take a bit more work. And so you'll see here there's a there's nine steps. Right. So you log in, you create an application, you add those callback URLs, you set up roles, set up users, set up this system to actually add your roles to the ID token and access token. And then you have to, you know, this just explains that that's using a custom prefix that j hips to recognize. So what I would encourage you to do is go to this issue for the also CLI. And let's make it as easy as it is for octa. And down here at the bottom, there's some votes. So we're up to 19. Appreciate it if you vote for that. And we'll get that fixed. So I already have that set up. And so I can do copying from a different or the original project, us zero dot env right here, source it, and then run it. Now, if we were to try to log in, goes to zero. And as long as I remember my credentials, I should be the log in. Or I could even use Google since I've already set that up. And that logs man. And of course, I can see my data. So it works with key cloak, octa, and us zero. And so, you know, this is just showing those instructions that I used. And then these are some numbers that I had before I actually, you know, use the M one. So in JVM mode, if you start this app, takes about four seconds. As far as build time goes, this is on my intel, took three minutes, 15 seconds. So here it was two minutes, 20 seconds. And then if I use docker, it took quite a bit longer. So I don't know if I'd recommend that the amount of memory after starting is 178 megs. And then the amount of memory used after running MPM E to E, which does Cypress test is 211 megs. And then here's the command I use to find that out. And then the M one, this was without Camtasia running right recording my screen, one minute, 49 seconds to actually build the binary. It starts in 433. So a bit faster. And as you saw today, you know, Camtasia did slow that down a good 100 milliseconds or so. And then the memory is a little more on the M one, should you use growl VM instead of the JVM? I think it makes sense if your Java apps are super fast, and you just want to operate them in a serverless environment and, you know, do it that way. But if you actually want to run, you know, for days and weeks and stuff like that, you know, the JVM is built for that and it optimizes over time. So, you know, running on the JVM is probably good enough. So this is a tweet. If you want to go, you know, respond to it, there it is, in response to people, you know, asking me about it, you can find the code on GitHub in the spring native branch. That's a github.com octadev, Oz zero full stack Java example, and that spring native branch. And then the blog post itself is introducing spring native for J hipster. Thanks for watching today. I really appreciate you taking the time and learning about J hipster native. If you want to find me, I'm on Twitter at mrable. My team is at octadev on Twitter. And you can also go to Twitter.com slash also zero if you want to follow them, our YouTube channel is at YouTube.com slash octadev. So subscribe and come back for more awesome Java content. Cheers.