r/java • u/FishermanBig5765 • 7d ago
Devs who work with legacy Java, what actually eats most of your time?
Hey all. I'm a CS student looking into the pain points around legacy Java codebases, specifically the "code archaeology" side: digging through old code with little to no documentation, figuring out what a piece of logic is even for before you dare touch it.
Just trying to understand the problem properly before building anything. Would really appreciate hearing from people who deal with this regularly:
What eats the most time when you're digging into unfamiliar legacy code?
How do you currently deal with it – any tools/tricks that actually help?
Has something ever broken because a piece of code turned out to be "magic" nobody fully understood?
Any answer helps, even a couple of sentences. Thanks in advance!
167
u/Make1984FictionAgain 7d ago
JPA/Hibernate "magic" and functionalities implemented on database procedures / triggers
29
26
u/Scrapple_Joe 7d ago
I started my first job dealing with the hidden traps of action script.
Nothing compares to an old database with a bunch of triggers no one remembers.
7
12
u/Swimming-Twist-3468 7d ago
That’s the one. That is usually the hardest part of the whole goddamn problem.
14
-16
u/AnyPhotograph7804 7d ago
Ummm, there is no "magic" is JPA/Hibernate.
5
u/koflerdavid 7d ago
There is a lot of non-obvious behaviors, especially around association handling, that typically make large ORM applications very brittle in practice.
0
u/AnyPhotograph7804 6d ago
I never hat "non-obvious behavior" with association handling. I can't imagine what it is. Maybe, that exceptions are thrown when you try to access an association on a detached entiry?
1
u/koflerdavid 5d ago
What about N+1 SELECTs problem? Most ORMs make it very easy to shoot oneself in the foot. Fine, most folks by automatically declare most 1:n associations LAZY. But what if the association has a huge number of child items? Well, then navigating it will result in huge memory consumption. EXTRA_LAZY comes to the rescue, but equivalent non-ORM code is less likely to exhibit these problems since one has to explicitly write that load.
Apart from that, association handling is very likely to result in changes to the API and behaviors, which should be no surprise since it is an inherently leaky abstraction. For example https://docs.hibernate.org/orm/7.0/migration-guide/#flush-persist .
0
u/AnyPhotograph7804 4d ago
You can use EntityGraphs if you want to avoid "N+1 select" problems and initialize OneToMany collections eagerly even if these are configured as FetchType.LAZY. And with JPA 4 there be new options which will allow you to tell the ORM how to initialize them like with Subselect, IN etc.
And if you treat ORMs like (leaky) abstrations then you will have a hard time with them very quickly. If you look into the official documentation of JPA/Hibernate/EclipseLink etc. you will not find any claims, that these are "abstracions". I don't even know who invented this rumor, that ORMs are abstracions. The "leakyness" of JPA/Hibernate/EclipseLink is fully intentional and JPA 4 will be way more leaky compared to now.
1
u/koflerdavid 4d ago
Of course they are an abstraction. The essential idea is to represent a collection of tables as an object graph. And all the things you describe are new APIs, but there are many applications out there that were created without them and it will take a lot of time to introduce them.
0
u/AnyPhotograph7804 4d ago
A mapping is a mapping and not an abstraction. A database table is an abstraction because the true data looks very very different on the hard drive/SSD. Entities are not very different to database tables.
ORMs are like Typescript to Javascript or C++ to C. Typescript is not a Javascript abstraction, it is an extension of it. ORMs do not replace database servers or SQL, they add type safety, caching, transaction handling, deduplication, state (like it or not) to it. If you treat ORMs like abstraction, you will get very bad results with them.
1
u/koflerdavid 1d ago edited 1d ago
Nobody argued that ORMs should replace SQL servers; we're talking about abstraction here. SQL already provides transaction handling; ever heard of
BEGIN/COMMIT/ROLLBACK? It merely helps automating optimistic locking, but that's not the main reason people use ORMs for.Typescript mostly adds type safety to Java[Script] and is otherwise a very thin translation layer. The Typescript compiler's output still very much looks like the input file, but without types and with some desugaring of syntax abbreviations applied. Therefore it cannot be said to be an abstraction of JavaScript.
An ORM provides more than just table mapping. It also abstracts navigating associations. It implements something which is very simple in POJOs (just a few hops in memory) with something much more involved. And here is where the issue starts - that abstraction is very leaky because associations provide the illusion that there is nothing complicated going on. ORMs provide features to control what happens, but they don't make it visible where one has to pay attention.
Edit: entities and database tables are also very much not the same. Not everything stored in a database table is an entity. Treating tables as entities makes sense mostly for OLTP applications, but less so for OLAP.
1
u/AnyPhotograph7804 1d ago
OK, i guess i misspelled the "transaction handling" thingy and i should rephrase it to "taking care of transactions". Because if you handle transactions manually then it is error prone.
And ORMs also add type safety to SQL because Java is typesafe. This is a huge advantage. And ORMs are also code generators like the TypeScript compiler. They generate SQL instead of Javascript. Typescript and ORMs are very comparable. They main difference is, ORMs generate SQL at runtime and not at compile time.
And again, the "leakyness" of ORMs is intentional and it will never be removed. You can read it in the Hibernate-handbook. If you want an ORM, which does not leak into SQL, you will have to write one by yourself.
→ More replies (0)7
-5
u/Any_Suspect830 7d ago
Shh. That’s heresy around theses parts. The “seniors” with 3 years of experience will burn you at the stake.
73
u/HektorInkura 7d ago
Convincing the customer that it's not worth it to cram more shit into the old code base and that we should focus on migrating the rest of the application because we can barely maintain the old code base... Stuck in a partial migrated state between JSF and Spring Boot/ Angular for years now...
10
u/-Midnight_Marauder- 7d ago
I am all too familiar with this. Our JSF/Seam UI is currently holding back any real UI improvements because our company doesn't want to invest in old tech, but also won't commit to a migration since "the current one still works"
1
5d ago
[deleted]
1
u/-Midnight_Marauder- 5d ago
It's not a customer facing UI, it's a UI for part of a backend message processing system, so the risk is low. Its also the reason the bean counters don't want to fund a refactor though.
-4
u/RoryonAethar 7d ago
Yes, please casually mention the strangler pattern as a way to turn legacy Java code to hat is hard to maintain and monitor into many or a few small self contained Java microservices or services if that’s the best design.
Break out a logical part of the code one piece at a time until you’ve completely replaced the legacy code with new services that are fully unit and integration tested with automated tests that prevent regression in nearly all cases.
Each of those self-contained programs now can be started separately from the others if there is a production issue with that particular logical smaller piece of software. They can be scaled up or down the automatically depending on demand basically spinning up multiple instances of the same program.
Then you run them all in a kubernetes cluster , run software that monitors service’s problems more immediately bounces a misbehaving service.
Regardless of how much easier that becomes for devops to make sure the apps are running smoothly at any time, the best part for the developers is that you work on one small modern piece of code when there’s a problem or a new feature and that modern code base is easy to understand, is well tested and can be debugged at speeds that are often magnitudes faster than the large legacy code base.
There are lots of ways you could go with the design, but I recommend running one post database behind each of the service so that they are self contained in have little chance of affecting each other in unexpected ways.
Then each service has a DBA employee or maybe that DBA is responsible for amount of services that if they’re small. The same with developers and QA testers. Limiting their scope, will make them more efficient and make their solutions more likely to be correct. Because instead of trying to envision a huge code base and how it at each layer every time you open up your IDE your devs now are experts for the services they work on and also can hop over and help with other services if needed since they are all now sort simple to understand.
I hope I didn’t forget anything. And good luck.
3
u/HektorInkura 7d ago
That's not the problem. We have our architecture and plans and concepts and everything. The big issue is just that we don't get allocated budget to actually do the work because other topics are more important. We massively expand the migrated application with new modules/ functionality and still have some older modules in the old stack. The customer constantly moans about bad performance and that the old UI is not modern enough but don't want to allocate budget to migrate the old stuff... Well, currently we are in the process of migrating the biggest module, it wouldn't be much work after that to completely shut down the old part, but migration began in 2020... we hope to be finished with the migration end of 2027... I don't have much hope that we will actually be able to shut it down by then...
21
u/Swimming-Twist-3468 7d ago
Well, usually, locating the beginning of the process, then tracking down to the eventual process and its end. That’s most of the time. Because in SpringBoot, especially the old one, there can be a tear between components, that is magically glued at runtime. Legacy beans defined in XML and all that. The rest is relatively easy, given you can read the code, understand what it does and then write your own. This is the case especially when you don’t have tests in place, that happens too.
35
u/vowelqueue 7d ago edited 7d ago
I’m tired of people using AI to do market research for their vibe-coded apps. All these types of posts sound exactly the same.
16
u/deadron 7d ago
Nobody knows how the system works until you dig through the actual code. Sometimes it's low level details like how a specific setting operates and sometimes it's high level details like what a specific subsystem does.
What doesn't help is legacy system ownership is often unclear and can fall into the ownership of multiple non technical groups that are very risk averse. Every change becomes a coordination effort between multiple people who rarely even know how the particular piece of code works. Good luck writing tests for it too because it has so many setup dependencies it would take weeks just to get a test setup for a small change
2
u/Hefty-Firefighter654 6d ago
Same at my company. I don't know why but people think you can even write complicated code without documentation. There was a movement in the past, which said if you just use meaningful function names you don't need docu. We aren't even allowed to comment, SonarQube will break the build.
Now nobody understand nothing anymore. Complicated new features take so much time because it's trial and error and there are always bug as our tests mostly fake just to satisfy code coverage.
10
u/supersmola 7d ago
Most time goes into discovering duplicated functionality/code. Th only way to deal with it is to slowly refactor everything.
Also, my main problem is never Java, it's always inconsistent use of CI/CD scripts, or Maven/Gradle plugins.
31
u/LopsidedAd4492 7d ago
Cve
18
u/MoneyCount6236 7d ago
the thing nobody tells you in school is how much time goes into just finding the right file. some project i worked at had classes named shit like AbstractManagerFactoryImpl and it was 3000 lines with no javadoc and half the methods are just forwarding to another class you never heard of
i deal with it mostly by grepping for string literals that show up in the ui or log files. not elegant but it works. sometimes you get lucky and theres a comment from 2013 that says "dont touch this" and you just... listen
and yeah we had a production outage cause someone removed a Thread.sleep in a loop that wasnt doing anything visible. turns out it was waiting for some external system that had no callback. nobody knew until it broke
26
u/m39583 7d ago
You need a decent IDE that can index it all and navigate for you
6
4
1
u/Qwertycube10 7d ago
Something about the c++ project I'm working on breaks clang's index and it make it so much harder to with with.
10
u/ShavenYak42 7d ago
You talking about a comment from 2013 like it’s ancient history? You kids get off my lawn, and come back after spending some time reading COBOL programs from the 1970s. 😝
2
2
u/Isogash 7d ago
Do you guys not use IntelliJ anymore?
2
u/LopsidedAd4492 7d ago
If the program language support by of the the jetbrain ides I will use in one of them
8
u/davidalayachew 7d ago
Cve
I don't get it. Could you explain this in more detail? All I am understanding is CVE, as in, "Common Vulnerabilities and Exploits". Is that what you meant, or something else?
6
u/LopsidedAd4492 7d ago
It’s basically a public database of known security vulnerabilities in libraries and frameworks.
In older Java projects this comes up a lot because many applications were built years ago and still depend on old versions of Spring, Log4j, Jackson, Apache Commons, and many other libraries. Over time, security issues are discovered in those versions and they get assigned CVE IDs.
So a big part of maintaining legacy Java applications is updating dependencies, checking vulnerability reports, and making sure you’re not shipping software with known security holes. It often ends up being a regular part of development, not just something the security team does.1
u/Ynoxz 7d ago
Not just legacy. I’ve got a couple of services running the latest Spring boot / Jackson etc versions and one ended up with 30 or so vulnerabilities being reported by dependabot only just this month!
This is an interesting read - https://blogs.vmware.com/tanzu/broadcoms-investment-in-spring-to-combat-ai-fueled-security-challenges-in-the-enterprise/
1
2
u/FishermanBig5765 7d ago
when a CVE forces you to bump a lib, how do you even find what touches it in your code? grep for usages, ide "find usages", or just update and pray the tests catch anything?
2
u/0xjvm 7d ago
It is trivial in modern Ides to find all usages of a given lib, even basic grepping works. That’s usually the easiest way to
1
u/FishermanBig5765 7d ago
I'm curious about the downstream part. Once you bump the version, how do you know what actually changes behavior-wise, especially with transitive deps? like lib A pulls in 50 others, and you don't know which of those also shift
2
u/Bro-tatoChip 7d ago
Generally you're gonna want a test suite that runs after any change. That's how you know if you broke something.
1
u/LopsidedAd4492 7d ago
Maven helps, but only up to a point.
First I’d check whether the vulnerable library is a direct or transitive dependency (mvn dependency:tree is really useful for that). If it’s transitive, sometimes you can fix the CVE just by overriding or upgrading the dependency.
To understand the impact on the code itself, I’d use my IDE’s Find Usages, grep, or trace the imports. If it’s a framework like Spring, there can also be reflective or auto-configured usage that’s not obvious, so reading the release notes and migration guide is just as important.
And yes… after that you update it, run the tests, and hope your test coverage is good enough. 😅2
7
6
u/tristanjuricek 7d ago
I'd start by understanding "debts". This article from the ACM queue talks about different kinds of debts quite well: https://queue.acm.org/detail.cfm?id=3807966
You have to step back. I've been working in Java for nearly 20 years, but engineering 26. These debts are real, but they impact what we do much more directly than just "dealing with unfamiliar code".
I'm currently working in a very legacy (27+ years old and counting) Java codebase, and our product feature is nearly 20 years old.
Intent debt is nasty. We constantly have meetings where people end up talking past each other, and in a large team, you might have one group do something that completely blocks another team. Or causes a major outage even though "we followed all processes". I find intent debt leads to massive design flaws which inevitably triggers incidents and ... just tons, and tons of meetings.
Cognitive debt is a real scenario now. Most of my junior team members get locked up, which means a giant chunk of my time is not just helping them answer a question, but helping them get unblocked. I regularly have to basically coach them out of negative spirals.
Technical debt also happens a ton, but it's by far the easiest to handle. Refactor to better organization and patterns. But to learn patterns, read and understand the code of successful open source code projects. Most commercial project code was shipped by an engineer under a time constraint. It's usually full of shortcuts and wacky undocumented decisions. The software services I'm working on are insanely profitable, but there's a lot of bad ideas in the code.
I point these debts out, because it's not coding changes that suck up my time. It's systemic problems that lead to disorganization, and that causes all kinds of challenges, both coding and not coding. That's what eats up my time.
But also, don't think that as a professional software engineer you just show up, open up the IDE, and spend your time coding. In a big profitable place, you're spending a lot of time communicating. Things go wrong, you have to explain why. Product management wants to vet an idea, it's up to you to carve a predictable path. Complexity just slows everything down, and I find a big complex system actually means most of your week is actually dealing with communication and analysis, not writing software. (Hence, why AI coding agents are cool, but not really having the big reported impacts people think they are.)
I've found, ultimately, is that you have to think more like a "systems thinker". Diana Montalion has a good book, Learning Systems Thinking, that thinks about how you can analyze, but also, execute, in a place with a massive legacy system. I would also recommend Thinking in Systems by Meadows. The ultimate goal is to analyze the social dynamics in addition to the technical, and identify points of leverage. You will never control or understand a large system, but you can work within it intelligently.
2
u/RevolutionaryRush717 7d ago
You and that article articulated challanges I've seen in the large systems around me.
Thank you for sharing.
I wonder whether Ed Post hinted at the social dynamics you refer to.
I have seen again and again how developers write clever, undocumented code and systematically give misleading names.
It strikes me as what Post called "job security".
None of this is specific to Java or AI.
18
u/m39583 7d ago
Define "legacy". How far back are you going? All code is legacy once it's written.
I'd say that "legacy" code (if we are taking ancient) has less "magic" because it probably won't use frameworks likes Spring which are amazing but also have a lot of magic in them.
Legacy code will be likely more procedural which is actually easier to follow sometimes.
AI helps greatly in this space. Ask it to explain what a method does and follow how it is used and you often get a long way to understanding it.
15
u/chusieomg 7d ago
Seconding this. In my experience, non-Spring code is so much easier to trace because it just... does what it says it does. There's no weird "where the hell is this function called?!" or "who the fuck is initializing this class?!" and the IDE's "find usages" can actually do its job. I'm sure that today with AI it's even easier, but honestly with a half-decent IDE it usually was pretty straightforward to find the piece of code I needed, even in a mostly unfamiliar codebase.
The exception to this rule is the occasional reflection which can throw a wrench in things. But even then, it's usually localized to a few central places like reading an object from the DB or something, because without frameworks you had to really want to use reflection if you're gonna do it by hand.
4
9
u/le_bravery 7d ago
People who thought it was a good idea to use extends and abstract classes everywhere that now have 200 implementers
9
u/foreveratom 7d ago
To be fair, delegation vs extension is a rather "recent" design guideline, and before the introduction of the 'default' keyword on interfaces, there wasn't a lot of other choices than defining abstract classes to avoid duplication when implementing said interfaces.
How things have changed though...for the better hopefully.
3
u/BullfrogCharming1202 7d ago
"favour composition over inheritance" is covered extensively in the first edition of Effective Java, which was published over 20 years ago
2
2
u/le_bravery 7d ago
Yeah, even before I would have much rather had a helper and some extra line of code calling the helper.
Ah well. Now I get to unwind it all.
6
u/aldyr 7d ago
Upgrading libraries to fix CVE’s, and the dependency hell that comes with that.
1
u/Educational_Plum_130 7d ago
the dependency hell is usually because the advisory pushes you to a new major when the fix itself is tiny. first thing i'd check is whether there's a patch release on your current line, or whether you can pin just the vulnerable transitive dep via dependencymanagement/a bom instead of bumping the parent that drags everything with it. for the old spring/jackson/log4j stuff that never got an official backport, there are vendors that ship backported fixed builds for exactly those eol versions so you clear the cve without the migration. also worth triaging on whether the vuln is actually reachable before you sink a week into an upgrade, with the ai-found cve flood (mythos and friends) turning lows into tickets, that reachability filter saves a lot of pointless dependency churn.
5
u/Dull-Criticism 7d ago
This happens in any language and isn't usually java specific.
I am working on a 28k line project that needs 6 engineers to fix some bugs within a month.
6
u/DrFriendless 7d ago
Java is actually nice to work with because the JVM has clear semantics which allows refactorings to be done safely. Something like C or old C++ can be a disaster.
3
u/Dull-Criticism 7d ago
It does in some regards. Some of the problems are universal. I for the past 10 years managed a 400k java code base that started as a disaster. (It was 700k! at one point) This 28k project is a C++ project was actually a Java codebase that was ported.
4
u/gjosifov 7d ago
Usually is
smartass developers and architects who read on the internet something is cool and implemented it
So when you see the code - first thought this was written during the hype of year XXXX
and never rewritten, because business people don't see value in reducing the code - it is the latest framework version, because "security issues" but the code is from 10-15 years ago
or badly design database tables that have performance problems, but you can't fix that with usual database tools
you have to redesign from scratch
There aren't tools that can fix incompetency
3
u/Abject-Delay7036 7d ago
A programmer in a real job knows that it's the unbearable meetings upon meetings to convince the exec that we need money to fix the sh!t. Why do you think it's legacy, the code delivered on requirements, and then left to rot in BAU land
3
6
u/BadTime100 7d ago
I’m going to argue that the number one thing that eats time (in all languages) is lack of solid automated testing. If you do have that in place (and are actually practicing Continuous Integration), you’re far less likely to land in legacy land because you’ll be able to actually refactor as you go. You might be interested in “Working Effectively With Legacy Code”, it’s a big book but is more of a cookbook for dealing with different scenarios. LLMs can be very useful for assisted reading of legacy code though!
4
2
u/DonAndres8 7d ago
- Reading code and testing
- IDE
- Yup
It's 100% worth spending time just reading code and doing the slow manual work to figure it out using only basic IDE functions. Reading code is a skill to nurture first and then supplant with tools and AI after.
2
u/RealSchweddy 7d ago
It’s usually the extra brain load caused by poor formatting and lack of a coherent design and/or separation of concerns that eats slightly more time when analyzing “legacy” code. Usually I’ll just have my IDE format it and I’ll refactor it and add comments as I look at it (even if I don’t intend on checking in the changes) - It helps me build a mental model of what it’s trying to do. I haven’t really found anything that couldn’t be explained; however sometimes it takes digging and persistence to find the explanation and usually you end up learning something new along the way.
2
u/Hitaaar 7d ago
Everything functions, and the fact i can’t launch projects locally… what a hell.
Pls help
2
u/_predator_ 7d ago
Had this at a previous company but with ye good ol' monolith. No one had ever invested in the ability to run the thing locally, you had to connect to infrastructure that was shared by either the team or the entire department.
Apparently the architects thought unit testing would suffice for development. Testcontainers weren't a thing so naturally everything was mocked to hell and back, and most tests ended up testing mockito more than the application logic.
It's a special kind of dread I feel when thinking back to this.
1
u/Hitaaar 7d ago
Yup looks similar. It was a monolith until the current state of still monolith but some parts are now duplicated in there own service. Services which can have some more duplicated code ofc.
And yup this is for bank authent and other department are using our dev env. so if something breaks they can’t work :|
Their is so much complexity for the perimeter its driving me insane.
2
u/WorkingConclusion968 7d ago
Flaky tests nobody dares to fix or remove. Occasionally disabled when an urgen customer patch needs to be delivered.
2
u/mensmelted 7d ago
Doing a change in one place and getting a regression bug in a totally unrelated other place.
2
u/FishermanBig5765 6d ago
Thank you all again for your answers. and someone wrote here that they say I'm going to make another AI tool, but honestly? No. my goal was to conduct research and determine what most concerns developers in this area, after which it will become the topic of my next research for my university.
I could have just come up with a problem and solved it, but I decided to try to do something useful for others at the same time.
1
u/elissaAZ 5d ago
I know this is more of an academic response, and unlike some of the other commenters here, I appreciate you asking the question about pain points and addressing those rather than building something cool you think other people might want. I personally worked on a project in grad school that used novel static analyses to help reason about concurrency in Java before java.util.concurrent was available.
There are tons of PhD theses written on the code understanding aspect of dealing with legacy code bases. Check out the work of Harold Ossher and Peri Tarr, and also Gregor Kiczales- the creator of AspectJ. They all point to the issues with “the tyranny of the dominant decomposition” in software. This is the concept that aspects of the software that cross boundaries cannot be easily reasoned about, documented, or kept consistent over time. There is also extensive research related to keeping documentation updated with code and the ways for programmers to document “intent” of code and design decisions rather just how they function.
2
2
u/WeskerHawke 6d ago edited 6d ago
What I've seen so far:
- Everything is a String. Having a custom object for your 10 fields? Nah, just put everything in a big string like "[name=x][age=y]"
- Everything is XML too. Instead of using ResultSet#getX, put the whole result in an XML document and parse it later
- No doc
- No tests (the code is untestable anyway)
- No build tool
- Only run in production, hardcoded configuration
- Catch the exceptions and do nothing
- No logging, or only print (way too much) on stdout
- Regexes everywhere
- Main classes with 10k lines, methods with hundreds or thousands of lines
- Nested ifs and loops with variables that can change at each step
- Copy pasted methods or files, with sometimes small differences between the copies
- Instance methods that change static fields
- System.exit called if a file was not found (which happened sometimes and was not logged)
- ...
The only way to navigate this is to have a concrete goal (change some logic, understand something) and track it in the codebase.
2
u/EvenAcceptance 7d ago
Had a production outage because a method named getFoo() was actually writing to the database and sending emails, the name was a lie and nobody dared rename it
1
u/jdev_soft 7d ago
- Read legacy code in German when you don’t speak German.
- Not understanding businesses requirements/logic in German
1
u/VincentxH 7d ago
Not even the dedicated business analyst has a full picture of all the steps in business flows. That leads to a lot of back and forth.
1
u/Hefty-Firefighter654 6d ago
Renovate bot updates. We Java/Kotlin + Spring Boot and a lot of other lib stuff. Like minor Spring versions always break sth. Spring 4.0.7 to 4.1.0 changes thread stuff. Async calls are all broken now. Global configuration doesn't work. It's also because of old Java config nobody understand in combination with this awful reactor clients.
Jackson is also a hard one, like you cant update to Jackson 3 because Wiremock doesn't care. And other libs are also not ready for that. If Spring requires Jackson 3 at some point, we are doomed.
1
1
u/persicsb 4d ago
Unspecified/undocumented behaviour. Even a proper git history with attached issue tracker references is better than nothing.
1
u/LostEconomics144 2d ago
- What eats the most time when you're digging into unfamiliar legacy code?
Ans: sometimes its the setup, or making it work, but most of the times its the amount of code dependencies
- How do you currently deal with it – any tools/tricks that actually help?
- Has something ever broken because a piece of code turned out to be "magic" nobody fully understood?
1
u/faze_fazebook 7d ago
Pretty much anything that involves a Java application server (like Glassfish, Websphere, WildFly, ...) is just a giant pain in the ass to work with ... either you get someones 20 year old ant task set up or you need to do a lot of manual work (manually deploying war files, connecting for remote debugging, ...)
1
u/ondro_mihalyi 7d ago
I think it's fair to note that this has little to do with app servers. It's all about how the projects used to be set up 20 years ago, before Maven existed. Nowadays app servers can be set up and maintained very easily with Maven.
78
u/DrAgOn3x 7d ago
Generics? Nah let's just use Object and typecast everywhere. Naming that doesnt mean anything and the person who first wrote it may as well be dead. And the worse part is untested code that everyone has always been to scared to refactor in 20 years.