Jakarta EE JakartaOne Livestream- September 2019, 27 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Jakarta RESTful Web Services Status Quo and Roadmap | JakartaOne Livestream - September 2019

Description

Speaker: Markus Karg

This talk shares some insight into the current project status and the road ahead of the technology formerly known as JAX-RS. If you maintain existing JAX-RS applications, or write new RESTful Microservices in Java, this is the strategic session you need to attend.

///GET SOCIAL!
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Follow the conference: https://twitter.com/JakartaOneConf
Like us on Facebook: https://www.facebook.com/JakartaEE/
Become a member of our Jakarta Tech Talks Meetup: https://www.meetup.com/jakartatechtal...
Join us on LinkedIn: https://www.linkedin.com/groups/13597...
Tag us: #JakartaEE #JakartaOneLivestream

A

Hello, everybody and welcome at Chikara one. My name is Marcus card I'm, a Czech Ceresco meter and shares a contributor mecha chase few times. I served in the expert groups chase our 339 and 370 in particular, I'm not employed with any checks or swender, but I'm more like a useless ambassador. So I do have a different angel than most of my co-workers as I'm not bound to business plans or work schedules. I do not care for marketing or strategic targets or committees.

A

My main focus is simply a real-world usefulness for the average programmer and that simply is why I wrote most of the new features of checks, rs-232, which we will release as soon as we can I assume. This is why you asked me to do this presentation today. So, let's see what's in the box for you.

A

So let's talk about Shikata restful, Web, Services status quo and the future. Before we begin there is a github page where you can see the overall progress of the project, I'd like to invite you to visit. That page regularly can see the top committers. Currently, it's me and Christian, and you can contribute by filing issues, pull any code or opening merge requests since Jack's arrest. Third one was authored, which is years ago. The IT world has changed a lot. The classic deployment option for jax-rs applications is application servers.

A

If workload increases, you need to spread your workload on more and more machines. You need to scale up with classic application servers. This implies adding complete application server instances with all the features needed or not, as the application servers cannot know upfront what features your Java EE application will use at runtime, so it provides more or less all of them, which leads to reserving more resources than actually needed, possibly much more, and it implies adding complete operating system in senses. Neither or not, hence, horizontal scaling of classic application. Server products is inefficient and expensive.

A

The typical solution to this problem is scaling only the needed pieces within a container.

A

This is what a Koopa need to stock. A combination does no more useless resources claimed no multiplicate operating systems. This is efficient and cheap, but how to run a checks, RS application without an application server.

A

There is no standard for that scenario and checks rescuer one. Certainly there are products that can do that, for example, you can use Haledon or quark, but again these are not standards. These are products also. You could use, for example, jerseys native modules and api's, but again that's a product, not a standard.

A

This was just one example why Jack's arrest has to evolve another environment. We need to talk about our restful devices. You may be heard of the term industry 4.0, which is rather common. These days, listen Germany, where we try to provide more intelligence into manufacturing fields and intelligent devices play a big role here, and these devices have to communicate and some of the devices shall communicate in restful ways. So we have to provide a way to run checks, arrest on these devices, which is a bit hard to do.

A

If you look at this device here, for example, it's a small computer. You can obtain in the internet for a few bucks and it's as safe 256 megabytes and a single one gigahertz core, and if you try to start GlassFish on this, you will fail. This will just not work. So an application server is a no-go here. We have to provide something different, and this is also doable with checks or s 2.2.

A

If you look at a Java, SE bootstrap, we will provide we talk about that later, so it effects on checks, RS ah that checks RS, has to start and stop instantly in these environments. It should consume less resources, it must provide its own HTTP server. It must be able to read an external configuration and it must accept application provided resource, because these were the things that an application server provided so far to check surest and if you take weight applications there are these other points you have to be able to do.

A

You can imagine that we have to change some parts of checks or s, and this includes that we have to drop some things. You know from the past. Let's say we, we kill the warrior principle at least a bit. Not every feature will survive. We have to change to make progress and to be future comfortable, and some of these are listed here on the slide in Java s e 11, there is no more checks, be bundled I. Think you heard that before and checks.

A

B was one of the features that were enabled and checks RS right from the start. You could use checks, B to bind your objects to XML, and everything was provided by Java SE. In fact. So now that's not there anymore. We have a problem. We decided not to bundle tracks be anymore.

