- I am using
JGL 2.0.2 within an applet. It runs fine locally, but
when I try to load it using HTTP protocol from a web
server I get the following error:
VERIFIER ERROR COM/objectspace/jgl/Array.([Ljava/lang/Object;)V:
Expecting to find object on stack

- There is a
problem with the 1.0.2 JDK when it is verifying bytecodes
that causes problems with some of the browsers. The bug
occurs when verifying a class that has a critical section
synchronized on an Object[] - got it?
You can also see this bug by running the java interpreter
using the -verify
option.
This happens three times in JGL; twice in Array
(constructor and the copyTo method) and once in
ObjectArray (constructor). Simply comment out the actual
synchronized line in these three places (the line reading
"synchronized ( array )
" not the
method modifier), recompile, and things should work fine.
You still have access to the functions this way, but have
to be a little more careful when writing heavily threaded
apps. This only occurs when using the 1.0.2 JDK, although
there does not appear to be a published bug fix report on
the Sun web pages.
I am using OrderedMaps that allow duplicate keys. I
want to iterate through my collection via the keys, but
all duplicate keys seem to point to the same object. My
code looks like this:
Enumeration keys = map.keys();
while ( keys.hasMoreElements() )
{
Integer i = (Integer)keys.nextElement();
System.out.println( "Key=" + i + "\tValue=" + map.get( i ) );
}

- This is a
side-effect of using maps with duplicate keys. What
happens here is that get( Object ) always gives you the
first value found for the given key. You are calling get(
i ) once for each key, but they will all return the first
value found. You'll notice that there is no enumeration
used in the get() call, so the container has no way of
knowing which value you really want. To enumerate through
all the values, you can use the elements() call, but then
you lose the keys (elements() is the complement of
keys(), returning an enumeration over the values of the
map). The code to go through an OrderedMap via the keys
and visiting all values when there are duplicate keys
looks something like this:
Enumeration keys = map.keys();
while ( keys.hasMoreElements() )
{
Integer i = (Integer)keys.nextElement();
Range r = map.equalRange( i );
while ( true )
{
Pair p = (Pair)r.begin.nextElement();
System.out.println( "Key=" + p.first + "\tValue=" + p.second );
if ( r.begin.equals( r.end ) )
break;
keys.nextElement();
}
}

- Not very
pretty, is it? Luckily there is a much easier way to do
this. The start() method will enumerate over all the
key-value pairs of a map.
Enumeration pairs = map.start();
while ( pairs.hasMoreElements() )
{
Pair p = (Pair)pairs.nextElement();
System.out.println( "Key=" + p.first + "\tValue=" + p.second );
}

- A full
example of this code is available at ftp.objectspace.com/jgl/OrderedMap9.java if you would like
to continue study.
It seems programs that use either HashMap or
OrderedMap objects won't run using the 2.x release of JGL
and Visual J++. They compile without complaint, but jview
aborts when executed.
- There is
apparently a problem with abstract classes implementing
interfaces under Visual J++. A replacement Map.java file
can be found at ftp.objectspace.com/jgl/Map.java. The source may
look a little strange from a Java perspective, but it
does solve the problem.
I updated the JDK to the final 1.1 release and I can
no longer compile the 2.0 version of JGL!
- When Sun
released the final release of the JDK, they removed or
renamed most of the classes dealing with collations,
causing a lot of compilation problems with the new
collation comparators in JGL 2.0. The new 2.0.1 JGL will
work with the final 1.1 JDK release.
If an OrderedSet is ordered, why doesn't it implement
Sequence?
- Conceptually,
a set is not ordered at all. A HashSet for instance
doesn't maintain objects in any particular order. An
OrderedSet does keep objects in a certain order as the
name implies, but does so to provide a fast method for
accessing them. A Sequence is designed to store both
objects and their position relative to one
another; a sequence need not be sorted. With an
OrderedSet, you have no control over the relative
position of an object; shuffling and sorting a set is not
a good idea, and doesn't even make sense. If you added
the Integers 3, 5, and 7 into an OrderedSet, the set will
internally be the same regardless of the order of the
insertions. With a Sequence, these integers may be stored
in any order. I guess the important thing to see is that
it is the "Set" part of OrderedSet that is
important; not the "Ordered" part. To
summarize, "Ordered" refers to the internal
storage mechanism and not the behavior of the collection.
When using Filtering.unique(), which object is kept
when a contiguous subsequence is found?
- The first
instance encountered will remain in the sequence. This is
also true for Filtering.uniqueCopy().
I can't seem to find an easy way to append two
sequences.
- Try this:
/**
* Copy the elements from one container to another container.
* @param source The source container.
* @param destination The destination container.
*/
public static void append( Sequence source, Sequence destination )
{
Copying.copy( source, new InsertIterator( destination ) );
}

Pair doesn't override the hashCode() method?
- As of JGL
2.0, it does. So stop asking!

Instances of PriorityQueue don't print in the correct
order.
- This is true,
a side-effect of how they are implemented. They will
always give the proper result when popped; just not when
printed.
If this behavior is not desired, change
PriorityQueue.toString() to read:
Array out = new Array( myArray );
Sorting.sort( out, myComparator );
Reversing.reverse( out );
return "PriorityQueue( " + out.toString() + " )";

What about the Mac?
- JGL will work
on the Mac using the standard .zip file. You need to
acquire a zip capable utility, and set your environment's
CLASSPATH. There is also a Stuffed version available for
1.1; 2.0 will be available in this format soon.
I'm having trouble unzipping JGL based on my shareware
version of PKUnzip.
- JGL uses
WinZip. An evaluation copy of WinZip is available for
free at http://www.winzip.com/winzip.
What happened to having the containers declared
'final'?
- User feedback
was overwhelming on this point. Users were willing to
give up the modest efficiency increases in order to allow
building of your own custom containers.
I'm adding instances of my own classes to a HashMap
and I can't retrieve them using get(). Is there a bug in
HashMap?
- The most
common reason for this is that you haven't overridden the
standard JDK methods hashCode() and/or equals()
correctly. Consult the section called "Storing
User-Defined Objects" in the "Containers" chapter of the
online user guide for more information.
Why are most of the JGL variables package protection
instead of private? Isn't this bad object-oriented
practice?
- The reason we
did this was due to bugs in the current release of Visual
J++ from Microsoft, which does not compile private access
properly. When this bug is fixed, we will probably return
most variables to the more appropriate private status.
However, note that package-level protection is still
sufficient to prevent users of JGL from directly
accessing the fields of a JGL instance.
HashMaps compare keys using equals(). How do I create
a Dictionary that only considers keys to match if they
are identical (i.e., match using ==)?
- You can
override the default HashMap (and OrderedMap) comparator
by supplying a binary predicate when it is constructed.
To obtain the behavior that you're looking for, supply an
instance of the binary predicate IdenticalTo. See the "Maps" chapter of the
online user guide for more information.
When I obtain an iterator from a HashMap using
begin(), it always returns Pair objects. Is there an easy
way to get the keys and values instead?
- A map's
elements() method returns an Enumeration over a map's
values. Similarly, a map's keys() method returns an
Enumeration over a map's keys. Alternatively, you can use
the key() and value() methods of a HashMapIterator to
obtain the iterator's associated key and value.