JavaC compilation error: '.' expected

[Klauer]

I am trying to find a reference to this error somewhere, but you can
imagine how difficult it is for a search engine to actually find '.'
verbatim, assuming that the first quote, the period, or the second
quote can be ignored.

In any case, I was compiling my java classes and I'm getting this odd
error, not knowing how to fix it:

com.thing.etc.etc...: '.' expected
import classIwasImporting

Where can I find out about this error, and how can I fix it? First of
all, can someone give me a reference to a specific place where I can
at least figure out what this error means, or if anyone has any
insight on what the compiler is thinking when it comes up with this
error, I'd appreciate it.

 

[bencoe]

I am trying to find a reference to this error somewhere, but you can
imagine how difficult it is for a search engine to actually find '.'
verbatim, assuming that the first quote, the period, or the second
quote can be ignored.

In any case, I was compiling my java classes and I'm getting this odd
error, not knowing how to fix it:

com.thing.etc.etc...: '.' expected
import classIwasImporting

Where can I find out about this error, and how can I fix it? First of
all, can someone give me a reference to a specific place where I can
at least figure out what this error means, or if anyone has any
insight on what the compiler is thinking when it comes up with this
error, I'd appreciate it.

I would assume that it's because you're importing something
incorrectly...

Can you give me an example?

if you've got a line like:

import com.net;

That's incorrect, should either import a specific class.

com.net.URL; or the whole thing 'com.net.*'

Ben.

 

[Klauer]

The class I'm importing is a specific class. This specific .class is
in the classpath, and this used to compile before(in IntelliJ). We
are moving our Ant scripts to be platform independent, and have come
across an error like this preventing it from happening. We are also
compiling this under JDK 1.3, if that helps any.

For instance, the class is a pre-compiled class crSampleClass.

All of our source for many of these files simply

import crSampleClass;

public class crExtSampleClassExtension
{
....
}

and this compiles correctly and creates a functional .jar that we use
in production. I'm just curious why this wouldn't be working now, and
coming up with an error like this in it.

 

[bencoe]

The class I'm importing is a specific class. This specific .class is
in the classpath, and this used to compile before(in IntelliJ). We
are moving our Ant scripts to be platform independent, and have come
across an error like this preventing it from happening. We are also
compiling this under JDK 1.3, if that helps any.

What's your package structure look like? If you could give me a better
idea of what package the file you can't compile is in, and what the
import statement looks like, when compared to the root directory I
could probably help more.

Ben.

 

[Klauer]

Well, I'll try my best to describe the package structure.

We have a set of pre-compiled .class files that sit on a client and
server of our software on the hard drive. These supporting .class
files are generated by that program itself, and we pull reference and
import these directly from those physical locations. They do fall
under a package, as defined in their .java, but physically--on the
hard drive--they sit in a random directory, e.g. client/module1/
runtime/classes.

With the way we had it working before, this is an example of what most
of the extending java modules would look like:

package com.company.name.package.one;

import crClass;

public class crExtClass
{
....
}

the crClass.class actually belongs to the same
com.company.name.package.one package, as it was defined pre-
compilation, so importing while in that same package worked just
fine. What I don't get is why I'm seeing this error now, as IntelliJ
compiled the source down to .classes and .jars without as much as a
whimper.

 

[Steve Wampler]

The class I'm importing is a specific class. This specific .class is
in the classpath, and this used to compile before(in IntelliJ). We
are moving our Ant scripts to be platform independent, and have come
across an error like this preventing it from happening. We are also
compiling this under JDK 1.3, if that helps any.

For instance, the class is a pre-compiled class crSampleClass.

All of our source for many of these files simply

import crSampleClass;

public class crExtSampleClassExtension
{
...
}

Are you sure you're using JDK 1.3? From 1.4 on, all imports have to
be from named packages (i.e. you can no longer import from the 'default'
package). This would exactly explain the behavior you're seeing.

See: http://mindprod.com/jgloss/package.html for more information.

Maybe this feature seeped into JDK 1.3 also...

 

[Steve Wampler]

Are you sure you're using JDK 1.3? From 1.4 on, all imports have to
be from named packages (i.e. you can no longer import from the 'default'
package). This would exactly explain the behavior you're seeing.

See: http://mindprod.com/jgloss/package.html for more information.

Maybe this feature seeped into JDK 1.3 also...

Also see: http://forum.java.sun.com/thread.jspa?threadID=723987&messageID=4179116

 

[Steve Wampler]

Well, I'll try my best to describe the package structure.

We have a set of pre-compiled .class files that sit on a client and
server of our software on the hard drive. These supporting .class
files are generated by that program itself, and we pull reference and
import these directly from those physical locations. They do fall
under a package, as defined in their .java, but physically--on the
hard drive--they sit in a random directory, e.g. client/module1/
runtime/classes.

With the way we had it working before, this is an example of what most
of the extending java modules would look like:

package com.company.name.package.one;

import crClass;

public class crExtClass
{
...
}

I think the rule about not being able to import classes from the default
package into classes in named packages may have existed in 1.3. See the
reference in the previous posting to Roedy's Java Glossary for details.

 

[Klauer]

This may be exactly what my issue is. I will do a little
investigating and toying with the code to see if this resolves by
changing that.

 

[Lew]

I think the rule about not being able to import classes from the default
package into classes in named packages may have existed in 1.3. See the
reference in the previous posting to Roedy's Java Glossary for details.

We do realize that Java 1.3 is obsolete, don't we? In addition to 1.3 being
three major versions old, Sun took it off life support last year. In fact,
Java 1.4 is already in its end-of-life process. It's probably worth upgrading.

Also, to the OP, please do not top post, and your question would be a lot
easier if you'd provide a short, self-contained complete (compilable) example
(SSCCE) that illustrates the difficulty. If you were to COPY and PASTE the
error message instead of waving your hands with some "etc.etc. [sic]"
mumbo-jumbo people could help better. Accurate answers can only come from
accurate information.

BTW, the tool is "javac", not "JavaC". Computers are picky about that sort of
thing.

 

[Lew]

Top-posting re-ordered for clarity. Please post comments in line with the
material quoted to make life easier on everyone else reading the thread.

<http://forum.java.sun.com/thread.jspa?threadID=723987&messageID=4179116>

This may be exactly what my issue is. I will do a little
investigating and toying with the code to see if this resolves by
changing that.

Production code should never live in the default package anyway, not even
under old Java versions. I guess abuse of that principle must have led Sun to
add that "no import" rule.

 

[Roedy Green]

com.thing.etc.etc...: '.' expected

for hints or what error messages really mean see
http://mindprod.com/jgloss/errormessages.html