Develop Reference

Is something else than com and org used in java?

After reading the question Java packages com and org and answers, I am still curious:
Is there some strict rule that I can use only com edu and org?
And, is it bad idea to create package starting with something else than this?
Say, I am fro, Czech Republic and I own PavelJanicek company, can I create package which would be imported like
import cz.paveljanicek.usable.awesomeutils;
edit: Since one of answers supposes it should be possible, can I apply it also to new domain TLDs?
example:
import berlin.berlincity.touristguide.api;

A package name is defined by the language specification as a succession of valid identifiers, separated by ..
So the convention (for unicity purposes) is to use your domain name but any valid identifier can be used. This is a valid package name too:
é.è.û.¥

You should check out this link: Java Packages and Java Package namings
You should also look at similar topic
At last a quote to add:
If you're just doing personal projects where nobody else will use the code, then you can make up a package name that you like. Don't
make up something that starts with com. or net. or other top-level
domain though, because that would imply that you own the domain name
(ie. using com.john as your package name just because your name
happens to be John is not a good idea).
If you're going to give the code to anybody else, you should use a
globally unique package name, which according to Java conventions
means you should register and use a domain name.
Short: Use whatever you like :)

yes, that's the way you have to do if you own paveljanicek.
there are a lot of 'com' and 'org', but you can find many others;
for example, logback logging library contains classes in package
ch.qos.logback....

You can use whatever you want just honoring the Java limitations for identifiers.
Said that, usually is safe using Java conventions, but killerapp.gui.Main is a valid class identifier

You missed a lot of the information given in the answer. Here once again a snipped of what Sun defined:
The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.
Today we have even more top-level domains. The important part is to choose the domain you own in reverse order. I suggest you should read the answer once again, slowly. The goal is to avoid naming conflicts by choosing unique namespaces. And because domain names are already owned by a single company / person, they are good candidates to choose.

Good naming convention for scala "pimpers"

I don't like the fact that in scala its not obvious what some of my imports are doing - imports for implicits so i'm trying to come up with good naming conventions for them so when i see in my import statements something like:
import com.mycomp.example.RectangleImplicits
or
import com.mycomp.example.RectanglePimper
I know i cant remove that import because its being used for pimping.
My problem with the above names is that sometimes I actually do an adapter, in that case
import com.mycomp.example.RectangleAdapter
does not say anyting about the fact that its actually a pimper however i don't want to name it RectangleAdapterPimp because the name becomes to combersome...
is there a golden bullet naming convention for that?
thanks

In std Scala library such classes are prefixed with Rich, like RichString, RichInt, etc... So why not to use RichRectangleAdapter

Java Namespace - Two classes with the same name in different packages

I am coming from Objective-C where we don't have packages and namespacing.
Android has android.text.format.DateFormat which has static methods that return java.text.DateFormat instances (getLongDateFormat() and getMediumDateFormat() specifically).
Are these methods referred to as "static methods" or "class methods" or both interchangeably?
Looking at Android documentation, how am I suppose to know that the android.text.format.DateFormat methods return a java.text.DateFormat instance and not an android.text.format.DateFormat instance (returning an instance of the latter is what I initially expected)?
How do I import the necessary packages to be able to use both of these classes in my source?
Is it possible to write my implementation code this way:
DateFormat df = DateFormat.getLongDateFormat(this.getActivity());
mLabel.setText(df.format(mEvent.getDate());
The other way I would write it would be to use the full package names, but this seems unnecessary:
java.text.DateFormat df = android.text.format.DateFormat.getLongDateFormat(this.getActivity());
mLabel.setText(df.format(mEvent.getDate());

Not sure why this is downvoted, it's a useful discussion.
1) I've always heard them referred to as "static methods".
2) The only way to see it is to follow the links. The documentation is definitely misleading in this case.
3/4) The typical way to do this in java is to not import one of the classes, and fully-qualify its class name. So if you elected to import java.text.DateFormat and not the android version, you'd do something like DateFormat df = android.text.format .DateFormat.getLongDateFormat(this.getActivity());

From the JLS:
A method that is declared static is called a class method.
I would say that I hear "static method" used more often than "class method", but both are in use and should be understood by competent Java developers.
The only option would be to hover the links on the return values. This is an example of extremely poor API design, with a name conflict built in, and the android.text.format.DateFormat should have been named something like DateFormatFactory. It appears that this class may have been intended to serve the same purpose as the java.text class originally and that API compatibility left it stuck. See java.sql.Date for a similar story.
Using import is a convenience only, allowing you to use the simple class name in your code. It's always legal to use a fully-qualified class name, and the compiler translates imported class names into fully-qualified ones. You can't import multiple classes with the same name because then there's no way to distinguish them
I suggest importing the class from java.text for two reasons: You'll probably be using it more often, and it's the more "standard" class. When faced with the choice of qualifying one of two classes with the same simple name, use the simple name for the one that developers would usually assume it refers to.

import classes from org.rda in java language

