Forum Stats

  • 3,727,656 Users
  • 2,245,433 Discussions
  • 7,852,906 Comments

Discussions

Java fundamental question, how best to put it all together

Robert Angel
Robert Angel Member Posts: 4,535 Bronze Crown
edited October 2017 in New To Java

Hi,

I am working my way through java resources and putting together some functionality as self training but I have a fundamental issue which I really don't understand.

My issue is when I am creating a large application / solution (call it what you will) how should I be creating it in terms of files.

I have read / experimented with the package, but the limitation on the number of main clauses therein does not seem to make it so useful to act as a thing that can 'bundle' together

Am I then supposed to building many classes saved in separate files, one per class, ideally keeping each class as simple as it can be, all of which stand alone and then writing a 'central' main class which essentially pulls it all together?

To make this a more tangible example I am intending to write a form which will be used to invoke various programs, schedule various programs and so the main would as I see it be the form functionality, buttons, events, all of that.

The classes that the form invokes would be classes, each in their separate files, each previously tested and compiled.

Where I need the form to pass in variables / objects then I write interfaces and where the form needs to know that program 'X' has completed or is scheduled then I return and catch a variable to this extent.

Do I understand this correctly?

i.e.

1 File = Main Class

x Files = Classes etc

Main calls Classes

mNem

Best Answer

  • Unknown
    edited October 2017 Accepted Answer
    This is the limitation I am alluding to, it comes from the online training I am working through, not from core Java docs; - "There can be only one public class in a java source file and it must be saved by the public class name.

    Ok - but that isn't quite the same as what you first posted:

    I have read / experimented with the package, but the limitation on the number of main clauses therein does not seem to make it so useful to act as a thing that can 'bundle' together

    The above says 'limitation on number of main clauses' while the training quote says 'only one public class in a java source file'. Jar files, not classes, are used to 'bundle' things together.

    First the info about 'common practices'.

    1. common practice is to have ONE public class/interface per file. Although not required by The Java Language Spec you will find that most platforms and JVM providers implement this restriction.

    2. common practice is to package class/resource files belonging to the same functional area in a jar file. For complex functional areas that might be multiple jar files.

    3. applications will typically consist of multiple jar files containing the classes/resources needed

    I suggest you avoid the temptation to take shortcuts in learning Java and  use a structured training program or book.

    The Java Tutorials has trails that cover ALL of the basic Java functionality and include hundreds of working examples.

    What is a package?

    https://docs.oracle.com/javase/tutorial/java/concepts/package.html

    What Is a Package?

    A package is a namespace that organizes a set of related classes and interfaces. Conceptually you can think of packages as being similar to different folders on your computer. You might keep HTML pages in one folder, images in another, and scripts or applications in yet another. Because software written in the Java programming language can be composed of hundreds or thousands of individual classes, it makes sense to keep things organized by placing related classes and interfaces into packages.

    You can have two classes with the same name if you use a different package (container/folder) for them.

    This is the limitation I am alluding to, it comes from the online training I am working through, not from core Java docs; - "There can be only one public class in a java source file and it must be saved by the public class name......If you want to put two public classes in a package, have two java source files containing one public class, but keep the package name same."True?

    Creating and Using Packages?

    https://docs.oracle.com/javase/tutorial/java/package/packages.html

    Creating and Using Packages

    To make types easier to find and use, to avoid naming conflicts, and to control access, programmers bundle groups of related types into packages.

    Definition: A package is a grouping of related types providing access protection and name space management. Note that types refers to classes, interfaces, enumerations, and annotation types.

    But you should start at the beginning of the tutorials and actually TRY the examples.

    Am I then supposed to building many classes saved in separate files, one per class, ideally keeping each class as simple as it can be

    Pretty much correct. Each class should implement just ONE piece of functionality but that doesn't mean it has to be simple.

    , all of which stand alone

    Not sure what you mean. They can all reference and interact with each other. You don't need to have a 'main' method in each class but you can. The main method is used to 'run' that class on its own. That is useful for testing some/all of the functionality in the class independently - outside the context of the application(s) the class might be used in.

     and then writing a 'central' main class which essentially pulls it all together?

    Yep!

    .....
    If you want to put two public classes in a package, have two java source files containing one public class, but keep the package name same."True?

    True.

    ------ you can ignore the info below since in only contains technical info - follow the advice above and that others have offered

    This is the limitation I am alluding to, it comes from the online training I am working through, not from core Java docs; - "There can be only one public class in a java source file and it must be saved by the public class name......

    The training doc is explaining 'common practice' as already explained above.

    The Java Language Specification does NOT have that restriction - although many, if not most, vendors implement the restriction because there really isn't any value in allowing multiple public classes in a source file. It would make it difficult to manage classes so you could find them when you want them.

    https://docs.oracle.com/javase/specs/jls/se8/html/jls-7.html

    7.2. Host Support for Packages

    Each host system determines how packages and compilation units are created and stored. Each host system also determines which compilation units are observable (§7.3) in a particular compilation. The observability of compilation units in turn determines which packages are observable, and which packages are in scope. In simple implementations of the Java SE platform, packages and compilation units may be stored in a local file system. Other implementations may store them using a distributed file system or some form of database. If a host system stores packages and compilation units in a database, then the database must not impose the optional restrictions (§7.6) on compilation units permissible in file-based implementations. For example, a system that uses a database to store packages may not enforce a maximum of one public class or interface per compilation unit. 

    See that last two paragraphs above? See the reference to section 7.6? That is the section for 'Top Level Type Declarations'

    https://docs.oracle.com/javase/specs/jls/se8/html/jls-7.html#jls-7.6

    If and only if packages are stored in a file system (§7.2), the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as .java or .jav) if either of the following is true:    class="norm-error"  class="norm-error"This restriction implies that there must be at most one such type per compilation unit. This restriction makes it easy for a Java compiler to find a named class within a package. In practice, many programmers choose to put each class or interface type in its own compilation unit, whether or not it is public or is referred to by code in other compilation units. For example, the source code for a public type wet.sprocket.Toad would be found in a file Toad.java in the directory wet/sprocket, and the corresponding object code would be found in the file Toad.class in the same directory. 

    See the first sentence '. . . may choose to enforce the restriction . . .'?

    So the spec does NOT require that restriction.

    But all JVM vendors whose products I have used enforce that restriction.

    You should follow that same practice - one public class per file.

    Robert AngelmNem