A

Also in tracks are s that means, if you want to run an application, that needs checks, be another hood and you have to provide it yourself, which means, if it's an application server the application server will provide checks, B I hope so, and if it's not an application server like a cloud environment, then you have to provide it yourself, which means possibly bundling something you pour from maven central by adding a dependency. So it's not hard to do, but you have to provide it. It will not be there by some kind of metric anymore.

A

Another point that it's broken by intention somehow is that the package is not Java X, dot, WS, dot, RS anymore, it's now Jakarta dot, W Esther RS, which simply was decided by the Eclipse Foundation because of trademark issues. So if you want to make your code run, then you need to rewrite it. That includes rewriting the Java code, not only the dependency and P om file. This will start with checks RS to the true which is here or rather soon, and then in checks rs3.

A

That o is even worse because we are starting to get rid after at context. Annotation. That's because we want to get rid of the dependency injection framework that checks our ass hat right from the beginning. The reason is that there is another dependency injection framework which you know is CDI, and we want people to use CDI.

A

Why are there two dependency injection frameworks simply because two projects started at the same time with the same intention. First one was checks. Our ass and checks are as needed, dependency injection, so it came with its own framework. That was normal standard framework and the second one which thought later was CDI a CD I made a race, so we decided draw our own framework and use CDI.

A

That's not so easy as you think, because the add contacts annotation can be used to do things that add inject cannot so either the CDI specification will learn to support these use cases or have to find a different solution. The futures open here and the discussion is going on. So this is very, very interesting to see how this develops, but in the end definitely add context will die and you have to rewrite your code and then you can use CDI really everywhere. So, let's take a look at the road map, inversion sequence.

A

What we have currently is tracks RS 2.1 release, six, which is mostly the same. You had in Java EE, eight, but now branded as Jakarta EE. So this is what we have today. What we get next is checks RS to the two, and the top feature is what I already explained in the introduction about the drivers of the next changes. It's the Java SE bootstrap API. The slide says it's delayed because it was planned many many months earlier, I'm, sorry for that.

A

Technically, it's done already and it was done months ago. We just cannot release it because the road map of Jakarta is different. They want Jakarta ie8 to be released completely first, so this is in the queues. Technically done, you can download it. You can use it, but it's not an official standard right now. So I already said, the top features of this release is that it's instant on earth. It has low resource, it includes an HTTP server, it reads: external configs and optionally.

A

It can support micro profile config api- and this is a very interesting point, because there's discussion going on about micro profile, config, worse --is checks, RS standards, and what we try to reach is that we get compatible in some levels. So here we said: if a product can use micro profile config api, then this configuration will be used to start up the Java as eBoost read API of checks RS. This is very interesting.

A

After checks are, as 2.2 is released, we try to do the releases more often. I cannot tell you the exact cadence that we will be able to deliver, but our plans are that we can release every quarter or at least twice a year, so the next one in sequence will be check, sir, as 2 to 3, which will provide support for CDI 2.0, including CD, is e. So this means that the support for CDI, which currently is optional and tracks, Russ, 2.1 and 2.2, will become mandatory for the runtime, not for the application.

A

The application can decide whether it uses CDI or whether it still keeps the add context, dependency, injection framework of checks for s, but the runtime must support CDI. So we will start here to Dupree Kate at context. It will still run, but it's clearly marked that we will remove at context in a later release and there will be support for context resolvers for trace and B. This is a feature you need when you want to use chase and binding API together with checks or ass in a more sophisticated way. You currently can use Jason B.

A

It is working already, but you cannot configure it. There is no standard for configuring. The chase and B runtime and starting with checks, are as two to three. The default way will be that you implement the contacts resolve or that provides a configured Jason B environment.

A

So the focus for checks RS to the three clearly is that we can process application provided resources again. I started with that. We want to replace some of the features application servers provided underneath checks, RS and application provided resources is one thing we have to do in future, so we can do it by these two things by supporting CDI to inject application, provide resources and by configuring Jason B environment.

A

