The Java Red Pill

1
Samizdat (Russian: самиздат, pronounced [səmɨzˈdat], lit. 'self-publishing'), was a form of dissident activity across the
Eastern Bloc, in which individuals reproduced censored and underground makeshift publications, often by hand, and
passed the documents from reader to reader. The practice of manual reproduction was widespread, because printed
texts could be traced back to the source. (Wikipedia)

2
Synapse
Until about the middle 2010s, the usual answer for the increasing complexity of
the business processes and infrastructure was very simple. Everything was replaced
by various Java software, developed either in-house or by external service providers.
That is a particularly characteristic feature of the German IT world. However, today -
middle 2020s - an increasingly popular solution in the external world is the API
Design: focus is on the interaction of the system components, and not on their local
implementation details.
On this way, we can integrate the already existing, sometimes diverse code base
into a central design, instead of extending the mess with yet another monster. This
time, we can have really separate, individually customizable and configurable system
components. This time, the about 20 years old promise of the Java world, about a
manageable business infrastructure, is fulfilled.

3
Inhaltsverzeichnis
The Java Red Pill..................................................................................................................................1
Synapse.................................................................................................................................................3
Why is Java bad – technological reasons............................................................................................. 5
ORM is a conceptional mistake....................................................................................................... 5
Runtime component scan is a conceptional mistake....................................................................... 6
Rigidity............................................................................................................................................ 7
Framework over a framework..........................................................................................................8
Why is Java bad – sociological reasons...............................................................................................9
Vendor lock...................................................................................................................................... 9
Socialism..................................................................................................................................... 9
„Informationgesellschaft“.........................................................................................................10
Conformism above everything.................................................................................................. 11
Frozen, rigid job market............................................................................................................ 11
Blocks diversity of new concepts and ideas..................................................................................12
Buzzword bongo, instead product................................................................................................. 15
Little lies............................................................................................................................................. 17
JIT.................................................................................................................................................. 17
„Application Servlet Containers“.................................................................................................. 17
Patterns...........................................................................................................................................18
Agile...............................................................................................................................................18
SOLID............................................................................................................................................19
Clean Code.....................................................................................................................................19
Microservices.................................................................................................................................20
„… developers“..............................................................................................................................22
YHVH............................................................................................................................................22
Tip for job interviews.....................................................................................................................22
Horror stories......................................................................................................................................23
When knowledge makes you outcast.............................................................................................23
„We write our own tickets“............................................................................................................24
Maven, „that Linux tool“............................................................................................................... 25
„Believe me, gitignore is not my job…“....................................................................................... 26
The unpleasant question.................................................................................................................26
„They do not know SQL“.............................................................................................................. 27
What to do instead.............................................................................................................................. 28
Standardized API format................................................................................................................28
Interface generation, Swagger....................................................................................................... 29
Introduction troubles......................................................................................................................30
Appendix............................................................................................................................................31
Glossary......................................................................................................................................... 31

License: please forward it where you only can. Any time if you forward this book to someone, author promises, he will smile once on
a scrum meeting.

4
Why is Java bad – technological reasons
ORM is a conceptional mistake
SQL is not an OOP language. It is a declarative language. You do not have
classes in SQL. Instead, you have relation calculus, which is applied set theory. This
is math. Not much more, but clearly above the abitur (K12) level. Most Java
developers do not know, how to grab it. Currently in Germany, most Java developers
can not program in SQL. They would not ever admit it, but they are ready to go really
far to avoid it.

Elephant in the China shop

Instead, what they do: they formulate with the hibernate api, essentially the same
what should be done in SQL. Obviously that leads to an additional layer of
complexity source. My estimation is about a 2-5x increase of the complexity, only to
formulate in Java, what should be done in SQL. Most of the increase happens
because you never have only a simple class for a simple feature in the Java world.
You must, you always must mess it with a bunch of interfaces and inheritance
structure. In their world view, OOP means that you implement with 5-7 classes
something what needs normally a single method. Or a single-line SQL query.
Then they use the bullshit called „patterns“ to ideologize this bloat explosion.

5
 The ordinary, proven OO answer to deal with a not-OO environment: we see
them as perifery, and we talk with it over some translator class. In the Java-SQL
relation, that would be a class of a set of hardcoded, static methods, casting SQL
queries over JDBC, and with some helper methods to do the conversion of the result
sets and the class instances. Of course, already the concept would be seen essentially
as blasphemy – but not because it would be bad et all. It would be seen as blasphemy,
because it would prefer SQL to their holy crap Java.

Tear down the idol

Runtime component scan is a conceptional mistake

