You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2017/07/24 15:22:58 UTC
[DISCUSS] Make trunk target JPA-2.2
Hi!
The JPA-2.2 spec is out and and only contains minor changes over 2.1.
I already noted in the board report that it might make sense to directly move to JPA-2.2 in trunk.
Because finishing an obsoleve version is probably not worth it.
We imo better focus on getting 2.2 done.
Wdyt?
LieGrue,
strub
Re: [DISCUSS] Make trunk target JPA-2.2
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
I'm perfectly fine with modular systems as such.
And in theory OpenJPA is very well cut.
But we have the JPQL parsing and other very JPA specific parts in openjpa-kernel.
Yes, currently the openjpa-kernel doesn't need use any JPA API classes.
But be honest, that's only because we upcast from Object to those classes later ;)
Given the 15++ years of history in the OpenJPA code I was always positively surprised how well designed and maintainable it still is.
But there are shortcomings which simply could not be seen back then.
Queck QueryExpressions.java for example. When you have a
public Map parameterTypes;
in openjpa-kernel, then all looks fine.
But once you introduce generics and the knowledge what those Maps store, then I wonder if the abstraction is correct. Currently it is
public Map<Object, Class<?>> parameterTypes;
But depending on the usage it should be
public Map <String, Class<?>> or Map<ParameterExpression, Class<?>>
isn't?
The first one in case of a classic JPQL query, the later in a CriteriaQuery.
A similar thing popped up when I looked into how to extract the enhancement into a sane API.
There is no real showstopper, but I wonder what others think what parts we might be able to tweak to reduce complexity.
LieGrue,
strub
> Am 25.07.2017 um 19:56 schrieb Kevin Sutter <kw...@gmail.com>:
>
> Mark,
> I think it's a combination of theory and practice, maybe a bit heavier on
> theory. And, I know that this abstraction has caused some headaches in the
> past when attempting to streamline some processing (for performance).
>
> Like you said, the other OpenJPA vendors probably already have their stable
> branches, so maybe this move to JPA 2.x would be a good place to
> cut-and-run. You might want to advertise this type of major revamping to
> allow for people to make their own branches, etc for future support.
>
> Although I agree in principle with the direction, I just wonder whether our
> eyes are bigger than our stomachs. Just be careful on how much you bite
> off...
>
> -- Kevin
>
> On Tue, Jul 25, 2017 at 12:00 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> If you have enough cycles i would be for simplifying all that but can't
>> really help myself these days so kind of +0
>>
>> PS: thought exactly that while working on stored proc on 2.1 branch
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>> rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-07-25 18:53 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>>
>>> We do have the 1.4.x branch for JPA-2.0.
>>> There is quite a bit of work to do for JPA-2.1 to be functional.
>>> And while trying to upgrade to Java8 I came across stuff I have long
>> moved
>>> out of my mind.
>>>
>>> E.g. is the abstraction of the Broker still important those days?
>>> I used Kodo back in early 2k. And Kodo was the base for OpenJPA. But is
>>> JDO still on the roadmap for OpenJPA?
>>> Is there some project which extends the openjpa broker with a JDO
>> frontend?
>>>
>>> Or does our great modular structur only exist in theory?
>>>
>>> While trying to upgrade our -source and -target to Java8 I came across a
>>> few ugly compat issues.
>>>
>>> In many classes in openjpa-kernel we have a OrderedMap<Object, Class<?>>.
>>> Mostly for Parameters.
>>> That worked fine in Java7, but Java8 complains that you cannot cast it to
>>> OrderedMap<ParameterExpression<?>, Class<?>> (CriteriaQueryImpl#410).
>>>
>>> While digging deeper I tried to extract the necessary parts, extract into
>>> real generics etc.
>>> By doing so I came across many JPQL related parts in openjpa-kernel.
>>>
>>> Why are those JPQL parts in openjpa-kernel?
>>> And now back to my initial question: does this separation and abstraction
>>> layer still make sense at all?
>>> Currently we fool ourselves in having an 'abstract'. But this core
>>> contains very JPA specific things. And then we upcast from Object to
>>> ParameterExpression...
>>>
>>> Do we go one step further and do a REALLY deep cleanup?
>>> We don't need to be afraid imo. WAS and TomEE have stable maintenance
>>> versions.
>>> And we need to either innovate/cleanup or we loose anyway.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>> Am 25.07.2017 um 18:32 schrieb Kevin Sutter <kw...@gmail.com>:
>>>>
>>>> Yep, sounds like the right plan of attack. Just for posterity and the
>>>> potential for a 2.1 release down the road, maybe you want to cut a
>>>> "sandbox" branch for the 2.1 development? And, then declare trunk as
>>> 2.2?
>>>>
>>>> -- Kevin
>>>>
>>>> On Mon, Jul 24, 2017 at 1:16 PM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <ilgrosso@apache.org
>>>
>>> a
>>>>> écrit :
>>>>>
>>>>>> Mark Struberg <st...@yahoo.de.INVALID> wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> The JPA-2.2 spec is out and and only contains minor changes over
>> 2.1.
>>>>>>> I already noted in the board report that it might make sense to
>>>>> directly
>>>>>> move to JPA-2.2 in trunk.
>>>>>>> Because finishing an obsoleve version is probably not worth it.
>>>>>>> We imo better focus on getting 2.2 done.
>>>>>>>
>>>>>>> Wdyt?
>>>>>>
>>>>>> +1, go ahead.
>>>>>> Regards.
>>>>>>
>>>>>
>>>
>>>
>>
.
Re: [DISCUSS] Make trunk target JPA-2.2
Posted by Kevin Sutter <kw...@gmail.com>.
Mark,
I think it's a combination of theory and practice, maybe a bit heavier on
theory. And, I know that this abstraction has caused some headaches in the
past when attempting to streamline some processing (for performance).
Like you said, the other OpenJPA vendors probably already have their stable
branches, so maybe this move to JPA 2.x would be a good place to
cut-and-run. You might want to advertise this type of major revamping to
allow for people to make their own branches, etc for future support.
Although I agree in principle with the direction, I just wonder whether our
eyes are bigger than our stomachs. Just be careful on how much you bite
off...
-- Kevin
On Tue, Jul 25, 2017 at 12:00 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> If you have enough cycles i would be for simplifying all that but can't
> really help myself these days so kind of +0
>
> PS: thought exactly that while working on stored proc on 2.1 branch
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-25 18:53 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>
> > We do have the 1.4.x branch for JPA-2.0.
> > There is quite a bit of work to do for JPA-2.1 to be functional.
> > And while trying to upgrade to Java8 I came across stuff I have long
> moved
> > out of my mind.
> >
> > E.g. is the abstraction of the Broker still important those days?
> > I used Kodo back in early 2k. And Kodo was the base for OpenJPA. But is
> > JDO still on the roadmap for OpenJPA?
> > Is there some project which extends the openjpa broker with a JDO
> frontend?
> >
> > Or does our great modular structur only exist in theory?
> >
> > While trying to upgrade our -source and -target to Java8 I came across a
> > few ugly compat issues.
> >
> > In many classes in openjpa-kernel we have a OrderedMap<Object, Class<?>>.
> > Mostly for Parameters.
> > That worked fine in Java7, but Java8 complains that you cannot cast it to
> > OrderedMap<ParameterExpression<?>, Class<?>> (CriteriaQueryImpl#410).
> >
> > While digging deeper I tried to extract the necessary parts, extract into
> > real generics etc.
> > By doing so I came across many JPQL related parts in openjpa-kernel.
> >
> > Why are those JPQL parts in openjpa-kernel?
> > And now back to my initial question: does this separation and abstraction
> > layer still make sense at all?
> > Currently we fool ourselves in having an 'abstract'. But this core
> > contains very JPA specific things. And then we upcast from Object to
> > ParameterExpression...
> >
> > Do we go one step further and do a REALLY deep cleanup?
> > We don't need to be afraid imo. WAS and TomEE have stable maintenance
> > versions.
> > And we need to either innovate/cleanup or we loose anyway.
> >
> > LieGrue,
> > strub
> >
> >
> >
> > > Am 25.07.2017 um 18:32 schrieb Kevin Sutter <kw...@gmail.com>:
> > >
> > > Yep, sounds like the right plan of attack. Just for posterity and the
> > > potential for a 2.1 release down the road, maybe you want to cut a
> > > "sandbox" branch for the 2.1 development? And, then declare trunk as
> > 2.2?
> > >
> > > -- Kevin
> > >
> > > On Mon, Jul 24, 2017 at 1:16 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > >> +1
> > >>
> > >> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <ilgrosso@apache.org
> >
> > a
> > >> écrit :
> > >>
> > >>> Mark Struberg <st...@yahoo.de.INVALID> wrote:
> > >>>> Hi!
> > >>>>
> > >>>> The JPA-2.2 spec is out and and only contains minor changes over
> 2.1.
> > >>>> I already noted in the board report that it might make sense to
> > >> directly
> > >>> move to JPA-2.2 in trunk.
> > >>>> Because finishing an obsoleve version is probably not worth it.
> > >>>> We imo better focus on getting 2.2 done.
> > >>>>
> > >>>> Wdyt?
> > >>>
> > >>> +1, go ahead.
> > >>> Regards.
> > >>>
> > >>
> >
> >
>
Re: [DISCUSS] Make trunk target JPA-2.2
Posted by Romain Manni-Bucau <rm...@gmail.com>.
If you have enough cycles i would be for simplifying all that but can't
really help myself these days so kind of +0
PS: thought exactly that while working on stored proc on 2.1 branch
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-07-25 18:53 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> We do have the 1.4.x branch for JPA-2.0.
> There is quite a bit of work to do for JPA-2.1 to be functional.
> And while trying to upgrade to Java8 I came across stuff I have long moved
> out of my mind.
>
> E.g. is the abstraction of the Broker still important those days?
> I used Kodo back in early 2k. And Kodo was the base for OpenJPA. But is
> JDO still on the roadmap for OpenJPA?
> Is there some project which extends the openjpa broker with a JDO frontend?
>
> Or does our great modular structur only exist in theory?
>
> While trying to upgrade our -source and -target to Java8 I came across a
> few ugly compat issues.
>
> In many classes in openjpa-kernel we have a OrderedMap<Object, Class<?>>.
> Mostly for Parameters.
> That worked fine in Java7, but Java8 complains that you cannot cast it to
> OrderedMap<ParameterExpression<?>, Class<?>> (CriteriaQueryImpl#410).
>
> While digging deeper I tried to extract the necessary parts, extract into
> real generics etc.
> By doing so I came across many JPQL related parts in openjpa-kernel.
>
> Why are those JPQL parts in openjpa-kernel?
> And now back to my initial question: does this separation and abstraction
> layer still make sense at all?
> Currently we fool ourselves in having an 'abstract'. But this core
> contains very JPA specific things. And then we upcast from Object to
> ParameterExpression...
>
> Do we go one step further and do a REALLY deep cleanup?
> We don't need to be afraid imo. WAS and TomEE have stable maintenance
> versions.
> And we need to either innovate/cleanup or we loose anyway.
>
> LieGrue,
> strub
>
>
>
> > Am 25.07.2017 um 18:32 schrieb Kevin Sutter <kw...@gmail.com>:
> >
> > Yep, sounds like the right plan of attack. Just for posterity and the
> > potential for a 2.1 release down the road, maybe you want to cut a
> > "sandbox" branch for the 2.1 development? And, then declare trunk as
> 2.2?
> >
> > -- Kevin
> >
> > On Mon, Jul 24, 2017 at 1:16 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> >> +1
> >>
> >> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <il...@apache.org>
> a
> >> écrit :
> >>
> >>> Mark Struberg <st...@yahoo.de.INVALID> wrote:
> >>>> Hi!
> >>>>
> >>>> The JPA-2.2 spec is out and and only contains minor changes over 2.1.
> >>>> I already noted in the board report that it might make sense to
> >> directly
> >>> move to JPA-2.2 in trunk.
> >>>> Because finishing an obsoleve version is probably not worth it.
> >>>> We imo better focus on getting 2.2 done.
> >>>>
> >>>> Wdyt?
> >>>
> >>> +1, go ahead.
> >>> Regards.
> >>>
> >>
>
>
Re: [DISCUSS] Make trunk target JPA-2.2
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
We do have the 1.4.x branch for JPA-2.0.
There is quite a bit of work to do for JPA-2.1 to be functional.
And while trying to upgrade to Java8 I came across stuff I have long moved out of my mind.
E.g. is the abstraction of the Broker still important those days?
I used Kodo back in early 2k. And Kodo was the base for OpenJPA. But is JDO still on the roadmap for OpenJPA?
Is there some project which extends the openjpa broker with a JDO frontend?
Or does our great modular structur only exist in theory?
While trying to upgrade our -source and -target to Java8 I came across a few ugly compat issues.
In many classes in openjpa-kernel we have a OrderedMap<Object, Class<?>>. Mostly for Parameters.
That worked fine in Java7, but Java8 complains that you cannot cast it to OrderedMap<ParameterExpression<?>, Class<?>> (CriteriaQueryImpl#410).
While digging deeper I tried to extract the necessary parts, extract into real generics etc.
By doing so I came across many JPQL related parts in openjpa-kernel.
Why are those JPQL parts in openjpa-kernel?
And now back to my initial question: does this separation and abstraction layer still make sense at all?
Currently we fool ourselves in having an 'abstract'. But this core contains very JPA specific things. And then we upcast from Object to ParameterExpression...
Do we go one step further and do a REALLY deep cleanup?
We don't need to be afraid imo. WAS and TomEE have stable maintenance versions.
And we need to either innovate/cleanup or we loose anyway.
LieGrue,
strub
> Am 25.07.2017 um 18:32 schrieb Kevin Sutter <kw...@gmail.com>:
>
> Yep, sounds like the right plan of attack. Just for posterity and the
> potential for a 2.1 release down the road, maybe you want to cut a
> "sandbox" branch for the 2.1 development? And, then declare trunk as 2.2?
>
> -- Kevin
>
> On Mon, Jul 24, 2017 at 1:16 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> +1
>>
>> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <il...@apache.org> a
>> écrit :
>>
>>> Mark Struberg <st...@yahoo.de.INVALID> wrote:
>>>> Hi!
>>>>
>>>> The JPA-2.2 spec is out and and only contains minor changes over 2.1.
>>>> I already noted in the board report that it might make sense to
>> directly
>>> move to JPA-2.2 in trunk.
>>>> Because finishing an obsoleve version is probably not worth it.
>>>> We imo better focus on getting 2.2 done.
>>>>
>>>> Wdyt?
>>>
>>> +1, go ahead.
>>> Regards.
>>>
>>
Re: [DISCUSS] Make trunk target JPA-2.2
Posted by Kevin Sutter <kw...@gmail.com>.
Yep, sounds like the right plan of attack. Just for posterity and the
potential for a 2.1 release down the road, maybe you want to cut a
"sandbox" branch for the 2.1 development? And, then declare trunk as 2.2?
-- Kevin
On Mon, Jul 24, 2017 at 1:16 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> +1
>
> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <il...@apache.org> a
> écrit :
>
> > Mark Struberg <st...@yahoo.de.INVALID> wrote:
> > > Hi!
> > >
> > > The JPA-2.2 spec is out and and only contains minor changes over 2.1.
> > > I already noted in the board report that it might make sense to
> directly
> > move to JPA-2.2 in trunk.
> > > Because finishing an obsoleve version is probably not worth it.
> > > We imo better focus on getting 2.2 done.
> > >
> > > Wdyt?
> >
> > +1, go ahead.
> > Regards.
> >
>
Re: [DISCUSS] Make trunk target JPA-2.2
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1
Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <il...@apache.org> a
écrit :
> Mark Struberg <st...@yahoo.de.INVALID> wrote:
> > Hi!
> >
> > The JPA-2.2 spec is out and and only contains minor changes over 2.1.
> > I already noted in the board report that it might make sense to directly
> move to JPA-2.2 in trunk.
> > Because finishing an obsoleve version is probably not worth it.
> > We imo better focus on getting 2.2 done.
> >
> > Wdyt?
>
> +1, go ahead.
> Regards.
>
Re: [DISCUSS] Make trunk target JPA-2.2
Posted by Francesco Chicchiriccò <il...@apache.org>.
Mark Struberg <st...@yahoo.de.INVALID> wrote:
> Hi!
>
> The JPA-2.2 spec is out and and only contains minor changes over 2.1.
> I already noted in the board report that it might make sense to directly move to JPA-2.2 in trunk.
> Because finishing an obsoleve version is probably not worth it.
> We imo better focus on getting 2.2 done.
>
> Wdyt?
+1, go ahead.
Regards.
Re: [DISCUSS] Make trunk target JPA-2.2
Posted by Craig Russell <ap...@gmail.com>.
Hi Strub,
Sounds like the right plan.
Craig
> On Jul 24, 2017, at 8:22 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>
> Hi!
>
> The JPA-2.2 spec is out and and only contains minor changes over 2.1.
> I already noted in the board report that it might make sense to directly move to JPA-2.2 in trunk.
> Because finishing an obsoleve version is probably not worth it.
> We imo better focus on getting 2.2 done.
>
> Wdyt?
>
> LieGrue,
> strub
>
Craig L Russell
clr@apache.org