Hi Pawel! A few of your commits do look interesting. Will surely come back to it after getting rid of Serp! I fear the problem I have now got introduced by finally wanting to get rid of generating Java5 code as due latest ASM does not support all features of ASM5 anymore.
LieGrue, strub > Am 30.04.2023 um 18:18 schrieb Pawel Veselov <pawel.vese...@gmail.com>: > > FWIW, we did this on 3.1.2 to use in J17. > https://github.com/veselov/openjpa/commits/3.1.2.xl4.j17 > > On Sun, Apr 30, 2023 at 5:44 PM Mark Struberg <strub...@yahoo.de.invalid> > wrote: >> >> Oh btw, some work can be seen over here. Not yet ready to be pushed, but is >> maybe a start: >> >> >> >> https://github.com/struberg/openjpa/tree/jakartaee >> >> >> LieGrue, >> strub >> >> >>> Am 30.04.2023 um 17:19 schrieb Mark Struberg <strub...@yahoo.de.INVALID>: >>> >>> Hi lords and ladies! >>> >>> I'm right now in the process of moving openjpa to jakarta natively. >>> While doing that I stumbled across a failing test >>> (org.apache.openjpa.persistence.detach.TestDetachNoProxy#testClear10Compat) >>> which is due to some proxy classes cannot be generated at build time. >>> >>> I'm looking at the generated classes right now and I have to admit I'm a >>> bit confused. >>> >>> It looks like they contain state? (via StateManager and delegating to super >>> which is java.sql.Date) >>> public class java$sql$Date$proxy extends Date implements ProxyDate { >>> private transient OpenJPAStateManager sm; >>> private transient int field; >>> >>> public java$sql$Date$proxy(long var1) { >>> super(var1); >>> } >>> >>> public java$sql$Date$proxy(int var1, int var2, int var3) { >>> super(var1, var2, var3); >>> } >>> >>> public void setOwner(OpenJPAStateManager var1, int var2) { >>> this.sm = var1; >>> this.field = var2; >>> } >>> public void setDate(int var1) { >>> Proxies.dirty(this, true); >>> super.setDate(var1); >>> } >>> >>> public void setMonth(int var1) { >>> Proxies.dirty(this, true); >>> super.setMonth(var1); >>> } >>> >>> But on the other hand we do cache those instances in ProxyManagerImpl >>> >>> private ProxyDate getFactoryProxyDate(Class type) { >>> // we don't lock here; ok if two proxies get generated for same type >>> ProxyDate proxy = (ProxyDate) _proxies.get(type); >>> if (proxy == null) { >>> ClassLoader l = GeneratedClasses.getMostDerivedLoader(type, >>> ProxyDate.class); >>> Class pcls = loadBuildTimeProxy(type, l); >>> if (pcls == null) >>> pcls = GeneratedClasses.loadBCClass( >>> generateProxyDateBytecode(type, true), l); >>> proxy = (ProxyDate) instantiateProxy(pcls, null, null); >>> _proxies.put(type, proxy); >>> } >>> return proxy; >>> } >>> and others. >>> It looks really weird, because this caches instances apparently? Reason why >>> I do look at it is that with moving to Jakarta and Java11 the Serp stuff >>> totally falls apart. And the ProxyManagerImpl#main which is called via Ant >>> during the build to create a few proxies named java$sql$... in >>> o.a.openjpa.util fails due to that. >>> >>> And the build time proxies are serializable, while the dynamically built >>> are NOT, because they are loaded via a separate synthetical BCClassLoader >>> from Serp. Which is not available or gets ignored during deserialisation. >>> Now we have >>> org.apache.openjpa.persistence.detach.TestDetachNoProxy#testClear10Compat >>> fail due to that if those proxy classes cannot be generated at build time. >>> But likely this problem also appears in other cases where this mechanism is >>> used. Which is _not_ really often the case afaict. Usually when enhancing >>> the class the whole getter and setters are changed during enhancement to >>> call StateManager#dirty. >>> Still it's imo important to fix the whole proxy generation. >>> >>> Is anywhere around which has a spare hour (or a few) to help me look at >>> this via a shared screen session? I fear this is not as easy as it looks >>> like. >>> >>> I'd first like to understand what this really is used for nowadays and only >>> then replace it with an ASM based approach. Writing the ASM stuff is >>> actually not the real problem here. >>> >>> Anyone up for a hacking session? >>> >>> txs and LieGrue, >>> strub >>> >>> >> > > > -- > With best of best regards > Pawel S. Veselov
