Steve Beckle

Yes, recursion is the correct term. Thanks for pointing that out...my choice of words was not the best. The recursion will fill up the heap and cause a run time exception as opposed to an infinite loop which will just spin silently in most cases. Thanks sheriff!

Yes, this is what I had in mind. Your list model will now contain these contact objects that contain all of the info for the contact. When you select the entry in the list, your list selection model will allow you to get the selected item, which, if you parameterize your list model properly, will automatically be a Contact object. You can always make a list/combo box hold any kind of object you want to, and as I mentioned before, if you override the toString() method for the Contact object, you can have your list display anything you want. For example,

@Override public String toString() { return lastName + "," + firstName; }

I would also parameterize my list model:

DefaultListModel<Contact> model;

That ensures type safety, (you can only add Contact objects to the list model) and when you work with a list selection object, you know you're dealing with a Contact object and don't have to do any casting.

I think one big advantage is the functional programming you can achieve. You can now create functional libraries and use individual methods as needed. For example:

class Helper { public static boolean isFreezing(double t) { return t <= 32.0; } public static boolean isTooHotToMowTheLawn(double t) { return t >= 88.0 } } public class App { public App() { Predicate<Double> isReallyCold = Helper::isFreezing; Predicate<Double> goSwimmingInstead = Helper::isTooHotToMowTheLawn; System.out.println("Is it cold? " + isReallyCold.test()); System.out.println("Go swimming? " + goSwimmingInstead.test()); } }

Now, you can move Helper to some other .jar file and recompile as needed if the logic changes, and leave your original code in App{} unchanged.

Remove the word "boolean" on line 6 of your second code block. You're redefining "light" rather than referencing the value you defined earlier. Also, just a friendly suggestion, if the intent is to not leave the light on indefinitely once it's been turned on, modify your logic so that if your action command is not "light on", set light=false.

Your button logic seems sound....I ran the code w/o all the chart stuff to verify that "a" does change when I edit the text area and press the button. Have you inspected the dataset that's being created? I'd put in some print statements near the return of the method that creates the dataset to see exactly what's getting built into the chart data.

I'd experiment with GridBagLayout instead of BorderLayout. Scroll panels can be tricky when they need to be resized, and I've always found that GridBagLayout prevents the kind of things from happening that you're seeing.

If you don't rename your actionPerformed(e) method, you're going to go into an infinite loop, as the button's actionPerformed(ActionEvent e) method will end up calling itself. Rename "your" actionPerformed() method.

Make each item in the list a an object that contains all the information for a contact, i.e. when you read in a string of info, parse it into different values, each of which is a member of the contact object. You can create each object by passing the data values to the object's constructor. You might also want to consider overriding the toString() method in the object to define what you see in the list. When you click a list item, you now have access to the object that represents the entire entity.

I've found this link to be a good one for what you're looking for. http://winterbe.com/posts/2014/03/16/java-8-tutorial/

Turns out I needed to upgrade to version 4.4 of Luna. That fully supports Java 8.

I'm having similar problems. I've updated my jdk in Eclipse (luna) to 1.8.0_45. For some reason Eclipse does not like "import java.util.Comparator", and in the package explorer, shows that class to be empty. Yet when I look at that class in 7zip, by looking inside the jre library rt.jar, it looks fine, and I can compile a simple .java file with that import statement when I run javac from the command line in DOS. Also, when I go to Window/Preferences/Java/Compiler in Eclipse, my choice for Compiler Compliance Level only goes as high as 1.7. Why wouldn't 1.8 show up since that's my most recent JDK?