We Keep Coding

Controlling Class Visibility in Java

My project has currently following package structure.
Here I have added a package name utils and defined all utility classes related to this module inside it. Those have been used by other packages (i.e. impl, internal), and because of that I have made classes and methods in util package public.
Because, it is public, not only classes in this module, classes in other modules can also access this and when I am coding using my IDE they are shown as coding suggestions.
I went through few research papers which describe how this can reduce the usability of the API and give a bad experience to developers who involve in the development [ref1, ref2].
I understand that java does not allow me to make classes inside util accessible to impl and internal packages and not to others.
Is it correct to put my utility classes to a package 'util'? Or should I put all classes that communicate with each other to the same package?

You are correct, something marked public becomes usable in any other package. In contrast to other languages, Java doesn't provide any control beyond that.
A simple workaround: it might be helpful to have one special package containing those public things that should be available to your external users.
Meaning: create something like com.whatever.product.api - and instruct your users that they are fine to use everything from there - but nothing else.
In other words: you make all those things public that you need to public; but you collect those things in a special place that you allow to be used by others.
It is worth mentioning though that Java9 will introduce the concept of modules, those allow you to define which of your packages should be public to users of your module. In that sense, java 9 modules allow you to distinguish between "internal" and "external" public.

Util classes are fine. Util classes are functionality that is used multiple places in a project but doesn't really belong to a specific class.
In a perfect world of OOP there wouldn't be any util classes, but it is however considered a good practice to create util classes if they do not belong to a specific class.
Your options for access modifiers are listed here:
https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
There is one way to achieve what you you want, it is however concidered a very bad practice. You can change your access modifiers of util classes to protected. This will make your util classes accessible from subclasses and packages. So if a class needs access to one of the util classes, then it has to extend this util class and thereby become a subclass. I cannot stress it enought, this is a very bad practice.

Where to put my framework classes using package-by-feature convention?

I've been reading a lot about package-by-feature naming convention. So I've decided to give it a try in a new project. However, I'm not sure how it should be named my packages that will be used by most of my classes, since I'm using a huge framework, such as Spring and Hibernate, for example.
This is how handle our Spring contexts classes:
And our database access class, the one that manages connections and so on.
I've a draft about this: using a common package for these frameworks, like:
com.company.project.common.spring
com.company.project.common.database
But I'm afraid that this still looks like package-by-layer a bit. :)
How the packages that will be accessed by my feature classes should be created ?

The common recommendation is "package by feature, not layer". What I often do is "package by feature, then layer". I also think that top-level packages should be "feature"-based (functional components, whatever). But I also like to have my layers separated into sub-packages.
From my point of view, framework-related code does not per se constitute "features" (as in "important, high-level aspects of the problem domain"), therefore package-by-feature is does not make much sense here. But still, this is important code and you need an approach to structure it.
I am normally use two approaches:
If I need to extend or augment libraries I'm using, I structure packages parallel to the package structure of the library. For instance if I'd need to implement some new number formatter for Spring, I'll probably name the package com.acme.foo.springframework.format.number, parallel to org.springframework.format.number.
However if I need to implement common base classes for layers of features, this would be probably something like com.acme.foo.common.<layer>. For instance if we have com.acme.foo.<feature>.dataaccess packages for data access layer of some feature, com.acme.foo.common.dataaccess could hold base classes for data access layers of all features.
Both approaches are used in parallel. You just have to decide whether some class is a framework or library extension (can you imagine using it outside this project?) or is it closer to the layers of your project.

Java, Maven: Models and Utils Circular Dependency, Combined Naming Convension

