You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Marc Prud'hommeaux <mp...@apache.org> on 2007/06/13 09:55:11 UTC
Enforcing JDK 1.4-specific modules
We recently had some problems where JDK 1.5-specific methods (e.g.,
String.contains(String)) were slipping into JDK 1.4-specific modules.
This isn't a problem for stand-alone OpenJPA (whose only
implementation is JPA, which is JDK 1.5-dependent), but other
products built on OpenJPA may still support JDK 1.4.
To that end, I've added a 'java14.jar' property to the pom.xml files
that can be used to specify the location of the JDK 1.4 runtime jar,
against which we will compile the JDK 1.4-specific modules. Since the
location of the JDK 1.4 runtime jar is platform- and installation-
dependent, we can't just rely on a single location (nor is there any
maven-friendly JDK 1.4 runtime jar that I am aware of), the flag
needs to be specified manually.
Note that the flag will be silently ignored when it is unspecified,
which I expect will be the common case for most OpenJPA developers.
You only need to use it if you are interested in ensuring that any
code you add to JDK 1.4 modules won't break 1.4 compatibility.
Re: Enforcing JDK 1.4-specific modules
Posted by Craig L Russell <Cr...@Sun.COM>.
I found an interesting posting with a reference to the answer. If you
care not to read it, the short answer is that Marc is right.
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/
javac.html#crosscomp-example
http://www.velocityreviews.com/forums/t146324-crosscompile-to-v14-
compatible-with-java-5-javac.html
Craig
On Jun 13, 2007, at 9:08 AM, Craig L Russell wrote:
> Is this a bug? I'd think that setting the source 1.4 flag would
> disallow compiling a file that contained a reference to 1.5 methods
> in the java.lang package. I'd have to look at any differences
> between the maven project.properties, the maven pom.xml, and the
> javac -source techniques. I'm pretty sure that javac -source
> chooses the right compile-time library (IIUC this technique is used
> by the Derby project to make sure they get the right java.sql jars
> to compile against).
>
> I'm copying the Derby dev alias because I think they've solved this
> problem.
>
> If we can't find a solution with flags, I think we should find
> ourselves a 1.4 jar file and check it into the project. We don't
> need to ship it (indeed we cannot) but using it for compiling
> should not be an issue.
>
> Craig
>
> On Jun 13, 2007, at 8:12 AM, Marc Prud'hommeaux wrote:
>
>>
>>> Is that what we want?
>>
>> No, but since there is no public maven-friendly JDK 1.4 runtime
>> jar that I am aware of, and since I bet that Apache wouldn't want
>> us to commit it to the repository, I don't think there is any
>> solution that wouldn't require the developer to perform a manual
>> installation of JDK 1.4 in some pre-determined location. And I'm
>> personally loathe to add any environmental requirements that
>> hinders new developers from being able to build OpenJPA.
>>
>>
>>
>>
>> On Jun 13, 2007, at 10:50 PM, Craig L Russell wrote:
>>
>>> Hi Marc,
>>>
>>> Ah, you are right. I looked at the projects and didn't see the
>>> project.properties where the compile.source and target properties
>>> are. They are also in the pom.xml though in the build plugins.
>>>
>>> But why should this be a choice of developers? I'd think that
>>> either we would want to enforce this restriction for the project
>>> or not. If we leave it up to developers' choice then someone will
>>> eventually have to come around and fix up the 1.5 dependencies.
>>> Is that what we want?
>>>
>>> Craig
>>>
>>> On Jun 13, 2007, at 7:35 AM, Marc Prud'hommeaux wrote:
>>>
>>>> Craig-
>>>>
>>>> We were already setting the "source" and "target" flags to "1.4"
>>>> for the 1.4 modules, but that only enforces language-level
>>>> restrictions (e.g., it would raise an error if you tried to use
>>>> generics or autoboxing), it doesn't check to make sure you
>>>> didn't use an API method that doesn't exist in 1.4. In order to
>>>> validate that, say, you didn't call String.contains() (which is
>>>> new in 1.5), you need to use the bootclasspath argument to
>>>> provide the 1.4 runtime jar so that that level of verification
>>>> can take place.
>>>>
>>>>
>>>>
>>>> On Jun 13, 2007, at 10:21 PM, Craig L Russell wrote:
>>>>
>>>>> There is a maven flag that you can put into maven's
>>>>> project.properties that specifies the level of jdk to use for
>>>>> that project.
>>>>>
>>>>> maven.compile.source = 1.4
>>>>> maven.compile.target = 1.4
>>>>>
>>>>> This can be dropped into those projects that we want to compile
>>>>> with 1.4. This will enforce the dependency at compile time.
>>>>>
>>>>> Craig
>>>>>
>>>>> On Jun 13, 2007, at 12:55 AM, Marc Prud'hommeaux wrote:
>>>>>
>>>>>>
>>>>>> We recently had some problems where JDK 1.5-specific methods
>>>>>> (e.g., String.contains(String)) were slipping into JDK 1.4-
>>>>>> specific modules. This isn't a problem for stand-alone OpenJPA
>>>>>> (whose only implementation is JPA, which is JDK 1.5-
>>>>>> dependent), but other products built on OpenJPA may still
>>>>>> support JDK 1.4.
>>>>>>
>>>>>> To that end, I've added a 'java14.jar' property to the pom.xml
>>>>>> files that can be used to specify the location of the JDK 1.4
>>>>>> runtime jar, against which we will compile the JDK 1.4-
>>>>>> specific modules. Since the location of the JDK 1.4 runtime
>>>>>> jar is platform- and installation- dependent, we can't just
>>>>>> rely on a single location (nor is there any maven-friendly JDK
>>>>>> 1.4 runtime jar that I am aware of), the flag needs to be
>>>>>> specified manually.
>>>>>>
>>>>>> Note that the flag will be silently ignored when it is
>>>>>> unspecified, which I expect will be the common case for most
>>>>>> OpenJPA developers. You only need to use it if you are
>>>>>> interested in ensuring that any code you add to JDK 1.4
>>>>>> modules won't break 1.4 compatibility.
>>>>>>
>>>>>>
>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>> products/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Enforcing JDK 1.4-specific modules
Posted by Craig L Russell <Cr...@Sun.COM>.
I found an interesting posting with a reference to the answer. If you
care not to read it, the short answer is that Marc is right.
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/
javac.html#crosscomp-example
http://www.velocityreviews.com/forums/t146324-crosscompile-to-v14-
compatible-with-java-5-javac.html
Craig
On Jun 13, 2007, at 9:08 AM, Craig L Russell wrote:
> Is this a bug? I'd think that setting the source 1.4 flag would
> disallow compiling a file that contained a reference to 1.5 methods
> in the java.lang package. I'd have to look at any differences
> between the maven project.properties, the maven pom.xml, and the
> javac -source techniques. I'm pretty sure that javac -source
> chooses the right compile-time library (IIUC this technique is used
> by the Derby project to make sure they get the right java.sql jars
> to compile against).
>
> I'm copying the Derby dev alias because I think they've solved this
> problem.
>
> If we can't find a solution with flags, I think we should find
> ourselves a 1.4 jar file and check it into the project. We don't
> need to ship it (indeed we cannot) but using it for compiling
> should not be an issue.
>
> Craig
>
> On Jun 13, 2007, at 8:12 AM, Marc Prud'hommeaux wrote:
>
>>
>>> Is that what we want?
>>
>> No, but since there is no public maven-friendly JDK 1.4 runtime
>> jar that I am aware of, and since I bet that Apache wouldn't want
>> us to commit it to the repository, I don't think there is any
>> solution that wouldn't require the developer to perform a manual
>> installation of JDK 1.4 in some pre-determined location. And I'm
>> personally loathe to add any environmental requirements that
>> hinders new developers from being able to build OpenJPA.
>>
>>
>>
>>
>> On Jun 13, 2007, at 10:50 PM, Craig L Russell wrote:
>>
>>> Hi Marc,
>>>
>>> Ah, you are right. I looked at the projects and didn't see the
>>> project.properties where the compile.source and target properties
>>> are. They are also in the pom.xml though in the build plugins.
>>>
>>> But why should this be a choice of developers? I'd think that
>>> either we would want to enforce this restriction for the project
>>> or not. If we leave it up to developers' choice then someone will
>>> eventually have to come around and fix up the 1.5 dependencies.
>>> Is that what we want?
>>>
>>> Craig
>>>
>>> On Jun 13, 2007, at 7:35 AM, Marc Prud'hommeaux wrote:
>>>
>>>> Craig-
>>>>
>>>> We were already setting the "source" and "target" flags to "1.4"
>>>> for the 1.4 modules, but that only enforces language-level
>>>> restrictions (e.g., it would raise an error if you tried to use
>>>> generics or autoboxing), it doesn't check to make sure you
>>>> didn't use an API method that doesn't exist in 1.4. In order to
>>>> validate that, say, you didn't call String.contains() (which is
>>>> new in 1.5), you need to use the bootclasspath argument to
>>>> provide the 1.4 runtime jar so that that level of verification
>>>> can take place.
>>>>
>>>>
>>>>
>>>> On Jun 13, 2007, at 10:21 PM, Craig L Russell wrote:
>>>>
>>>>> There is a maven flag that you can put into maven's
>>>>> project.properties that specifies the level of jdk to use for
>>>>> that project.
>>>>>
>>>>> maven.compile.source = 1.4
>>>>> maven.compile.target = 1.4
>>>>>
>>>>> This can be dropped into those projects that we want to compile
>>>>> with 1.4. This will enforce the dependency at compile time.
>>>>>
>>>>> Craig
>>>>>
>>>>> On Jun 13, 2007, at 12:55 AM, Marc Prud'hommeaux wrote:
>>>>>
>>>>>>
>>>>>> We recently had some problems where JDK 1.5-specific methods
>>>>>> (e.g., String.contains(String)) were slipping into JDK 1.4-
>>>>>> specific modules. This isn't a problem for stand-alone OpenJPA
>>>>>> (whose only implementation is JPA, which is JDK 1.5-
>>>>>> dependent), but other products built on OpenJPA may still
>>>>>> support JDK 1.4.
>>>>>>
>>>>>> To that end, I've added a 'java14.jar' property to the pom.xml
>>>>>> files that can be used to specify the location of the JDK 1.4
>>>>>> runtime jar, against which we will compile the JDK 1.4-
>>>>>> specific modules. Since the location of the JDK 1.4 runtime
>>>>>> jar is platform- and installation- dependent, we can't just
>>>>>> rely on a single location (nor is there any maven-friendly JDK
>>>>>> 1.4 runtime jar that I am aware of), the flag needs to be
>>>>>> specified manually.
>>>>>>
>>>>>> Note that the flag will be silently ignored when it is
>>>>>> unspecified, which I expect will be the common case for most
>>>>>> OpenJPA developers. You only need to use it if you are
>>>>>> interested in ensuring that any code you add to JDK 1.4
>>>>>> modules won't break 1.4 compatibility.
>>>>>>
>>>>>>
>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>> products/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Enforcing JDK 1.4-specific modules
Posted by Craig L Russell <Cr...@Sun.COM>.
Is this a bug? I'd think that setting the source 1.4 flag would
disallow compiling a file that contained a reference to 1.5 methods
in the java.lang package. I'd have to look at any differences between
the maven project.properties, the maven pom.xml, and the javac -
source techniques. I'm pretty sure that javac -source chooses the
right compile-time library (IIUC this technique is used by the Derby
project to make sure they get the right java.sql jars to compile
against).
I'm copying the Derby dev alias because I think they've solved this
problem.
If we can't find a solution with flags, I think we should find
ourselves a 1.4 jar file and check it into the project. We don't need
to ship it (indeed we cannot) but using it for compiling should not
be an issue.
Craig
On Jun 13, 2007, at 8:12 AM, Marc Prud'hommeaux wrote:
>
>> Is that what we want?
>
> No, but since there is no public maven-friendly JDK 1.4 runtime jar
> that I am aware of, and since I bet that Apache wouldn't want us to
> commit it to the repository, I don't think there is any solution
> that wouldn't require the developer to perform a manual
> installation of JDK 1.4 in some pre-determined location. And I'm
> personally loathe to add any environmental requirements that
> hinders new developers from being able to build OpenJPA.
>
>
>
>
> On Jun 13, 2007, at 10:50 PM, Craig L Russell wrote:
>
>> Hi Marc,
>>
>> Ah, you are right. I looked at the projects and didn't see the
>> project.properties where the compile.source and target properties
>> are. They are also in the pom.xml though in the build plugins.
>>
>> But why should this be a choice of developers? I'd think that
>> either we would want to enforce this restriction for the project
>> or not. If we leave it up to developers' choice then someone will
>> eventually have to come around and fix up the 1.5 dependencies. Is
>> that what we want?
>>
>> Craig
>>
>> On Jun 13, 2007, at 7:35 AM, Marc Prud'hommeaux wrote:
>>
>>> Craig-
>>>
>>> We were already setting the "source" and "target" flags to "1.4"
>>> for the 1.4 modules, but that only enforces language-level
>>> restrictions (e.g., it would raise an error if you tried to use
>>> generics or autoboxing), it doesn't check to make sure you didn't
>>> use an API method that doesn't exist in 1.4. In order to validate
>>> that, say, you didn't call String.contains() (which is new in
>>> 1.5), you need to use the bootclasspath argument to provide the
>>> 1.4 runtime jar so that that level of verification can take place.
>>>
>>>
>>>
>>> On Jun 13, 2007, at 10:21 PM, Craig L Russell wrote:
>>>
>>>> There is a maven flag that you can put into maven's
>>>> project.properties that specifies the level of jdk to use for
>>>> that project.
>>>>
>>>> maven.compile.source = 1.4
>>>> maven.compile.target = 1.4
>>>>
>>>> This can be dropped into those projects that we want to compile
>>>> with 1.4. This will enforce the dependency at compile time.
>>>>
>>>> Craig
>>>>
>>>> On Jun 13, 2007, at 12:55 AM, Marc Prud'hommeaux wrote:
>>>>
>>>>>
>>>>> We recently had some problems where JDK 1.5-specific methods
>>>>> (e.g., String.contains(String)) were slipping into JDK 1.4-
>>>>> specific modules. This isn't a problem for stand-alone OpenJPA
>>>>> (whose only implementation is JPA, which is JDK 1.5-dependent),
>>>>> but other products built on OpenJPA may still support JDK 1.4.
>>>>>
>>>>> To that end, I've added a 'java14.jar' property to the pom.xml
>>>>> files that can be used to specify the location of the JDK 1.4
>>>>> runtime jar, against which we will compile the JDK 1.4-specific
>>>>> modules. Since the location of the JDK 1.4 runtime jar is
>>>>> platform- and installation- dependent, we can't just rely on a
>>>>> single location (nor is there any maven-friendly JDK 1.4
>>>>> runtime jar that I am aware of), the flag needs to be specified
>>>>> manually.
>>>>>
>>>>> Note that the flag will be silently ignored when it is
>>>>> unspecified, which I expect will be the common case for most
>>>>> OpenJPA developers. You only need to use it if you are
>>>>> interested in ensuring that any code you add to JDK 1.4 modules
>>>>> won't break 1.4 compatibility.
>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Enforcing JDK 1.4-specific modules
Posted by Craig L Russell <Cr...@Sun.COM>.
Is this a bug? I'd think that setting the source 1.4 flag would
disallow compiling a file that contained a reference to 1.5 methods
in the java.lang package. I'd have to look at any differences between
the maven project.properties, the maven pom.xml, and the javac -
source techniques. I'm pretty sure that javac -source chooses the
right compile-time library (IIUC this technique is used by the Derby
project to make sure they get the right java.sql jars to compile
against).
I'm copying the Derby dev alias because I think they've solved this
problem.
If we can't find a solution with flags, I think we should find
ourselves a 1.4 jar file and check it into the project. We don't need
to ship it (indeed we cannot) but using it for compiling should not
be an issue.
Craig
On Jun 13, 2007, at 8:12 AM, Marc Prud'hommeaux wrote:
>
>> Is that what we want?
>
> No, but since there is no public maven-friendly JDK 1.4 runtime jar
> that I am aware of, and since I bet that Apache wouldn't want us to
> commit it to the repository, I don't think there is any solution
> that wouldn't require the developer to perform a manual
> installation of JDK 1.4 in some pre-determined location. And I'm
> personally loathe to add any environmental requirements that
> hinders new developers from being able to build OpenJPA.
>
>
>
>
> On Jun 13, 2007, at 10:50 PM, Craig L Russell wrote:
>
>> Hi Marc,
>>
>> Ah, you are right. I looked at the projects and didn't see the
>> project.properties where the compile.source and target properties
>> are. They are also in the pom.xml though in the build plugins.
>>
>> But why should this be a choice of developers? I'd think that
>> either we would want to enforce this restriction for the project
>> or not. If we leave it up to developers' choice then someone will
>> eventually have to come around and fix up the 1.5 dependencies. Is
>> that what we want?
>>
>> Craig
>>
>> On Jun 13, 2007, at 7:35 AM, Marc Prud'hommeaux wrote:
>>
>>> Craig-
>>>
>>> We were already setting the "source" and "target" flags to "1.4"
>>> for the 1.4 modules, but that only enforces language-level
>>> restrictions (e.g., it would raise an error if you tried to use
>>> generics or autoboxing), it doesn't check to make sure you didn't
>>> use an API method that doesn't exist in 1.4. In order to validate
>>> that, say, you didn't call String.contains() (which is new in
>>> 1.5), you need to use the bootclasspath argument to provide the
>>> 1.4 runtime jar so that that level of verification can take place.
>>>
>>>
>>>
>>> On Jun 13, 2007, at 10:21 PM, Craig L Russell wrote:
>>>
>>>> There is a maven flag that you can put into maven's
>>>> project.properties that specifies the level of jdk to use for
>>>> that project.
>>>>
>>>> maven.compile.source = 1.4
>>>> maven.compile.target = 1.4
>>>>
>>>> This can be dropped into those projects that we want to compile
>>>> with 1.4. This will enforce the dependency at compile time.
>>>>
>>>> Craig
>>>>
>>>> On Jun 13, 2007, at 12:55 AM, Marc Prud'hommeaux wrote:
>>>>
>>>>>
>>>>> We recently had some problems where JDK 1.5-specific methods
>>>>> (e.g., String.contains(String)) were slipping into JDK 1.4-
>>>>> specific modules. This isn't a problem for stand-alone OpenJPA
>>>>> (whose only implementation is JPA, which is JDK 1.5-dependent),
>>>>> but other products built on OpenJPA may still support JDK 1.4.
>>>>>
>>>>> To that end, I've added a 'java14.jar' property to the pom.xml
>>>>> files that can be used to specify the location of the JDK 1.4
>>>>> runtime jar, against which we will compile the JDK 1.4-specific
>>>>> modules. Since the location of the JDK 1.4 runtime jar is
>>>>> platform- and installation- dependent, we can't just rely on a
>>>>> single location (nor is there any maven-friendly JDK 1.4
>>>>> runtime jar that I am aware of), the flag needs to be specified
>>>>> manually.
>>>>>
>>>>> Note that the flag will be silently ignored when it is
>>>>> unspecified, which I expect will be the common case for most
>>>>> OpenJPA developers. You only need to use it if you are
>>>>> interested in ensuring that any code you add to JDK 1.4 modules
>>>>> won't break 1.4 compatibility.
>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Enforcing JDK 1.4-specific modules
Posted by Marc Prud'hommeaux <mp...@apache.org>.
> Is that what we want?
No, but since there is no public maven-friendly JDK 1.4 runtime jar
that I am aware of, and since I bet that Apache wouldn't want us to
commit it to the repository, I don't think there is any solution that
wouldn't require the developer to perform a manual installation of
JDK 1.4 in some pre-determined location. And I'm personally loathe to
add any environmental requirements that hinders new developers from
being able to build OpenJPA.
On Jun 13, 2007, at 10:50 PM, Craig L Russell wrote:
> Hi Marc,
>
> Ah, you are right. I looked at the projects and didn't see the
> project.properties where the compile.source and target properties
> are. They are also in the pom.xml though in the build plugins.
>
> But why should this be a choice of developers? I'd think that
> either we would want to enforce this restriction for the project or
> not. If we leave it up to developers' choice then someone will
> eventually have to come around and fix up the 1.5 dependencies. Is
> that what we want?
>
> Craig
>
> On Jun 13, 2007, at 7:35 AM, Marc Prud'hommeaux wrote:
>
>> Craig-
>>
>> We were already setting the "source" and "target" flags to "1.4"
>> for the 1.4 modules, but that only enforces language-level
>> restrictions (e.g., it would raise an error if you tried to use
>> generics or autoboxing), it doesn't check to make sure you didn't
>> use an API method that doesn't exist in 1.4. In order to validate
>> that, say, you didn't call String.contains() (which is new in
>> 1.5), you need to use the bootclasspath argument to provide the
>> 1.4 runtime jar so that that level of verification can take place.
>>
>>
>>
>> On Jun 13, 2007, at 10:21 PM, Craig L Russell wrote:
>>
>>> There is a maven flag that you can put into maven's
>>> project.properties that specifies the level of jdk to use for
>>> that project.
>>>
>>> maven.compile.source = 1.4
>>> maven.compile.target = 1.4
>>>
>>> This can be dropped into those projects that we want to compile
>>> with 1.4. This will enforce the dependency at compile time.
>>>
>>> Craig
>>>
>>> On Jun 13, 2007, at 12:55 AM, Marc Prud'hommeaux wrote:
>>>
>>>>
>>>> We recently had some problems where JDK 1.5-specific methods
>>>> (e.g., String.contains(String)) were slipping into JDK 1.4-
>>>> specific modules. This isn't a problem for stand-alone OpenJPA
>>>> (whose only implementation is JPA, which is JDK 1.5-dependent),
>>>> but other products built on OpenJPA may still support JDK 1.4.
>>>>
>>>> To that end, I've added a 'java14.jar' property to the pom.xml
>>>> files that can be used to specify the location of the JDK 1.4
>>>> runtime jar, against which we will compile the JDK 1.4-specific
>>>> modules. Since the location of the JDK 1.4 runtime jar is
>>>> platform- and installation- dependent, we can't just rely on a
>>>> single location (nor is there any maven-friendly JDK 1.4 runtime
>>>> jar that I am aware of), the flag needs to be specified manually.
>>>>
>>>> Note that the flag will be silently ignored when it is
>>>> unspecified, which I expect will be the common case for most
>>>> OpenJPA developers. You only need to use it if you are
>>>> interested in ensuring that any code you add to JDK 1.4 modules
>>>> won't break 1.4 compatibility.
>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Enforcing JDK 1.4-specific modules
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Marc,
Ah, you are right. I looked at the projects and didn't see the
project.properties where the compile.source and target properties
are. They are also in the pom.xml though in the build plugins.
But why should this be a choice of developers? I'd think that either
we would want to enforce this restriction for the project or not. If
we leave it up to developers' choice then someone will eventually
have to come around and fix up the 1.5 dependencies. Is that what we
want?
Craig
On Jun 13, 2007, at 7:35 AM, Marc Prud'hommeaux wrote:
> Craig-
>
> We were already setting the "source" and "target" flags to "1.4"
> for the 1.4 modules, but that only enforces language-level
> restrictions (e.g., it would raise an error if you tried to use
> generics or autoboxing), it doesn't check to make sure you didn't
> use an API method that doesn't exist in 1.4. In order to validate
> that, say, you didn't call String.contains() (which is new in 1.5),
> you need to use the bootclasspath argument to provide the 1.4
> runtime jar so that that level of verification can take place.
>
>
>
> On Jun 13, 2007, at 10:21 PM, Craig L Russell wrote:
>
>> There is a maven flag that you can put into maven's
>> project.properties that specifies the level of jdk to use for that
>> project.
>>
>> maven.compile.source = 1.4
>> maven.compile.target = 1.4
>>
>> This can be dropped into those projects that we want to compile
>> with 1.4. This will enforce the dependency at compile time.
>>
>> Craig
>>
>> On Jun 13, 2007, at 12:55 AM, Marc Prud'hommeaux wrote:
>>
>>>
>>> We recently had some problems where JDK 1.5-specific methods
>>> (e.g., String.contains(String)) were slipping into JDK 1.4-
>>> specific modules. This isn't a problem for stand-alone OpenJPA
>>> (whose only implementation is JPA, which is JDK 1.5-dependent),
>>> but other products built on OpenJPA may still support JDK 1.4.
>>>
>>> To that end, I've added a 'java14.jar' property to the pom.xml
>>> files that can be used to specify the location of the JDK 1.4
>>> runtime jar, against which we will compile the JDK 1.4-specific
>>> modules. Since the location of the JDK 1.4 runtime jar is
>>> platform- and installation- dependent, we can't just rely on a
>>> single location (nor is there any maven-friendly JDK 1.4 runtime
>>> jar that I am aware of), the flag needs to be specified manually.
>>>
>>> Note that the flag will be silently ignored when it is
>>> unspecified, which I expect will be the common case for most
>>> OpenJPA developers. You only need to use it if you are interested
>>> in ensuring that any code you add to JDK 1.4 modules won't break
>>> 1.4 compatibility.
>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Enforcing JDK 1.4-specific modules
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Craig-
We were already setting the "source" and "target" flags to "1.4" for
the 1.4 modules, but that only enforces language-level restrictions
(e.g., it would raise an error if you tried to use generics or
autoboxing), it doesn't check to make sure you didn't use an API
method that doesn't exist in 1.4. In order to validate that, say, you
didn't call String.contains() (which is new in 1.5), you need to use
the bootclasspath argument to provide the 1.4 runtime jar so that
that level of verification can take place.
On Jun 13, 2007, at 10:21 PM, Craig L Russell wrote:
> There is a maven flag that you can put into maven's
> project.properties that specifies the level of jdk to use for that
> project.
>
> maven.compile.source = 1.4
> maven.compile.target = 1.4
>
> This can be dropped into those projects that we want to compile
> with 1.4. This will enforce the dependency at compile time.
>
> Craig
>
> On Jun 13, 2007, at 12:55 AM, Marc Prud'hommeaux wrote:
>
>>
>> We recently had some problems where JDK 1.5-specific methods
>> (e.g., String.contains(String)) were slipping into JDK 1.4-
>> specific modules. This isn't a problem for stand-alone OpenJPA
>> (whose only implementation is JPA, which is JDK 1.5-dependent),
>> but other products built on OpenJPA may still support JDK 1.4.
>>
>> To that end, I've added a 'java14.jar' property to the pom.xml
>> files that can be used to specify the location of the JDK 1.4
>> runtime jar, against which we will compile the JDK 1.4-specific
>> modules. Since the location of the JDK 1.4 runtime jar is
>> platform- and installation- dependent, we can't just rely on a
>> single location (nor is there any maven-friendly JDK 1.4 runtime
>> jar that I am aware of), the flag needs to be specified manually.
>>
>> Note that the flag will be silently ignored when it is
>> unspecified, which I expect will be the common case for most
>> OpenJPA developers. You only need to use it if you are interested
>> in ensuring that any code you add to JDK 1.4 modules won't break
>> 1.4 compatibility.
>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Enforcing JDK 1.4-specific modules
Posted by Craig L Russell <Cr...@Sun.COM>.
There is a maven flag that you can put into maven's
project.properties that specifies the level of jdk to use for that
project.
maven.compile.source = 1.4
maven.compile.target = 1.4
This can be dropped into those projects that we want to compile with
1.4. This will enforce the dependency at compile time.
Craig
On Jun 13, 2007, at 12:55 AM, Marc Prud'hommeaux wrote:
>
> We recently had some problems where JDK 1.5-specific methods (e.g.,
> String.contains(String)) were slipping into JDK 1.4-specific
> modules. This isn't a problem for stand-alone OpenJPA (whose only
> implementation is JPA, which is JDK 1.5-dependent), but other
> products built on OpenJPA may still support JDK 1.4.
>
> To that end, I've added a 'java14.jar' property to the pom.xml
> files that can be used to specify the location of the JDK 1.4
> runtime jar, against which we will compile the JDK 1.4-specific
> modules. Since the location of the JDK 1.4 runtime jar is platform-
> and installation- dependent, we can't just rely on a single
> location (nor is there any maven-friendly JDK 1.4 runtime jar that
> I am aware of), the flag needs to be specified manually.
>
> Note that the flag will be silently ignored when it is unspecified,
> which I expect will be the common case for most OpenJPA developers.
> You only need to use it if you are interested in ensuring that any
> code you add to JDK 1.4 modules won't break 1.4 compatibility.
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!