A Spring Boot app iterates its class hierarchy on its start, it looks for
annotations, then it generates or executes the object initialization code in runtime.
That is a school example of doing in runtime what should have been long done in
compilation time. Your component initialization code should be generated by a
maven plugin, without any runtime annotiation processing. Anyways, why do you
need annotations, if we have configuration?
...any time, if you wait a minute until you can see your own Spring Boot app
working, remember: if you feel, your lifetime is now being wasted purposelessly, you
are right. Yes, you are totally right! No one wants you to create a good product!
The right thing to do would be to generate the object initialization / DI code in
compilation time, by builder plugins or by command line tools. It would be also

6
much more fast (because the IDE already knows, where are your components). Note,
this is also what modern JS/TS frameworks are doing.

Rigidity
A typical Spring Boot app, compiled into a far jar, is using about 50-60MB of
disk. It is a single .jar file, containing the .class files, the various resource files
(including the static web files, like frontend code). It also contains, recursively, all
dependent jars, and their dependents and so on, until the JRE runtime level. At most
some percent of this terrible mess will be ever seen by the CPU. But you must
package them together, upload them, deploy them every time, if you want to see, how
well is your code working.
Javascript frameworks, like AWT or Angular, are using a trick called tree
shaking. That means that the unreachable part of the blob is removed in the late
linking phase of the build. Also Java has tools for that, they are mostly related to the
fat jar creation; for example ProGuard or shakyboi. No one uses them. You would
need intensive googling to even find them.

Enterprise problem solving

Yes, annotations and the – anyways, conceptionally bad – dependency injection

would make it somehow complicated, but not much. The tree shaking tool should be
able to understand the annotation meta-data, that is nothing impossible and not even
too much work.

7
 The reason, why the Java jars are exactly the same terrible mess as they were 25
years ago, is that no one cares.

Framework over a framework

Let be honest. No one has ever needed Spring. What we call today "beans" or
"components", we already have since the early 90s: classes. A component is nothing
more as a class. Spring is probably the most unneeded framework ever, since
computers exist. And I am sure, deep inside we all feel it.

In their glass towers, they are all the same

Spring Boot tries to fix it, and it partially simplifies it, but honestly it is still
nowhere to what should be done. Another conceptional problem of the Spring Boot:
Spring is an unneeded complexity provider, now Spring Boot tries to simplify it. We
have a framework over a framework. Then why have we ever started this whole
Spring thing et all?

8
 The only what Spring is really doing, is called pooling in sane environments.
You have a managed pool of database connections, a managed pool of incoming http
connection handlers, and possibly a pool of outgoing REST connections. It needs a
pooling generic class, in some kB of sources. And not a framework with about
100MB source.
You do not need the "scopes" and similars. Java has already the various visibility
and encapsulation rules, and you do not want to reinvent the wheel. Just use a generic
pool. But the best is just throwing out this whole Java wirthschaft of the window.
Problem solved.

Why is Java bad – sociological reasons

Vendor lock
It is an interesting question, how the German IT world has degraded in such
depths. I think, we have a combination of multiple causes.

"It was my workplace task"

Socialism
The worst fear of someone in a capitalist country is unemployment. Germany, as
a West German inherit, tries to solve it by providing safety on market-based ways.
The actual government actions are complex, but their effect can be summarized in a

9
single sentence: the government pressurizes the market to employ everyone, and it is
working against the effectivity.
That is very fine, because as we know, while it is hard to get a job in Germany,
but they are also stable. In exchange, salaries are lower, taxes are higher – we are not
only with a single step closer to the former East Block.

„Informationgesellschaft“
Again, the purpose was very fine, and very logical, sometimes in the 90es:
educate so many programmers, IT-guys as possible, they will make the best IT of the
world. However, it went against the quality, and now the government has a hard task
to find jobs for all of them. The result is that the German IT jobs are mostly Java jobs,
and they are not really the best jobs on the world market.

Do not. Beside basic moral principles, there will be

also no reward. Corporations have no friends.

Maybe you should have trained, for example, also electroengineers, to stay the
race with the Chinese, uhm? The guys, who should be your today electroengineers,
are wasting their life, and their high quality brains, for bullshit scrum rituals, on
purpose-less Java projects. And your electronics industry is dead, or at least it is
nowhere to the Chinese. That was bad management, isn’t it?

10
Conformism above everything
Companies have the habit to do everything like the others. They do not think. In
the years, I have seen a lot of various decisions: which technology do we use, do we
go „to the cloud“ and how, when to switch what into which tech and so on.
I have never seen a single case that someone had made a calculation and the
decision had been based on the numbers. Never.
What I have always seen: companies are always doing what the others, and they
are doing what they think, it is becoming „usual“. These are always decisions licking
the boots of some big corporate of the USA. Among them, particularly the boots of
the Microsoft are shining, at least in Germany.
Money does not matter. Does it worth, no one cares. What is important: do
everything like the others. If you do not, you risk becoming a „weirdo“.

Frozen, rigid job market

Programmer salaries are roughly fix, and known with some hundred EUR
precision. You have a lot of programmers, but only a few of them are really good. The
high education system creates mostly Java programmers. If you start a new project,
your worst horror is that it fails. What will you do?

We only wanted better manageable software

production.

Beside that, also the companies – particularly decision makers about important
questions, like who will be employed of the 40 applicants – are very rigid. They have
an idea in the head, what they expect from new guys in the job. If you can more: it
won’t be paid. If you can lesser: you don’t get the job. The concept, that your skillset
has a market value, on which you try to sell it, is entirely alien from the country.

11
Needless to say, it is not even remotely similar to anything like a free market
capitalism. I think it is some like an idiocracy.
Now scroll back, what did I write about this German half-socialism. The
government pressurizes the market to employ everyone, which is fine, but it works
against the effectivity. In my opinion, probably that went too far – maybe we could
even interpret the German IT world as a sinkhole of the unemployment, to tune
various stats. At least, we help still much more the economy, as doing similarly
nothing, but on unemployment insurance or in much lesser paid jobs, being really
angry. The only question what arises, there is a huge amount of intellectual capital,
which is simply wasted. I have seen a guy with electroengineering Phd, working as
an Oracle database administrator at a big German electronics company. And he made
it still better as the guy, with also electroengineering Phd, who processed server
configuration xml-s with Java tools. But meanwhile, the German electronical industry
is only a shadow of its former self some decades ago. What happened here in the
heads?

They are compatible only with the other Java

solutions.

Consequence: jobs have a very fixed expectations, essentially a minimum what

will be surely a subset of your broad skills. They won’t ever expect signifcantly more.
You won’t ever earn significantly more. Consequence: there is no real motivation to
work and learn more. Everyone is doing the possible minimum, so in short term in
his daily tasks, and so on the long-term, in learning new things.
What also means, if you have started your career as a Java droid, you will
remain there. Not only because there are no other options on this job market, but also
because no one will ever except more from you.

12
 The result is a collective catch22: the high education will yet more focus to Java,
the companies will only find Java developers, so they will only have Java projects, so
the upper education will focus yet more to Java.

valid/strong
Science premises Bad science

has
„science“
in its name
presents
sound/cogent misleading or
conclusions fraudulent

Pseudoscience
invalid/weak premises

Where would you put „SOLID“ and the „design patterns“? Classify the theories by practical
experience and critical mind.

In the external world, out of the German IT bubble, things are much more sane
and healthy. Just check, for example, [Link] or [Link] or
[Link] , what the world market expects. In summarily: Java is strong also
there, but it is only one of the about 5 strong, and maybe 15 lesser common
technologies.
With foreigner eyes, the German IT-world is entirely surreal. Most people not
having seen it directly, can not even understand, how is it possible. For them, it is
simply not belieavable, that a highly developed country has nearly exclusively Java
developer jobs on its Xing or Linkedin Jobbörse. Or that companies have a trouble to
understand that software development does not always mean Java development.

13
 However, if your company has mostly Java solutions, or it is going to have only
Java solutions, you are now going into a trap. The whole German IT World is in the
Java Trap! It will be hard to escape!

Blocks diversity of new concepts and ideas

„If the only tool you have is a hammer, you tend to see every problem as a nail“,
says the proverb, and nothing is more true for the rigid Java-oriented social
hierarchies of the German IT world. A Java programmer can not really think in
general IT concepts and terminologies.
He can not really think in DB records, he thinks in persistent entities. He does
not think on, what is in the SQL. Sometimes, rarely, he is using some DB
management GUI, but he can see the persistent entities even there, and not SQL
tables. And particularly nothing relation algebra.
He can not see an URL, he can see only a controller. Where we see a file, he can
see a resource. Where we see a library, he can see only an API. Where we see a row
(in a db table), he can see an entity.
Where we see a TCP port, he does not see anything. For him, it is a forgotten
number somewhere in the [Link]. He might see some
AbstractBullshitFactoryImpl<GenericTrashpile>. His brain can not grab the
concept of „socket“ or „TCP port“. He can see a handler pool managed by the
framework, but he can recognize even that, if it is described in his own exact
terminology.
What a Java guy knows well and uses exclusively, that is his complex class
hierarchy. It is really complex, and it is a mostly unneeded complexity. It is an
intentionally generated needless complexity. It serves as a shield, to protect our brain
from the fear of the unemployment.
If you want to do any non-Java with a Java team, you will hit walls. I have seen
Java team rejecting maven for its xml configs. How can you expect them to cooperate
with, for example, a ruby or django tool of your business partners?
A Java team does everything with Java, completely ignoring the unneeded costs.
They rather re-implement a DB manager tool in Java, but they won’t extend an
opensource python tool (in about 5% of the work need). They rather re-deploy a
whole Java Webapp to change its Javascript frontend part, but they do not use a
proxying solution. I have seen both of these directly, and many, many, many similars.

