You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/02/25 16:01:08 UTC
[Proposal] Splitting JDK dependent code [was: Re: Javac task design problems]
One solution to avoid filtering our java-code because of jdk-dependencies
is to separate this code into different source directories.
For example for the databases block that uses ant filtering we could
generate three directories:
blocks/databases/java - the common code
blocks/databases/java1.2 - the AbstractEqslConnection.java for JDK 1.2/1.3
blocks/databases/java1.4 - the AbstractEqslConnection.java for JDK 1.4 and
above
This is then similar to our libs directory.
This solution would not only remove the need of filtering but would also
make the source directly usable within your favorite IDE.
What do you think?
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
Re: [Proposal] Splitting JDK dependent code [was: Re: Javac task
design problems]
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> If you want one base class for Java 1.2 and one derived class for Java
> 1.4... Just check that Java 1.4 will work with that... How it will react
> on non-abstract class (BaseEsqlConnection) which does not implement
> interface (Connection) fully?
> Or you want to have one abstract (BaseAbstractEsqlConnection) and two
> concrete classes (EsqlConnection12 and EsqlConnection14)?
Well, binary compatible or not we already have this warning message in
our build:
"This build is targeted for use with JVM ${target.vm}"
"Using this build on a virtual machine other than the one"
"it is targeted for may result in runtime errors."
so?
--
Torsten
Re: [Proposal] Splitting JDK dependent code [was: Re: Javac task
design problems]
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
>
> Vadim Gritsenko wrote, On 25/02/2003 16.19:
>
>> Carsten Ziegeler wrote:
>
> ...
>
>>> blocks/databases/java1.4 - the AbstractEqslConnection.java for JDK
>>> 1.4 and
>>> above
>>>
>>> This is then similar to our libs directory.
>>>
>>> This solution would not only remove the need of filtering but would
>>> also
>>> make the source directly usable within your favorite IDE.
>>>
>>
>> OTOH, it will increase maintanence - you have to maintain two copies...
>
>
> Can't we extend a BaseAbstractEqslConnection and just add the methods
> that change from one JDK to the other?
Now you are talking! ;-)
If you want one base class for Java 1.2 and one derived class for Java
1.4... Just check that Java 1.4 will work with that... How it will react
on non-abstract class (BaseEsqlConnection) which does not implement
interface (Connection) fully?
Or you want to have one abstract (BaseAbstractEsqlConnection) and two
concrete classes (EsqlConnection12 and EsqlConnection14)?
Vadim
RE: [Proposal] Splitting JDK dependent code [was: Re: Javac task design problems]
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ok, I just did the split as a proof of concept - and we don't need to
copy the source code anymore. Now, if you want to refactor it... :)
Carsten
> From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> > Can't we extend a BaseAbstractEqslConnection and just add the methods
> > that change from one JDK to the other?
>
> hmm.... I doubt the AbstractEsqlConnection will change that often
> so this should not be too hard to maintain.
>
> If we would go this way I'd propose to name it AbstractJdbcConnection
> since then there is no relation to esql anymore. Maybe it should also
> better live in a different package.
>
> Could also be useful for other components that use JDBC directly...
>
> Hm... I start to like it...
Re: [Proposal] Splitting JDK dependent code [was: Re: Javac task
design problems]
Posted by Torsten Curdt <tc...@dff.st>.
> Can't we extend a BaseAbstractEqslConnection and just add the methods
> that change from one JDK to the other?
hmm.... I doubt the AbstractEsqlConnection will change that often
so this should not be too hard to maintain.
If we would go this way I'd propose to name it AbstractJdbcConnection
since then there is no relation to esql anymore. Maybe it should also
better live in a different package.
Could also be useful for other components that use JDBC directly...
Hm... I start to like it...
--
Torsten
Re: [Proposal] Splitting JDK dependent code [was: Re: Javac task
design problems]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote, On 25/02/2003 16.19:
> Carsten Ziegeler wrote:
...
>> blocks/databases/java1.4 - the AbstractEqslConnection.java for JDK 1.4
>> and
>> above
>>
>> This is then similar to our libs directory.
>>
>> This solution would not only remove the need of filtering but would also
>> make the source directly usable within your favorite IDE.
>>
>
> OTOH, it will increase maintanence - you have to maintain two copies...
Can't we extend a BaseAbstractEqslConnection and just add the methods
that change from one JDK to the other?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Proposal] Splitting JDK dependent code [was: Re: Javac task
design problems]
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>One solution to avoid filtering our java-code because of jdk-dependencies
>is to separate this code into different source directories.
>For example for the databases block that uses ant filtering we could
>generate three directories:
>blocks/databases/java - the common code
>blocks/databases/java1.2 - the AbstractEqslConnection.java for JDK 1.2/1.3
>
I think that because Avalon (IIRC) could not be run under 1.2, and
because 1.3 almost (99.9%) everywhere available (see POLL), we should
write simply 1.3 and do not mention 1.2 anymore.
>blocks/databases/java1.4 - the AbstractEqslConnection.java for JDK 1.4 and
>above
>
>This is then similar to our libs directory.
>
>This solution would not only remove the need of filtering but would also
>make the source directly usable within your favorite IDE.
>
OTOH, it will increase maintanence - you have to maintain two copies...
Vadim
>What do you think?
>
>
>Carsten
>
>Carsten Ziegeler
>Open Source Group, S&N AG
>
Re: [Proposal] Splitting JDK dependent code [was: Re: Javac task
design problems]
Posted by Torsten Curdt <tc...@dff.st>.
>>> One solution to avoid filtering our java-code because of
>>> jdk-dependencies
>>> is to separate this code into different source directories.
>>> For example for the databases block that uses ant filtering we could
>>> generate three directories:
>>> blocks/databases/java - the common code
>>> blocks/databases/java1.2 - the AbstractEqslConnection.java for JDK
>>> 1.2/1.3
>>> blocks/databases/java1.4 - the AbstractEqslConnection.java for JDK
>>> 1.4 and
>>> above
>>>
>>> This is then similar to our libs directory.
>>>
>>> This solution would not only remove the need of filtering but would also
>>> make the source directly usable within your favorite IDE.
>>>
>>> What do you think?
Hm... I don't know... at least for now it seems to be the KISS solution.
As long as the differences can be kept small and we don't get more by
the time it sould be ok.
But I am not very enthusiastic about this solution.
So I give a +0
>> That should turn Constants.java in a property file that Cocoon reads
>> out of its own jar file when it starts.
+1
> So both Cocoon and the build system can read it! One source! :-)
Exactly the opposite of the KISS solution above :-/
--
Torsten
Re: [Proposal] Splitting JDK dependent code [was: Re: Javac task
design problems]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 25/02/2003 17.22:
> Carsten Ziegeler wrote:
>
>> One solution to avoid filtering our java-code because of jdk-dependencies
>> is to separate this code into different source directories.
>> For example for the databases block that uses ant filtering we could
>> generate three directories:
>> blocks/databases/java - the common code
>> blocks/databases/java1.2 - the AbstractEqslConnection.java for JDK
>> 1.2/1.3
>> blocks/databases/java1.4 - the AbstractEqslConnection.java for JDK 1.4
>> and
>> above
>>
>> This is then similar to our libs directory.
>>
>> This solution would not only remove the need of filtering but would also
>> make the source directly usable within your favorite IDE.
>>
>> What do you think?
>
> big +1!
I kinda like the idea, but why not
blocks/databases/java/org/apache/xxx
blocks/databases/java/org/apache/xxx/1.2
blocks/databases/java/org/apache/xxx/1.4
?
And how can one use them within the favourite ide?
> The code filtering problem is suggesting me that preprocessing source
> code is a very bad habit and we should try to avoid it alltogether!
;-)
I have been working on a build system for quite some time too, and my
opinion is that... I don't have an opinion! ;-)
Filtering is a "hack" to overcome javac and java deficiencies with some
sort of preprocessing. Think about instrumenting code, using altrmi
statically, or using aspects. Filtering here is needed.
It's just a tool, use it only when it's really needed. In this case it's
not so needed, so this solution seems optimal :-)
> That should turn Constants.java in a property file that Cocoon reads out
> of its own jar file when it starts.
Yes!
So both Cocoon and the build system can read it! One source! :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Proposal] Splitting JDK dependent code [was: Re: Javac task
design problems]
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> One solution to avoid filtering our java-code because of jdk-dependencies
> is to separate this code into different source directories.
> For example for the databases block that uses ant filtering we could
> generate three directories:
> blocks/databases/java - the common code
> blocks/databases/java1.2 - the AbstractEqslConnection.java for JDK 1.2/1.3
> blocks/databases/java1.4 - the AbstractEqslConnection.java for JDK 1.4 and
> above
>
> This is then similar to our libs directory.
>
> This solution would not only remove the need of filtering but would also
> make the source directly usable within your favorite IDE.
>
> What do you think?
big +1!
The code filtering problem is suggesting me that preprocessing source
code is a very bad habit and we should try to avoid it alltogether!
That should turn Constants.java in a property file that Cocoon reads out
of its own jar file when it starts.
Thoughts?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------