JAVA help

[WdnUlik2no]

Please take a look at the following code (pulled from Head First Java 2nd ed).

This is how the code is written in the book, but it does not compile:

import javax.sound.midi.*;


public class MiniMiniMusicApp
{
public static void main (String [] args)
{
MiniMiniMusicApp mini = new MiniMiniMusicApp();
mini.play();
}

public void play()
{
try
{
Sequencer player = MidiSystem.getSequencer();
player.open();

Sequence seq = new Sequence(Sequence.PPQ, 4);

Track track = seq.createTrack();

ShortMessage a = new ShortMessage();
ShortMessage first = new ShortMessage();

first.setMessage(192,1,122,0);
MidiEvent changeInstrument = new MidiEvent(first, 1);
track.add(changeInstrument);
a.setMessage(144, 1, 20, 125);
MidiEvent noteOn = new MidiEvent(a, 1);
track.add(noteOn);

ShortMessage b = new ShortMessage();
b.setMessage(128, 1, 20, 125);
MidiEvent noteOff = new MidiEvent(b, 16);
track.add(noteOff);

player.setSequence(seq);

player.start();

}catch(Exception ex){
ex.printStackTrace();
}
}
}


The code above returns the following errors when attempting to compile:

MiniMiniMusicApp.java:20: cannot find symbol
symbol : variable PPQ
location: class Sequence
Sequence seq = new Sequence(Sequence.PPQ, 4);
^
MiniMiniMusicApp.java:20: internal error; cannot instantiate Sequence.<init> at
Sequence to ()
Sequence seq = new Sequence(Sequence.PPQ, 4);
^
MiniMiniMusicApp.java:22: cannot find symbol
symbol : method createTrack()
location: class Sequence
Track track = seq.createTrack();
^
MiniMiniMusicApp.java:39: cannot find symbol
symbol : method setSequence(Sequence)
location: interface javax.sound.midi.Sequencer
player.setSequence(seq);

If I go back and simply add "import javax.sound.midi.Sequence;" right under the import.javax.midi.*; statement, then the problem compiles and runs.

My question is why do I have to explicitly have the line import.javax.sound.midi.Sequence IN ADDITION to import.javax.midi.* in order for the program to work.

This appears to be redundant

import javax.sound.midi.*;
import javax.sound.midi.Sequence;

Since the * wilcard should include everything in that package automatically. However this is the only way the program works.

Please explain someone.

 

[kamper]

Works fine here. What java compiler are you using?

 

[WdnUlik2no]

Thanks for your response!

I am using JAVA 5.


I figured out the problem after doing trial and error tests with my CLASSPATH. I had a suspision that it has something to do with another Sequence.class file somewhere on my computer that happened to be in my CLASSPATH.

I did a search and discovered that there were some other Sequence.class files from seperate programs that I wrote. I deleted the all of the other Sequence.class files, but not the associated Sequence.java files. When that didn't fix the problem, I just started removing stuff from my CLASSPATH until the program worked.

Well it turned out that one of my directories in my CLASSPATH had a Sequence.java file that was causing the problem. As soon as I moved the Sequence.java file to another directory and ran the program I originally posted it worked fine without having to explicitly import the Sequence class from the javax.sound.midi package.

I was under the impression that the compiler only looked at CLASS files that were in the CLASSPATH, but it seems that it was looking at the Sequence.java file eventhough there was no associated class with that file.

Could anyone explain why it does this and why Sequence.java was the thing causing my program not to compile?

 

[brikis98]

using the wildecard character (*) creates ambiguity: rather than java knowing to use some particular class, you are forcing it to search for the right one. so, when you just had mport javax.sound.midi.* and referenced the class Sequence in your code, the Java compiler searched through the packages in your import statement and classpath for the proper class. since there was more than one class called Sequence, you had an ambiguity, so there was a compile-time error.

to resolve the ambiguity, you either remove the second Sequence from your classpath or avoid using wildcards and just import the exact class you need (mport javax.sound.midi.Sequence).

 

[WdnUlik2no]

So the wildcard means it looks at .java files (the file with the actual Source code) as well? There was no other Sequence.class file on my computer since I deleted all of the other Sequence.class files I had.

But the program did not work until I moved the Sequence.java file to another directory that wasn't in the CLASSPATH or until I renamed that Sequence.java file to something else.

 

[kamper]

No, the wildcard is not what caused the Sequence.java to be included. Try removing the wildcard and implicitly importing every class from javax.sound.midi except Sequence and you should find that you get the same problem. Probably what caused the incorrect class to be picked up before the j.s.m.Sequence class was that it was in the same package as MiniMiniMusicApp (default, I'm assuming). .java files and .class files are pretty much equivalent to the linker in this situation. If a .java file is found with the correct content it will be compiled and treated the same as if the .class file had already existed.

Really, using the CLASSPATH env variable is a pretty bad idea. It's far better practice to keep your code in packages and only set the classpath as arguments to the compile and run commands. Ant helps a lot with this.

 

[WdnUlik2no]

^^^ Thanks Man! You were right! I put that other Sequence.java file in the directory that was in the CLASSPATH and then recompiled my program with all the classes in the javax.sound.midi package except for the javas.sound.midi.Sequence class and it came out with the same errors as before! I had no idea that it tries to compile .java files if the class in that file is equivalent to a clas that I'm using in my program.

I guess I better start getting used to putting my code in packages like you said.

 

[kamper]

Reading over this again, I should retract a bit and say that brikis98 is right too. There is ambiguity which is causing the problem. However the ambiguity itself isn't what causes the error, it's that the compiler deterministically (as in, not randomly) chose the source file first and so the Sequence class was used incorrectly. I'm actually surprised that explicitly importing j.s.m.Sequence fixed the problem, as the same ambiguity exists: both Sequences are in the relevant namespace. Must be part of the spec that an implicitly imported class gets precedence over something just in the same package. I'm curious about how that applies when you are not using the default package, or if you had a class called Sequence defined in the same file.

Of course, not using CLASSPATH or the default package will eliminate most of the problems, but explicit naming in your actual code would be a good practice to avoid confusion otherwise (write j.s.m.Sequence right in your code).