We have a project that has several war files that reference one-another. I've recently realized that there is a circular-dependency between two, in particular, the utils and the models. Other services use both of these, and the utils was created for operations that would be performed on the models by other services. I was just curious what is best-practice here. Utils and models sound like they are companions to the main project, but I've never heard of a war file being called 'utils and models'... just seems strange.
Additional Info (not necessarily needed to answer the question):
To be more specific, the model uses the utils for it's type adapters, which allows MyBatis to convert timestamps to joda time. The utils uses the models, which I think is more acceptable, to do common operations on model objects.
Should I just combine both into the models war? What are some other options I would have. If I should combine them, is there some sort of design pattern that combines utilities and models together? What's the appropriate naming convention for a service that supplies both model and utility classes?

There are a lots of post on how you can remove cyclic dependencies like maven cyclic dependencies
But regarding utils a general advice is that utilities can be of two types in the sense that they are general or project specific i.e. if you are writing general utilities then those should not depend on any of your modules(they just perform general tasks) so should always come first in your reactor build order.
Secondly, for project specific utilities you can always do 'xxx.modals.utils' as in your scenario and these can easily consume your beans.
One more reason that general utilities(independent of your beans) should be kept in a different module is that they can be easily reused in other projects too. Hence you don't have to reinvent the wheel time and again!

I believe that the solution to your question would based on the view and experience and not a technical problem as such. I would suggest the following:
Go with Utils in same module if : Your Model classes' are not going to be reusable in other modules. In other words, if your Util classes is in relationship with Model classes only. It wouldn't make sense to split it as a module if your util classes are just designed for the specific model classes only.
Go with Utils in different module if : Your util classes are going to be generic. For example, your Utils classes are designed to convert the Model/Entity to Business Objects using some DataMapper like Dojo/Orika etc. That's coz, these util classes would not be tightly coupled to the Model classes as they would have the implementation to convert any type of Model to Business/Value Objects and vise versa.
This is actually been addressed by micro-services where you concentrate on loosely coupling the services which can survive independent of each other(like a plugin component).

Can we make a package as serializable

We implement java.io.Serializable when our class is acting as model class/passing on network and generally we keep all these classes as one package (Say model). Instead of implementing each class, why can't we make a package can be serialize-able?. Anyways we no need to worry about implementations as its a marker interface. I am thinking to make something like "auto-scan in spring".
Edit
com.mycorepackage.model is package where i have all POJO classes which are mapped to ORM (hibernate) and all classes here are java.io.Serializable. I want to make any class from this package is java.io.Serializable without declaring in each class. THINKING out of the box.

There is no way to do this in java since the technical feasibility is questionable.
Where would you write the code that communicates the message 'All classes in this package will implement Serializable'.
What happens when you include other jars that contain the same package but different classes ?
There is one way to implement it at the IDE level. Write a plugin that provides a menu option similar to Right Click -> Source -> Organize Imports on eclipse. That option organizes the imports for all classes under a tree. You can do something similar for classes that are of interest to you. Although I doubt the option would be widely used, it solves your problem.

Grouping Java classes

When I'm using Eclipse i work with lots of Java classes (especially when working with abstract factory design pattern) and I need a way to visually group classes belonging together (different classes extended or implemented from interfaces get mixed together).
I need a way to group classes that extend the same class or implement the same interface so I don't lose my mental health. I started using Eclipse and Java few day ago, so I'm sure I'm missing something to do what i need...

Have you organized your classes in packages? This is precisely what packages are for. If you organize them in packages, you'll have a nice view of the classes belonging together in the Eclipse Package Explorer.
Further reading:
The Java Tutorials: Creating and Using Packages

Import the classes into a UML tool of some kind. There are several free ones out there, including JUDE. Or see if Eclipse has a UML plug-in.

Eclipse has a very handy feature which allows you to see exactly which classes extend (or implement) any class/interface.
Select the superclass/interface/method you are interested in, and press CTRL-T. This will show a popup dialog with the implementing or extending class hierarchy. CTRL-T again will show the super class hierarchy (reverse direction)

You can organize your classes belonging to same event into different packages.for example: com.abc.birds should contain classes related to birds only.com.abc.human should contain all classes related to human only.