Re: [sca-j] NEW ISSUE: JCI90003 -- Java SE 5 requirement should be on theruntime not on the class

Jim,

Just to clarify:

The testcase suite client uses JAX-WS.
 The sample build & run files provided do use JDK 6, but they
are just samples and those 

files can be replaced so that in principle
the test client code could be run against JDK 5.  I chose not to do
that to keep things simple

- JAX-WS is fully part of JDK 6 whereas
you have to add a set of external JARs to JDK 5.

The test suite SCA components make no
assumptions about the level of JDK used by the SCA runtime, other than
>= 5, in that 

SCA annotations are used, which demand
minimum of JDK 5.

I'm with you in thinking that an SCA
runtime can support JDK >= 5 and that in general code that works on
JDK 5 should work on 

later versions of the JDK too.

Yours, Mike

Dr Mike Edwards
 Mail Point 137, Hursley
Park

STSM
 Winchester, Hants SO21
2JN

SCA & Services
Standards
 United Kingdom

Co-Chair OASIS SCA
Assembly TC
 

IBM Software Group
  

Phone:
+44-1962 818014
  

Mobile:
+44-7802-467431 (274097)
  

e-mail:

  

 

 

From:
Jim Marino <>

To:
OASIS Java <>

Date:
14/05/2011 10:18

Subject:
Re: [sca-j] NEW ISSUE: JCI90003 -- Java
SE 5 requirement should be on the runtime not on the class

Hi Anish,

#1 makes sense. However, I don't understand why someone would want to disallow
a runtime supporting Java SE > 5.0 on portability grounds. Is this a
view someone is advocating?

Given that Java SE 5 has been end-of-lifed, I would expect many runtimes
would not want to waste QA resources validating against it and instead
use many of the new features in Java SE 6: 

http://www.oracle.com/technetwork/java/eol-135779.html

I don't see how supporting Java SE >5 materially affects portability
given the existing extension point mechanisms in SCA. If an application
requires 100% portability, it should use the minimum specified Java SE
and no vendor extensions points. Taking this to an extreme, if application
portability is the overriding requirement for SCA, then extension points
should be eliminated as well (a bad idea). IMO, 100% portability is impossible
for application development in SCA given all of the things it does not
address (data access, UI, clustering, etc.).      

On a practical level, I believe the test cases assume Java SE 6 as they
rely on the JAX-WS API as a JDK dependency. This could be changed (I believe
it is possible to run the JAX-WS RI on JDK 5), but maybe the minimum should
be Java SE 6?

Jim

On May 14, 2011, at 2:22 AM, Anish Karmarkar wrote:

> Thanks for bringing this up. It was discussed on the last call.

> 

> There are two related things here:

> 1) what is the minimum version of a complaint SCA runtime? Obviously
that has to be 5.0, since we use annotation. Any runtime < 5.0 should
be considered non-complaint.

> 2) can runtimes support Java SE > 5.0?

> 

> Point 2 is interesting. If we allow complaint runtimes to use features
that are present in SE>5, then we can't guarantee portability of contributions
but we provide flexibility and future-proof the spec (no need to rev the
spec everytime there is a new Java version released -- Java 7 is slated
to be released this summer).

> 

> My view is that, on balance allowing SE>5 makes more sense. Anyone
who deals with deploying Java classes always checks to ensure that the
underlying system's Java version is compatible. So, the potential loss
of portability isn't that much of an issue.

> 

> -Anish

> --

> 

> On 5/9/2011 2:18 AM, Jim Marino wrote:

>> Hi Anish,

>> 

>> I'm not sure the intent of this is to disallow classes that use
a feature in Java 6 or greater, but the issue reads that way. For example,
a component implementation class could make use of a JDK 6 API. I think
it should be valid for a runtime to support use of those APIs.

>> 

>> Jim

>> 

>> 

>> 

>> On May 9, 2011, at 8:22 AM, Anish Karmarkar wrote:

>> 

>>> Title: JCI90003 -- Java SE 5 requirement should be on the
runtime not on the class

>>> 

>>> Specification: Java POJO CI

>>> 

>>> Description:

>>> 

>>> JCI90003 say --

>>> The Java class referenced by the @class attribute of<implementation.java/>
 MUST conform to Java SE version 5.0. [JCI90003]

>>> 

>>> This seems unnecessary. We should allow classes compiled using
earlier version of Java SE to be used with SCA. We should also allow classes
complied with Java SE version>  5.0 as long as the classes don't
use any features that are not present in 5.0.

>>> 

>>> If we need a requirement for Java SE version, that requirement
should be on the Runtime not the class.

>>> 

>>> Proposal:

>>> 

>>> Change the target of the requirement to be the Runtime not
the class.

>>> 

>>> ---------------------------------------------------------------------

>>> To unsubscribe from this mail list, you must leave the OASIS
TC that

>>> generates this mail.  Follow this link to all your TCs
in OASIS at:

>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

>> 

>> 

>> ---------------------------------------------------------------------

>> To unsubscribe from this mail list, you must leave the OASIS TC
that

>> generates this mail.  Follow this link to all your TCs in
OASIS at:

>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

>> 

> 

> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail.  Follow this link to all your TCs in OASIS
at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU