I just started looking at the new FIRST Robotics Java SDK, which includes project generators to build sample robotics programs.
Something I was curious about is the file it generates begins with:
package edu.wpi.first.wpilibj.templates;
Does this actually make sense? (The library I'm using is from first.wpi.edu, but my project doesn't really have any affiliation with them otherwise.) I'd think that I should want to instead use my own reverse domain for the package specifier.
Thoughts?
I would say your intuition is correct. I would personally refactor it to be your own package. Is this just a tutorial project it generated, or is it your project that you are going to be working on. If this is not a tutorial project, I would be surprised if there is no way to override the package name when it is created.
the idea is that the package names will be globally unique
I would think that it would generate something in a customer supplied package name? Ie: ask the user the package they would like to use.
Does it generate things in more then one package?
It probably does this so it can access "package local" classes.
Related
Is it possible to modularize the app/models folder adding packages into it in play2.1 framework (java)?
Actually I have to put all of my classes (models) into app/models folder, otherwise play! framework can't find my classes on compilation time. I really don't like to have all of my classes into a single folder.
I did a research about play2 projects on github and most of them are simple and have all of their models into app/models with no packages into this folder as the samples bundled with the framework.
Do you add packages into app/models folder in your project? If so, do you have to configure something else?
Thanks for your time.
You can create as many packages in the models package as you want, and I consider this good practice. I.e. this is how my current structure looks like:
/models
/i18n
/forms
/roles
/utils
/users
The only thing that you must change is that you must use the fully qualified name as parameter in templates. (see this post)
Besides that, if you call static methods, you must also use the full name: #User.getUsername becomes #users.User.getUsername.
I am not so aware of the java project structure. I have few selenium tests which I want to write in java. So I have chosen eclipse as my editor. Here I wan to create a new java project with proper folder structure as I am planning to add few more java classes in future.
Please let me know how to create an idea java project in eclipse. I have seen people create something like com.org.project_name etc and then src , resources directories inside that.
I am not able to make any sense out of those. Please explain.
The software project management tool Apache Maven recommends, uses and expects a common directory layout that can be considered as best practise.
An overview can be found here: Introduction to the Standard Directory Layout
In Java you can create packages. Simply said packages are folders that contain classes.
The statement import java.net.Socket means: from the folder java/net import the class named Socket.
The statement package myApplication.util.SuperCounter means that the class SuperCounter can be found under myApplication/util folder.
Packages are an easy way to organize your work. Because in a big project you will have class name collisions (i.e. classes that use the same name). With packages you can avoid it.
Also Java supports default (private, public, protected). Default methods, attributes, classes can only be seen by elements in the same package!
Eclipse should create the proper folders for you...here is an example
http://www.wikihow.com/Create-a-New-Java-Project-in-Eclipse
If you want to have a Java Project then go to File -> New -> Java Project.
If its web application then, select Dynamic Web Project.
These will automatically create the required structures.
In Java you work in packages, which define the scope of your classes, and is basically the only thing you should really be concentrating on in the beginning. There's a good article on the subject here - http://docs.oracle.com/javase/tutorial/java/package/packages.html
Every time I look at some Java source code, I find myself surfing in a folder that has folder that has folder that has folder in it etc. Why does Java require so many nested folders, which have nothing else in them except the new subfolder?
For example:
https://github.com/halfninja/android-dragcontrol3d/tree/master/src/uk/co/halfninja/android
That's probably not the worst example, but there are two folders "uk" and "co" that just don't make sense. I see this in Java sources only!
And for example minicraft: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=398
import com.mojang.ld22.gfx.Font;
import com.mojang.ld22.gfx.Screen;
import com.mojang.ld22.gfx.SpriteSheet;
Why not just write:
import gfx.Font;
import gfx.Screen;
import gfx.SpriteSheet;
That's so much cleaner.
(I have never programmed in Java.)
These are there to prevent conflicts with other jars. Having something like the company url in the package name makes it likely to be unique enough to not conflict with someone else's package and classes.
Your example is a good one, since it seems pretty reasonable to imagine two people thinking of using "gfx" as a package name and with classes like Font or Sprite. Now, if you wanted to use both of them, how could you since the package and class name would be the name?
Your way is cleaner, but it assumes nobody else in the world is ever going to create a package called gfx, which is a pretty weak assumption. By prepending your reversed domain name, you create a unique namespace that avoids collisions.
This fits perfectly with the "culture of sharing" that pervades Java programming, in which applications typically combine large libraries from many sources.
In Java, the convention is to name your packages (which correspond to the folder structure containing your code) with information identifying your organization (typically including a TLD and the company name) and project (which might add a few more sections).
Being more specific like this also reduces the likelihood of namespaces accidentally colliding with eachother.
It's merely an organizational technique for preventing namespace conflicts. Nothing more or less. Java package names match the underlying directory structure, so any organizational pattern at the package level will be reflected there. It's typical for teams to start their package names with their organization's name and wax specific. This is simply convention, but it's ingrained and should be followed absent a very good reason.
It's all about Namespaces. With 'Namespaces', you can create 2 classes with the same name, located in different packages/folders. This Namespace logic can also be used for creating 'Access Privileges', etc etc. Below are some links:
1) Namespace
2) Java Package
3) Java Package Naming Conventions
EDIT: Let us assume that you are creating a new project and are using 2 open source frameworks from companies/organizations - comA and comB. Also, let us assume that comA and comB have created a class in their projects with the same classname. Now, with the Java package naming conventions, we have com.comA.SomeClass and com.comB.SomeClass. You can import and use both the classes in your class, without having a conflict. This is just a simple example. There are other uses from this naming convention.
If you want to share code with everyone else, but use generic names without conflict. its considered good practice to include you domain name (backwards)
Everyone write a package called gfx.Font you wouldn't be able to use more than one version in the same application.
You might feel your code will not be shared with the world (or even should not be shared) In which case, a shorted package structure may be simpler.
If you use an IDE, it does a good job of hiding long package structures so you don't need to worry about it.
This is due to recommended packaging structure. In large projects, so many packages/libraries are used and in order not to put source files into same folder with another library, programmers put their source codes into unique folders. As websites are unique, it is a convention to use packaging structure that looks like folder structure of websites.
Java does not require anything: you can just put all your classes in the default package and surf away. But for serious projects that kind of organization is not only wise, it's mandatory. The com.mojang.ld22 part is just a convention:
com = either this or org, java/javax for official packages
mojang = second part is company name
ld22 = third part is application name
I wrote a package in eclipse (Java/Android package, that is). Now I want to make another package which is a slight variation on the original. My plan is to copy and paste each .java file into the new package and change the import package.somename to the name of the new package, and develop from there. Is there a better way to do this?
Select the package in the project explorer, press Ctrl+C and then Ctrl+V, Eclipse will prompt with a package name conflict warning and ask you to enter a new package name. Just enter it and Eclipse will repackage all copied classes accordingly.
Unrelated to the problem, there's a design smell in your approach :)
In a comment on an answer you've given the reason you want to do this: "Now I want to put up a free demo version, with some functionality removed."
Instead of copying all the code to another package I'd take the approach of having only one code base and using a build parameter to specify if you're building the free or commercial version. The classes and config (e.g. spring) that are included in the build could then depend on this parameter.
Duplicating the codebase may seem like the easier option now but will duplicate your work in the long run when maintaining it, and increase the risk of bugs.
How about just extend the classes you want to change? that way you can the two variations in the same package
Depending on how much "slight variation" really is you might want to keep it as one package and handle the differences. Reasons you might not want to do this is that by duplicating a whole package for only small changes is not really clean. Duplicated code is a code smell and can cause headaches in the future if a bug is found in one package and needs to be fixed as well in other sections of code.
To answer the question though, Eclipse should have the functionality to copy the whole package and to paste it back into the project. You will have to rename either one of the packages so that you have a unique package name though.
I've read the syntax conventions for naming Java packages, and I know the general rule of thumb, but what if you've just started building your application, you haven't chosen a license, and it is a personal project? It doesn't make sense to throw in "com.mycompany" or "org.myorganization" if that is not the case. Does anyone have suggestions for this?
Many Java books and online examples just use the name of the book or project, i.e., ejb3inaction.* or tutorial.*.
I usually just go with something like lastname.firstname.<other packages>. The package name should just be unique, and the combination of your last name and first name is probably unique enough (if you have a common name, throw in a middle initial or a middle name or something like that).
Perhaps org.{myname} ?
I don't think it particularly matters for personal projects. In fact I've seen commercial (in-house) projects flout this rule and simply call their packages {servicename} or similar (which I don't particularly like). The packaging rules are designed to prevent name clahes when sharing code cross-enterprise (or organisation) and consequently for personal projects you can use most anything.
Java packages are just for namespacing. Call it whatever you want! Think of something that will be useful to you later on when you want to remember what this code was supposed to do.
how about org.{projectname}? Think about some open-source projects (e.g. org.hibernate, org.springframework and org.junit) ... did they start this way because it was the name of the website, or the name of the project itself?
Besides, re-factoring is so trivial these days, just name it whatever you want.
What about name.yourname.myproject or net.sf.myproject or com.googlecode.myproject or simply myproject.
As long as you don't make your code public, it's not that important actually (and you can easily refactor it later before releasing your code if you need to). Once people start using your code, it's another story...
In the case you might also think about sharing the project (making it an open-source project), to open an project entry, in that case you can use something like 'net.sf.{project-name}.*', be careful here, that the project-name, must be the unix name, of the project (at least then you follow the rules correctly :)
SourceForge
Java Net
Google Code
Launchpad
JavaForge
Tigris.org
I generally use nl.myname.myapp for all personal projects. There is no rule against open sourcing something that uses your personal name. If you decide to make the project bigger and create a web site for it you can always rename the packages if you really want to.