By the way, I want to say that this road map is not carved into stone. We are an open project and besides what I told about tracks are as 2.2 everything could change in theory, actually, I, don't think that much will change, because what I tell here today is discussed already among all contributors among all vendors, and we have a road map which lists these features already and I'm pretty sure they're already implemented.

A

In most of the products, so while in theory the future is open, I'm, pretty sure this is what checks are as tutor to will bring next analysis checks, arrest, 2.4- and this is rather far wanes so I'm- not so convinced that what we plan today, which is JPMA support and support for Java SE larger than 8, is actually what comes into.

A

Therefore, but it's at least our plan, and if you have any features that you think are good for addition to 2.4 and don't hesitate to send them to the mailing list and we're happy to discuss them. So far, all version numbers you saw are 2 dot, X and that had a reason. The reason is backwards. Compatibility. You can be assured that your applications will still run on checks or ass or I need to say, Jakarta rest version, 2 directs next on the roadmap is checks, RS 300 and possibly your application won't run anymore.

A

That's because I already said that we replace at context annotation by add inject annotation, so we might need you to change your programs again. This only will happen if you run on checks, RS 3.0 I. Don't know what the applications are. Vendors or the checks are, as implementers will do, whether they provide different products for checks or as tutor the extra checks or 300 or whether they manage to run both in different containers.

A

I, don't know, but the plan for the standard API is clearly to get rid of the dependency injection framework by check surahs 3.0. So you should start to think overhauling your existing applications because there will be a day when add context is definitely gone and it's with checks rs300.

A

On the other hand, this will not be tomorrow and it will not be in two months. It will not be even by end of the year, it will be possibly in middle or end of next year. So you have time to do the neat changes. You don't need to be hasty, but please keep in mind. The changes have to be done for the checks arrest team, it's like to switch from Java 8 to Java 9.

A

The introduction of the modules framework was really a nightmare for many programs, including some of my own open source projects and the introduction of tracks arrest. 3.0 might become like an earthquake for some applications. On the other hand, CDI is here for a long time, and maybe it's just time to overhaul your applications anyway. So don't fear that release but expect some troubles.

A

This light looks in the very worried, far future its checks, arrest, 3.1, and we have no clue what comes there. If it's the flow API from Java 9, it might be in that release, it might be earlier. I, don't know it might be an I/o that that far future is really open for discussion. We have no clue, what's really the most important thing there and we invite you to discuss with us, come to our mailing list discuss with us.

A

Anyway, we will start with implementation of checks for a three row in one or in two years, so there there is plenty of time to discuss 3.1, let's look into release to the to once more in there. So this is what you can do today.

A

Checks provides a new API, we call it a Java, SE, bootstrap API. Actually, the products implementing tracks arrests were able to run on Java SE for a long time. Checks are, as mentioned, Travis e environments right from the start, but what was missing?

A

There was the code that I have to write when I want to bootstrap it and what we did was we looked at two ways: the implementations were working, we adapted the api's, they had we discussed and we came up with an API that now all implementing products that are able to run on Java as he must support. So this means we do not force the vendors to be able to run on Java as e, but if they are able to run on Java as e, then we force them to implement this API.

A

So why did we do that? Because we want that? You can write a simple hello world application and have a main method and in that main method, write code that startups HX RS container, and this is pretty much what this API does, and this is what I will demonstrate later in this presentation. The main features that this API provides for. You is that, depending on the actual implementation, you have more or less instant on/off, which means your application will put and shut down.

A

In one second or possibly less than a second, which is really great compared to application servers, application servers need typically very very long to put because they don't know what features you need here. We have a different situation in a Java, EE environment. Your program must provide everything you need. So if there is nothing your application expects to get, then the bootstrap is rather easy comprised what an application server has to do. Another thing is that we have very low resource consumption.

A

This also is because the application server simply doesn't know what you want to do. So it provides a lot of resources which need system resources on their own. Your own charm, as a program, knows exactly what he wants to do, so it's very, very low resource consuming.

A

Also, we have an included HTTP server, we don't mandate a particular product, but we say if and checks our s. Implementation is able to run checks or as applications in Java SE environments, then it must be able to start up some HTTP server. For example, Jersey is Modula implementation and it provides several HTTP service. You can choose off simply by binding different dependencies, which is a really cool way to simply switch the implementation. I, don't know about the other checks res implemented, I assume there will be flexible in a similar way.

