Hi Gerd,
I was completely wrong about the compareTo. Thanks for pointing that out.
I agree the compareTo method should be removed. TableA should really be
using an IdentityLinkedHashMap, but this doesn't exist in the standard jdk.
Thanks,
Brian
On Thu, Nov 6, 2014 at 9:45 AM Gerd Petermann <
gpe
Hi Brian,
I read again your posts. I think you got something wrong.
I think we allow to create multiple instances of RoadDef
having the same values in the id field and in the name field.
This happens when a style adds the same OSM way
with different routing attributes, e.g. one way for bicycles
a
Hi Uli,
please try r3345. I think there is more to do, but the NPE should
no longer occur.
Gerd
UliBaer wrote
> Hi Gerd,
>
> this is good news! I'll use my single threaded workaround for the time
> being.
> When a patch or a different approach is committed, i will run again multi
> threaded.
>
Version mkgmap-r3345 was committed by gerd on Thu, 06 Nov 2014
- remove compareTo() method from RoadDef and the Comparable attribute.
The sorting of RoadDef instances is done with a more complex method
in NETFile.sortRoads().
This might also prevent an NPE that occurs with JRE 8.
Hi Brian,
reg. use of compareTo():
I think you also use JDK 8, I think the compareTo() method is called because of
the change described here:
http://javaagonist.blogspot.de/2014/04/whats-new-in-java-8.html
I tried running SimpleRouteTest and diverse input files and I never reached the
breakpoin
Hi Gerd,
In Steve’s stack trace it shows RoadMap is being used by a LinkedHashMap in
TableA. A linked hash map maintains an ordered list of nodes, which is the same
in every JDK version. You can set a breakpoint in CompareTo and run the
SimpleRouteTest and see that it’s being used.
The TableA
Hi Gerd,
this is good news! I'll use my single threaded workaround for the time
being.
When a patch or a different approach is committed, i will run again multi
threaded.
I was sure that the error also happened with Java 7, but now i'm not so sure
anymore.
Maybe, i had already switched to Java 8,
Oops, sorry, r3076 was the merge of the sort branch, not the unicode branch
Gerd
From: gpetermann_muenc...@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Thu, 6 Nov 2014 10:42:03 +0100
Subject: Re: [mkgmap-dev] NPE with mkgmap 3320
Hi Uli,
I am able to reproduce a similar error when I
Hi Uli,
I am able to reproduce a similar error when I use a TreeMap
instead of a LinkedHashMap
for RoadDef objects in TableA. I think the problem was introduced with
the merge of the unicode branch (r3076) which
introduced the new encText field in Label and a possible text==null .
@Steve:
I a
Hi Uli,
yes, you are probably right.
BTW: This seems to be related to a new HashMap implementation in Java 8.
In my environtment (with Java 7), the compareTo() method is never called
which could explain why nobody else has reported the problem.
Gerd
> Date: Thu, 6 Nov 2014 00:58:06 -0800
> Fro
BTW:
Since there is a check against City object being null before the compare
method:
// TODO: look at what this is doing...
if(city != null && other.city != null)
return city.getName().compareTo(other.city.getName()); <--- Here
happens the NPE
if (hashCode() == other.hashCode())
Hi Brian,
thanks for the patch. If I got it right, the compareTo() methid is obsolete
as we do no longer sort RoadDef instances anywhere. So,
it would be easier to remove the Comparable attribute from the class
public class RoadDef /*implements Comparable*/ {
and remove the compareTo() method.
Yo
12 matches
Mail list logo
