As a strawman consider the package java.util it is a dumping ground for various classes that in most cases do not share anything in common other than the person that put them there was lazy or uninspired to come up with a more semantically correct package name for their class.
As but one example, take the class UUID what would have been a semantically correct package name for that class?
I am working on implementing my own UUID class to be more lightweight. I do not want to use me.myproject.util.UUID for my package name.
I considered me.myproject.rfc4122.UUID but that does not imply the semantic of the use of UUID.
I also considered me.myproject.uuid.UUID but I do not like the tautology in that, even though it is a popular approach in Python to put a class in a module with the same name, and packages in Java are not semantically equivalent to modules in Python.
I also considered me.myproject.UUID but rejected it because I do not want to pollute that part of the namespace with things that are not related. This just moves the problem up a level.
I also considered me.myproject.lib.UUID but this has no more semantic meaning than .util and just renames the problem.
semantics : the branch of linguistics and logic concerned with meaning.
Best Answer
The problem with trying to put each class in a package which has a semantically correct name for that class is that it tends to lead to packages that contain very few classes, or sometimes even just one class. This in turn leads to a multitude of packages.
A more pragmatic approach to package naming is to simply help you find stuff. Keeping frequently used stuff that you always know where to find all bunched up in one place keeps them out of the way and therefore makes it easier to find the more rarely used stuff. So, you do not really need package names which are semantically correct for each one of the classes that they contain, you just need package names which are not semantically incorrect. Obviously, the 'util' package name was chosen according to this line of thinking: it is not the semantically correct name for the classes it contains, but it is also not semantically incorrect, and that's good enough.
So, if this UUID type of yours is destined to only be used by this specific application, (as evidenced by the fact that you are planning to put it under 'myproject',) then it is probably part of the 'model' of your project. You should already have a 'model' package, containing the set of all classes that correspond to your persistent entities, many of which probably have relationships between them, with UUIDs probably being the means of implementing these relationships. Also, your UUIDs probably know how to persist themselves, right? And also, your UUIDs can probably only be found as members of your model entities, right? So, your model package is probably the best place for it.
Otherwise, if this UUID type of yours may be used in other projects too, then it needs to be seen as part of some framework. So, it may live in the root source folder of that framework, or in some 'types' sub-package as MainMa suggested, or even in some sub-package of that framework called 'util' or 'misc'. Nothing wrong with that.