OK, thanks. I was aware of the difference now but was simply using the wrong terminology. My apologies.
To be more precise, may I request that some of the current committers ideally including the project lead share some thoughts on when they see the Jakarta EE 9 work being started? Clearly a lot of folks are keen on seeing activity on this technology resume and are willing to help? What do you think?
Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
Finally went through the issues. To be
honest, I remain convinced big ticket changes to JPA is probably
not necessary right now though clearly some work could be triaged
after Jakarta EE 9.
I am wondering though, when will the
javax*->jakarta* transition work start? I noticed Oracle
remains the spec lead. Is that correct?
Not entirely since there is spec lead role in the Jakarta EE Specification Process. Lukas is the Project Lead for Jakarta Persistence, but decisions are made by the committers where all have an equal vote.
Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an individual
community member and do not reflect the views of my employer.
On 11/8/2019 1:36 PM, Roberto Cortez
wrote:
Hi,
The JPA Github repo already
has a bunch of issues reported, migrated from the old repo:
I think we should look into
what is in there and figure out what makes sense or not. I
suggest that the requests being discussed here to be reported
over there.
Let us see how others respond. If the response is
good, I would create a JIRA with some example code. In
fact, you may want to check if there is one already
and add to that.
Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an
individual community member and do not reflect the
views of my employer.
Sent via the
Samsung Galaxy S7, an AT&T 4G LTE smartphone
I try to get more engaged here. Right now off
the top of my head, I was thinking about
discussing the possibility of adding support for
UNION to JPQL/Criteria.
It sometime can lead to significant performance
improvement as some planners struggle optimizing a
query with many joins but do fine when the query
is split into two where results are combined using
UNION.
Another feature was the possibility of
declaring associations with Streams instead of
Collections, with semantics that would allow
iterating over millions of rows without eating too
much memory.
Also now that some RDBMSes have first class
support for JSON, letting users inttospect JSON
fields and use them in WHERE clauses, adding
support to JPQL/Ctiteria would be nice.
I am adding a few folks
here that could help mentor and kick-start this.
I myself frankly can only guess at this point.
However, I would say all
of this is new so starting just about anywhere is
fine.
Additional responses below. I have removed extra
text for brevity.
Reza Rahman
Principal Program Manager
Java on Azure
Please note views expressed here are my own as an
individual community
member and do not reflect the views of my
employer.
On 11/2/2019 9:04 AM, Christian Beikov wrote:
>
> I think there are lot's of issues in the
issue tracker that could be
> tackled, but at this point I am not sure
about how to start.
>
I suggest starting by triaging the issues here
together.
> Are the discussions about the big bang
namespace change already over?
>
There is still some churn but looks like things
are very, very slowly
gravitating towards big bang. I believe the
community stepping up to
move things forward will accelerate these
decisions.
>
> Is it even possible to add features in such a
seemingly
> "namespace-change-only" release?
>
Likely not.
>
> What needs to be done to actually add a
feature? Is a PR containing
> the spec and API changes enough? I guess a
TCK test would have to be
> added as well? How is the decision made that
a feature is added?
>
Anything that can be done is progress. In order
for something to be
considered complete, it likely needs an API
change, change in one of the
implementations, a TCK change and a spec document
change. They don't all
need to be done by the same people. The project
committers and lead
decides if a change will be made - effectively
that means all of us
together. Given the state of things, I would say
most reasonable changes
should make it in. It is contributing that
actually matters.
>
> It would be great if we could illustrate the
process with a more or
> less simple issue(https://github.com/eclipse-ee4j/jpa-api/issues/163)
> so that people get a feeling for how the
specification can be shaped.
>
As long as you have the paperwork set up, I would
say there is nothing
stopping you from doing exactly that.
_______________________________________________
jpa-dev mailing list jpa-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jpa-dev
--
Reza Rahman
Principal Program Manager
Java on Azure
Please note that views here are my own as an individual community member and do not represent the views of my employer.
