1. How about using class initializer ? When it is run ? If i include a class
from package, will it be also an initializer run for every class in that
package ?
2. I have problem with this code :
// FILE primer.java
import static narzedzia.LiczbyPierwsze ;
public class primer {
public static void main(String[] args) {
LiczbyPierwsze.main();
// TODO, add your application code
System.out.println("Hello World!");
}
}
// FILE LiczbyPierwsze
package narzedzia;
public class LiczbyPierwsze {
protected final static long length = 21;
protected final static long sito [] = new long [1<<length];
public static void main(String[] args){
int i;
for (i=0;i<length;i++){
System.out.println(sito[i] + "\n ");
}
}
public final static long czyPierwsza(long x ){
return 0;
}
public final static long naCzynnikiPierwsze(long x){
return 0;
}
}
//
When compiling this I've got: " cannot find symbol main".
3. Is the static public main() method a class initializer ? If so, suppose
we have code like that :
class Dummy{
static int i=3;
public static main(){
i=7;
}
public static get_i{
System.out.println(i);
}
}
and than if someone call Dummy.get(i) out of that class what would be the
output of the program. Yes i know i can run it myself, but could someone
explain me the result ? Is the line
static int i=3; regerded as a part of initializer ?
>1. How about using class initializer ? When it is run ? If i include a class
>from package, will it be also an initializer run for every class in that
>package ?
see http://mindprod.com/jgloss/initialisation.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
>import static narzedzia.LiczbyPierwsze ;
drop the static. You are doing an ordinary import.
See http://mindprod.com/jgloss/import.html
Bleh, another page that assumes that everyone owns their own domain
name (and can afford to keep it in perpetuity, for as long as their
Java code will be in service, and remember the lesson learned in the
y2k crisis -- that is always a lot longer than you think it will be or
plan for!)
I have an interesting suggestion for getting unique package names that
is free, and just as sure to avoid name clashes, and only depends on
one web site with proven staying power sticking around.
If you have your own domain and are fairly sure nobody else will have
it decades from now go ahead and use Sun's suggested naming
convention. Otherwise (and this shouldn't clash with it) find a page
on the web that is "yours", e.g. a forum thread you started, your
profile on a forum site, the page at Google Groups with the first post
of a Usenet thread you started, etc.; and feed its URL to http://tinyurl.com
to get a TinyURL linking to it. Remember it links to a page that is in
some way YOURS. Now just start your package name with the gobbledygook
at the end of your TinyURL, after the last slash in the TinyURL. It
should be unique and stay that way, and it's very unlikely to be
"com", "org", or some other TLD.
For example, this thread is at GG at
which gives a TinyURL of
so our OP "Thomas" can safely use names like
3asyxw.thomas.projectname.module.Class
and avoid clashing with anyone else who uses either this method or the
"official" method for picking package names, since http://tinyurl.com/3asyxw
leads to a web page effectively belonging to Thomas, with his name on
it and everything. Even if that page later goes away, the TinyURL is
probably forever (even if it's 404) and the same (in this case six)
characters in the same order won't be reissued for any other URL, and
it's highly unlikely GG will someday reorganize and have a completely
different thread at the same GG URL posted above rather than it always
linking to either this thread or a 404 page.
Ok neither of you answered to my questions, but thanks.
Eh. Identifiers starting with digits might be a problem. I suggest
amending this to always prepend an "a", whether or not the tinyurl
code starts with a digit, e.g.
a3asyxw.thomas.projectname.module.Class.
> // FILE primer.java
>
> import static narzedzia.LiczbyPierwsze ;
Just import narzedzia.LiczbyPierwsze;
>
>
> public class primer {
>
> public static void main(String[] args) {
> LiczbyPierwsze.main();
You declare the reference main function to be main(String[] args), so you
would have to do something like this:
LiczbyPierwsze.main(args);
> 3. Is the static public main() method a class initializer ? If so,
> suppose we have code like that :
>
>
> class Dummy{
>
> static int i=3;
> public static main(){
> i=7;
>
> }
>
> public static get_i{
> System.out.println(i);
>
> }
>
> }
>
> and than if someone call Dummy.get(i) out of that class what would be
> the output of the program. Yes i know i can run it myself, but could
> someone explain me the result ? Is the line
> static int i=3; regerded as a part of initializer ?
The value will be 3. The static intializer is everything of the form
static {variable} i = {expression} and everything included in static {}
blocks.
I don't see that assumption embodied anywhere on that link.
> Java code will be in service, and remember the lesson learned in the
> y2k crisis -- that is always a lot longer than you think it will be or
> plan for!)
> I have an interesting suggestion for getting unique package names that
> is free, and just as sure to avoid name clashes, and only depends on
> one web site with proven staying power sticking around.
"Proven"? Now you are assuming that tinurl will be around in perpetuity,
which in light of the Y2K+1 "crisis" may not be safe.
> If you have your own domain and are fairly sure nobody else will have
> it decades from now go ahead and use Sun's suggested naming
> convention. Otherwise (and this shouldn't clash with it) find a page
Key words being "suggested" and "convention". In point of fact, the
convention allows you to make up your own package "domains" and does not in
any way require that you actually possess that domain, e.g., registered with
InterNIC.
> on the web that is "yours", e.g. a forum thread you started, your
> profile on a forum site, the page at Google Groups with the first post
> of a Usenet thread you started, etc.; and feed its URL to http://tinyurl.com
> to get a TinyURL linking to it. Remember it links to a page that is in
> some way YOURS. Now just start your package name with the gobbledygook
> at the end of your TinyURL, after the last slash in the TinyURL. It
> should be unique and stay that way, and it's very unlikely to be
> "com", "org", or some other TLD.
This is a very good suggestion, if you feel the need to tie your fake "domain"
with something in the outside world, often a good idea.
> and avoid clashing with anyone else who uses either this method or the
> "official" method for picking package names, since http://tinyurl.com/3asyxw
It's "official" as a suggestion, not a mandate, and obviously only for those
who actually do have some assurance that they can keep their domain for a
while, as, say, companies like IBM or Oracle, or organizations like PostgreSQL
have. There is no real requirement that your packages' "domains" actually
correspond to real domains - a point in favor of your tinyurl trick. Sun
suggests their suggestion just as a way of getting a likely unique package
name, which is the real goal.
Consider - if Oracle Corp. somehow lost the "oracle.com" domain, how much real
additional difficulty will new packages in the "com.oracle.*" patterns cause?
Likely not too very much - most folks using "old" com.oracle packages will
not upgrade to newer ones, and most folks using newer ones likely will not
want the old ones.
Also, it's a practical convention - anyone is permitted to write
"com.oracle.*" packages, but it isn't in our interest usually to create such
name conflicts. The idea is to allow packages from many places to coexist
peacefully.
The tinyurl trick is a clever way to get such unique names. So is using a
package scheme based on your own name or other unlikely string, e.g.,
package person.doe.john.q.genies.lamp;
Even if others use a similar top-level package hierarchy, chances are good the
specific packages won't collide. It's not as clean or objective or (for now)
reliable as the tinyurl trick, though.
--
Lew
>> Roedy Green wrote:
>>> drop the static. You are doing an ordinary import.
>
> Ok neither of you answered to my questions, but thanks.
>
Actually I think he did.
>Ok neither of you answered to my questions, but thanks.
That is no way to persuade people to spend more time working to help
you. I did answer your questions. You did not understand or perhaps
did not like the answers.
Simple ask a follow on question. There no need to flog your slaves for
failing to please your highness. You are not owed any answers.
You did not ask about package naming, and apparently you did not
follow the link from import to package.
See http://mindprod.com/jgloss/package.html
There is a very simple solution if the $8 a year is too onerous to get
you a domain.
$8 a year *in perpetuity*, or however long your code will be in use
(and y2k taught us that assuming it won't be in use for more than
forty years is foolhardy). The bigger risk isn't that you can't afford
it but that you'll forget to pay it and let the name lapse. Then
someone else grabs it. Then they release code of their own with
clashing names...
probability(you forget to pay for the domain) *
probability(the other guy also write Java code) *
probability(your code and their code will be used together)
is not that frightening in my view.
Arne