14
 It is particularly „funny“ to see, what they are doing, if a server certificate is
needed for a https site.

Definition of
Burn-down Job Router Gitops Stakeholder
Done (DoD)

Sprint Objective Retrospective Backlog User Story

***
Rollout Stack JOKER Funnel Epic
***

Business Analysis Sprint

Portfolio Ecosystem
Owner (BO) Phase Planning

Scrum
Product
Time-box Master Story Points Platform
Owner
(SM)

If a horizontal, vertical or diagonal line is fulfilled, you can safely sleep

or work.

Buzzword bongo, instead product

Note, while - for example - Scrum actually limits the daily length to about 15
min, in the reality it almost never happens. In my experience, the average length of
the Scrum Dailys is about an hour. In its most usual flow, we start as a "daily": what
we did, what we want, and how. And then, two or three "lead", "principal" or similar
guys start the bongo: the talk starts to diverge into a meaningless buzzword-race
among them.
In my experience, about after the first half an hour of a scrum daily, you are safe
to just mute them, because any meaning of the talk decreases to zero. But the average
length of the scrum dailys is much longer, and in most cases, you can not just leave
them to play with each other.

15
 It is of course extended with some additional rituals: retrospective and similars
are in the scrum standard, that is further extended with some local time wasting. For
example, once I worked by a company where we started every sprint with a month of
official doing nothing: it has run under the name "analysis". The idea was that we
only write tickets for the sprint. In practice... probably no one knew, what was the
purpose, except to provide believable timesheets for a layman controller in our
customer hierarchy.

The problem of the Gordian Knot was solved. The

Java Trap is not much worse

In other case, we had a week of doing nothing in all months. This doing-
nothing week happened between the sprints.
Beside the usual, very, very boring Scrum rituals, we also had a lot of courses,
lectures and presentations, mostly about high level OO design theory. There the good
intent of bosses could be clearly felt, although its effectivity was clearly questionable.
Kanban helps a lot in this, because Kanban is already a reversion of the Scrum
bullshit to the reality: you have your stream of tickets and you are working on them.
The PM or the lead splits them if needed, handles unexpected problems and tries to
give the best ticket to the best guy. That is agile in the reality. Yes, of course any PM
would say for that: "no, that is waterfall", but he will say it only because he believes
his own bullshit.

16
 Note: never go into a buzzword race with a PM guy, they are not your weight
group. Instead, fight on your own field: always explain, why and how his own
pseudo-scientific crap does not create a working product. However, in many cases,
still he is in advantage, because in the reality, there is no need for a working product.

Adapt, what you do. Adapt, what you say (or keep silent).
Never adapt, what you think.

Kanban is the result of that the bosses recognized: the cost of the scrum rituals
is too much, both in developer salary and in developer work morale. So we went back
to a better managed waterfall, but we have also invented some pseudo-scientific crap
to save our face. And Kanban was born.

Little lies
JIT
Java is not a compiled language, it is a tokenizing language. JIT is a marketing
buzzword, and as it was sold, it was not ever developed. „Just in time compilation“
in the JVM simply does not exist, and everyone can see that who has seen a JVM
source code. (Note, most Java developers have not ever seen the JVM source, they
would not even understand what is it. They would mix it with the JDK source.)

17
 Another reason, why JIT does not exist, is that no one has ever wanted to make
anything well in Java. What they wanted, that is a well believable and paid timesheet.
About well-done work, they would not even understand, what are you talking about.
And this is cumulating over the layers of the libraries more quickly, as our
CPU/RAM is getting better. So a liferay restart has taken 10-15 minutes 20 years ago,
and today, with about 1000x faster machines, it still takes about 10-15 minutes. Same
to the average start of a Spring app (1-2 min).
Btw, generating machine code in runtime would have problems with most
current security settings or most server environments (google for „NX“, „stack
noexec“ or similars). We would have problems with it even if it would exist.

Well, not exactly a compiler...

but... they must have sold it.

„Application Servlet Containers“

The buzzword-bongo of "Application Servlet Container" and similars are crap.
You are developing Java web apps, most likely for the company intranet, or for a
public page of a customer. Your "application servlet containers" are simply Java
webservers.
Any time if you find some overwhelming baroque-ish terminology, odds are
high: it is just corporate bullshit and the real meaning is much more trivial. For
example, Confluence is only a company wiki, as Wikipedia says. What Atlassian says
- „collaborative team workspace“ - is corporate bullshit.

Patterns
Your "coding patterns" are faked reasons to develop everything at least twice
more complex as needed. Particularly in the ORM, they help a lot to implement with
about 5-7 classes (interfaces) what should be done with a single, hardcoded static
function with an embedded SQL query. Yes, that would be the OO way to handle an
SQL backend, or any non-OO API.

