since programming is at its core a combination of data structures and algorithms,
and since the java language is the most robust language ever to hit the programming
planet, i think it would be a real plus if some of its core libraries or utils developers
though of the following stuffs.

graphs : - graphs are the core of most of the advanced applications on the planets
and even for simple ones, they are their super sets, e.g a linked list is a type of graph,
but sadly there's no native java graph primitives.
would be so nice to have.
Algorithm books are full of graph topics yet java doesnt deem it fit to make it available,
how odd.

more robust hash maps.
At least java is ahead of some other languages that provide very little utilities in this
respect - some give you an array and a list and that's all.
but java's hashmaps, could be expanded some more e.g
multiple key hashing to same value- this would be really nce to have.
work arounds for these can be very messy and tedious to hand code.

equal-bases-hash-maps.
-----------------------
for a name to call something like this.
this would be not so easy to define as a hashmap that is defined as A maps to B.
but the real world is more complex,
sometimes and object maps to a universe of other objects,
with this kind of container- you throw in one object thats belongs to a set,
and the result returns any other object in the set (but not the entered object)
- examples in real life.
synonyms - in english.
a word like steal, is in the same bag with pilfer, rob, shoplift, loot etc.
and yet they are all similar , so someone who doesnt want to use the cliche'd
'steal' may throw into the container holding the others and get a different
but equivalent word.

table type:
--------------
this type of data structure is so long over due, that i wonder why
a real primitive hasnt been put in the util package.
tables are all around us,but its implementation is still done via
hash table constructs,
multiplication tables - database tables, excel spreadsheets, mileage-distance tables,
etc.
this is like an expanded hashtable/map but its built to be able to use by
lay programmers who must tabulate data.
there's so much 2D data around us that a table primitive ought to be
a commodity not hiding away as a model for a gui.
imagine a multiplication table,
where you could cut - out a subtable. say the table is a square with
9 by 9 dimension and you want the sub table from column 3 to 7 , making
a 4 by 4 subtable, cumbersome to hand code - but zooming and minimizing functions
on the table really really is an application of this function.

Graphs are not a basic part of programming though. Anyway, java has some third party graph libraries. Google em.

Table is just an array of arrays. Most languages have this facility.

to the last poster:

it's all about convenience.
Strings are just a 'mere' collection of characters- they can be represented
as an array of characters.
C treated strings as such, erlang and haskell treat them as such
and both languages (erlang,haskell) have come under heavy criticism
for their crudeness in this respect.
Any programmer who's programmed with String objects doesnt want to
return back to manipulating an array of characters.
Same thing should go for table types.
whatabout when tabular data gets into more than 2 dimensions,
which would be easier, manipulating a 3 d or 4,5 d array or manipulating
a single table object?
This data type is begging to be created !
and should.
All java provides is a crude data model for gui's - jtable model-
i'm talking of a generic table object- that resides in the java.util. library.

e.g of tabular data -
in this programming section sb talked about creating a cgpa calculator-

a table (that can have pre-canned algorithms applied to it can handle this very easily)

without tables - a programmer will resolve to linear solutions.
i.e 1) create a template - describing the equivalent of row1 of a table.
e.g
class studentData
{
courseCode:
qualityPoint:
creditHours:
Grade(char):
}

courseForm<studentData> //collection of records,
then the algorithms will be applied to the courseForm.
or courseList.
e.g
cgpa = sum of gradePoint/sum of credit hours

but a table can handle this.
--
stock markets
----------------
creating a stock market app will necessitate the redundant templating
that goes into making the student cgpa data app,
a template will be created - representing the tables first row-
algorithms will be applied - sth. that can be abstracted,
the list goes on and on.
A table data type is long over due.

The point is that, some features are used more frequently than others. People obviously don't spend as much time writing code involving graph algorithms as they do writing code processing strings.

When designing a standard library, presumably you should include things that people spend most of their time doing. Not things that represent a tiny fraction of programmer's time.