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 for the rest.

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

### 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.

### 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 to this approach, 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