openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Enforcing JDK 1.4-specific modules
Date Wed, 13 Jun 2007 17:12:26 GMT
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!


Mime
View raw message