Answers

  • mNem
    mNem Member Posts: 1,380 Gold Trophy
    edited October 2017

    I may check out the sample application ensemble that gets shipped with javase.

    JavaFX Samples

    It is a java client for showcasing the javafx features. surely, someone should be able to get some idea from there.

    Robert Angel
  • Unknown
    edited October 2017
    My issue is when I am creating a large application / solution (call it what you will) how should I be creating it in terms of files.

    You should be writing MODULAR code.

    I suggest you read about modularity and how to do it by going through the 'Creating Extensible Applications' trail of The Java Tutorials.

    https://docs.oracle.com/javase/tutorial/ext/basics/spi.html

    On that page you will see there are links to the steps that discuss how the app is 'packaged'.

    I have read / experimented with the package, but the limitation on the number of main clauses therein does not seem to make it so useful to act
    as a thing that can 'bundle' together

    What 'limitation' are you talking about? And what 'main clauses' are you referring to?

    An application only needs ONE 'main' method (not clause). As that tutorial shows each application is generally 'packaged' separately. If everything is in one giant JAR file for multiple applications then you have to distribute that one big jar file even if someone only needs one applications.

    It isn't clear what your 'issue' really is or what type of app you are even talking about: desktop, 3-tier using middle-tier app servers, servlets, etc.

    Robert Angel
  • Robert Angel
    Robert Angel Member Posts: 4,535 Bronze Crown
    edited October 2017

    Hi,

    my issue is just lack of experience which I do not want to manifest in an architecturally diabolic solution, so my question is one of what is best practise to hold large java programs, but I guess the word modularity says it all.

    thank you!

  • morgalr
    morgalr Member Posts: 457
    edited October 2017

    Robert,

    You only need 1 main method in your application, it is the entry point that allows the JRE to get things started.  If you think of it as that, then all you really need is your entry point, and then start instantiating the objects from your project.  You can launch new thread, or just keep your objects running in the same thread--you decide, but all you need to is have one main for your project entry point.

    Generally speaking my main only have one call or line in it.

    MyObject new MyObject().myControlMethod;

    So basically the JRE launches my main and then I instantiate a new object which has my control logic in it.

    Don't make the mistake of being a "static programmer", as is the temptation of many newbies.  "static" modifies the way things operate and if you do not know how, then you can really have it come around and bite you.  "static" is like a "worm hole in space" it connects all points along the way as a conduit, but has no dimension in and of itself--in other words, anything marked static is common to all instances of objects made from that class.

    If you have an instance variable say:

    int i=0;

    that is unique in each instance you instantiate from that class, no side effects, but if you add static:

    static int i=0;

    it becomes a class variable and is distinctly different because that variable i exists in every object instantiated from that class, that class variable is common in all objects instantiated from that class, in that, if you change i any where that is using that class variable, then it is instantly changed throughout your population of objects there were instantiated from that class, regardless of your intent, the value is changed throughout your objects.

    Les

    Robert Angel
  • Unknown
    edited October 2017
    my issue is just lack of experience which I do not want to manifest in an architecturally diabolic solution, so my question is one of what is best practise to hold large java programs, but I guess the word modularity says it all.

    Ok - but you didn't answer the main question

    What 'limitation' are you talking about? And what 'main clauses' are you referring to?

    You said you had a limitation - so we need to understand what it is you were referring to.

  • Unknown
    edited October 2017
    it becomes a class variable and is distinctly different because that variable i exists in every object instantiated from that class,

    Not quite correct. It is a 'class variable' so it does NOT exist in every instance.

    It can, however, be accessed from every instance.

    See the details in The Java Language Specification

    https://docs.oracle.com/javase/specs/jls/se9/jls9.pdf

    Class variables exist once per class. Class methods operatewithout reference to a specific object. Instance variables are dynamically createdin objects that are instances of classes.
  • Robert Angel
    Robert Angel Member Posts: 4,535 Bronze Crown
    edited October 2017

    This is the limitation I am alluding to, it comes from the online training I am working through, not from core Java docs; -

    "There can be only one public class in a java source file and it must be saved by the public class name.

    .....

    If you want to put two public classes in a package, have two java source files containing one public class, but keep the package name same."

    True?

  • Robert Angel
    Robert Angel Member Posts: 4,535 Bronze Crown
    edited October 2017

    Hello,

    probably like all beginners I am suffering from when to make static and when not, and how to call non-static from static.... but I get the fundamental OO concepts and I am trying to leave previous programming baggage behind to take full advantage of the power of objects in java.

    thanks for your input, it is appreciated.

    Robert.

  • Robert Angel
    Robert Angel Member Posts: 4,535 Bronze Crown
    edited October 2017

    To explain I come from a background where a package is a useful container for related functionality and little more.

    So only one main clause felt like a restriction from my perspective, as I am used to being able to call any 'procedure' that is publically exposed.

    Whereas, in Java it seems to me that the package is a more controlled thing, it gives a user of the package the ability to be able to call via what you have made the main package.

    However, as I can call a class from another package without it being present in the package, then I see that this "restriction" is really not a restriction.

    thanks for helping,

    Robert.

  • mNem
    mNem Member Posts: 1,380 Gold Trophy
    edited October 2017

    Each Java source file (with .java extension) is defined within a package (at max 1).

    A package is a way of grouping the classes (run-time version of the source files) together for scoping access to their non-private methods, constants and variables.
    If you noticed, I didn't say source files. The package statement in the source file will determine the location of the class file after compilation.

    A package is a folder or multiple folders. As folders are nested, they become sub packages in java land.

    If you don't define a package for a source file, then any classes defined in that file is assumed by the compiler to belong to the default package.

    i.e., all java files that do not have a package statement defined will be in the default package scope.

    Only one class is allowed to be defined as public in a file (with .java extension). And that MUST be the same as the file name before the .java extension.

    ie. If your file is named as HelloWorld.java then the only public class definition allowed in the file is

    public class HelloWorld { ... }

    Additionally, the file can contain any number of non-public class definitions.

    One distinct thing to note, a class definition can have any number of public inner class definitions. They can be instantiated by a caller as long as it has access to a reference to the outer class object.

    For how scoping works in java, you may want to have a look at:

    https://stackoverflow.com/questions/215497/in-java-difference-between-default-public-protected-and-private/33627846

    Robert Angel
  • Unknown
    edited October 2017 Accepted Answer
    This is the limitation I am alluding to, it comes from the online training I am working through, not from core Java docs; - "There can be only one public class in a java source file and it must be saved by the public class name.

    Ok - but that isn't quite the same as what you first posted:

    I have read / experimented with the package, but the limitation on the number of main clauses therein does not seem to make it so useful to act as a thing that can 'bundle' together

    The above says 'limitation on number of main clauses' while the training quote says 'only one public class in a java source file'. Jar files, not classes, are used to 'bundle' things together.

    First the info about 'common practices'.

    1. common practice is to have ONE public class/interface per file. Although not required by The Java Language Spec you will find that most platforms and JVM providers implement this restriction.

    2. common practice is to package class/resource files belonging to the same functional area in a jar file. For complex functional areas that might be multiple jar files.

    3. applications will typically consist of multiple jar files containing the classes/resources needed

    I suggest you avoid the temptation to take shortcuts in learning Java and  use a structured training program or book.

    The Java Tutorials has trails that cover ALL of the basic Java functionality and include hundreds of working examples.

    What is a package?

    https://docs.oracle.com/javase/tutorial/java/concepts/package.html

    What Is a Package?

    A package is a namespace that organizes a set of related classes and interfaces. Conceptually you can think of packages as being similar to different folders on your computer. You might keep HTML pages in one folder, images in another, and scripts or applications in yet another. Because software written in the Java programming language can be composed of hundreds or thousands of individual classes, it makes sense to keep things organized by placing related classes and interfaces into packages.

    You can have two classes with the same name if you use a different package (container/folder) for them.

    This is the limitation I am alluding to, it comes from the online training I am working through, not from core Java docs; - "There can be only one public class in a java source file and it must be saved by the public class name......If you want to put two public classes in a package, have two java source files containing one public class, but keep the package name same."True?

    Creating and Using Packages?

    https://docs.oracle.com/javase/tutorial/java/package/packages.html

    Creating and Using Packages

    To make types easier to find and use, to avoid naming conflicts, and to control access, programmers bundle groups of related types into packages.

    Definition: A package is a grouping of related types providing access protection and name space management. Note that types refers to classes, interfaces, enumerations, and annotation types.

    But you should start at the beginning of the tutorials and actually TRY the examples.

    Am I then supposed to building many classes saved in separate files, one per class, ideally keeping each class as simple as it can be

    Pretty much correct. Each class should implement just ONE piece of functionality but that doesn't mean it has to be simple.

    , all of which stand alone

    Not sure what you mean. They can all reference and interact with each other. You don't need to have a 'main' method in each class but you can. The main method is used to 'run' that class on its own. That is useful for testing some/all of the functionality in the class independently - outside the context of the application(s) the class might be used in.

     and then writing a 'central' main class which essentially pulls it all together?

    Yep!

    .....
    If you want to put two public classes in a package, have two java source files containing one public class, but keep the package name same."True?

    True.

    ------ you can ignore the info below since in only contains technical info - follow the advice above and that others have offered

    This is the limitation I am alluding to, it comes from the online training I am working through, not from core Java docs; - "There can be only one public class in a java source file and it must be saved by the public class name......

    The training doc is explaining 'common practice' as already explained above.

    The Java Language Specification does NOT have that restriction - although many, if not most, vendors implement the restriction because there really isn't any value in allowing multiple public classes in a source file. It would make it difficult to manage classes so you could find them when you want them.

    https://docs.oracle.com/javase/specs/jls/se8/html/jls-7.html

    7.2. Host Support for Packages

    Each host system determines how packages and compilation units are created and stored. Each host system also determines which compilation units are observable (§7.3) in a particular compilation. The observability of compilation units in turn determines which packages are observable, and which packages are in scope. In simple implementations of the Java SE platform, packages and compilation units may be stored in a local file system. Other implementations may store them using a distributed file system or some form of database. If a host system stores packages and compilation units in a database, then the database must not impose the optional restrictions (§7.6) on compilation units permissible in file-based implementations. For example, a system that uses a database to store packages may not enforce a maximum of one public class or interface per compilation unit. 

    See that last two paragraphs above? See the reference to section 7.6? That is the section for 'Top Level Type Declarations'

    https://docs.oracle.com/javase/specs/jls/se8/html/jls-7.html#jls-7.6

    If and only if packages are stored in a file system (§7.2), the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as .java or .jav) if either of the following is true:    class="norm-error"  class="norm-error"This restriction implies that there must be at most one such type per compilation unit. This restriction makes it easy for a Java compiler to find a named class within a package. In practice, many programmers choose to put each class or interface type in its own compilation unit, whether or not it is public or is referred to by code in other compilation units. For example, the source code for a public type wet.sprocket.Toad would be found in a file Toad.java in the directory wet/sprocket, and the corresponding object code would be found in the file Toad.class in the same directory. 

    See the first sentence '. . . may choose to enforce the restriction . . .'?

    So the spec does NOT require that restriction.

    But all JVM vendors whose products I have used enforce that restriction.

    You should follow that same practice - one public class per file.

    Robert AngelmNem
  • Robert Angel
    Robert Angel Member Posts: 4,535 Bronze Crown
    edited October 2017

    Many thanks for the comprehensive and very well worded response, which I am sure I shall continue referring to for sometime to come until I have ascended the lower half of the learning curve.

    Much appreciated.

    Robert.

  • mNem
    mNem Member Posts: 1,380 Gold Trophy
    edited October 2017

    Thank you for clearing few of my own misconceptions.

This discussion has been closed.