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.