A

Also, we can read external configuration, which means, for example, the hostname, the IP port or possibly the class name implementing the HTTP server. This is features in us. You can have some file, for example, or some environment properties that tells the chassis implementation which HTTP server you like to have so you bind, let's say natty and Chetty and grizzly, and at runtime and user can decide which HTTP server it wants to run. I.

A

Don't think that many people who will actually do that, but it shows how flexible you program becomes when using the Java SE bootstrap api external configuration. Certainly, this configuration can come from different sources. So, for example, we can have a file, we can have environment variables and certainly we can have things like the market profile.

A

Config API I told earlier that this is possible, and the interesting part is that even without a market profile, config API, this flexibility allows you to run your application in a very light wide kubernetes environment, because kubernetes is able to provide, for example, environment variables. So here we have clearly a cloud native feature because we can run checks are as in kubernetes without any particular product in between. If you want to try out these features before or track, the rest to the true is is released.

A

You need to take care of the version. Numbers I have set up this bleeding edge cookbook for you, which you can follow to compile exactly what you need and I a literally mean compile, because you need a runtime and there currently is no runtime released. That supports checks, rest 2.2. So, for example, you can take jersey, there's a branch checks or s22. If you compile that branch, then you will be able to do the same things. I will show you later in this demonstration for checks, RS itself, it's not released.

A

You also have to build it on your own, with mbm install before you will be able to compile Jersey. So it's not that easy, but I'm, very confident that you manage to do that before there is a binary release. I mentioned the shade plug-in here. You can't just ignore that. It's just because I am using a shade feature here, which I will show you later, which has nothing to do with checks or ass, and this feature is in the master branch which is not released now.

A

Okay, now, let's dive into the actual code, I will demonstrate you, the Java SE bootstrap API, so you have at least seen it without compiling it on your own and after that, I will talk about some of the numbers. I have taken with limited devices running this application, so you will get an understanding what the actual measurable benefits are of running checks, RS applications on native java SE, instead of using an application server.

A

Let's have a look at some real code. I have small checks or as application here, which simply prints a string on screen, it's not worse to tell what the application actually does. Just let's look at the code itself, I think most of it is self-explanatory, so I will only show you the hotspots. What the interesting points are, what we have changed in checks or as API, so you have an idea what you can do with check the rest to the to and later I talked about the problems.

A

We have bootstrapping a treacherous application outside of an application server, because we have to provide services ourselves that normally application servers would do so. What we have here is the bootstrap code for a checks, RS application.

A

We have a normal protocol ass, which has a typical main method as you are used by Java SE, and if we want to configure this application. For example, we want to tell the bootstrap code the IP port that we want to use. Then we simply use normal Java features for that there is no special feature built-in which just can do whatever you want. For example, I could imagine this is running on Cuban and kubernetes provides some environment variable.

A

Then we could parse it or here. In this example, we also have a default and default is number zero and zero, for example, would tell the system I want automatic check for on free IP porn. So this is plain drama that there is no checks or s so far. But what are we doing with that? And now this is the interesting point.

A

Normally the checks, RS application server would create an instance of the application and ask this that for the resources it needs- and we have to do that on our own. So first thing I do I create an instance on my own. This is normal Java, plain Java. As you know it, and then I have to put this instance into two checks or s runtime. So we added an API currently its name checks or restore start. This might change.

A

In the next week we were discussing the names, but the idea is the same and we have to give it a configuration again. Normally an application server has that configuration, but we have to provide it. So we have added this configuration class and a builder API, and using that builder, API I can set different settings like the protocol to use the hosts IP port, but also much more, and it's not limited to that. You can also use specific properties of your particular checks or as implementation. For example, I could give Jersey specific configuration options here.

A

There are more options inside of the configuration builder. We can also, for example, give it an external configuration. So we can have a supplier for properties. We could also have external configuration systems. Such a system, for example, could be the micro profile config API, so this is open to accept configuration parameters from more sources. Besides the manual builder api shown here now with this configuration and this application checks, RS is able to start an HTTP server. Now the question is: where is the HTTP server? Coming from? This is dependent of your actual actual checks.

A

