Intro/Question
I fear that frameworks in many cases have become a fashion or trend and are being abused. In many ways people are sacrificing speed just because they want to keep up with every single lib that comes out. I am for a more conservative approach that only makes use of new libraries and frameworks when it absolutely makes sense.
Related: When NOT to use a framework
Update/Disclaimer (May 18, 2017)
I’ve come to the conclusion that rapid application development, ease, and maintainability are the targets. So frameworks (new and old) should be used provided they help in reaching a final product quicker. Only when special cases exist (actual measurable performance issues) should we switch to custom code… or when the project itself is legacy and the cost of completely rewriting are too high.
Case
We have a Tomcat6 Servlet production that has been ongoing development since 2008 and there are many hours of work behind it. The code is very mature but it does not use any frameworks.
A new team member loves using frameworks and patterns for everything. Except for the love of frameworks, they also love cutting edge new releases and even proposed migrating from Tomcat6 to somethiong newer (JBOSS,GLASSFISH, or TOMCAT8).
I would never move a core production service to a container/server/web-server that just came out.
Not against refactoring code to keep it clean though!
I am against adding frameworks and patterns that add delay to production code servicing thousands of requests per second.
Serialization to stream (JSON/XML) while maintaining backwards compatibility
When a request comes, we produce both XML and JSON documents containing data related to the request params.
Since we maintain backwards compatibility for older clients changes must not break older support. Since we also support both JSON and XML, we make use of the Jackson but also KXML libraries.
For both formats we have 2 different serialization methods that use the streaming API. Except for being faster, I also find it is MUCH more flexible for maintaining backwards compatibility.
I like to use a sysyem of Major and Minor version. All minor changes to the backend that cause changes to the serialized document I add with IF statements in the serialization method. Once quite a few changes have accomulated (over 1 year), we add a new serialization method. So, all requests specifying version=1.00 to 1.99 are sent to serializeJSON1. All requests using version 2 to 2.99 are sent to serializeJSON2.
I’ve heard the argument that we should use ANNOTATIONS and MAP to objects.
I find this very distastefull as I have read streaming is the fastest.
The streaming API allows you to make necessary changes on the fly while MAPPING would require to store multiple versions of the same data as different objects, or jump through other hoops.
output.startTag(null, TagTable.PRODUCT);
output.startTag(null, TagTable.ID);
output.text(ID);
output.endTag(null, TagTable.ID);
output.startTag(null, TagTable.DESCRIPTION);
if (locale != null && Translations.containsKey(locale) && version >= 1)
output.text(this.DescriptionURL + "/" + locale);
else
output.text(this.DescriptionURL);
output.endTag(null, TagTable.LONGDESCRIPTION);
if (version >= 1 && version < 1.5) {
output.startTag(null, TagTable.POPULARITY);
output.text(String.valueOf((int) this.pop));
output.endTag(null, TagTable.POPULARITY);
} else if (version >= 1.5) {
output.startTag(null, TagTable.RATING);
output.text(String.valueOf((int) this.rating));
output.endTag(null, TagTable.RATING);
}
In the specific 3 cases above I really don’t see the point to replace working mature code with frameworks/libs/patterns that may add additional overhead and cost additional development time.
So, when is it worthwhile to replace working mature code with frameworks+patterns??
Comments?
Update: Some benchmarks
For the first two examples posted previously, using REST and HASHMAPs does not make overly that big a difference in performance but does make the code more readable.
Now for the more interesting issue about serialization when used in a hotspot.
Since the actual servlet in question had too much other code I made a toy example to test streaming vs mapping. The code is available at: https://stackoverflow.com/questions/21781540/
By all means test it, change it, run it.
What is very interesting is that the Just in time optimizer in java ends up making the difference negligable over time. So, here is how the percentage between mapping and streaming changes the more iterations there are.
Iter Stream Mapping
0 36,71% 63,29%
20 44,75% 55,25%
40 45,65% 54,35%
60 45,95% 54,05%
80 46,24% 53,76%
100 47,09% 52,91%
120 47,09% 52,91%
140 47,37% 52,63%
160 47,64% 52,36%
180 47,92% 52,08%
200 47,64% 52,36%
220 47,92% 52,08%
240 47,92% 52,08%
260 47,92% 52,08%
280 48,19% 51,81%
300 48,45% 51,55%
320 48,45% 51,55%
340 48,45% 51,55%
360 48,45% 51,55%
380 48,45% 51,55%
400 48,45% 51,55%
1000 48,72% 51,28%
2000 49,24% 50,76%
3000 49,24% 50,76%
4000 49,49% 50,51%
5000 49,75% 50,25%
6000 49,75% 50,25%
7000 49,75% 50,25%
8000 49,75% 50,25%
9000 49,75% 50,25%
I also re-ran one more time have first 20 iterations more detailed:
0 39,76% 60,24%
1 41,18% 58,82%
2 40,83% 59,17%
3 40,12% 59,88%
4 40,48% 59,52%
5 40,83% 59,17%
6 40,83% 59,17%
7 40,83% 59,17%
8 40,48% 59,52%
9 40,12% 59,88%
10 41,52% 58,48%
11 42,53% 57,47%
12 42,86% 57,14%
13 42,86% 57,14%
14 43,18% 56,82%
15 43,50% 56,50%
16 43,50% 56,50%
17 43,82% 56,18%
18 43,82% 56,18%
19 43,82% 56,18%
20 44,75% 55,25%
After 10,000 iterations (or calling JSON generation code 1000 times) here is the screenshot from VisualVM profiling (visualVM snapshot NPS file):
So, if this optimization behavior holds up in Tomcat servlets as well, it means there really is no point NOT to use mapping (and many other convenience functions/libs since the JVN will optimize over time).
Conclusions
Based on the answers/comments, I think at the end of the day whether to rewrite working production code is affected by business requirement, and specific cost-benefit analysis for each project.
Based on the benchmarking, it turns out avoiding some libs/frameworks may make no difference in the long run due to JIT JVM optimizations.
Update: After leaving code running all night
After 275,137 iterations and approximately 30,000 MS:
Mapping - 19,80%
Streaming - 80,20%
I really wonder what JIT optimizations happen here and whether the behavior holds for a servlet.
25
They say
a bird in the hand is better than 2 in the bush
Applied here, I take it to mean its better to have something that works and is maintainable than to tear it all down for some fantasy daydream of “but it’ll be vaguely better if we use X Y or Z cool new technology for the sake of using the cool new technology”.
I mean, you could have rewritten it in a functional language a few years ago, or Ruby on Rails a couple of years ago, or Node.js a year ago or… whatever comes along next that gets attention in the technical blogosphere. None of these things would create you a stable product that satisfies the ‘must use new stuff’ people as they will be considered old technologies before they’re even finished and they’ll want to re-rewrite!
So I have to ask “what’s your problem?”. You have good code that might be a bit mucky here and there, but in my extensive experience, when you start a big rewrite you end up with code that’s a bit mucky (often quickly implemented due to inexperience with the tooling or done under time pressure that you will come back to and fix up nicely, promise.)
When you use a framework is when you are doing a new project and you want a load of code written for you, that’s the time to go framework, to re-use all that boring boilerplate that you’d have to write yourself. You never go for a framework because its there to be used, especially when you have an existing framework that you know (even if you don’t call it a framework because its grown by itself, it’s effectively still one).
One thing to note, I do find a lot of the people who insist on using any kind of new technology want to for 1 of 2 reasons: they either want to boost their CV, or they do not want to learn the existing technology you use (after all, learning tech x is way more fun than actually doing work on existing product). I treat all calls with suspicion as in either case their intention is not in the best interest of the product or the business.
Heavy refactoring…that’s a different story, and usually a good one.
2
Ugh. Some points:
- “I have read it is fastest”. Don’t be a cultist. Think for yourself. Measure for yourself. Personally, if you’re generating XML by hand, I would question your sanity.
- who knows what bugs lurk It is foolish and shortsighted to fear what you do not know. This leads to “not invented here” syndrome and quickly being passed by programmers who had the courage to learn better tools.
- frameworks hinder performance Runtime performance is very often cheap. Programmer time is not. The trade off here is that these frameworks may add a slight performance penalty in exchange for saving you a bunch of time writing and maintaining the code. In the XML example, if you had used annotations and a serialization framework, you wouldn’t have to write and test your own XML formatter (read: cost your company all that money).
Look – code that is done and tested is good. And certainly, adopting a framework because “that’s what you’re supposed to do” is a good way to make bad software. But these examples strike me as simply you making excuses to avoid change. Yes, change is scary. Yes, change can lead to bugs. But change is necessary to eliminate inefficiency, and improve your ability to maintain and extend your code.
13