paul nisset wrote:. . . Is it worth refactoring the app using some any of the new Java 8+ constructs ?
Only if you don't breach one of the greatest principles of software development:-
If it ain't broke, don't fix it.
What would be the benefits? . . .
If you can multi‑thread something easily with ...stream()...parallel()..., you can leverage the higher processing capacity of a multi‑core chip. But that will need some benchmarking to confirm.
And, as you say, you would learn streams and λs for future work. Once you get your hand in, it is easier to write a Stream than a for‑each loop, and if you are lucky, the stream code is much easier to read. Urma Fusco and Mycroft (which I am going to win so I can have two copies ) show some examples of loops versus streams.
Do you use anonymous classes? Find out how many of them use functional interfaces, of which I shall give you three frequently used examples: 123. Try replacing the anonymous classes with λs. See how much neater the code is with a λ, and explore the bytecode with javap and explore the classes folder with a file explorer and see what the differences are.
posted 1 week ago
Thank you for your perspective Campbell.
Not being broken is one of the main reasons I haven't refactored.
The initial design and implementation problems of the site far out way the performance issues of various constructs.
The examples of functional interfaces were interesting. Thank you for that.
What definition of "broken" and what definition of "refactor" are you using?
If you're using Martin Fowler's definition of refactoring, it means to "make the code/design easier to understand and work with." This would imply that the code is not actually "broken" in terms of working the way you want it to. However, with regard to understandability and ease of working with, then a lot of legacy code usually is "broken," so to speak, because it's usually difficult to understand, difficult to test, and difficult to debug. Is this a pretty good characterization of your code right now?
paul nisset wrote:
I'm thinking more of what the benefits would be for app performance or maintenance .
Be careful to separate "app performance" from refactoring. Refactoring and performance tuning might have some overlapping activities but their goals are entirely different. Performance tuning is about improving the use of computing resources. Refactoring is about design and maintainability. Again, the goals are very different so try not to conflate refactoring with performance tuning.
As far as using newer features, I would use Kent Beck's Four Rules of Simple Design as guidelines. If I can refactor so that using new language features makes the code more testable, more expressive (which lambdas and functional style code certainly can, if used prudently), eliminate duplication, and reduce the amount of code I have to test and maintain, then I would think there's some benefit to doing it.
While I totally agree with Campbell about "If it ain't broke, don't fix it." and this is pretty much my approach too. But off-lately, I have a slightly different mindset.
Does the application have a very thorough and working functional test plan in place that covers all usecases ?
If yes, then the whole app codebase is your playground do as much as refactoring as you wish since you are able test your changes.
If no, then you will have to take that step first and write test cases first for all the code that might be affected by your refactoring so that you know that it works before and after your refactoring.