Date: Thu, 24 Jan 2013 14:50:57 +0100
Bill/Linda,
Thanks. I leave that to you. Let's hope the EE 7 EG (and Spec Leads as last
decision making authority) comes to a conclusion here that satisfies also
those EC Members who raised concerns about non-compatibility of this JSR in
earlier stages...?
From a client code point of view it may not be totally incompatible should
let's say those redundancies remain for a limited amount of time (till a MR
maybe or V x.x in worst case scenario) Of course new features like "Try
with Resources" look unlikely in that case. Which would be a pity for users
of EE 7 and create some inconvenience and inconsistency.
JSRs including this one are very likely to require further adjustments
towards EE 8 and the use of Lambdas, so if there were really
killer-criteria to stick with SE 6 minimum at least for V1.0, then this
could and should be the occasion to scrap those redundancies by simply
inheriting from AutoCloseable.
Any JSR that uses Lambda, Type Annotation or similar stuff in EE 8, must
have SE 8 as minimum then[?]
Werner
On Wed, Jan 23, 2013 at 9:16 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
> And to be clear, Java EE 7 products require Java SE 7.
>
> That *doesn't* mean that all component technologies going into Java EE 7
> *must* require a minimum of Java SE 7.
>
> Some of our component technologies see significant use outside of Java EE
> and choose to support older versions of Java SE. Clearly there are
> tradeoffs
> involved. There is no one simple answer that applies in all cases.
>
> Linda DeMichiel wrote on 01/22/13 13:50:
> > Werner/all,
> >
> > On 1/20/2013 9:00 AM, Werner Keil wrote:
> >> Linda/all,
> >>
> >> I wanted to run this by you, as Linda's "fear" she expressed last week
> at the
> >> JCP EC Meeting that Spec Lead or EG
> >> Members of Java Batch (JSR 352) argue, they wish to keep redundancies
> to Java
> >> 7 (AutoCloseable) for the sake of
> >> backward-compatibility with some old JVMs, and EE Containers and a JDK,
> which
> >> is scheduled for Sun-down this February.
> >>
> >> What is your oppinion on that? I was under the impression, the idea of
> >> "Simplification" and "Harmonization" for EE 7
> >> wants to address exactly cases like that, or would you prefer it to
> duplicate
> >> things that the Platform (SE7/EE7) already
> >> defined elsewhere?
> >>
> >> I remember, other EC Members, Oracle and Red Hat primarily expressed
> >> discomfort with some aspects of JSR 352 being
> >> incompatible with Java EE 7. That is clearly another one, regardless if
> those
> >> members spotted it earlier or not.
> >>
> >
> > Well, to be fair, this is somewhat of a gray area, as it involves the
> non-use of
> > a newer API
> > rather than an API incompatibility in the direct sense.
> >
> > In any case, we are in contact with the specification lead, who is
> evaluating
> > the issue.
> >
> > regards,
> >
> > -Linda
> >
> >
> >> Thanks and Regards,
> >> --
> >>
> >> Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
> >> Language Champion| Java Godfather
> >>
> >> Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
> >>
> >> Skype werner.keil | Google+ gplus.to/wernerkeil <
> http://gplus.to/wernerkeil>
> >>
> >> * Social Media Week: February 18 2013, Hamburg, Germany. Werner Keil,
> JCP
> >> Executive Committee Member, Agorava
> >> Co-Founder will present "Enterprise Social using Open Source Frameworks
> like
> >> Agorava"
> >>
> >> ---------- Forwarded message ----------
> >> From: ** <bugzilla-daemon_at_java.net <mailto:bugzilla-daemon_at_java.net>>
> >> Date: Sun, Jan 20, 2013 at 5:40 AM
> >> Subject: [Bug 4518] Both ItemReader and ItemWriter should extend
> AutoCloseable
> >> To: keilw_at_java.net <mailto:keilw_at_java.net>
> >>
> >>
> >> http://java.net/bugzilla/show_bug.cgi?id=4518
> >>
> >> --- Comment #8 from mminella_at_java.net <mailto:mminella_at_java.net>
> 2013-01-20
> >> 04:40:41 UTC ---
> >> I would argue that, as Chris brought up in his original response to
> this issue,
> >> the AutoClosable interface would be of limited (at best) usefulness for
> an
> >> ItemReader or ItemWriter. As he points out, the open and close methods
> are not
> >> called as part of the public API, and even if it was, there isn't a
> concrete
> >> association with an ItemReader/ItemWriter with a resource. It could be
> >> accessing a file, a database, a method on an object, a web service,
> etc. The
> >> coupling of this to a resource like this doesn't make sense to me.
> >>
> >> However, the cost of adding it and changing the required JDK version to
> 1.7 is
> >> huge IMHO. I'd vote for not implementing this interface and keeping
> the JDK
> >> requirement at 1.6.
> >>
> >> --
> >> Configure bugmail: http://java.net/bugzilla/userprefs.cgi?tab=email
> >> ------- You are receiving this mail because: -------
> >> You reported the bug.
>
>
(image/gif attachment: 347.gif)