jooby 3: next major release

This is an open discussion of what we want for Jooby 3.x. For now we will start a discussion here and then cleanup ideas/features to a wiki page (or similar).

Beside is going to be a major release... I'm not planning to break compatibility like we did in 1.x -> 2.x upgrade, so:

Web site will keep as it is today: https://jooby.io, same goes for Java package: io.jooby.
The 3.x source code will be just a refactor of existing 2.x source code (not an entire rewrite). Unless something really bad/ugly come up, you will be able to upgrade doing a search/replace session.

Some notes I have so far:

Review Context API add getter/setter for almost everything (simplify unit test)
Keep minimum request/response related method into Context (simply context API)
Add getRequest/getResponse method to Context and add all the necessary getter/setter to each of these new Request/Response API
Remove bytecode analysis for return types and get back reactive operators (similar to 1.x)
Remove asm from jooby core
Kotlin Normal route vs Coroutine route try to simplify usage and remove the HandlerContext object. Favor usage of fun some(ctx: Context) and then get("/route", ::some). This probably implies that lambda body route are bind to Context itself
Rename FileUpload.destroy to close and make it Closable
Value API make them getter friendly
Remove runApp. Replace. with new App()
Rename Jooby class to WebApp?
Use application.logback.xml so we don't have initialization issues

As always, your feedback is welcome

These look good. Can you also include adding of setter methods for the ModelAndView class so we don't have to re-initialize the class in case we are changing the view name for the same route?

Having to do this right now, in stead just set the view name based on the request parameters. Other routes can have multiple such initialization which looks expensive?

get("/", ctx -> {
            ValueNode asyncPage = ctx.query("asyncPage");
            ModelAndView modelAndView;
            if (Boolean.parseBoolean(asyncPage.toString()))
                modelAndView = new ModelAndView("index_async.ftl");
            else
                modelAndView = new ModelAndView("index.ftl");
            
            return modelAndView;
        });

Nice to hear that compatibility with 2.x is kept in mind. We just started to use Jooby 2.x and planning with it for the long run, also planning to migrate our older codebases.

Huge thumbs up for the API refactoring for Contect -> Request + Response!

We ran into some problems with the Guice extension. In Jooby 1.x it was very convenient that you could inject request scoped objects into controllers / services. In Jooby 2.x it's only possible with some custom extensions implementing @RequestScoped and co. similarly to Jooby 1.x.

Could you briefly explain what does return value analysis and ASM in Jooby do?

Huge thumbs up for the API refactoring for Contect -> Request + Response!

Going to keep Context in 3.x, because feel it is better the single argument handler:

get("/", ctx -> {...})

and not the two arguments

get("/", (req, rsp) -> {...}

There are some method name collision will keeping everything in Context class. In 3.x going to only keep the most frequently used methods in Context class, while less frequently or more specific methods will be available in Request/Response classes. This helps to keep some common code in Context (jooby-core) and force server to implement more simple/basic Request/Response objects.

Could you briefly explain what does return value analysis and ASM in Jooby do?

ASM helps to identify handler return types in lambda/script routes:

get("/rx", ctx -> CompletableFuture.supplyAsync(() -> "..."));

So here ASM find the handler returns a completable future and:

Run route handler in EventLoop
Attach a completable listener and to send response when ready

Same for other reactive types from: rxjava and reactor
In 3.x this will requires some manual intervention (like in 1.x):

use(new CompletableFutureAdaptor());
get("/rx", ctx -> CompletableFuture.supplyAsync(() -> "..."));

Removing ASM give us:

Even faster startup time
Reduce memory in class space

Would removing ASM slow performance down?

Would be good to add a jackson alternative such as dsljson since that's been 1 of the bottlenecks in techempower benchmarks :)

Maybe other security options besides a heavy weight like pac4j?

GraalVM aka native mode would be useful in a lot of places but might be a bit of work.

Would removing ASM slow performance down?

A bit on some specific use cases, but not for usage on real application.

Would be good to add a jackson alternative such as dsljson since that's been 1 of the bottlenecks in techempower benchmarks :)

Yea, nothing stop us from using dsljson today. Due it requires an annotation processor, don't think we need to support as Jooby module. I keep jackson in TEB bc is a real library that works for complex use cases. Still, we. could rewrite the benchmark to use. something more lightweight

Maybe other security options besides a heavy weight like pac4j?

Hahaha, feel something similar... but is there any security framework lightweight?

GraalVM aka native mode would be useful in a lot of places but might be a bit of work.

We did some work and got something working with 2.x, slf4j-simple logging and netty (think undertow didn't work). Removing ASM from core (actually from runtime) will help to make Graal image.

Yea, nothing stop us from using dsljson today. Due it requires an annotation processor,

dsljson has a reflection option, which is still quite a bit faster.

but is there any security framework lightweight?

If it's just basic auth or jwt (via e.g. jjwt) then it doesn't really need a "framework".

netty (think undertow didn't work)

Undertow 3 will be a wrapper around netty.

dsljson has a reflection option, which is still quite a bit faster.

cool, I didn't know it.

If it's just basic auth or jwt (via e.g. jjwt) then it doesn't really need a "framework".

Yea, I usually do header auth so never use pac4j. There is a jwt auth module too: https://jooby.io/modules/jwt-session-store/

Undertow 3 will be a wrapper around netty.

Awful/wrong decision is you ask me. Found undertow super fast (faster than netty) and by far lot easy to work than netty. Also, it is a truly option/alternative to netty today. Don't want to be a wrapper over netty.
I believe Undertow API and execution model will be more or less the same (but around netty). Probably going to drop support for Netty when Undertow run on top of it.

Found undertow super fast (faster than netty)

Depends. Netty has more features like OpenSSL support. There's a lot of options that can be turned on. Out of the box Undertow is faster. Netty is complex though I agree.

Awful/wrong decision is you ask me.

Main focus is on moving off Wildfly (the main use of Undertow) and into Quarkus (which is Vertx/Netty). Makes sense as a business - Netty has a lot more users in the community, e.g. Twitter, Google and Apple. I don't think it's wise for IBM to be re-implementing HTTP3 and many of the other missing features in Java land when it comes to it so consolidating was a good move.

Undertow hasn't had major features properly in a long time. It was almost a solo project and the ex-lead now moved to Quarkus. I really like the API of Undertow!

Probably going to drop support for Netty when Undertow run on top of it.

Would be good to compare once Undertow 3 or 4 comes out to see how much overhead they've added too.

There is a jwt auth module too

Is it a documentation issue? The session store doesn't feel like authentication so maybe I'm misunderstanding it...

Simple caching with annotations and some assistance with API versioning would be good too.

I'm not going to say anything about Quarkus... 😄

Is it a documentation issue? The session store doesn't feel like authentication so maybe I'm misunderstanding it...

Integrates the HTTP Session with JWT token using a cookie or header.

Simple caching with annotations and some assistance with API versioning would be good too.

Yea, this is more or less: module (so we can probably add something today). This thread is more for core changes. Do you have an example of API versioning?

@Version

Do you have an example of API versioning?

@Version(1) -- so via annotations on methods / classes and option to set it as either via header, request parameter, or part of the uri to request it. Can return via uri, mime type or header etc.

kotlinx.serialization support!

Would be great to see some native support for https://github.com/Kotlin/kotlinx.serialization

Thanks!

I agree. I just floated the vertx option if folks wanted to have a single underlying HTTP server/servlet implementation throughout their code base but as I said it really adds very little value to jooby as vertx itself is built on netty and jooby already is. If undertow switches to Netty then undertow is basically like vertx and doesn't add much value.

I guess the point I'm making is I would consider Undertow in jooby 3.0 lower priority given its apparent future and possibly replaced. Loom may change a lot of stuff so something like Helidon Nima maybe a better 3rd option to explore.

First milestone is out: https://github.com/jooby-project/jooby/releases/tag/v3.0.0.M1

Still lot more to do.

@jknack

@jknack is there a possible chance we can add automatic modules in the META-INF/MANIFEST.MF for v2.x?

The reason being is it will make it easier for me to test 3.x on our code base by swapping them out (I know there are api changes but I can deal with that) while still retaining a module-info in our projects.

I don't have time to do it but also isn't a good idea. I don't want to get bugs, questions on 2.x around modules.

Yeah I was thinking the same while driving that I will just upgrade v3 across the board that way I can better help you as it will get confusing for me if we have issues.

Plus I assume v3 will get updates faster anyway and you generally accept PRs from me so I'll go ahead with it.

Right. 2.x will go to maintenance mode, no more (new) changes there.

@agentgt

@agentgt @jknack I played around with enabling virtual threads on Jetty as well as a super bare bones Helidon Nima server implementation for Jooby. Let me know what you think. I know this isn't exactly related to the release, but I saw you all talking about loom up above. Maybe we can enable the Jetty virtual thread options if you're on Java 19 somehow?

Jetty Loom Branch

Helidon Nima Server Branch

@blquinn

@blquinn The best way to do it would be manual wiring or through the ServiceLoader with some caveats.

I can't remember how we load up the various Server implementations but if it is with the ServiceLoader ~~which I'm fairly sure it is~~ (it is) then sadly you would not be able to decorate the existing Jetty Server implementation. This is actually a problem with most SLF4J implementations as well (ie there is no way to decorate say logback with your own slf4j implementation).

https://github.com/jooby-project/jooby/blob/3.x/modules/jooby-jetty/src/main/java/module-info.java#L22

There is actually a pattern I follow because of this but I'm fairly sure @jknack is not going to like this.

Basically you make an abstract jar that has almost the entire implementation minus the ServiceLoader registration.

Below is how the modules would look (modules being jpms jars).

jooq-jetty <-- all jetty code
jooq-jetty-server-plugin <-- ServiceLoader maybe using static provides method
jooq-jetty-server-loom <-- depends on jooq-jetty and wraps it for loom and compiled 19
jooq-jetty-server-loom-plugin <-- depends on jooq-jetty-server-loom and has ServiceLoader registration

Of course the easiest thing for now is to literally copy all the code in the io.jooby.jetty module.

BTW most folks do not know that you no longer need a no-arg class anymore to create for the ServiceLoader and instead can create static method like:

public class LoomJetty {
    // the method has to be static, public and named provides
    public static Server provides() {
      // create jetty server code using shared logic or copied logic
    }
}

And thus you avoid the constructor annoyances and or having to use the delegate pattern.

@blquinn

@blquinn

I guess what I'm saying is the easiest thing to do for now is to make separate projects for nima and jetty that are outside of jooby. Use the ServiceLoader registration to make your own Servers. You will have to duplicate jetty logic for now.

That way you avoid jooby code base locked on 17 (albeit there are ways to compile with multiple jdks in maven it isn't worth it).

Then the instructions are simple. Tell whoever to include your module (maven runtime dep) instead of jooby-jetty.

@agentgt

@agentgt Yea I did suspect that copying everything would probably be the easiest way. Thanks for the info though. I'm somewhat familiar with ServiceLoader because I had to use it already for nima to work.

I guess I'm wondering if it's worth setting up a separate module, I'm not really sure if anyone will be interested in using this, or not. Jetty at least is basically ready to go because its just a couple lines of code, maybe that would be worth it.

'm not really sure if anyone will be interested in using this, or not. Jetty at least is basically ready to go because its just a couple lines of code, maybe that would be worth it.

I'm sure they will assuming the quality is good (btw you might want to remove what I assume is an accidental kotlin dep). In fact I would be curious to see it in the techempower results. Hell I was going to do what you are already doing myself I just didn't have the time. So sally forth with testing loom 👍

@agentgt

@agentgt Okay, you've convinced me ;)

Navigation Menu

Repository navigation

jooby 3: next major release #1712

36 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

jooby 3: next major release #1712

Description

Activity

sayyiditow commented on May 18, 2020

imeszaros commented on May 28, 2020

jknack commented on May 28, 2020

re-thc commented on Jun 8, 2020

jknack commented on Jun 8, 2020

re-thc commented on Jun 8, 2020

jknack commented on Jun 8, 2020

re-thc commented on Jun 8, 2020

jknack commented on Jun 8, 2020

re-thc commented on Jun 9, 2020

inaiat commented on Jun 18, 2020

36 remaining items

agentgt commented on Sep 12, 2022

jknack commented on Dec 5, 2022

agentgt commented on Jan 13, 2023

jknack commented on Jan 13, 2023

agentgt commented on Jan 13, 2023

jknack commented on Jan 13, 2023

blquinn commented on Jan 24, 2023

agentgt commented on Jan 24, 2023

agentgt commented on Jan 24, 2023

blquinn commented on Jan 27, 2023

agentgt commented on Jan 27, 2023

blquinn commented on Jan 28, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions