db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Date Thu, 08 Jun 2006 21:10:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-289?page=comments#action_12415429 ] 

David Van Couvering commented on DERBY-289:
-------------------------------------------

Now that the i18n work is pretty much done and the 10.1.3 release is
closed, I'd like to revisit our beloved issue of code sharing.

I have had time to think about this further, and believe it or not I
am warming to Kathey's proposed approach.  I'd like to propose a
refinement to this here, and get your feedback.

I'd like to desribe the proposal in terms of an example.  Let's say
we have a class we want to share between derbyclient jar and
derby.jar, called DavidUtil.  Here's how I would share it.

(a) Create the class under the shared package hierarchy (or move
    it if it is an existing class.  Yes, yes, I know it needs
    copyrights and javadoc :)

package org.apache.derby.shared.common;

public class DavidUtil {
  public int foo(int a, int b) {
     // code here
  }
}

(b) Add an ant target that takes all classes under
org.apache.derby.shared and makes a copy of them under
org.apache.derby.shared.generated.client.  This would need
to be done prior to any compilation.

Yes, I know the package name is a mouthful, but we really should
have the "generated" package name to make it clear this is generated
code.  The alternative is to add a comment, but then the line numbers
are out of sync between generated and original code, and this makes
debugging very difficult.

If we also want to create shared classes for derbynet and
derbytools, we would create copies there too.   For example:

package org.apache.derby.shared.generated.client.common;

public class DavidUtil {
   public int foo(int a, int b) {
      // code here
   }
}

==
package org.apache.derby.shared.generated.net.common;

public class DavidUtil {
   public int foo(int a, int b) {
      // code here
   }
}
==
package org.apache.derby.shared.generated.tools.common;

public class DavidUtil {
   public int foo(int a, int b) {
      // code here
   }
}

Although this needs to be tested and verified, The 'generated' directory 
would be marked as a directory to be ignored by subversion using the 
svn:ignore property.  This way these files would not show up under 
svn status as "?" and could not be checked in by accident.

(c) In the engine code (e.g. the classes that go into derby.jar),
I import org.apache.derby.shared.common.DavidUtil.

In the client code I import
org.apache.derby.shared.generated.client.common.DavidUtil

and so on...

(d) During runtime, the stack trace on the client will show
the generated class.  The line numbers should match because
we're not adding or removing any lines, just modifying the
package name.

ADVANTAGES
- Meets all the requirements of shared code.  Each jar has a distinct
  and separate class.   There is no potential for shadowing and
  compatibility issues in mixed-version environments.

- Simple to implement and fairly simple understand (my concern about
  the classloader solution has been its overall complexity and that it
  would require most developers to understand the subtleties of
  classloading to  be able to work with parts of Derby).

DISADVANTAGES
- Potential of confusion for developers who try to modify
  generated code or add new classes to the generated packages.
  This is mitigated by the "generated" part of the package name
  and the fact that the generated directories are ignored by
  subversion.

- Doesn't solve the more general problem of being able to include
  third-party jar files and share them between derby jar files
  in a mixed-version environment.  I would argue this
  is a different problem to solve and less urgent than sharing code
  within Derby itself.

Your thoughts are most appreciated.

Thanks,

David

> Enable code sharing between Derby client and engine
> ---------------------------------------------------
>
>          Key: DERBY-289
>          URL: http://issues.apache.org/jira/browse/DERBY-289
>      Project: Derby
>         Type: Improvement

>   Components: Network Client
>     Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.1.0
>  Environment: N/A
>     Reporter: David Van Couvering
>     Assignee: David Van Couvering
>     Priority: Minor
>      Fix For: 10.2.0.0
>  Attachments: DERBY-289.diff
>
> Right now, there is no way for the Derby network client to share code with the Derby
engine.  We should have a separate jar file, e.g. derby_common.jar, that contains shared code
and is used by both the client and the engine.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message