[DISCUSS] Make trunk target JPA-2.2

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[DISCUSS] Make trunk target JPA-2.2

Mark Struberg-3
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Make trunk target JPA-2.2

Craig Russell
Hi Strub,

Sounds like the right plan.

Craig

> On Jul 24, 2017, at 8:22 AM, Mark Struberg <[hidden email]> 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
[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Make trunk target JPA-2.2

ilgrosso
In reply to this post by Mark Struberg-3
Mark Struberg <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Make trunk target JPA-2.2

Romain Manni-Bucau
+1

Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <[hidden email]> a
écrit :

> Mark Struberg <[hidden email]> 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.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Make trunk target JPA-2.2

kwsutter
Administrator
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 <[hidden email]>
wrote:

> +1
>
> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <[hidden email]> a
> écrit :
>
> > Mark Struberg <[hidden email]> 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.
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Make trunk target JPA-2.2

Mark Struberg-3
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 <[hidden email]>:
>
> 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 <[hidden email]>
> wrote:
>
>> +1
>>
>> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <[hidden email]> a
>> écrit :
>>
>>> Mark Struberg <[hidden email]> 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.
>>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Make trunk target JPA-2.2

Romain Manni-Bucau
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 <[hidden email]>:

> 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 <[hidden email]>:
> >
> > 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 <
> [hidden email]>
> > wrote:
> >
> >> +1
> >>
> >> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <[hidden email]>
> a
> >> écrit :
> >>
> >>> Mark Struberg <[hidden email]> 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.
> >>>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Make trunk target JPA-2.2

kwsutter
Administrator
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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> > >
> > > 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 <
> > [hidden email]>
> > > wrote:
> > >
> > >> +1
> > >>
> > >> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <[hidden email]
> >
> > a
> > >> écrit :
> > >>
> > >>> Mark Struberg <[hidden email]> 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.
> > >>>
> > >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Make trunk target JPA-2.2

Mark Struberg-3
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 <[hidden email]>:
>
> 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 <[hidden email]>
> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>:
>>>>
>>>> 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 <
>>> [hidden email]>
>>>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <[hidden email]
>>>
>>> a
>>>>> écrit :
>>>>>
>>>>>> Mark Struberg <[hidden email]> 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.
>>>>>>
>>>>>
>>>
>>>
>>


.
Loading...