18
 The primary purpose of the OO is to control code complexity, to keep it below
comprehensibility. The primary purpose of the coding patterns is to increase
complexity.
No widely used programming language is using these patterns, only Java. Others
are sane. I would like to suggest to make a pilot project in Django or Erlang. It will
be like a cold, refreshing douche.

This is agile. This is not.

Agile
"Agile" means only that someone checks, what are you doing, and you can
prove what you did. But it is nothing agile at all, it is just a way to make proven, well
organized work. The various „agile methodologies“ are at least pseudo-scientific, and
often harmful. Particularly Scrum is harmful with its catalysis of the bullshit-bongo
and with its ritualistic time wasting (retrospective and similars).

SOLID
"SOLID" principles are a set of two trivial and three harmful concepts. The last
three clearly goals to work on about at least double cost. I would like to attract your
attention particularly to the „open/closed principle“. Looking behind the pseuo-
scientific curtain, what we actually have: this rule forbids you to fix or improve
things, you are only allowed to extend them (and, after the mess falls on you, then to
re-write them). Fortunately, no one are using the harmful parts. It is enough if you
can talk about them on the interviews.

19
Clean Code
Clean code means that the source code you are writing is… clean. Nothing
more. It has nothing unclear, hardly maintainable, buggy parts. That is mostly trivial,
we all have learned it on the University, in our hobbyproject or as junior developers.
For example, we do not duplicate code, we give meaningful names to the variables,
we isolate working from behavior and similars.
Beside that, there was also a guy, who collected its most important principles,
extended it with a lot of misleading, often clearly fraudulent trash, and then he has
written a book about it, with the title „Clean Code“. With it, he committed the same
hostile naming, as, for example, Microsoft named their SQL implementation as „SQL
Server“. If the company representative asks about „clean code“ on a job interview, he
wants to hear this specific book back, that part what he remembers or considers

Matters have gotten even worse since he left

important, and not your concepts or that how you interpret it.
If you naively explain what you understand on that – maybe with some
surprising tone, because they seemingly consider you a beginner –, so if you do not
give back what this asshole thinks top important, they will politely reject you. Very
likely, it means that they want to employ a guy like those in the „Maven, that Linux
tool“ horror story.
If they would be really interested on the quality of your source code, they would
check your reference works. Optionally, they would talk with you about it. Maybe
they would show some source code for you and ask your opinion about it.

20
 By the way, if you have more than a decade work experience, and then they ask
you to replicate decade old University textbooks instead of talking about your work,
that is already an insult.
And they know it.

Microservices. Control them by iron fist, where

they interact. Or they will control you. Google
for „API Design“.

Microservices
In general, that is a good idea, it is just not said, exactly why. The exact reason is
to have many small server processes what you can manage with your OS-level tools,
what is impossible on a purely Java level.
We have these problems, together:

- Java has no destructors, you can not be ever sure if something is gone.
- You have no easy way to investigate, what trash is contaminating your JVMs.
- Consequence of the first two: wonderful „application servlet containers“, aka
java webservers, can only load java webapps, and they can not unload them.
- And their service processes are restarting braindamagedly slowly.

So you break up your huge monster into many smaller monsters. On this way,
you can manage with your OS-level tools what Java can not do. I short: you use
Linux to compensate the Java braindamages. Not surprisingly, this reinvention of the
wheel is a very characteristically Java product. In any others, including Python or

21
Ruby things, it would be even so possible, but the problem simply does not appear.
They use mostly horizontal scaling, except really big systems, or if sociological
structures have to be followed.
Using microservices, you can get back part of the manageability and

You must have this in your mind.

maintainability, what is simply not known in the Java world, but it is actually basic
features everywhere out of it. However, it is never admitted openly – first, most Java
programmer does not know any other, and second, no one wants to admit, that their
most widely used technology is actually the worst one.
There are also many related lies.
Most importantly, "microservices" are not "micro" et all. Beside that it makes
the infrastructure better manageable, their purpose is also to generate work. Problem
is that a Java project will be once unavoidably ready: we will have our rigid,
monstrous mess, which does what it has to do. So we split our monster into about 10
similar monsters, all of them about third in size of the original. Note the numbers.
Converting this project to microservices can result roughly a triplication of the code
size.
The cause of that is that now we need to implement also their communication.
And we use all the crap we do with spring annotations, inheritance trees, and similar
bloats, AbstractBullshitFactoryImpl-s, as usual in the ORM. So we can generate a lot
more work and paid timesheet. In theory, the goal would be to have a network of
services, manageable independently from each other.
Note, important features could be done much better by swagger-generated
communication primitives, however it would mean that the central part of the project
will be a yaml file. See the chapter „What to do instead“. Spoiler: no Java team
would accept it without force.

