Packages in IntelliJ IDEA (Xlets)

[DameEdna]

Guten Morgen,

ich habe vor Kurzem damit begonnen, mir Java mithilfe von YT-Tutorials und Beiträgen auf Webseiten und in Foren beizubringen. Um ganz präzise zu sein: Es geht um Java in Verbindung mit (UHD-)Blu-rays (Xlets). Am besten lerne ich solche Dinge anhand von bereits vorhandenem Code. Daher habe ich den Java-Code einer Blu-ray in IntelliJ IDEA (Community Edition 2024.1) geladen. (Eines meiner Authoring-Programme bringt zudem Eclipse mit. Aber IntelliJ gefällt mir derzeit besser.) Ich erarbeite mir dann Schritt für Schritt die Funktionen des Codes. Das geht kreuz und quer. Denn sobald der Java-Code durch das Authoring-Programm läuft, werden alle Bezeichner entfernt und durch Buchstaben ersetzt. (Das geht sogar so weit, dass „do“ Verwendung findet, weil einfach von a bis z durchbenannt und dann mit aa, ab, ac etc. weitergemacht wird. Bei IntelliJ führt „do“ natürlich zu Irritationen. Warum auch immer es funktioniert, dass so eine Disc dennoch abgespielt wird.) Daher ist der Code ein einziges Rätsel. Erst recht für mich als Anfänger. 🙂
Durchschaue ich eine Sache, vergebe ich meine eigenen Bezeichnungen. Nur gut, dass IntelliJ die Zusammenhänge besser erkennt als ich. Denn sonst würde es wohl Ewigkeiten dauern. Wobei sich auch IntelliJ gelegentlich irrt, da manche Buchstabenkombinationen häufiger vorkommen, aber zu unterschiedlichen Funktionen gehören. Da muss man dann aufpassen.

Nun zu meiner Frage: Bei Xlets sind ja einige Dinge anders. Der Startpunkt ist ein bestimmter Code innerhalb einer Klasse. (Es gibt keine klassische Main-Methode.) Diese Klasse wird dann im Authoring-Programm hinterlegt, damit die Disc später weiß, wo sie starten soll. Dieser Code liegt meist in einem Package. (Ist jedenfalls bei meinem Authoring-Programm der Fall.) Dadurch, dass der Code in einem Package liegt, ist er von den restlichen Klassen außerhalb des Packages „isoliert“. Wenn ich das richtig verstanden habe, ist das auch richtig so.
Mein Problem ist nun, dass bei der Umbenennung von z. B. Klassen IntelliJ die Bezeichner in Packages ignoriert. Dasselbe gilt, wenn ich mich durch den Code klicke, um zu verstehen, wohin eine z. B. Methode oder Variable führt. Und natürlich frage ich mich, wie das bei der Ausführung des Codes funktioniert: Wie gelingt der Sprung aus dem Package zu einer anderen Klasse? (Im vorliegenden Code liegt die Start-Klasse in ihrem eigenen Package. Alle anderen Klassen liegen außerhalb oder in anderen Packages.)

Übrigens: Eine Blu-ray oder UHD-Blu-ray, welche auf Java basiert, nennt sich „BD-J“. In Abgrenzung zu einer HDMV-Blu-ray. HDMV ist der „klassische“ Code, welcher extra für Blu-rays entwickelt wurde. HDMV habe ich mir vor Jahren ebenfalls selbst beigebracht. Dabei handelt es sich allerdings um eine sehr rudimentäre Sprache. Also kein Vergleich mit Java. 🤣

Ich bedanke mich schon jetzt für Eure Antworten und Eure Geduld.

Lukas

 

[mihe7]

Mein Problem ist nun, dass bei der Umbenennung von z. B. Klassen IntelliJ die Bezeichner in Packages ignoriert.

Was soll das bedeuten? Wenn Du eine Klasse a.b.c.X hast (also Klasse X im Package a.b.c) und X nach Y umbenennst, dann wird daraus a.b.c.Y (also Klasse Y im Package a.b.c).

Wie gelingt der Sprung aus dem Package zu einer anderen Klasse?

Jede Klasse hat einen eindeutigen Namen - den "vollqualifierte Bezeichner" (FQN - Fully Qualified Name). Der besteht aus den Paketnamen und dem Klassennamen. Oben wäre z. B. a.b.c.X der FQN der dort genannten Klasse X.

Du kannst jede Klasse über ihren FQN ansprechen. Das ist aber auf Dauer mühselig und macht den Code auch sehr schwer lesbar. Deswegen "importiert" man die Klassen mit der import-Anweisung.

Nehmen wir mal an, Du möchtest eine Liste (java.util.List) verwenden:

import java.util.List;

Damit brauchst Du im Quelltext bei der Verwendung der Klasse nicht mehr java.util.List zu schreiben, sondern kannst einfach List verwenden. Die Klassen aus dem java.lang sind immer "importiert", hierfür brauchst Du keine Import-Anweisung zu schreiben.

Wenn die Frage darauf abzielt, wie Du Methoden aufrufst: hierfür brauchst Du entweder statische Methoden oder Instanzen der Klasse (sprich: Objekte).

Beispiel:

System.out.println(String.format("%d", 12));

System ist java.lang.System. Die Klasse hat eine öffentliche Klassenvariable out, die ein Objekt vom Typ java.io.PrintStream referenziert. Diese Klasse wiederum bietet die Methode println an, die mit allen möglichen Parametertypen überladen ist.

String ist java.lang.String. Die Klasse hat eine öffentliche, statische Methode format, die hier verwendet wird, um einen String zu formatieren.

Achtung: das Beispiel ist nicht zur Nachahmung gedacht (suboptimaler Code).

 

[M.L.]

Die Authoring-Tools zum Erstellen von BlueRay-Inhalten (mit Java) dürften wohl die bessere Option sein, da die "klassischen" IDEs (Eclipse, IntelliJ,...) eben nur für die reine SW-Entwicklung ausgelegt sind (das dürfte auch die Änderungen aus #1 unter IntelliJ erklären).
Grundsätzlich ist Progammierung die Frage, wie sich der Compiler verhält, wenn er im Quellcode auf ein Schlüsselwort (auch i.V. mit anderen Schlüsselwörtern) (nicht) trifft. Den Compiler interessiert nur die formelle Korrektheit des Codes (z.B. Verwendung einer main-Methode), weniger dessen Quelle (Framework, andere Packages,...). Aus menschlicher Sicht sollte man den Code so organisieren, dass Änderungen / Erweiterungen an nur einer Stelle vorzunehmen sind.

 

[DameEdna]

Vielen Dank für Eure Antworten. 👍

Was soll das bedeuten? Wenn Du eine Klasse a.b.c.X hast (also Klasse X im Package a.b.c) und X nach Y umbenennst, dann wird daraus a.b.c.Y (also Klasse Y im Package a.b.c).

Es geht um Refactoring, nicht nur um das reine Umbenennen. Das hätte ich dabei schreiben sollen. Letzteres funktioniert natürlich ohne Probleme.

Jede Klasse hat einen eindeutigen Namen - den "vollqualifierte Bezeichner" (FQN - Fully Qualified Name). Der besteht aus den Paketnamen und dem Klassennamen. Oben wäre z. B. a.b.c.X der FQN der dort genannten Klasse X.
Du kannst jede Klasse über ihren FQN ansprechen. Das ist aber auf Dauer mühselig und macht den Code auch sehr schwer lesbar. Deswegen "importiert" man die Klassen mit der import-Anweisung.

Beim originalen Code befindet sich die Start-Klasse „XletBD“ im Package „title“:

package title;

public class XletBD extends ir

Bleibt der Code wie im Original, dann beschwert sich IntelliJ, dass es „ir“ nicht auflösen kann. Erst wenn ich das Package „public“ mache, findet IntelliJ die „ir“-Klasse außerhalb des Packages. (Und sämtliche anderen Verweise innerhalb des Codes.) Damit behelfe ich mir gerade. Aber das entspricht natürlich nicht dem originalen Code, welcher vom Authoring-Programm erzeugt wird.

Die Authoring-Tools zum Erstellen von BlueRay-Inhalten (mit Java) dürften wohl die bessere Option sein, da die "klassischen" IDEs (Eclipse, IntelliJ,...) eben nur für die reine SW-Entwicklung ausgelegt sind (das dürfte auch die Änderungen aus #1 unter IntelliJ erklären).

Ja, das wäre gut. Aber solche Tools gibt es nicht bzw. sind gar nicht vorgesehen. Entweder produziert das Authoring-Programm seinen eigenen Java-Code, da hat man dann überhaupt keine Einflussmöglichkeit. (Einen solchen Java-Code analysiere ich gerade.) Oder es ist wie bei Scenarist BD/UHD: Dort gibt es ein separates Programm namens Scenarist BD-J. Dabei handelt es sich allerdings um Eclipse. Eine sehr alte Version von Eclipse (Version: 3.3.1.1 ), denn der Blu-ray-Standard ist ja nicht mehr der neuste. 😉 Daher arbeitet man auch mit den Standards und Regeln von vor 15 Jahren. Muss ja alles auch zur Not noch mit einen Blu-ray-Player von 2009 funktionieren. 😆

 

[mihe7]

Erst wenn ich das Package „public“ mache, findet IntelliJ die „ir“-Klasse außerhalb des Packages.

Ich denke, Du suchst https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html