jgrapht-developers

[jgrapht-developers] 0.7.0

[John V. S. <js...@gm...>]

Hi Hartmut,

When you get a chance, could you post an update to this list on the
state of generics support and any core changes that are going to be
required?  I'd like to start making up a list of all of the proposed
alterations we've been talking about for the 0.7.0 release.

Also, Charles Fry has reserved the org.jgrapht domain name, so we'll be
renaming all of the packages accordingly.  This requires some
coordination now that branching is being used; we won't start the
renaming until all changes to generics have been integrated to the
trunk.

JVS

p.s. Charles, I'm missing the Burma-Shave jingles!

RE: [jgrapht-developers] 0.7.0

[Hartmut B. <Har...@gm...>]

About the state of the generics in the branch ivins_Generics_Pre0_7_0:

I have successfully removed quite a number of warnings relating to the
generics. Alas, there is still a lot of complaining from the compiler and
some seem to point to underlying problems of the package.

Changes introduced in the branch:
- org._3pq.jgrapht.DirEdge: Interface for directed edges
- a small number of JUnit tests


Things I think should happen for 0.7.0
======================================
- Rename edge.DirectedEdge to edge.DefaultDirectedEdge
- Rename DirectedWhightedEdge to DefaultDirectedWhightedEdge
- etc.
- Lots of places still with warnings
- Lots of "COMMENT ME" places asking for comments (with and without this
  string)
- Lots of JUnit test


Things I have problems with
==================
- EdgeFactories are tricky with generics,
  and more so in the context of sub-classes of graph and the default
  constructor. The warnings are in the Default*Graph classes.
As of now, I have not been able to declare and assign an edge factory to a
graph without a compiler warning. The reason, I think, is that the types of
generics are tested (and only testable) at compile time.
Any suggestions and help are welcome.

  A more serious problem occurs with sub-classing and the default
constructor: When you use or sub-class a graph using generics specifying
that you have edges of type EEEE and forget to feed it with the correct
EdgeFactory for EEEE you will get a runtime-error. John suggested we might
need to remove the default constructor entirely.

- Heaps - I don't understand sufficiently what is going on in there in order
to get it watertight with generics/type-safety. Maybe Michael can have a
look and help.


There a probably quite a number of other things I can't remember right now
(just back from a long vacation).
In the immediate future (4-6 weeks) I will not be able to do a lot of
programming with generics. Everyone feel free to update the branch whenever
you like.


Hartmut

RE: [jgrapht-developers] 0.7.0

[Hartmut B. <Har...@gm...>]

Just an addition to my previous mail:
I just checked and as far as I can see there are 77 warnings regarding type
safety left. I consider most of them non-trivial. They are in
- alg (11)
- experimental (35)
- graph (18 - almost entirely related to the edge factories)
- traverse (1)
- util (12)

Parts of the code (e.g. permutations) explicitly go through Object Arrays,
which makes it hard to keep track of the generic type (there are no
generically typed arrays).

Hartmut

RE: [jgrapht-developers] 0.7.0

[Hartmut B. <Har...@gm...>]

I just treated the .util.equivalence and some of the dependent classes
package for generics. Down to 74 generics-type-cast warnings now:
- alg (19 - some usage of equivalence classes untouched)
- experimental (35)
- graph (18 - almost entirely related to the edge factories)
- traverse (1)
- util.permutation (1)

The JUnit tests still work OK, but I think the equivalence package (and the
other classes) need some regression testing (by people that actually use
them in previously working code - the test cases are insufficient).

Hartmut

RE: [jgrapht-developers] 0.7.0

[John V. S. <js...@gm...>]

Thanks for the update!

Regarding experimental, we already have separate ant targets compile and
exp.compile.  If we can get compile warning-free, that would be a big
step forward.  After that we would impose the rule that any code moving
out of experimental would have to be warning-free.

I'll contact the author of .util.equivalence (in case he's not reading
this) to see if he has any more tests available.

JVS

On Wed, 2006-01-25 at 23:46 +0100, Hartmut Benz wrote:
> I just treated the .util.equivalence and some of the dependent classes
> package for generics. Down to 74 generics-type-cast warnings now:
> - alg (19 - some usage of equivalence classes untouched)
> - experimental (35)
> - graph (18 - almost entirely related to the edge factories)
> - traverse (1)
> - util.permutation (1)
> 
> The JUnit tests still work OK, but I think the equivalence package (and the
> other classes) need some regression testing (by people that actually use
> them in previously working code - the test cases are insufficient).
> 
> Hartmut
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> jgrapht-developers mailing list
> jgr...@li...
> https://lists.sourceforge.net/lists/listinfo/jgrapht-developers

