Think of objects as those things that are running in your system. They are very much like real objects in the real world (car, window, room, etc). The classes are blueprints for those objects. Think of them like an engineers design of a car, an architects design of a room, etc. The files are simply a way to organize the classes (and not objects). Think of them as folders or drawers in which the architect keeps paper designs.
Let's think about your problem in OO terms:
You want a parser that can parse the file and create an object which represents the contents of the file. I don't know what is in the file, but let's say it contained the details of a book (title, author, ISBN, etc), then the parser would create a Book object from that file. This object needs to be displayed, so you need a BookView object. The BookView object would contain all the visual artifacts you need. Since we are using OO, these artifacts would also be objects, and objects would be composed of other objects. A theoretical example would be like a room being composed of windows, doors, etc. A practical example would be a BookView objects being composed of JFrame, JMenu, JTextArea, etc.
How would all these objects be created by the system? It needs a blueprint. Just like we need a floor plan and elevation before we can build a house. These blueprints are your classes. Again the files are simply a way of organizing those classes so that your software is understandable and maintainable. Typically we use one file per class WE create (there are exceptions to this rule, but I will not get into that right now).
You do not need a file for menubar. You need a file for your view class, which will be composed of a JMenuBar, etc. You also need a file for your Parser and a file for a class which will start your software (this is a good practice).