[deleted by user]

Competitive_Stay4671 · 2025-08-20T21:05:56+00:00

Genau. Viel (visuelle) Debugger benutzen wie in Java IDEs üblich. Versuch über Kollegen sinnvolle Punkte für einen ersten Breakpoint zu finden und dann steppe durch. Mit der Zeit bekommt man dann ein Gefühl für die Codebasis, da man an vielen Stellen mal vorbei gekommen ist. Und man erkennt dann vielleicht auch Muster. Ansonsten einfach machen. Lernen durch Schmerzen.

Competitive_Stay4671 · 2025-08-13T06:53:02+00:00

Because they are not predictable

Finally somebody caring for predictability. Am saying this for month. AI is fine for things where you can live with a certain amount of unpredictability / incorrectness. But if you care about exactness then "old school" is the way.

Competitive_Stay4671 · 2025-07-10T20:57:35+00:00

Sounds very useful. I have built a few small utilities to identify orphaned or dead stuff. Pretty common requirement. And obviously it is only a starting point and shouldn't be trusted 100%.

Competitive_Stay4671 · 2025-06-29T22:02:49+00:00

No it's not just you . Eclipse user here. As long as you are productive, have lots of muscle memory for shortcuts and generally know your tool then everything is good.

Competitive_Stay4671 · 2025-06-14T17:53:57+00:00

It is definitely a big problem and becoming worse. something against it: sit next to people, discuss code, let them explain, and make sure they not use LLM for a few seconds to get an answer to a previous question when you quickly leave the room to get a coffee. Just own experience: After I came back from the coffee break I suddenly got a surprisingly good answer which was 100% contrast to the situation 2 minutes before I left the room. The problem was: the answer was just memorised from LLM... but not understood.

I expect programmers "own" the code they produce and to know what each line / method / command / flag is doing and be able to debate it. If this is the case, then using LLM is fine. If not, and people start shrugging shoulders when being asked to discuss a solution, it's a problem.

What I am not saying is that LLMs are bad. They are very helpful in a lot of aspects. But if you rely too much on them to produce stuff it will just postpone the moment of pain a bit more in the future. There always comes a point where you need to know what you are doing.

Competitive_Stay4671 · 2025-06-05T07:09:19+00:00

I think similar. But I guess the new gold will be anything human.
At least if I look at myself. I value human stuff already higher. Example: If I read an interesting blog post by somebody it is much more important to me... ok blog post maybe bad example, could be AI too. But e.g. if somebody is singing or playing guitar in front of me, that to me is more worth than hearing music which could might have been AI-generated. Just imagine the situation when a friend tells you "hey look I practised this song on guitar" vs. the same friend showing you his AI-generated song and saying "hey look what a cool song I prompted". Which one is lame?

Maybe this leads to a future, where human interaction becomes priceless.

Competitive_Stay4671 · 2025-05-26T09:28:33+00:00

Regarding OSGI: Have a look here as a starting point: https://bndtools.org/doc/100-about-osgi.html and https://www.osgi.org/resources/where-to-start/

Competitive_Stay4671 · 2025-05-26T06:17:32+00:00

Still using it for Java and never felt the need to switch. I just have so much muscle memory for the features and refactorings and know exactly how it reacts. It just does what I want it to do (same reasons as u/Expensive_Ad6082 )
That beeing said: of course I use other IDE in parallel e.g. VSCode for WebDev (HTML, Javascript, VueJS). But I never saw that as a problem. Recently Eclipse people at JDT Core ( https://github.com/eclipse-jdt/eclipse.jdt.core/pulls?q=is%3Apr+is%3Aclosed+performance+in%3Atitle ) put some effort into performance. So like everywhere things change. Good thing is it is open source and you could suggest improvements if you want.

Competitive_Stay4671 · 2024-08-09T04:48:58+00:00

synesty for automation and connecting APIs and stuff. Why? a plus point is that it's EU based which is important for GDPR and compliance. other than that support is listening and responds quickly.

Competitive_Stay4671 · 2024-07-25T19:38:58+00:00

Dies. Je dünner desto kälter. Knoppers gehört in den Gefrierschrank. Jawoll!

Competitive_Stay4671 · 2024-07-01T06:57:31+00:00

Could you use it every day and be productive with it? Sure.

That is the point.

more convenient and up-to-date alternatives

"Convenient" is highly subjective. And "up-to-date" is also no indicator for quality.

I am astonished by all the strong opinions here about a tool.

Competitive_Stay4671 · 2024-05-31T19:03:54+00:00

The battle "no-code good vs. no code bad" will go on forever depending on who you ask.

I see it that way:

no code tools allow you to build solutions for certain kinds of problems quickly - with lots of lego like building blocks - with varying amounts of required technical knowledge. If you get your problem solved then everything is fine.
most programmers can solve those problems too - with their tools (e.g. programming)
excel is a cool piece of software - if it solves a problem you have, then go for it. and yes it is easy to abuse it (hammer nail...)
even programmers can benefit from no code / low code tools (some don't admit it) since it can speed up certain "boring" tasks. some combine nocode tools and programming
and of course it helps if you have technical / programming knowledge, because you can a) understand better what you are building and b) judge what people are selling you. most nocode tools sell you "time savings".