Rs runtime you are using I will show you the pom file later, so you have an imagination. What the possibilities are here. Just let me go on with this code. First checks: RS is starting the HTTP server and it is providing another stage and that stage is called when the application server actually was able to start up the checks or as application.

A

It provides an instance. An instance is a pointer to the class of you checks, RS application running on the HTTP server, so you have some kind of life access to this instance, and this is nice because we can do some things with that. For example, we can tell this instance to stop from an external trigger. The external trigger we are using in this example.

A

Simply is a shutdown hook when I try to kill this Java VM, for example, kubernetes wants to shut down this container, then the shut down hook will run, and this code would execute in sense. That stop instance does stop by the way. Also has another stage where I can react on the end of the stopping I'm getting a stop result. This is nice in case. You want to lock, for example, whether the shutdown was successful or whether there had been problems.

A

You can even access native shutdown result codes of your application server products underneath sorry, not applications are I'm an HTTP server. In my example here, I simply lock the native result by unwrapping the checks are as standard class into some core class here. I could provide if I know the class that the HTTP server provides. I could unwrap it into this class and access its members as I have a 100% pure checks or as application here. I can just say it's an object.

A

Another nice thing, I get from the instance I- can ask for an actual configuration. So what's difference between this variable- and this result this variable here is the configuration I want to reach. So, for example, in kubernetes I said I want to run this checks, replication on HTTP localhost and on port 8080.

A

Then there is no difference with the actual configuration either. It can start it or not, but there are also dynamic properties. For example, if I provide a sea row- and this is part of our check- the rest to the to stand a zero to port. This means the checks are as implementation product like Jersey, for example- shall look up a dynamic port so inside this configuration part is set to serum here. If I ask the started, application for its configuration, I can ask the port actually used. So this is what this code does.

A

It builds up a URI and prints it on screen. So if we start it, we actually see to choose important okay. Here it is.

A

So this is just one small example of the API. What what you can reach? Certainly thanks to the lots of properties that are built into the different checks or as implementations. You have much much more things. You can do another nice thing you can do and I want to demonstrate this shortly. Its debugging I always had a problem when I want to debug checks, RS code on a real application.

A

Server I have to start up the application server, which is rather slow compared to a POJO, and when this is running it's running in a different Java VM, so I have to set up remote debugging and this is slow and it's error-prone, and it's just not nice, even with all the plugins you have, you have to install a plug-in, it has to work, it has to fit the ide version and so on and so on. I, don't like that.

A

I just one started as a normal program and debug it, and you can do that with this new checks or as Java SE bootstrap, it's just like normal debugging. It is normal. Debugging go into hello world. Now it's starting up to debug of you and you stopped on this breakpoint and from this point on I can use all the features built in the VM again. This is not a special Eclipse plug-in you are seeing here. This is the normal trauma debugger.

A

There is no specific built into Eclipse for that, and here I can do whatever I want so just go on and do to the fact that checks are ass, uses, inversion of control.

A

Debugging is a bit more complex because I have to start a request. Now again, I don't have any special tooling here. I just use curl to start a request. Oh.

A

Sorry that was the wrong point. That's a bad thing! When using dynamic ports, you have to match report.

A

Ok, now you have seen in the background the debugger stopped on another breakpoint, and what we see here is that it stopped inside our tracks, arrest, resource and I cannot actually guess what it's going on in the next step check. The res has lots of steps before and after that, like filters interceptors, but with the debugger. Do the fact that it's a normal Java code I can see what happens. I just have to go on. I can step into.

A

Let's do that a few times I can't go on jump to the next breakpoint. The next breakpoint is in a filter, so we can't see the filter. We can see the requests. You can see the response, let's open this and we can see it a bit more here's the status. If we got it's ok, we can't go on we step into an interceptor.

A

We are in about to proceed with the next interceptor. So let's just change the code. Eclipse is able to replace code life. So let's do that again. We were in the debugger.

A

And it jumped to the breakpoint again and we can debug to change code. Certainly this is no magic. This is what Eclipse to us with any code. On the other hand, that's so great about it, because now a Czech Terez application, even with the inversion of control, it's debuggable in Eclipse, without any magic, without any special tooling without any hassle, and if I want just. Let me, let's start another request. If I want I, stop this thing within seconds start it again and do the same again.

A

