Adding a byte array converter

[garcia-jj]

Useful for applications that uses cryptography, to reduce window size of String polling when work with passwords.

[Turini]

is there an use case which you need to get a byte array in the controller?
I can't see this as a global need, so I'm not sure if it should be added to core
what do you think? isn't it too specific?

[garcia-jj]

In the pull request description there are an example. Of course threre is not too common used like Integer or Long, but can be used as we have ByteConverter or CharacterConverter. I have two applications thar uses this converter, and in the next week another app. So I think can be useful for our users.

[Turini]

I'd vote to wait a little more users asking for it (maybe here, after seeing this pr)
that's because I've never seen someone asking for it on vraptor's mail list or something
you can easily package this converter in a jar that can be shared on your apps

[garcia-jj]

Really your are ask me to share a jar with my apps for a simple converter that can be useful for some users, that won't disturb anyone? There is a lot of very useful and valuable features never asked in the mailing list, but I contribute (and suggested) to vraptor, and now users love it. So its too hard to me to understand your arg. I can understand when I suggest a dangerous feature or behavior, but not a simple component like this.

[garcia-jj]

I think I have a lot of valuable contributions for vraptor, over 6 years, 2 thousand commits, so I'm a good user too suggest new features like this. I have a lot of applications using vraptor, and all my contributions and suggestions are based in these applications.

[Turini]

No need for this, garcia. I'm just providing my option/vote, it doesn't mean your contribution aren't valuable or something like that. This kind of reaction isn't healthy for the project. If anyone else upvote this pr, I'm ok merging it. I'm just suggesting to wait a little more before merging, since IMHO it's 135 lines of dead code to (guessing) 99% of our users now.

[rponte]

Relax, guys!

by the way, I can't imagine a case where I could use this feature.

Otavio, could you give us some use cases for this feature?

[garcia-jj]

@Turini Maybe you don't see, but you are too hard to me in your comments, like saying my contribution is 135 lines of dead code. And this action makes me think to giving up contribute to vraptor, to avoid this kind of feeling. It is very important to you look beyond the horizon and see that even if you have not used in your projects, others can use and have these needs. As I have many applications using vraptor, I just try some needs before someone have the same needed.

[garcia-jj]

@rponte There are an example in the pull request description. I can't provide more information about the application due a NDA.

But I have some applications using a hard cryptography. Since Java Strings are immutable and shared by a pool, we need to use password as String so less time when possible. Using byte array or char array as good pratice when we are using a hight security, because we can override the values when we want, and Strings not.

Without this converter, in any method I need to use byte array I need to inject EncodingHandler to do something like this:

public void foo(String passwd) {
   Charset charset = Charset.fromName(encondingHandler.getCharset());
   byte[] passwdArray = passwd.getBytes(charset);
}

So this converter can save too much work.

At this time we have ByteConverter, CharacterConverter converters, and also for primitive types: PrimitiveByteConverter, PrimitiveCharacterConverter. Why these converters are useful and byte array isn't?

[garcia-jj]

since IMHO it's 135 lines of dead code

I'll close this pull request without applying, since in the opinion of project leader this is only 135 lines of dead code.

Thank you.

[lucascs]

I don't think this is dead code, but I don't agree with the implementation.

In my experience coercing bytes that are not text to String and back can lead to all kinds of nonsense and hidden bugs (forget about encoding in one place and you're doomed!). It's very hard when you know what you're doing, imagine how it could confuse users.

One good way to do this is to use Base64 or Base32, so there is no room for encoding problems.

What do you think about changing this PR to use Base64?

[csokol]

Hi @garcia-jj, notice that @Turini didn't mean to say that your whole PR is dead code. It was just a way to say that he believes that most of the users won't use this feature, so it would be as if this was dead code for those users. Probably he haven't used the best words to expose his idea, but that's what can happen when none us is using our mother language :-)

I think that PR's discussions like that are the best place to improve our skills and we should try to learn as much as we can from them instead of just arguing what feature should get in or out.

[Turini]

I've oppened #1043 to track lucas' suggestion. Thank you guys.