Using the default package - is there a special compiler flag?

[Bura Tino]

Hi,

I know that it is illegal to use a class from the default package in a named
package. But JBuilder 7 is able to somehome circumvent this problem even
though it is set up with a recent sdk. Does anyone know if JBuilder sets a
special flag that I can also set manually to get the same effect?

I'm using badly written libraries that put some key classes in the default
package.

Thank you very much in advance. A positive response will make my life a
whole lot easier.

Bura

 

[Neal Gafter]

I know that it is illegal to use a class from the default package in a named
package. But JBuilder 7 is able to somehome circumvent this problem even
though it is set up with a recent sdk. Does anyone know if JBuilder sets a
special flag that I can also set manually to get the same effect?

JBuilder has its own compiler that doesn't yet implement this constraint.

 

[Bura Tino]

JBuilder has its own compiler that doesn't yet implement this constraint.

Not sure this is so. JBuilder allows you choose your own SDK. I guess it's
possible that they only use the VM and not the compiler.

But in any case, was your answer pertaining to JBuilder or was it
essentially "no, there's no way to enable javac to do that"?

Thanks

Bura

 

[Andrew Thompson]

"Neal Gafter" ..wrote in message
Not sure this is so.

(chuckles) Trust me. Neal knows more about
compilers (particularly javac) than most of
us ever want to know. ;-)

...JBuilder allows you choose your own SDK.

So does javac.. You use the -bootclasspath
option to point it at any rt.jar, I do so in my
on-line compiler, which even allows people to
compile code aginst the MSVM..

...I guess it's
possible that they only use the VM and not the compiler.

But in any case, was your answer pertaining to JBuilder or was it
essentially "no, there's no way to enable javac to do that"?

The way I read Neal's comment,
no, javac cannot do that.

 

[Neal Gafter]

But in any case, was your answer pertaining to JBuilder or was it
essentially "no, there's no way to enable javac to do that"?

There is no way to enable javac to do that. It's not allowed by the language
specification, which is why the reference implementation doesn't support it.
With the exception of the -source flag that selects among the versions of the
language specification javac is asked to comply with, there are no compiler
flags that are intended to relax the set of programs javac will accept.

 

[Bura Tino]

There is no way to enable javac to do that. It's not allowed by the language
specification, which is why the reference implementation doesn't support it.
With the exception of the -source flag that selects among the versions of the
language specification javac is asked to comply with, there are no compiler
flags that are intended to relax the set of programs javac will accept.

This answer is very clear an unequivocal. Thank you.

I'm still left wondering how those library developers compiled their code.
(In particular, I'm talking about the lamentable JMatLink.)

Also, is it suprising in the context of language specification, that once a
"packaged" class A, which uses the "default-packaged" class B is compiled
(by that old and special JBuilder compiler) it can be then used on all vm's?

 

[Neal Gafter]

I'm still left wondering how those library developers compiled their code.
(In particular, I'm talking about the lamentable JMatLink.)

Using older or noncompliant compilers.

Also, is it suprising in the context of language specification, that once a
"packaged" class A, which uses the "default-packaged" class B is compiled
(by that old and special JBuilder compiler) it can be then used on all vm's?

Not surprising. The JVM is a completely different language than Java, though it
is intended to support Java well.

 

[Dale King]

Hello, Neal Gafter !

There is no way to enable javac to do that. It's not allowed by the language
specification, which is why the reference implementation

doesn't support it.

I realize that you are an expert on javac matters, but I think
you are overstating what the spec says. I was in many discussions
on thos topic years ago when it was allowed by javac and the only
compiler that didn't support it was Visual AgeFor Java. There
were people who claimed VAJ was non-compliant because it didn't
support.

The spec does not forbid importing from the unnamed package, but
does allow a host to not support it. A system can support it and
would not be non-compliant as you claimed in another message,
otherwise javac was non-compliant before 1.3.