RE: [jgrapht-developers] 0.7.0

[Hartmut B. <Har...@gm...>]

Hallo,

I have just merged the Generics tree into the HEAD version and create two
new tags:
	vers_0_6_0_1	Immediately before the Merge
	vers_0_6_1		The merged version.

"Down" to 206 generics-type-cast warnings now:
- alg (22 - some usage of equivalence classes untouched)
- experimental (35)
- ext (11)
- graph (18 - almost entirely related to the edge factories)
- traverse (1)
- util (3)
- testsrc (116)

This move to generis turned out to be an order of magnitude more work tan
expected - even with eclipse helping a lot. As a consequence, I merged my
work back into the main stream and I'll ask *all* developers and
non-developers to help.
I am also no longer working with the project using jgrapht and thus will be
quite limited on the time I can spend working on jgrapht in the coming
months.

The principle problems with the EdgeFactories remain. I have no immediate
solution to either removing the warnings currently there, or making the
whole construction with it type safe. Removing the default constructors,
which set problematic default factories, entirely is a solution, but that
question is probably better answered by large-scale users of jgrapht.
Another (drastic) option is to give the current edges the same status as
vertices, i.e., make them user objects and move the incidence/adjacency
relation into the graph object itself. This would effectively remove the
user-visible edge factory altogether.

I am curious to hear opinions of others on this subject.

Greetings and success
	Hartmut

Re: [jgrapht-developers] 0.7.0

[Christian H. <ha...@fm...>]

Hartmut Benz wrote:

>Hallo,
>
>I have just merged the Generics tree into the HEAD version and create two
>new tags:
>	vers_0_6_0_1	Immediately before the Merge
>	vers_0_6_1		The merged version.
>
>"Down" to 206 generics-type-cast warnings now:
>- alg (22 - some usage of equivalence classes untouched)
>- experimental (35)
>- ext (11)
>- graph (18 - almost entirely related to the edge factories)
>- traverse (1)
>- util (3)
>- testsrc (116)
>
>This move to generis turned out to be an order of magnitude more work tan
>expected - even with eclipse helping a lot. As a consequence, I merged my
>work back into the main stream and I'll ask *all* developers and
>non-developers to help.
>I am also no longer working with the project using jgrapht and thus will be
>quite limited on the time I can spend working on jgrapht in the coming
>months.
>
>The principle problems with the EdgeFactories remain. I have no immediate
>solution to either removing the warnings currently there, or making the
>whole construction with it type safe. Removing the default constructors,
>which set problematic default factories, entirely is a solution, but that
>question is probably better answered by large-scale users of jgrapht.
>Another (drastic) option is to give the current edges the same status as
>vertices, i.e., make them user objects and move the incidence/adjacency
>relation into the graph object itself. This would effectively remove the
>user-visible edge factory altogether.
>
>I am curious to hear opinions of others on this subject.
>
>Greetings and success
>	Hartmut
>
>  
>
Hi,

Maybe it's not such a good idea to use Eclipse only. I just checked out 
the most recent version an got about 12 errors using Suns java compiler:

"ConnectivityInspector.java": a type variable may not be followed by 
other bounds at line 105, column 35
"ConnectivityInspector.java": type parameter EE is not within its bound 
at line 105, column 79
"AsUndirectedGraph.java": a type variable may not be followed by other 
bounds at line 97, column 39
"GraphDelegator.java": incompatible types; found   : 
java.util.List<capture of ? extends capture of ? extends E>, required: 
java.util.List<? extends E> at line 203, column 60
"GraphDelegator.java": incompatible types; found   : 
java.util.List<capture of ? extends capture of ? extends E>, required: 
java.util.List<? extends E> at line 219, column 60
"AsUndirectedGraph.java": type parameter ED is not within its bound at 
line 97, column 78
...

It seems the Eclipse compiler is not as strict as Suns.

