I couldn't make last week's call so I don't know how much of this was discussed already... But, I think David's first question has to be asked (and answered) before we dive into the details of what tooling is available to accomplish some task...
> - Should all code be transitioned from javax.* to jakarta.*
> - If so, when and would anything not be moved?
My take is that we should not do a "big bang" move from javax.* to jakarta.* in Jakarta EE 9. I think we should do this on an "as needed" basis. So, instead of doing a full-scale move of everything from javax.* to jakarta.*, we should do it as the Java EE components require it. As an example, let's assume that JAX-RS and JMS are chomping at the bit to add new functionality in Jakarta EE 9. These components should figure out what the impact is to move to jakarta.*. And, there may be ripple effect. But, we shouldn't move EJB to jakarta.*, if there are no proposed updates in the space.
Some may argue that we should just bite this and make the move all at once. But, why affect every Java EE application with Jakarta EE 9 if we could limit it to maybe 20% (or whatever)? And, allow a more gradual move to the new namespace. Maybe at some point down the road, we determine that we have critical mass and we can move the rest of the dormant components. Or, maybe we determine that these dormant components should just be left with javax.* and never "promoted" to Jakarta EE... Decisions that we can move out a bit.
Once we determine the scope of the change in Jakarta EE 9, then we can determine how best to roll it out for each component and also look at providing tooling to help with any required migrations.
-- Kevin
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
----- Original message -----
From: Ivar Grimstad <ivar.grimstad@xxxxxxxxx>
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc:
Subject: Re: [jakarta.ee-spec.committee] Potential Agenda item for tomorrow
Date: Wed, Apr 10, 2019 3:10 AM
I agree! This is an item we need to address that cannot wait until after any announcement regarding javax.* namespace.
Ivar
There is an agent based project that has the ability to do this via rules:
http://byteman.jboss.org/
On Tue, Apr 9, 2019 at 2:43 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>
> I mentioned I can attend, but won't have time to create material for us to review. Tanja was wondering if she should cancel.
>
> We do need to have a directed technical discussion on how we can move Jakarta EE forward without the javax namespace. Dmitry raised on this morning's PMC call that we really need to communicate some path forward as part of the public disclosure that modification of javax is no longer on the table. I agree. It cannot wait till after we disclose the minutes and after Jakarta EE 8.
>
> I dont' think we need firm agreement on how. Any sign of hope to cling to is good -- it can evolve. We just need to:
>
> - Collect some ideas on how to move forward, technically
> - Write it down and hand it over to the Steering committee
> - The ideas will not constitute agreement, just options (hope)
>
> I would suggest we need to have this discussed, written up and closed for delivery by next Wednesday.
>
>
> Some discussion items:
>
> - Should all code be transitioned from javax.* to jakarta.*
> - If so, when and would anything not be moved?
>
> - How do we imagine solving the compatibility issues:
>
> - Could we write a Java Agent to transform application bytecode from java
> - How would we handle META-INF/services/javax resources?
> - How do we handle system properties in the javax namespace?
> - Are there any xml schema related concerns?
> - Does JSF have any additional issues with faces descriptors?
> - Could we create an Eclipse IDE plugin to update the source of old apps?
>
> Both Dmitry and I had been independently dreaming up a dynamic bytecode modification solution for backwards compatibility with old apps. The IDE plugin idea is entirely his and I think could be used in a way that creates positive spin, "aren't we lucky we're at the same home as the Eclipse IDE."
>
>
> -David
>
>
>
>
> An idea both Dmitry and I had was to write a Java Agent that could modify bytecode and "upgrade" old apps to run on new jakarta.* servers. There's obvious issues on handling resource lookups to META-INF/services/javax.* files. As well, could we leverage being Eclipse and imply we may start an effort to write an IDE plugin to update people's source code from javax to jakarta?
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 310-633-3852
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
