On 22/01/2024 15:04, Romain Manni-Bucau wrote:
Hi Mark,
Checked deeper the sample and seems it is the old lambda issue, so indeed
we can avoid the NPE and fallback on Object but since it was not done I'm
not sure it would be helpful compared to current code.
Here is the test:
@Test
public void testLambda() {
final MessageHandler.Whole<String> handler = message -> {
};
Assert.assertEquals(Object.class, Util.getMessageType(handler));
}
So guess we can play the status-quo.
To save others doing the search:
https://bz.apache.org/bugzilla/show_bug.cgi?id=65458
+1 to leaving things as they are.
Side note: seems ide-intellij ant task got broken with java 22 API usage of
the source.
Possibly. I'm an Eclipse user so we'll need an IntelliJ user to take a
look at that.
Mark
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 22 janv. 2024 à 12:53, Mark Thomas <[email protected]> a écrit :
On 21/01/2024 18:33, Romain Manni-Bucau wrote:
Hi,
I know websocket 1.0 methods without providing the handler type are kind
of
deprecated (not recommended would be more correct) so not sure this bug
would get a fix or not.
Long story
short,
org.apache.tomcat.websocket.WsSession#addMessageHandler(jakarta.websocket.MessageHandler)
will call Util.getMessageType which goes into the reflection code and the
interesting part is org.apache.tomcat.websocket.Util#getGenericType and
more precisely TypeResult superClassTypeResult = getGenericType(type,
superClazz); which can return null (end of recursion) but next line
being int
dimension = superClassTypeResult.getDimension(); we can get a NPE.
The fix is trivial but I'mnot sure it is worth it or just redirecting to
the right API would be better.
It depends whether this is one of the cases we can actually handle
correctly or if it is one where you have to use the new API.
If we can handle it correctly, we should. If not, I'm fine with throwing
an although it looks like the error handling might need a small tweak in
that case.
Can you provide a concrete example that currently fails?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
