For the IDE issue, how do you setup the build in eclipse, didnt java version reference in eclipse files? using java 21 + --enable-preview fails due to allocateFrom() usage (java 22) but using java 22 EA fails cause both setups are not compatible it seems. Alternatively, moving panama integration to another module until it is final wouldnt be bad IMHO, in particular while no LTS supports the required code and it still moves, no?
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 à 20:58, Mark Thomas <[email protected]> a écrit : > > > 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] > >
