You are right, 8 parameters -all strings- makes the constructor a candidate for a code review.

Consider some of the next points.

### Essential attributes first

Look at the message model and guess what attributes are essential to initialize a valid instance. Reduce the number of arguments to the essential. Add setters or functions for the rest.

If all 8 attributes are required and read-only, there's not too much to do.

### Encapsulation

Consider encapsulating related parameters. For example, *A, B and C* might go together within a new class. It reduces the number of arguments at the cost of one more class. It might not seem a big deal but, it contributes to express better the model and the code reuse. No to mention readability.
Find out which parameters change together, at the same time due to the same reasons.

### Use [creational patterns][1]

Instead of initializing messages directly, do It from [factories][2] or [builders][3].

### Arrays

If none of the above works, try an array of parameters. Given the lack of meaningful param's names, it's probably the simplest solution. 

In relation to this approach (which I was reluctant to trust), I posted a [question][4] where I ask about its suitability. The answers helped me out to be less reticent, so check it out if you are reluctant too.

### Inheritance

Eventually, you will realise that messages are excellent candidates for inheritance. Segmenting messages by attribute generates a little overhead because sooner than later you find yourself asking for the type `if(message.getType() == ...)` all over the code.


  [1]: https://en.wikipedia.org/wiki/Creational_pattern
  [2]: https://en.wikipedia.org/wiki/Abstract_factory_pattern
  [3]: https://en.wikipedia.org/wiki/Builder_pattern
  [4]: https://softwareengineering.stackexchange.com/questions/353253/are-arrays-as-data-structures-suitable-for-constructors