paulrutter commented on PR #433: URL: https://github.com/apache/felix-dev/pull/433#issuecomment-3357792022
> > Anything specific? I'm looking at using a MRJ for activemq-client to use that for the Virtual Thread classes that need JDK 21+. > > Even for that I would use a separate project that holds the Java 21+ code that uses Virftual Threads and then pull the classes into the project that still targets the old Java release. Then have code that knows what class to load based on Java versions. That is what we do for the Virtual threads. We then created an `org.osgi.service.condition.Condition` ID for the Java version so that we can enable the correct service component based on the Java version. > > For example, this component only gets enabled for Java versions < 21: https://github.com/OpenLiberty/open-liberty/blob/f8638a00c65c9dec748d21253571b2d0acd9fcab/dev/com.ibm.ws.threading/src/com/ibm/ws/threading/internal/VirtualThreadDisallowed.java#L34 > > And this one gets enabled for Java versions >= 21 > > https://github.com/OpenLiberty/open-liberty/blob/f8638a00c65c9dec748d21253571b2d0acd9fcab/dev/io.openliberty.threading.virtual.internal/src/io/openliberty/threading/virtual/internal/VirtualThreadOperations.java#L40 > > The rest of the system gets injected with the right component implementation without having to worry about what Java version is running. That's an elegant solution to the problem indeed. In Felix, we have resorted to reflection to determine java 21 specific features, see for example https://github.com/apache/felix-dev/blob/0c74c4693d49211beff294a2cfdf5bf42c8c0e14/http/jetty12/src/main/java/org/apache/felix/http/jetty/internal/JettyService.java#L287. But this is pretty isolated. To get back to the problem of the SecurityManager in Felix, i feel we've only scratched the surface and are not aligned on the approach to take. The options as i see them: 1. use reflection or a similar approach outlined above to go about distinguishing java features and thus remain to have one main branch 2. Maintain two branches, depending on java version support or remain to have one and increase minimum java version to 25 (probably undesired) in next release 3. Investigate MJR feasibility 4. Other ideas? I don't have a strong preference yet, but i do think we should come up with a plan forward, while also respecting the [OSGi spec](https://osgi.github.io/osgi/core/framework.security.html) on the security aspects. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
