Re: [jakartabatch-dev] Generics need to move post-EE9

["Scott Kurz" <skurz@xxxxxxxxxx>]

I like the idea of having a generic extension. Feel free to create a new branch, either just for this or even a "2.1-dev" branch (or just a PR). (Or we can just reference the BatchEE artifacts while we're discussing).

------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Romain Manni-Bucau ---03/11/2020 09:16:59 AM---Right, this can be enhanced by enforcing compile type checks but rational was that it shouldn't chan

From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 03/11/2020 09:16 AM
Subject: [EXTERNAL] Re: [jakartabatch-dev] Generics need to move post-EE9
Sent by: jakartabatch-dev-bounces@xxxxxxxxxxx

---

Right, this can be enhanced by enforcing compile type checks but rational was that it shouldn't change much actually since these methods are never called in user land and code generally delegates to another "service" which is typed. Main impacting part for the users is the data "injections", not the outcome.

That said, the point was mainly the fact we don't need any breaking change to get this feature in and this remains valid ;).

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


Le mer. 11 mars 2020 à 14:12, Martijn Dashorst <martijn.dashorst@xxxxxxxxx> a écrit :

Unfortunately readItem still has Object as return type rather than R, as does checkPointInfo() (returning Serializable rather than C).

Martijn


On Wed, Mar 11, 2020 at 1:34 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
Yes or no ;)

Typically in BatchEE we provide typed components already just subclassing built-in classes: https://github.com/apache/geronimo-batchee/blob/master/extensions/extras/src/main/java/org/apache/batchee/extras/typed/TypedItemReader.java#L28

In Java >= 8 it can even be done at interface level with default methods, so no breaking change needed IMHO.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


Le mer. 11 mars 2020 à 12:45, Scott Kurz <skurz@xxxxxxxxxx> a écrit :
Romain,

I agree that in terms of the significance of the function, generics is not a big deal . However if Jakarta is strongly encouraging semantic versioning, as in https://semver.org/, then, well, we are talking about an incompatible API change: we'd be breaking source compatibility (even if binary compatibility were still present).

------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Romain Manni-Bucau ---03/11/2020 02:11:02 AM---Hi Scott, Think a 2.x can add it, it is not a central feature by itself, just very

From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 03/11/2020 02:11 AM
Subject: [EXTERNAL] Re: [jakartabatch-dev] Generics need to move post-EE9
Sent by: jakartabatch-dev-bounces@xxxxxxxxxxx


---




Hi Scott,

Think a 2.x can add it, it is not a central feature by itself, just very expected and convenient but does not enable a single use case we can't already do.

That said it asks questions about companion features so I agree we should do it after jakarta namespace move - but quite shortly after.

Romain

Le mar. 10 mars 2020 à 23:30, Scott Kurz <skurz@xxxxxxxxxx> a écrit :
So while I raised the issue:
https://github.com/eclipse-ee4j/batch-api/issues/13
asking should we consider adding generics (for the various "item" types and others), I think it is simply too late at this point.

I think there was an opportunity and unfortunately I just wasn't engaged enough in the project to take advantage of this. At this point we'd be jeopardizing the whole EE 9 plan.

This would be the case even if we knew exactly what changes we wanted to make and had tested them in runtime impls, which isn't the case.

Looking ahead,

I'm not sure of an easy, non-breaking way to make such a change. If we were to follow semantic version that could even push generics into a 3.0 release.
Not quite the normal progression to go so long between 1.0 and 2.0, then quick do a 3.0.

The generics seem even more useful with jobs constructed in Java (rather than XML)... maybe if we tie generics to that function, which we've also talked about recently, we would have a decent-enough story.

Thoughts?
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev



_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev
_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev


--
Become a Wicket expert, learn from the best: http://wicketinaction.com
_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev