A simple Java program consists of the following components:

1. Class Definition: Every Java program must have at least one class definition.
2. Main Method: This is the entry point of any Java program. The syntax is public static void main(String[] args).
3. Statements: Instructions that the program executes.

Example

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

As cuixiaoyiyi puts it on github: „An anonymous inner class will hold a reference to the this pointer of the outer class and will not be released until the thread ends. It will hold the Activity and prevent its timely release.“

The effect on garbage collection of the outer class is obvious. In my case, the anonymous inner class is a runnable that holds references to some gui elements it should update. Exceptions can occur if the referenced Activity is closed by the user, while the runnable is still in the queue and waiting to be executed.

A solution can be to use a static class with a weak reference as referencing object, which is the runnable in this case.

This exemplifies that one major meaning of the keyword static is: not bearing a reference to a current instance. It would even be a compile time error if a static class contains a usage of a non-static member of an enclosing class.

This might occasionally also apply to updating entities.

Step by step

• If you have any mappings (for example in hibernate), these should be updated
• If your entity has relations to others from your domain world, annotations should be given and checked for correctness.
• If there is a database representation of your entities, you might have to update this manually and also consider the effects of your adding the new entity.
• Can your entity be non-existent? What happens (or needs to happen) if your entity is deleted?
• Has your entity the correct name regarding best practices, technical and domain considerations?
• Do the fields of your entity have the correct default values?

Basic Requirements

Analyse the requirements. Understand what the api should do. Check which data is needed. Choose a point where the api should be integrated.

Planning

Develop an architecture, choose which technologies should be used. Determine the timeline for the integration.

Hands on

Test the endpoints and implement them. Do the same for the integration.

Fallacies

Make sure you avoid the common fallacies of distributed computing:

• The network won’t fail
• There is no latency
• There is unlimited bandwidth
• The topology of the network will never change
• There is only one network admin
• The cost of network transport is zero
• The network is homogenous

This could be a good starting point for your test cases. The term „distributed“ can be applied in terms of time, space and hierarchy – over time the network may change, the distribution may cover large areas and incorporate multiple levels of hierarchy.

Intro

Hello! I’m Carsten Neubauer, a passionate musician and software engineer with a love for sailing. I enjoy exploring new ideas and continuously learning to improve my skills.

Background

I have a background in Systematic Musicology, with experience in Computer Science. Over the years, I’ve worked on various projects that have helped me grow both professionally and personally.

Interests

• Technology: I love staying updated with the latest tech trends and innovations.
• Travel: Exploring new places and cultures is something I cherish.
• Podcast: I’m an avid listener, always on the lookout for a good podcast.
• Biking: Staying active and healthy is a priority for me.

Thank you for visiting my page!