I recommend you install an IDE like NetBeans, Eclipse, or (my favorite) IntelliJ IDEA. Make sure that in each IDE you attach the sources and the Javadoc documentation to the rt.jar file, which contains the standard java.* and javax.* API. After you've done you can read the JavaDoc documentation about every method that's available on a certain variable.
Say you have something like this:
Code:
JFrame f = new JFrame("foo");
f.
After typing f., your IDE should open up a scrolldown list of possible method and member completions. Take your time to look at each method, reading its documentation if you're not 100% sure what they're supposed to do and making little test programs to find out what the common way is to achieve feature X or Y. Inline documentation for each method in your IDE is a great way to quickly learn an API.
Also, you haven't said what part of the Java API you're having trouble with grokking. One user responded about why there are lots of classes to do file I/O. Yes, for the uninitiated, it's pretty confusing on why there's InputReaders and Writers, BufferedReaders, OutputStreams, PipedReaders, etc. But once you understand that one should chain these classes together to achieve a goal none of these classes can attain on its own you see the beauty of the system. The I/O classes are an example of the decorator design pattern.
Similarly, in graphical development, it's important you understand the base classes: Component and JComponent and their properties. They're the top classes in the Swing system from which all GUI components are derived. They're also generic handles one can use to traverse and compose a part-whole relationship frequently used in Swing GUIs (again, an implementation of the Composite pattern). The way Event dispatching is performed in Swing is also something you just have to grok. For any event, say an event that encapsulates a mouse click, there are at least three and sometimes more objects cooperating. You attach a MouseListener to a Component. Said Component fires a MouseEvent whenever it detects a click. Listeners are attached with addXYZListener(XYZListener) and removed with removeXYZListener(XYZListener). This is an implementation of the observer pattern.
The way JTables, JLists and JComboBoxes work is also something you just have to see in action in someone else's code to appreciate. A JComboBox is actually a fairly dumb class that only strings its model, renderers (and if it were editable, editors) together. You could see an implementation of the mediator pattern in it. The model stores some information (strings, ints, complex user-defined objects) and a renderer you write to interpret said model items is supplied with it to your JComboBox. That way, JComboBox can be reused, whether you have a model containing books with pictures or just plain ints. Similarly, the way a model is visualized is easily changed without touching the model or the JComboBox by supplying a different renderer (which implements ListCellRenderer). The latter is an example of the Strategy pattern.
For EJB development, you should also look at the general compositions of the classes rather than looking at all the different methods in isolation. When tackling EJB, you should understand what it's trying to solve: fixing the object/relational impedance mismatch. It does this through something called Entity Beans, which are usually kept at the server and fronted by a Session Facade, which, for any given method, can span operations on one or more tables and table rows (Facade). In a Java web-application, you'd have some view technology (plain JSPs, Velocity, or a component framework like Swing with JSF) that talks to a Controller (the Session Facades) which does some magic to the underlying Model (the Entity Beans). The EJB standard and all of its companion standards is huge. You only need to understand the key parts to get going, however. Once you run into something you can't fix with the core pieces, you can sit back and look in all of the other APIs for a way that can help you achieve your goal.
I hope it's clear by now that to learn an OO-API, you should invest in learning the classic design patterns (google for the Gang of Four book). Once you have some programming experience and while learning an API, you can readily apply these patterns to the classes you're studying: "Oh, this listener, event object and these methods on this class are just infrastructure to implement the observer pattern. I should treat them as one whole." "Hmm, there should be a way to add behavior to an Object without having to subclass it. Great, it implements an interface. I can implement that interface too, compose the object being enhanced inside of me and just delegate the calls I'm not interested in to said object while doing my thing on the methods I am interested in."
You should also understand that Java is a type-safe language. Yes, there are lots of classes and interfaces, but all these classes and interfaces allow you to better describe your intent to fellow programmers and work with them in a team. If it's just you alone behind your computer banging out code, then yes, Java's API is a bit verbose. However, verbosity, type safety and clean, extensible architecture helps tenfold once you're in a group of programmers trying to achieve a certain goal.
Finally, there are lots of great books about the various APIs used in Java. I can highly recommend the 'monkey' O'reilly book "Java Swing" if you're interested in understanding just how that huge Swing API fits together. Of course one doesn't know all the minute details about a method or field of a certain class in this API. Such "freak" knowledge comes over time when using an API daily. The important bit is that you understand how everything relates to each other: for example, how you can do custom painting or even go wild by implementing your own UI delegates through composition.
So, to summarize my rant: learn the classic design patterns, look for them in an API you're studying, install an IDE which allows you to view documentation inline for each method and class and allows you to view the source of the core Java APIs. Don't be shy to search for and buy a book about an API you're confused about. If you're cheap, just look the net for articles describing common practices on how to achieve something. Quick answers can be great, but it's far better if you find articles describing the composition and the intent of an API rather than just how to achieve feature X or Y.
So what you need is some local Java guru you can ask for help - or beg online. IDE could help you when you know the class name, but how to find that name?
Adv Reply
Bookmarks