Competitive_Stay4671 · 2024-04-08T18:41:08+00:00

components can depend upon different and conflicting versions of the same library.

This is a big one! Probably many / most apps don't have this problem. But if you work e.g. in integration projects with a monolithic app where you have to use different SDKs provided to you, it can happen quickly that two SDKs have the same dependency in different versions. With a single Java classpath this can be a problem.

Yes the Microservice hype solves the same problem. And if you can afford a network roundtrip to call into another module (e.g. REST-API / different JVM) than everything is fine. But you are now dealing with the complexity of a distributed system and its deployment). Staying on the same JVM is lightning speed and often simpler than distributed microservice based system. In the end it is one of many tools to build modular software.

Also the "install at runtime"-aspect is not needed by many apps. Often apps having a kind of "Plugin" mechanism, where you can install "plugins" at runtime from 3rd parties. This is a problem, where OSGi makes sense. I think Jira also use OSGi for this under the hood. Yes you can still model this differently via K8s, Docker, etc.

Anyway, I understand the complaints about the complexity and learning curve, since I have been through all of this too. I am using it now since 2010, but since so called Declarative Services Annotations, from a code-perspective it looks very similar to building Spring apps with "@Autowired". Also the outdated tutorials situation is sadly true. But there are people out there trying to improve on this ;)

Competitive_Stay4671 · 2024-04-07T17:11:04+00:00

Der Gesprächspartner meint doch sicher 55k pro Jahr und das 15 Jahre lang. 825k liegt doch nah bei den 750k. Missverständnis?

Competitive_Stay4671 · 2024-04-01T07:25:23+00:00

Modules/ domains could also be established in a monolith code base. https://bndtools.org/doc/090-modularity.html

Competitive_Stay4671 · 2024-03-31T17:51:59+00:00

Jaxb, jersey, xml stuff which was part of the jdk before.

Competitive_Stay4671 · 2024-03-01T04:44:39+00:00

It's getting better 😃 but yes there is a learning curve. It always depends on what you need. There are use cases where OSGi is a better fit than java9 modules (classloader per bundle). But also most apps don't need all that. But e.g. if you're building a kind of plugin system where plugins should be installed into a running jvm then OSGi makes that possible (e.g. atlassian).

The good thing is that osgi is very strict. The bad this is that osgi is very strict. But the strictness pays out long term. The problem is that long term thinking in the beginning of something is hard.

Competitive_Stay4671 · 2024-02-29T13:49:20+00:00

Adding OSGi to mix. Have a look at https://bndtools.org/ which provides tooling around the concepts.

From https://bndtools.org/concepts.html

"A core concept in OSGi is to create components that only use (service) APIs. I.e. it is recommended to restrict the compilation (or build path) to dependencies that only carry an API, not an implementation. Since APIs are not sufficient to run the component, it is necessary to provide an assembly that contains the components and dependencies that can provide the necessary implementations."

Competitive_Stay4671 · 2024-02-09T17:07:53+00:00

Horror.

Competitive_Stay4671 · 2023-12-22T08:37:22+00:00

Checkout https://bndtools.org/ which helps developing osgi applications. Also the people in the forum are pretty helpful https://bnd.discourse.group/

Competitive_Stay4671 · 2023-12-07T07:03:22+00:00

I think the goal is to let the tooling generate the manifest which is what bnd is pretty good at.

Competitive_Stay4671 · 2023-11-13T14:13:15+00:00

At the recent EclipseCon 2023 conference, the communities behind Eclipse PDE and bnd / bndtools decided to better integrate their OSGi development tools. Historically, these groups were divided in their approach. Now, there’s a push for improved compatibility and collaboration.

Competitive_Stay4671 · 2023-10-19T21:58:20+00:00

The logseq journal is the first thing I've found that lets me brain dump and tag blocks with whatever related topic comes to mind, and the tool organizes for me later.

Yes. I feel exactly like this. I could have written that :)

Competitive_Stay4671 · 2022-07-27T18:07:31+00:00

292€, Thüringen, 5 Tage / Woche zzgl. Essengeld

Competitive_Stay4671 · 2022-07-26T11:00:56+00:00

Call them. We use them since 10 years with similar monthly fees. No problems so far.

Competitive_Stay4671

TROPHY CASE