🚀 go-pugleaf

Hi,

I don't use the import on demand often (because VAJ3 now ask
what to do and i always point to import only the needed class)

But is it really a problem?
If you compile your code later with a jdk1.2 compiler then
it shows up and you must change some import statements.
VAJ (java2) makes it very easy to detect because of its incremental
nature. You are right of course that you can better beat the problem
before it is there.

Enrique's post was about compiling with 1.1 and running it under 1.2
this works fine because lukely the import statements are just helpers
for the programmer. And the compiler saves full qualified names in the
class files.

Greetings
Johan

P.S.
do you have tested Swing1.1.1? Because IBM should!!
If they don't release 3.0 with 1.1.x then they should test if they can
import the swing repository i send you!
A complete clean install of 3.0beta i couldn't get swing1.1.1 added first
to the workspace: corruption all the time. I tried several times.
Then i added all the other projects (many errors because of !swing)
i wanted and try to add swing as last. That did work! Very strange.


Scott Stanchfield <thetick@jguru.com> schreef in berichtnieuws
7tsr90$140i$1@news.software.ibm.com...
> [Sorry about the cross-post -- I felt this is a MAJOR issue that needs a
> bit more visibility.]
>
> I REALIZE THIS IS LONG, BUT PLEASE READ AS IT IS CONTAINS CRITICAL
> INFO!!!
> Note that this is _not_ a problem in the VAJ tool, but VAJ makes it a
> bit too easy to accidently get this problem...
>
>
> Enrique's post on ibm.software.vajava.language made me check a few
> things out and I wanted to put a big warning out there on some coding
> practices in case people didn't read that thread.
>
> To sum up: IMPORT ON DEMAND IS DANGEROUS!
>
> "Import on demand" is use of "*" in import statements. Whenever you use
> a statement like:
>
>   import a.b.*;
>
> it tells the compiler "whenever you see a name you don't recognize, look
> in package a.b".  If you have multiple import statements like this
>
>   import a.b.*;
>   import x.y.*;
>
> and the unknown class exists in more than one of the listed packages,
> the compiler reports an ambiguity conflict.
>
>
> When I teach Java, I stress like crazy that you should _never_ use
> import-on-demand in production code. I recommend you use it during
> initial development for speed, but change it to explicit imports like
>
>   import a.b.C;
>   import x.y.Z;
>
> before releasing.
>
> THIS BECOMES CRITICAL FOR Java2!
>
> In Java2, Sun has seen fit to add "List" to java.util as part of the
> Collections support. This means that if your program has
>
>   import java.util.*;
>   import java.awt.*;
>
> and you use "List" in your code, it will compile cleanly under JDK
> 1.1.x, but fail under the Java2 compiler. Think about the poor
> maintenance programmer who has to figure out what to do...
>
> Sun is doing similar API foolishness in 1.3, where they add Timer to
> java.awt. This conflicts with Timer in javax.swing...
>
> [Personally I feel this is idiotic for them to do -- they know damn well
> that many people have
>
>   import java.awt.*;
>   import java.util.*;
>   import javax.swing.*;
>
> in their code. Not to mention the evil Date class in both java.util and
> java.sql since 1.1... This just begs for problems when they allow
> import-on-demand]
>
> ACTION TO TAKE:
> 1) NEVER use import on demand in your code. Always use fully-qualified
> imports
> 2) UNCHECK the "Add imports for fully qualified types from SmartGuides"
> box in the Coding options if you're using VAJ 3.x. This adds
> import-on-demand statements to your code.
>
> Feel free to follow up or email me with questions or concerns...
>
> --
> -- Scott
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Scott Stanchfield    thetick@jguru.com    http://www.jGuru.com/thetick
> jGuru Training by MageLang Institute      http://www.jGuru.com
> VisualAge for Java Tips --> http://www.jGuru.com/thetick/visualage/tips
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
>
>