How To Branch Java

A

Alan Gutierrez

I'd like to try removing some stuff from an interface.

If it were C, I'd ifdef it. Then I could compile against the
older version, or the newer version by setting a compiler
switch. I could try the slimmed interface, but now worry about
losing the older interface.

In the end there are utilities I could use to help me make up my
mind, or I could leave the choice in.

Basically, I wrote the code, but I don't know if I want to
release it, and thus support it. However, I don't want to branch
SVN, and cut it out either, because I might want it after
experience with the release.

What do Java programmers do when they want to branch code in
this way? Is it a matter of creating a new branch in version
control?
 
S

Stefan Schulz

What do Java programmers do when they want to branch code in
this way? Is it a matter of creating a new branch in version
control?

I usually leave such worries to the version control software, yes. Just
create a new branch, and massacre away. If you find that the new concept
is untenable, you can still go back to the previous branch.

The C-Style ifdefs become quite a bother soon, just imagine having a
method with three #ifdef'ed blocks... horrible to read, and nearly
impossible to understand.
 
X

xarax

Stefan Schulz said:
I usually leave such worries to the version control software, yes. Just
create a new branch, and massacre away. If you find that the new concept
is untenable, you can still go back to the previous branch.

The C-Style ifdefs become quite a bother soon, just imagine having a
method with three #ifdef'ed blocks... horrible to read, and nearly
impossible to understand.

I generally split it into 2 interfaces. The interface
with "more stuff" simply extends the interface with
"less stuff". Then you have to contend with deciding
which interface you'll reference in your code. You
can hide that behind a factory API that instantiates
an object that implements one or the other interface
(polymorphism).

In short, stop thinking in C and start thinking in Java.
 
A

Alan Gutierrez

I usually leave such worries to the version control software, yes. Just
create a new branch, and massacre away. If you find that the new concept
is untenable, you can still go back to the previous branch.

The C-Style ifdefs become quite a bother soon, just imagine having a
method with three #ifdef'ed blocks... horrible to read, and nearly
impossible to understand.

Yes. Difficult to understand. Not anything to be taken lightly.

Sometimes, however, it does make sense. In my case:

public interface Foo
{
public String getData();

public boolean isImmutable();

public Foo getImmutable();
}

~ I've got a framework that provide an GoF observer with a Foo.

The framework might use a object cached foo. If the observer
wants to keep the foo, it calls getImmutable().

This was a premature optimization.

I don't like that I've two implementations of every flavor of
Foo. Any performance gain might not be worth the documentation
effort. I'll have to wait and see.

Release version 1.0 without the is/getImmutable. If there are
issues, I've got a solution.

But, if I hive this off to source control, I can't build it
frequently to make sure that the optimization code still works.

I'll end up rewriting it at some future date.

This kind of branching is an acceptable application of #ifdef.
 
A

alan

I generally split it into 2 interfaces. The interface with "more
stuff" simply extends the interface with "less stuff".

It doesn't work that way in this case. There needs to be one
interface. It either has more stuff, or it doesn't. You can add
stuff to an interface in subsequent released, but you can't take
things away. I'm faced with a problem of having prematurely
written more stuff. I don't want to release that stuff, but I
want to make sure it still works.
Then you have to contend with deciding which interface you'll
reference in your code.

Yes. That's what I'm trying to decide. That's the problem.
You can hide that behind a factory API that instantiates an object
that implements one or the other interface (polymorphism).

That's not ploymorphism.
In short, stop thinking in C and start thinking in Java.

I am. I'm sincerly interested to see if anyone has taken a route
short of "refactor merciliously", which it the route I
ordinarily take.
 
C

Chris Smith

Alan Gutierrez said:
But, if I hive this off to source control, I can't build it
frequently to make sure that the optimization code still works.

I'm curious why it would be easier to continue testing another #ifdef
case than another CVS branch.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
A

Alan Gutierrez

I'm curious why it would be easier to continue testing another
#ifdef case than another CVS branch.

~ First off, I'm not trolling. The question is not which is
better, C or Java, nor am I whigning that Java does have a
precompiler. Want to make that clear.

~ In another thread, I described my problem, one that I don't see
as a problem to be solved in design. I have an interface that
has a method, for which I've spent some time writing an
implementation. I don't know if I want to support the method,
and want to release the code to see if the method is requested,
necessary. If so, I have an implementation ready.

This is a different version of the source.

This is my problem, and I'm wondering how people have dealt with
it. So far, I've been told that people use source control.

No one has shared with me, how they managed to keep the branched
code in sync with the production code.

In the case, source control is not acting as a versioning
mechanism, it's acting as a differencing mechanism.

That's what ifdef is. It maintains a context diff in your source
code.

Simply branching the code, how do I maintain a test environment?
How do I perform the merge? Do I branch all the dependent
projects as well?

Let's say I were to branch the code, create an entirely separate
Eclipse workspace with the branch, and spend some time each week
syncing new development. How to I bring changes over to the
branch? There are changes I don't want bring over, those changes
that revolve around the removal of this method. How is
Subversion going to know what lines are not supposed to be merged?

Any insight is welcome.
 
X

xarax

Alan Gutierrez said:
~ First off, I'm not trolling. The question is not which is
better, C or Java, nor am I whigning that Java does have a
precompiler. Want to make that clear.

~ In another thread, I described my problem, one that I don't see
as a problem to be solved in design. I have an interface that
has a method, for which I've spent some time writing an
implementation. I don't know if I want to support the method,
and want to release the code to see if the method is requested,
necessary. If so, I have an implementation ready.

This is a different version of the source.

This is my problem, and I'm wondering how people have dealt with
it. So far, I've been told that people use source control.

No one has shared with me, how they managed to keep the branched
code in sync with the production code.

In the case, source control is not acting as a versioning
mechanism, it's acting as a differencing mechanism.

That's what ifdef is. It maintains a context diff in your source
code.

Simply branching the code, how do I maintain a test environment?
How do I perform the merge? Do I branch all the dependent
projects as well?

Let's say I were to branch the code, create an entirely separate
Eclipse workspace with the branch, and spend some time each week
syncing new development. How to I bring changes over to the
branch? There are changes I don't want bring over, those changes
that revolve around the removal of this method. How is
Subversion going to know what lines are not supposed to be merged?

Any insight is welcome.

I use interfaces, sub-interfaces, classes and subclasses. An
interface (implemented by a class) is used in production. When
I want to add a method, I extend the interface with a sub-interface
that is implemented by a subclass. Then the production code still
runs fine with the "old" stuff. New code that uses the sub-interface
and subclass can be tested, then integrated with production. I don't
often re-open the original interface or class to add methods. This
is the open/closed principle of object oriented design (Betrand
Meyer -- Object Oriented Software Construction).

I also use factory classes and objects to centralize where classes
are instantiated, so I can change to a new subclass without disturbing
any client code that uses the factories.
 
F

frankgerlach22

There are also preprocessors for java available. For some problems
this might be the ideal solution, for others it's just a pain in the a..
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top