4 ms·

> Also, I think you may have misunderstood what this feature... No, I am aware of the differences between StringBuilder and string templating. One of the most

> Also, I think you may have misunderstood what this feature... No, I am aware of the differences between StringBuilder and string templating. One of the most common usage is concatenation (e.g. toString() methods). Sometimes it's cleaner to use StringBuilder instead of + operator to do that. And templating will be mostly used for concatenation. All I am saying is, it could be simpler. I read the full JEP before my first comment. I frequently do Python and did little bit of Kotlin before. I guess that's where all this is coming from.

pron 3y ago
> And templating will be mostly used for concatenation. Whether it will or won't, interpolation is not the reason for the feature, so clearly that's not the use case that should be prioritised, especially as it's been recognised as an exceptionally dangerous use-case. The starting point that we must in no way make string interpolation, which is known to be dangerous, any easier than using safer template processors. This feature was created (among some other reasons) to solve the severe security problems created by string manipulation, not to make string concatenation -- which is already pretty easy -- easier. As the JEP explains, after a lot of thought the decision was not to offer string interpolation as a language feature and go for string templates instead. Saying that the feature doesn't accomplish well the thing it explicitly doesn't try to accomplish is really not saying much about the potential of this feature. Making string interpolation as easy as it could possibly be was not only not a goal of this feature, but the very thing it was designed to avoid given how dangerous that is. On the other hand, consider that you can now safely embed HTML templates in Java code. > I frequently do Python and did little bit of Kotlin before. I guess that's where all this is coming from. In this case, as in many others, we studied what many other languages did, incorporated what's been learnt about code injection vulnerabilities, and did what we believe to be a marked improvement over other languages' features, at least as appropriate for Java's users. You may disagree, but a lot of thought has gone into the design by some of the world's most accomplished language designers as well as user testing, and so I don't think speculation trumps that. If further experience shows that we got it wrong, it can be fixed.

pron 3y ago

> And templating will be mostly used for concatenation. Whether it will or won't, interpolation is not the reason for the feature, so clearly that's not the use case that should be prioritised, especially as it's been recognised as an exceptionally dangerous use-case. The starting point that we must in no way make string interpolation, which is known to be dangerous, any easier than using safer template processors. This feature was created (among some other reasons) to solve the severe security problems created by string manipulation, not to make string concatenation -- which is already pretty easy -- easier. As the JEP explains, after a lot of thought the decision was not to offer string interpolation as a language feature and go for string templates instead. Saying that the feature doesn't accomplish well the thing it explicitly doesn't try to accomplish is really not saying much about the potential of this feature. Making string interpolation as easy as it could possibly be was not only not a goal of this feature, but the very thing it was designed to avoid given how dangerous that is. On the other hand, consider that you can now safely embed HTML templates in Java code. > I frequently do Python and did little bit of Kotlin before. I guess that's where all this is coming from. In this case, as in many others, we studied what many other languages did, incorporated what's been learnt about code injection vulnerabilities, and did what we believe to be a marked improvement over other languages' features, at least as appropriate for Java's users. You may disagree, but a lot of thought has gone into the design by some of the world's most accomplished language designers as well as user testing, and so I don't think speculation trumps that. If further experience shows that we got it wrong, it can be fixed.