22
„… developers“
You are not "frontend developers", "backend developers", "full-stack
developers". You are all Java developers. Any time, if you deal with Java, without
being mentioned that it is Java, you can be sure: further lies will follow soon. In the
Rust, Ruby, Python world, developers are called as they are: Rust, Ruby or Python
developers. Only a Java developer would call himself „full-stack developer“.
Anyways, stack is a last-in-first-out abstract collection. A data structure. What type of
brain is needed to call part of the programmers as „full-stack“?

That is a full stack That is a Java developer

Very different things

YHVH
Another ritualistic behavior of the Java world is the taboo. Very often, you do
not mention Java. If your boss says, „we are going to microservices“, that means
almost always „Java microservices“. If someone says, „it was a frontend developer
role“, his job was to generate HTML with a Java library. Java can not be mentioned
directly. It is like YHVH in the Old Testament.

Tip for job interviews

Another tip, for Java job interviews: ask the company representant, how big is
the source code. For example, how many commits does it have, or what is the size in
lines or in kB. He must be able to give at least a rough estimate. If he can not, or he
answers a bullshit, odds are that the job will be very, very bad.
Most of the Java team leads can not answer this question, at least in Germany
and today. They do not know, how big their source code actually is. They do not think
in „source code“, they think in „project“ (and in various scrum bullshit terms). They
might have long forgotten that behind the libraries of the bullshit bongo, there is also

23
a source code what should work. In many projects, making a working product is not
even expected (see „The Unpleasant Question“ chapter below).

It should have been only a bad dream. They did not

understand, what is my problem.

Horror stories
When knowledge makes you outcast
It was in 2013, by a big company of my local region. We had a Java project, of
course, but this time with a thick client. Using SPA (single-page web app) which talks
over REST with a backend, it was a new thing at the time. However, as we know,
Javascript in browsers can only talk with the same hostname and port from which it
was downloaded. CORS did not exist yet. The result was that our large Javascript
code and our REST API should have been downloaded from the same server.
Their solution was a complex build where the backend code is recompiled, and
then the Javascript code is merged into it as resource. That has also meant that the
backend code must be re-deployed on any Javascript change, totally needlessly,
leading to many bugs and unneeded waits.
On some reason, we also could not use some tricky deployment pathes. Afaik
the team had already a problem to understand, that a deployment in an appserver can
be also a purely static thing, it does not need to have also .jar or .class files. They
have not ever deployed a resource-only webapp in an appserver in their entire life.

24
 I have suggested that maybe we could use a http reverse proxy. I.e. the REST
API could lie on /rest, the frontend on „/“ or on „/client“, and a reverse proxy could
forward the requests as it should. Today, that is what angular is doing in an „ng serve“
command, but it did not exist at the time.
Then I faced the problem. A really big problem.
My teammates did not know, what is a http proxy.
I explained it to them. I thought, they will thank it. They did not.
In their view, I became the guy who did not want to follow the company
processes.

Some of them might have

some intelligence

„We write our own tickets“

Yet another outsourcing project for a Big Company. Our sprints are about 3
months long. In the first month, it was forbidden to change in the code anything. We
have only written tickets and talked about them on meetings. It has run under the
name „analysis phase“. A whole month of buzzword meetings was quite a strong
experience, probably a month of prison had been better.
But our customer has believed the trash, that we are in „analysis phase“.
Possibly even our team lead has believed his own fart.
We communicated with the customer representants over a ticketing system
written in ActiveX, working exclusively in IE8. Parallel we also had our Jira. Ticket
synchronization happened by hand. Such a customer has probably eaten easily, why
we do not work in the third of our paid work time.

25
 Inside Outside

If you can not do, what you need to, you still need to do, what you can

Maven, „that Linux tool“

Team of junior Java developers. They know Eclipse and various wizards, they
do not know what are these „.project“ and similar files in the project directory, but for
their luck, Eclipse hides these from them.
We have a Spring Boot Java project, based on maven. They do not know
maven. They use Eclipse Spring wizards for everything. They consistently block
everything what is not direct Java source code, including the maven [Link]-s. It
goes well - until a minor [Link] change is needed. I do it. They talk about it, as
„that Linux tool“, and I become „that Linux guy“.
However, as I was „that Linux guy“ of the teams, later I was called as „that
weirdo“. Why? Because I talked about concrete things – I have talked about „jars“
where they have talked about „API“s, I have talked about „maven config“ where they
have talked „build workflow“, and so on.
They were junior, they were inexperienced, they only knew Java – but they
have grabbed the corporate buzzword bongo on the spot, on an instinctual level. It
was for them like well oxygenated water for the fishes. They seriously believed, it has
a meaning.

26
 I remember, once a praktikant by us made his AI homework in python, and
they all have checked it. In the next weeks, their bullshit race was that they wanted to
say the most possible sentences with the word „hyperparameter“. They have
somehow enjoyed this word, and they wanted to say it so many times as possible,
which was quite surreal for a Java dev team.

