In Jackson the Kotlin module tells it that the CTor is JsonCreator which changes further behavior.

We set that plus all the parameter names, so it doesn't follow full default path of Jackson.

Jackson Jr works differently for Kotlin, it is a port specifically for Kotlin yet supports Java Beans as well, no extra annotations. More interceptors.

JSONProperty should on be on field if on getter and setter.

It can be on parameter and is required in Java when using JsonCreator. For Kotlin we imply these annotations if JsonCreator doesn't exist explicitly.

So there ya go, fun and games with annotations

Whatever the outcome, I think it should be at least apply to the field because there are some annotations like @Volatile which can only apply to fields. Difference per annotation would be very confusing I think.

Volatile is nor very common, and maybe less set in a constructor. I think that You can use the annotation target syntax on those rare cases. Making common cases easy.

The fact that it might be less set in a constructor is I think not a persuasive argument for exceptions in language grammar.

Otherwise an annotation like volatile shouldn't be allowed in primary constructors but should be allowed on class fields

That feels like the same code behaving differently

You either go more wordy to be specific, or need a less wordy workable default. Would be nicer if the annotations all had their intended targets baked in. Annotations in M13 can be more targeted, like volatile. But ones used from Java that don't have the same level of targeting as a Kotlin built one, become a problem. Maybe we could override targeting of Java annotations so we use the 'apply to all of their intended targets' but can fix that where Java is lacking.

I had a brain fart about http routing and how it could be implemented. Let me state upfront that there is nothing wrong with how it’s implemented in ktor, it’s by no means a reaction to the current implementation. It just really about the idea. I wanted a way of registering routes in thread safe manner, easy api, blazingly fast lookups and avoid as much garbage as possible during lookups. The rudimentary implementation of this idea can be found here https://github.com/mplatvoet/routes/blob/master/projects/routes/src/test/kotlin/example/performance.kt It’s by no means a full version (yet), the only thing implemented are paths including wildcard matches. Query paramaters and that kind of stuff not yet but I have a pretty good idea how to do that. I like the performance results for now. In a single threaded lookup setup (more threads, matching cores, will just be faster in this case) 1 lookup in a table with 100,000 route entries (which of course far more than most apps) takes about 0.001ms (on a macbook pro).

why do you need threadsafe registering?

also, I don’t trust very much timestamp-and-loops benchmarks simple smile I’d prefer JMH as a benchmark tool.

But the goals are almost the same as I had when designing routes in ktor simple smile Linear lookup in a List that is used in almost every framework out there somewhat confuses me.

oh I don’t think of it as an actual benchmark, it’s performed on my local machine, so the only value it gives is a bit of an idea in which range it sits

that’s often a problem with timestamp-and-loop benchmark. using JMH is not any harder, but they do amazing work in getting rid of various JVM tricks.

e.g. if you have an unused value, JVM is often capable of not only eliminating calculating this value, but also any value that is required to calculate it. in some cases it just eliminate half of the code under test.

yes, but only if it can determine it hasn’t any side effects, do you have any idea to which extent this happens. I can think of a theoratical extent, but the actual extent I haven’t got clue of

this is often the case in microbenchmarks, when you are measuring short code with not much happening, like an algorithm

no, I’m NOT telling your numbers are not accurate or something simple smile Just if I were to do it, I’d use JMH. I will, but when ktor is more or less feature-ready (in first iteration) and API is good and stable enough.

yeah this is by no means an attempt to change the implementation of ktor

why not?

I do think, as you have pointed out with the list implementation of most frameworks, this is an area where a lot of performance gain is to be found

may be not in its entirety, but of course good ideas should propagate simple smile

this is to be measured yet, because there are things that will complicate routing

My goal is to support the same things as Springs @RequestMapping

e.g. in ktor routing, you may have selector for headers, so that you can select handler not only by method and path, but also by

Accept:

header for example. And since such header(s) can have

;q=0.5

parameters for ordering, it complicates things. "First one wins” doesn’t work anymore.

I was thinking of changing the lookup method to an Iterator