Another point about the compiler warnings: I am not convinced that one 
can really eliminate all those because there are definitely some points 
in the code where the code itself is not 100% secure. Another problem 
seems to be when one would like to cast e.g. a Graph<V,E> to a 
DirectedGraph<V,DE> where E extends Edge<V> and DE extends DirEdge<V>. 
It seems secure as DirectedGraph is defined as extends Graph<V,DE> but 
I'm not sure if and how one can express it such that the type systems 
accepts it.

By the way: there seems to be a solution proposed by Sun how to 
integrate Factories into generics. I will do some experiments and send 
you the results.

-- 
Christian Hammer
E-Mail: mailto:ha...@fm...
WWW: http://www.infosun.fmi.uni-passau.de/st/staff/hammer/

Re: [jgrapht-developers] 0.7.0

[John V. S. <js...@gm...>]

Right, I will change the checkin criteria in etc/project-policies.html 
to be more explicit:  it must compile with command-line ant.

Regardless of that, Hartmut, thanks for the checkin!  Once we get the 
build fixed I can start on some of the repackaging work that's been 
planned (including move to org.jgrapht and migration to Subversion).  We 
can keep investigating the generics "warts" in parallel.

JVS

Christian Hammer wrote:
> Hartmut Benz wrote:
> 
>> Hallo,
>>
>> I have just merged the Generics tree into the HEAD version and create two
>> new tags:
>>     vers_0_6_0_1    Immediately before the Merge
>>     vers_0_6_1        The merged version.
>>
>> "Down" to 206 generics-type-cast warnings now:
>> - alg (22 - some usage of equivalence classes untouched)
>> - experimental (35)
>> - ext (11)
>> - graph (18 - almost entirely related to the edge factories)
>> - traverse (1)
>> - util (3)
>> - testsrc (116)
>>
>> This move to generis turned out to be an order of magnitude more work tan
>> expected - even with eclipse helping a lot. As a consequence, I merged my
>> work back into the main stream and I'll ask *all* developers and
>> non-developers to help.
>> I am also no longer working with the project using jgrapht and thus 
>> will be
>> quite limited on the time I can spend working on jgrapht in the coming
>> months.
>>
>> The principle problems with the EdgeFactories remain. I have no immediate
>> solution to either removing the warnings currently there, or making the
>> whole construction with it type safe. Removing the default constructors,
>> which set problematic default factories, entirely is a solution, but that
>> question is probably better answered by large-scale users of jgrapht.
>> Another (drastic) option is to give the current edges the same status as
>> vertices, i.e., make them user objects and move the incidence/adjacency
>> relation into the graph object itself. This would effectively remove the
>> user-visible edge factory altogether.
>>
>> I am curious to hear opinions of others on this subject.
>>
>> Greetings and success
>>     Hartmut
>>
>>  
>>
> Hi,
> 
> Maybe it's not such a good idea to use Eclipse only. I just checked out 
> the most recent version an got about 12 errors using Suns java compiler:
> 
> "ConnectivityInspector.java": a type variable may not be followed by 
> other bounds at line 105, column 35
> "ConnectivityInspector.java": type parameter EE is not within its bound 
> at line 105, column 79
> "AsUndirectedGraph.java": a type variable may not be followed by other 
> bounds at line 97, column 39
> "GraphDelegator.java": incompatible types; found   : 
> java.util.List<capture of ? extends capture of ? extends E>, required: 
> java.util.List<? extends E> at line 203, column 60
> "GraphDelegator.java": incompatible types; found   : 
> java.util.List<capture of ? extends capture of ? extends E>, required: 
> java.util.List<? extends E> at line 219, column 60
> "AsUndirectedGraph.java": type parameter ED is not within its bound at 
> line 97, column 78
> ...
> 
> It seems the Eclipse compiler is not as strict as Suns.
> 
> Another point about the compiler warnings: I am not convinced that one 
> can really eliminate all those because there are definitely some points 
> in the code where the code itself is not 100% secure. Another problem 
> seems to be when one would like to cast e.g. a Graph<V,E> to a 
> DirectedGraph<V,DE> where E extends Edge<V> and DE extends DirEdge<V>. 
> It seems secure as DirectedGraph is defined as extends Graph<V,DE> but 
> I'm not sure if and how one can express it such that the type systems 
> accepts it.
> 
> By the way: there seems to be a solution proposed by Sun how to 
> integrate Factories into generics. I will do some experiments and send 
> you the results.
>