Inspired by @Billgates

everyone around is hyped about new tech they get to use, new toys to tinker with, I can see their eyes shining when they hear "let's try and introduce kafka" - they would wiggle their tails all day long if they had ones!

And me? Well, a new potential employer got me so excited I couldn't wash a smile off my face for a few days! You know what they said? "we don't use any frameworks, we focus on clean code, solid, kiss and we write with tdd". Bare java - that's the best position I've heard of in years!

I guess I'm oldschool. But I truly believe their approach is the right one. Not trashing the code with spring [which is turning into smth what systemd is for linux/unix], hibernate and what not.

Just good old java code. Db, multithreading, request-mapping -- all plain, manual and simple.

Amazing!

Bashing on systemd?
I approve.

I've got the weirdest boner right now

All cool unless you want to build a scalable distributed, high performance backend. Or anything large scale tbh.

What's the app, out of interest?

I'm genuinely curious, because the "plain old Java" codebases I've worked in have been way worse (in terms of verbosity, lack of clarity, security holes etc.) than those I've worked with using the common frameworks. But perhaps we're talking about different domains here.

@RememberMe oh, but they ARE large-scale :) Any particular reasons why you believe plain java won't scale well?

@AlmondSauce Backend of one of the most popular fin-tech companies (at least in EU and probably Asia?).
Not yet sure which backend.. although I wouldn't be surprised if they were doing it all this way.
Sorry, won't name it, don't want to jinx it :)

Lol so your mention didn't work since it's not part of a comment but I saw this in my feed anyway.

What were the chances....

@netikras Nah that's cool, was just after a general idea rather than any specifics. Interestingly I'm currently in a similar situation - Fintech (though much smaller than your example) and our main codebase is pure Java, no frameworks to speak of.

In some ways it's nice - it's performant and we don't need specific framework experience when onboarding new devs. But it has a collosal amount of boilerplate by modern standards, the concurrency primitives are notoriously difficult to test well and still catch even the experienced devs out from time to time, JDBC is a royal PITA where it's trivial to make "off by one" errors, and the lack of dependency injection has led to some rather, let's say questionable, design patterns.

I know it boils down to opinions, but it's a large part of why I'm jumping ship to work on a greenfield project elsewhere where Spring boot, lombok & reactor (amongst other popular frameworks) are heavily used from the get-go.

@AlmondSauce Well I may have been under wrong impression about the scale of the company. Although they are quite big. And (I think) should be a big deal in the UK, so there are chances we're talking about the same company :) Is your company name made out of 7 letters by any chance? :)

Yepp, boilderplate and mistakes is what I expect. However I'd expect mistakes to be caught early in the development process by TDD/BDD. Do you use it as well? And I do hope that the right levels of abstractions and properly applied design patterns will make JDBC, multithreading and others less of a pain to work with.

I've always been curious, how do you handle lack of dependency injection in projects like that?

same here. i'm about to make a website.

"what libraries are y..."

"FUCK OFF with that bullshit. maybe jQuery, but i'm not even sure about that one yet, and that will be all, in any case."

@netikras Not the same company (you'll be pleased to know!)

TDD catches many mistakes, yup. But when there's heaps of boilerplate involved the tests for this boilerplate (if there are any) often get copy/pasted then modified to suit. That's a recipe for simple typo errors that never get picked up (as the test can then just be identical to a previous one that was never changed.)

Yup, abstractions definitely make the concurrency primitives and Jdbc easier to deal with, but then you reach a fine line between vanilla Java and an internal framework that does something similar to jooq (for example.)

In terms of DI - usually just a utility class containing "public static final" all the things, and you initialise your stuff to values grabbed from that global class. I don't particularly like it, but that part works well enough at least.

@AlmondSauce Frankly I don't see anything wrong with an internal framework. It's internal, crafted to finely suit that particular project's needs, so no extra overhead.

These are good points to keep in mind, thank you.

BTW, do you also say NO to reflection and java's Proxy in your bare-java project? I believe it would tremendously reduce boiler plate created by DI, Repository layers (lazy-fetch!!) and quite a few other places.

@netikras Nothing inherently wrong with internal frameworks when they're designed well and kept up-to-date. The main issues I have are twofold - firstly it's impossible to verify that before joining, and secondly that any knowledge I build up on that internal framework is useless after I leave. I'd personally much prefer to be gaining ground in Spring (or more recently, Quarkus / Micronaut) however much I may have issues with aspects of those frameworks personally. That second reason is my main one by far.

As for our main codebase at the moment - proxying is allowed, reflection is sometimes allowed but strongly discouraged and has to be justified in code review (though we have to put up with it in some cases.)

@AlmondSauce Thank you :)

@netikras depends on how large that scale actually is and what all it has. If it's something straightforward then sure, plain Java all the way.

If I have a complex application that I want to scale involving stuff like messaging between nodes or distributed data storage and computation, then nyeh, I'm not reimplementing Kafka or Akka or whatever. Getting distributed systems correct and fast at the same time is extremely tricky. Libraries all the way.

@RememberMe I'm not sure I'd call kafka or AMQ for that matter a framework... It's not part of the code. It's a part of the system, like the database(s) or Redis, but not part of the code.

Framework is something like Spring suite, Hibernate, OpenJPA, Thymeleaf, Dagger, Lombok (which is to become obsolete since java 14/15 IMO) and others of the kind.

I would never even try to implement a cache as good as Redis in Java. It's a mad man's journey. I believe the same applies to Kafka as well :)

@netikras fair enough

@Midnight-shcode hey what static site generator you will be using? What about ui library? No library for UI? What CSS processor then? Not even templates like pug or haml? Ok ok what about BEM? classic CMS or headless one? What about CI/CD? lol

Just joking, but I get your point and I dig it!

@devJs
c# or php + mysql on backend.
generating html, styled by css, manipulated by js/jquery.

done.
fuck all that other shit made because morons were afraid that without it they wouldn't be employed in 2 months.

(i get you're joking, i'm just clarifying)