„Believe me, gitignore is not my job…“

...said the guy, committing his target/ directory, including the many MB jars,
regularly in the company repo. I could not do anything, it had looked as if the guy
outside (of the project) would harass the guy inside. He understood my dilemma, and
he smiled as he misused the situation.
After he finally went away, I silently fixed the .gitignore. Then I have used a git
tree-filter to remove the target/-s retroactively from the repo. I did it purely on
eigeninitiative. No one had had ever any problem with such a repo.

The unpleasant question

By one of our top customers of one of my previous workplaces, we worked on a
big data process manager tool. It could start, stop, manage, check and configure large
(hours to days) data mining and conversion processes. It had already about 2-5
manyears of work in it.
If I had got this task, as a freelancer project, I had extended some already
existing open-source tool, like pgAdmin or similar, with the required functionality.
This whole thing had required maybe a month of work, plus maybe two month of
testing-bugfix-configuration-introduction. The idea of the extension of a nicht-Java,
opensource tool in some manmonths, that idea had looked like if I say, I am from the
Mars. They rather wasted years of high quality, developer work. But it was no
problem – it was paid.
As I joined the project, the tool already could start, stop, manage, check, clone
and (re)configure the large database mining and conversion processes. Then I asked,
if we can do these all, why we can not create them?
...the air has frozen on the spot. We all understood, no one should ever ask this.
Then I got a bullshit answer about some external entity, which is creating/deleting the
entities independently of our code. Some of us knew that it is bullshit, but most of us
did not care et all. But we all knew that I am persona non grata from now in the
team. There are always questions, what you should not ever ask.

27
„We do not know SQL“
Customer is using Java appservers. He does not want to know, what are the
containers. On some cloudy reason, Db Schema manager tools can be used only in
Prod and not on Dev. The project is about 3-5 microservices. Development happens
by all of them in their own docker container, with a WebSphere running in it, and the
jar or war is deployed into this WebSphere. The whole thing is managed by quite
custom [Link] -s.
Our DB schema initialization happens by a very specifically parametrized
maven execution: this starts the docker containers with the webspheres, deploys the
apps, initializes them in some specific mode, which only initializes the Db schema,
then exits. This whole thing has race conditions in both on the SQL and on the
container initialization level, making a simple DB initialization irrationally slow, and
working with only about 50% probability.

"We do not know SQL, and we do not want to

learn it“

The team does not want to admit that it is a problem.

I suggest to use a short SQL script to initialize the DB. It is rejected. Instead,
they wire the crap to their IDE, so they can try it with only some clicks. They are
using Idea – Eclipse is stinking for them, because it is open source. Then we all lie
that everything is fine. We all know that we lie.
They still do not want to use any SQL script. There is no meaningful
explanation.
Later the team lead admits: they do not know SQL and they do not want to
learn it. It is like if the window of the cellar would be shattered, where I lived until
now, and the Sun shines in. I suddenly understand everything.
It is not something what I don’t understand. Not at all! They are simply stupid.

28
 Comfort Stretch Learning
zone zone zone

Java

They could get out of their bubble. But not without hard
measures. Stretch them hardly, and filter for the
survivors.

What to do instead
Standardized API format
The purpose of this text is to show for you an escape route from the Java Trap. If
you, as a German Boss / Dept Lead / Team Lead, can follow it, that means, you can
free yourself from your own sociological imprinting.
Many of you can do that. The idea is not mine. The idea is from the guy, who
was the de facto leader of the company, where some of these horror stories happened.
At the time as I worked for him, he was a department lead, essentially he was the
boss running the business (with about 80 guys below him).
And he tried. And he failed. His own Java teams resisted it. They resisted it on a
tricky way: they made it on the paper, but exactly without its essence in the practice.
Being a boss does not mean, that you could do what you want to.
Maybe you will be more lucky.
Microservices solve some of the worst braindamages of the Java world. But it is
not enough. There are always problems what you can solve only by replacement, and
to replace things easily, you must decouple them. And never forget: the root of the
problems is the Java itself. You need at least the option of the independence from the
Java, even much better if it also cleans things up. Do not make Java exclusive.

29
Instead of the services, describe their interaction. Describe it on a language-agnostic
way. Define the APIs. After that, the ball is at the teams. You can not micromanage
them effectively, but you can politely motivate them to be ready.

There will be still many room for the big corporate timewaste, to fullfill special organizational
needs. The difference is, that it will be this time under your control.

The API definition must not happen in Java. You will only get yet another
unneeded complexity layer, we have seen it many times since EJB. The API
definition must happen on a platform-independent way, in a platform-independent
API description language. Then enforce it with iron fist.

Interface generation, Swagger

