Specs that don't change don't need to move out of javax.*.
I'd like to see a bigger vision for Jakarta EE 9. Is there still a
platform? Is there still an application server? Does it include
everything that was in Jakarta EE 8, plus more? Is it pruned to the
bone? Is it microservices only? Is it all a la carte?
With some guiding principles, maybe some of the detailed answers
will fall out?
Werner Keil wrote on 4/15/19 5:39 PM:
Kevin,
Good Point, thanks for
elaborating.
Especially
>
- If so, when and would anything not be moved?
Is a key question probably mainly towards
Oracle.
Would an existing spec like JCA (Java
Connector Architecture) have to change to a new “jakarta”
namespace, even if hypothetically it may never be touched or
upgraded again?
While e.g. Ivar’s and Christian’s MVC
standard is close enough to a Final release, JSR 382 (led by
“Eclipse Foundation” although at least Emily is a permanent
employee of IBM, not sure, how the whole IP situation works in
that case?) https://jcp.org/en/jsr/detail?id=382
is quite inactive by JCP standards. And even after upgrading
to JCP 2.11, the 18 months before a failure to submit a Public
Review trigger a Renewal Ballot seem only a few weeks away.
For MVC or the specs that went Final with
Java EE 8 already it is a good question, if an update towards
Jakarta EE 9 or above means, only the new elements should be
declared under “jakarta” or everything refactored from
“javax.*” to “jakarta.*” starting with a new version.
We had similar cases before, remember http://medialab.di.unipi.it/web/doc/tutorial/uiswing/start/_packagename.html
with package names literally swinging from
“com.sun.java.swing” to “java.awt.swing” and “javax.swing”?
Who knows, if it followed the fate of
JavaFX it may end up with a 4th package name some
day.
If JSR 382 which has not even produced an
EDR yet wanted to become a part of the Jakarta EE platform,
then for the sake of consistency and to avoid confusing
possible users (or other projects and specs hoping to use it)
it really should make up its mind, if a start with
“javax.config” still makes any sense if it had to rename new
or all parts to “jakarta.config” anyway.
Werner
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.
-----
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.
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
_______________________________________________
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
|