Because I don't have an application server, it's it's fast I can I can do that as often as I want so to turnaround time. The iteration time when developing checks or ass is really really great and fast without any special tooling and and that's what we want to reach with checks or ass in the future. That developing checks are s and executing checks, RS and deploying checks. Rs fields like a normal Java code and fields like a normal cloud native application. I wanted to tell you how this all works. Where is the HTTP server?

A

Coming from you haven't seen just checks error as standard code, there was no product. Specific API is called. Let's go to the pom file, I think you're familiar with the syntax and can read it. There is not much very complex inside it.

A

This one tells I want to use sure see. I could use any checks or, as implementation I just like to see I'm a contributor to Jersey, so I have choosen that one here I tried it with others, it's working actually, so certainly we need checks. Rs.

A

Then we are adding checks B, because I said there is no checks be anymore after Java SE 11. So we have to provide it on our own there's no applications who are providing it for us.

A

We also have to provide an implementation of checks, be certainly the AP itself is not producing anything without an implementation. Then this one is the very core server product of cursing.

A

This is the dependency injection framework providing the content for @inject annotation.

A

This is the actual HTTP server and there is one nice thing interesting. Everything is in a module. You can change modules among lots and I change now, just by changing the palm from natty to Cherry and Eclipse immediately is recompiling the application and now I start the same application without changing any line of the code without any line of the configuration, and it has booted and it is working. So this is to prove that our ID is working.

A

We can start up a checks, RS application within a second or within seconds, and we can change the underlying technology just by changing the class path, not by changing the configuration or by changing the application itself. Sorry, this was the wrong poor. Certainly, this proves nothing: let's use the right port.

A

Okay, so here's the result: 200, okay,.

A

And since everything in Jersey is a module, we also have to provide the possible content types as modules. So here we start up the Chasen binding, and here we start up to java xml binding.

A

So if we, if we don't need XML, we can just drop it. I will keep it and now, let's look at the class path. This is the complete class path of the application, including all technology needed, including all api's, including sure, say, container, including jetty HTTP, including the checks being implementation, I have chosen and so on and so on, and this is all you need to run inside your taco container later there is no application server. There is not anything more that you really will need.

A

You will not load any classes that you will never fire up, and this is really great I think- and this was the one feature that we thought is the signature feature for checks or s 2.2. There are more smaller features in the in the box with the release notes when we have released them and tried out as soon as you can here are the numbers I talked about earlier and I hope they look good to you. What we see here is that I have measured the boot time, the char size, the amount of limited memory.

A

You need to run this amount of limited stack. You can run on and the number of docker space I provided for my application and in the in the bold column, you see my actual HelloWorld application, which was Java, SE, sure, C, 230, preview, natty and check sure as to the two and the boot time was about 2.5 seconds. I said earlier: it's able to start up in less than a second. This is actually true, but it depends on device so the device here it was very, very very limited.

A

It was some kind of system on a chip device and it only had 256 megabyte of RAM. It has a single core and it's running on a gigahertz. So when you start the same application on your laptop, it will put in much less than a second. So on this limited device you can run it with a 6 megabyte charm, so a 6 megabyte sha was 6 megabyte. Let's look on the right side. We have Java EE server with Jack's arrest, 2.1, which comes with 142 megabytes, plus your application.

A

So this this is the difference you get from running it on Travis II and look in the first row to startup time of the application server on that device would be around 60. Second I couldn't actually measure it because it failed you to the missing memory. I tried it later in a comparable, docker container and it actually needed around one minute just to boot, with this limited justments, so you can start very much faster. You need very, very few memory compared to the application server and this is actually measuring numbers.

A

So this is the proof that using Java S II as your foundation instead of an application server, it's not only possible, but it's very beneficial, and now this was neither Quackers nor hell alone. This was really only the code you saw in the live demonstration.

A

The application server used here by the way was ir a--, once more I'd like to invite you to discuss with us. Unfortunately, I couldn't attend life to Jakarta one today. So, if you have any questions for me in person about this presentation about the numbers, I measured, you can write directly to me. The address is given here in this slide and that's pretty much it. Thank you for your interest in cheques RS. If you like to contribute just open an issue in the cheetah tracker or write your mailing list, your help is very appreciated.

A

Have a good time bye.