In Swagger, you can define APIs in yaml. You simply define the types, the
interfaces, the URLs, and so on. This all is beautiful. A Swagger file describes a
REST API on a platform-independent and language-agnostic way.
Then, you have your tools. You can convert this API description into a list of
Java interfaces. Or to a list of PHP templates. Or to a [Link] skeleton code. You can
generate also the client-side part of the API, which is used by the tools using the
service. You can also generate the server-side API.
For Java, the code generates a bunch of interfaces. Compile them to a jar,
version it, upload it into the artifactory, and oblige the teams to use these jars. Do not
allow any change on the API definition without the agreement of all the teams using
it.
Nothing on the world prevents you from, for example, using the generated
server-side PHP with a Java client-side part. The PHP and the Java teams can work
together, despite that, knowing only one of these languages makes you hating the
other with a high probability. Actually, having different languages on the sides is an

30
advantage: it will be a guarantee that they will talk about the API and not about their
local language details.
Because you can re-use your own existing code base. You can safely refactor a
not swagger-based project to a swagger-based one, just reconstruct the required yaml.
Technically. On an organizational level, just watch, who see the most problems in this
refactor task. They are the real bottleneck guys of your teams.

He wants to retire as a Java developer

Introduction troubles
The Java teams will sabotage it. As written before, a Java team can not and does
not want to handle anything non-Java. They won’t ever accept the usage of a bunch
of interfaces generated from a swagger yaml file. They will sabotage it on all possible
ways.
In my direct experience, the team converted the code generation step to a maven
plugin execution. On this way, essentially they had an interface set generated from
the yaml, and nothing fixed contract-like among the projects. The other side of the
API had been an Angular SPA, there it was not used et all, citing integration
problems.
No one could say, why they can not convert the API into a separate project and
use its generated code from our Artifactory.

31
 As I can remember, the Volkslied was that the „customer does not want
additional repositories“. It was probably a lie, in other projects he had no problem
with >50 repos. Their true reason was to sabotage the API design concept. They did
not want any non-Java in their projects, particularly not in such a central role.
However, you have the iron fist and they only need to work. Do not allow it.
In the API design try I have seen, the cause of the failure was that the team was
allowed to convert the interface generation into a maven build step. Again: convert
the generated code into a jar and forbid them to modify it. But make it obligatory to
use it.

Appendix
Glossary
---
abstract: unneeded

agile: → scrum or → kanban

analysis phase: cooperative timesheet faking

application servlet container: java webserver

clean code:
- that is what you write if you play stupid, to keep your job
- that is what you write if you give your best
# warning: working on this way is mostly unneeded/dangerous
- code with an extended usage of patterns # → "pattern", "solid"
- a low quality OO introduction book, with a pile of fraudulent bullshit
# warning: exactly that is asked from you on German job interviews

cloud:
- our own hosting service what we want to sell
- hosting service of a big evil company, whose marketing we try to refer

cloud native: low-educated cloud-fan and particularly agressive bullshit

generator. Buzzword of the 2020s. # → "cloud", "serverless"

cloud native dbms service: sql hosting

collaborative team workspace: company wiki

definition of done: → "objective"

ecosystem: set of particularly shit softwares we must use for higher command
# much worser as → "software stack"

focus: you have your stream of tickets, and you solve them all
# warning: working on this way is mostly unneeded/dangerous

gitops: IaC config files in a git, with unneeded 100 pushes/day, because

32
 the crap config management tool can work from git only

job router: reverse proxy

kanban: playing agile, some work in focus is allowed # → "agile", "focus"

objective: communicated version of our subjective project goal

pattern: using at least 3 classes for the task of a single method

# → "solid", "clean code"

project owner: team lead, management contact # → scrum master, stakeholder

retrospective: particularly long and boring bullshit bongo, wasted afternoon

# → "agile", "sprint"

rollout: upload binary to the customer

# never disclose its exact meaning, if mystery makes you the local
# strong man

scrum: abstract bullshit factory

# → "analysis phase", "rollout", "sprint", "retrospective"

scrum master: team lead, management contact # → stakeholder, project owner

serverless: uses only microsoft servers, and only with mouse

solid: set of two trivial and three harmful concepts, in a pseudo-scientific

mask # → "clean code", "pattern"

spring: most unneeded framework ever existed in the IT history

spring boot: boosting spring with a boot to leck # → "spring"

sprint: work week

stack:
full stack developer:
- developer knowing only Java, but plays not stupid
- developer knowing not only Java, playing Java specialist, to survive
software stack: set of shit tools we must use for command, lesser terrible as
an → "ecosystem"
protocol stack: ISO/OSI bullshit. Remembers of an era as IT was already
not science, but tried to look as if it would be
NEVER means: last-in-first-out linear collection

stakeholder: team lead, management contact # → project owner, scrum master

waterfall: like kanban but does not play agile # → "kanban", "focus"

33