My question is very basic. I wanted to use the randomX in my java code.
jgap.sourceforge.net/javadoc/3.01/org/jgap/util/randomLEcuyer.html
sample code from here:
https://code.google.com/p/fractalproject/source/browse/FractalProject/src/org/dla/model/DlaModel.java?spec=svn40&r=40
I am already using another package, lets say MyProj, with other files of my current code.
I used the following lines,
package MyProj;
import org.jgap.util.randomLEcuyer
But eclipse does not recognize the randomLEcuyer. I appreciate if you help me.

First of all, you have two package declarations in your code:
package MyProj;
package org.dla.model;
This is invalid. Second, the class you want to use, as the javadoc you linked to indicates, is org.jgap.util.randomLEcuyer, and not org.rda.dice.randomx.randomLEcuyer.
Finally, I would be careful in using a class that doesn't even respect the basic Java naming conventions: classes should start with an upper-case letter.

Why won't Javadoc make my subclasses inherit documentation from Java's classes?

I've been searching for an answer for several months and I have tried multiple things, including unzipping the Compressed folder src.zip and using it as a parameter for Javadoc (for example: javadoc -sourcepath src com.example.test)
This is the default Javadoc that comes with the JDK 6 Update 24.
Let's say that I'm working on a new map that implements the java.util.Map interface. By default the methods that I override from the Map interface should inherit the documentation from the interface, if I'm not mistaken. However, javadoc never does it.
The only thing that has worked this problem out so far, has been actually javadoc-ing the classes written by Java (for example: javadoc com.example.text java.util). I don't want to do this because it makes it seem like I rewrote the Java classes, but is this the only way to do it? If it is I suppose I could just live with it, but it was my understanding that there was another way to do this.
Thank you =) I'm sorry if this is a little messy. This is my first time using Stack Overflow. I'm also sorry if this question has been asked already. I have read many similar questions by they don't cover everything that I wanted to ask and I've found them very confusing because they involve writing your own implementation of Javadoc. Anyway, thank you in advanced =)
Edit: May 25 at 4:44
All right =) If I understand correctly, you would like to see an example. This is a simpler example that I tried to see if it was because I was trying something that shouldn't work.
package com.example;
/**
* A simple class that returns an upper-case string representation.
*/
public class UpperCaseObject {
#Override public int hashCode() {
return super.hashcode();
}
/**
* {#inheritDoc}
*
* <P>The {#code toString} method for class {#code UpperCaseObject} returns
* converted to uppercase.</P>
*
* #see String#toUpperCase()
*/
#Override public String toString() {
return super.toString().toUpperCase();
}
}
I moved this example (file name is UpperCaseObject.java) into a directory javadoc-test/com/example and I also made another directory javadoc-test/java/lang, placing Object.java (from src.zip) in it.
The call to javadoc that I made was javadoc -link http://download.oracle.com/javase/6/docs/api/ com.example from the directory javadoc-test. I have the jdk6 bin directory in my path parameter.
The two things that I expected was for UpperCaseObject.hashCode to inherit all of the documentation, and UpperCaseObject.toString everything before the extra paragraph from java.lang.Object. However, unfortunately, I didn't get any of the documentation.
Edit:
Well, what I had to do was the following. It is just a simple workaround.
I copied all the source files from source.zip like you would normally do so.
I also made package files for each package. They contain the very first paragraph (the one with the summary) and a second paragraph that says "See the Package Summary in the Java™ Platform, Standard Edition 6 API Specification for more information."
The source files were essentially the super classes, their super classes (and interfaces), and any exceptions that they threw that were also in the same package. The only exception was java.lang where I only needed to get Object. The exceptions were also needed because except for java.lang, the other packages did not link if an exception was in the same package as the throwing class.
I javadoc'd all the packages that I was using/subclassing/exception-throwing from.
I'll make sure to include some information about the standard packages and my own package in he overview file.
Unfortunately, I can only do a work around for now, but I'm convinced that it may be a problem with my version of Java. It sounds like other people have had a similar problem and came up with their own workarounds. This is just my own =)
I'll still be taking answers, but this is the most convenient option in the meanwhile. Thank you very much!

The source file for the inherited method needs to be on the -sourcepath of the javadoc tool when it runs. You don't need to pass the inherited class on the command line.

One thing you can do is link to the official Javadoc for those classes, using the -link option:
javadoc -sourcepath src -link http://download.oracle.com/javase/6/docs/api com.example.test
This will allow Javadoc to treat the classes of the SDK as "external referenced classes". From the Javadoc documentation:
The referenced classes whose documentation is not being generated during a javadoc run. In other words, these classes are not passed into the Javadoc tool on the command line. Links in the generated documentation to those classes are said to be external references or external links. For example, if you run the Javadoc tool on only the java.awt package, then any class in java.lang, such as Object, is an external referenced class. External referenced classes can be linked to using the -link and -linkoffline options. An important property of an external referenced class is that its source comments are normally not available to the Javadoc run. In this case, these comments cannot be inherited.
Note that the Javadoc for these class will still not be inherited. However, you can now link to it, like so:
public class MyMap implements java.util.Map {
...
/**
* #see java.util.Map#isEmpty()
*/
#Override
public boolean isEmpty() {
...
}
}
[EDIT]
The #see tag is there for illustration. Javadoc should automatically generate a "Specified By" link, so you could omit the Javadoc comment altogether.