This question already has answers here:
How should I name my Java 9 module?
(2 answers)
Closed 4 years ago.
What's the naming convention for java 9 modules? Let's say my package name is me.jasonyeo.awesome.project, and whenever I create a module-info.java file in IDEA, it would suggest me to name it awesome.project
Is that the convention? Or should I name it me.jasonyeo.awesome.project?
It seems, IDEA’s suggestion is based on the fact the Java’s builtin modules have two components, e.g. java.base or java.desktop, but that doesn’t make a good suggestion for 3rd party modules.
JLS §6.1, Declarations says:
The name of a module should correspond to the name of its principal exported package. If a module does not have such a package, or if for legacy reasons it must have a name that does not correspond to one of its exported packages, then its name should still start with the reversed form of an Internet domain with which its author is associated.
Example 6.1-2. Unique Module Names
com.nighthacks.scrabble
org.openjdk.compiler
net.jcip.annotations
You may find the cited part faster using the direct link to the example
So your assumption is right, the recommended module name is me.jasonyeo.awesome.project, not awesome.project.
Related
This question already has answers here:
What is Facades used in Laravel?
(3 answers)
Closed 4 years ago.
Can you please describe elaborately about Facade?
A Facade is an alias to classes that are available in the application's service container, these classes can be Laravelor vendor package classes. Facades are used because they provide a terse, memorable syntax that allows us to use Laravel/Vendor features without remembering long class names.
In short Facades allow you to use fro example JWTAuth::getToken(), instead of having to type out Tymon\JWTAuth::getToken() in full, increasing code readability.
[read More][1][1]: https://laravel.com/docs/5.5/facades
This question already has answers here:
What is the purpose of the package declaration?
(2 answers)
Closed 6 years ago.
All of the Go source files inside directory x have package name x declared on top. I know this is not mandatory but doing otherwise will make things unnecessarily complex. So why the go compiler does not infer the package name from directory name?
This exists in almost many other languages like Java or C# where you are forced to declare what can be easily calculated at compile time.
What is the rationale?
Without package you wouldn't be able to distinguish between main programs and libraries.
Furthermore, according to the language specification, the language does not require a package to be identical with a directory:
An implementation may require that all source files for a package inhabit the same directory.
And in practice some packages have different names than their import paths:
If the PackageName is omitted, it defaults to the identifier specified in the package clause of the imported package.
Consider github.com/google/go-gcm which has package gcm in its files. Projects that use this library will have:
import "github.com/google/go-gcm"
And then call things like this:
res, err := gcm.SendHttp(APIKey, notification)
This is particularly common with - because you can't use it in an identifier.
This question already has answers here:
Organizing a multiple-file Go project [closed]
(7 answers)
Closed 9 years ago.
OK, Go's major selling point is its ease of compilation and wonderful toolchain, but as a go newbie I'm really lost there and can't understand the documentation on that point.
I have a stack toy example within two files (one for the type definition and methods, called stack.go, one for the main program, called main.go), both are in my GOPATH/src/stacker directory.
How should each file be named ? Does it have any importance at all ? Is there at least a convention ? A mandatory naming ?
What should be the package name ? I understood they should use the same package name, but which one ? Is it stacker ?
In main.go, how should I use the import directive to import stack.go ?
I have tried many combinations, none working until now.
You can name the files however you like, just beware of special suffixes like _test and _<arch> (_darwin, _unix, etc.). Also note that files prefixed with . or _ won't be compiled into the package!
It is recommended that you name the package like the folder the file is in, although it's possible (but confusing) to name a package differently in the declaration package mypkg
If stack.go is in the same folder/package as main.go, you don't need to import. Everything delcared in stack.go is already available in main.go, because it is in the same package.
If stacker should compile into an executable, you should use package main.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Is there an API for verifying the MSIL of a dynamic assembly at runtime?
I'm dynamically generating an assembly using Reflection.Emit and the like.
For a unit test, I'd like to PEVerify my IL.
I can do it from the command line, but I'd rather do this in code.
Is there a way to do this which is more convenient than calling PEVerify.exe? Ideally, I'd like to directly hand it the dynamic assembly without having to save that assembly to disk first.
Ideally I'm looking for something along the lines of (psuedocode:
Assert.IsFalse(new PEVerifier(myAssembly).Verify().Errors.Any());
You could, as the 'duplicate' question's answer suggests, figure out how to hook into the native DLL used by PEVerify.exe (which I'm guessing would cause issues since it is not documented and probably is subject to change).
The other option would be to use the AssemblyBuilder class to write the dynamic assembly that you're creating to the disk at a temporary location and then call PEVerify.exe via the System.Diagnostics.Process class (much like this PEVerifier class example does).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Does anyone know of the practical reasons for the com.company.project package structure and why it has become the de-facto standard?
Does anyone actually store everything in a folder-structure that directly reflects this package structure? (this is coming from an Actionscript perspective, btw)
Preventing name-clashes is a rather practical reason for package structures like this. If you're using real domain names that you own and everybody else uses their package names by the same role, clashes are highly unlikely.
Esp. in the Java world this is "expected behaviour". It also kind of helps if you want to find documentation for a legacy library you're using that no one can remember anymore where it was coming from ;-)
Regarding storing files in such a package structure: In the Java world packages are effectively folders (or paths within a .jar file) so: Yes, quite a few people do store their files that way.
Another practical advantage of such a structure is, that you always know if some library was developed in-house or not.
I often skip the com. as even small orgs have several TLDs, but definitely useful to have the owner's name in the namespace, so when you start onboarding third-party libraries, you don't have namespace clashes.
Just think how many Utility or Logging namespaces there would be around, here at least we have Foo.Logging and Bar.Logging, and the dev can alias one namespace away :)
If you start with a domain name you own, expressed backwards, then it is only after that point that you can clash with anyone else following the same structure, as nobody else owns that domain name.
It's only used on some platforms.
Several reasons are:
Using domain names makes it easier to achieve uniqueness, without adding a new registry
As far as hierarchical structuring goes, going from major to minor is natural
For the second point, consider the example of storing dated records in a hierarchical file structure. It's much more sensible to arrange it hierarchically as YYYY/MM/DD than say DD/MM/YYYY: at the root level you see folders that organize records by year, then at the next level by month, and then finally by day. Doing it the other way (by days or months at the root level) would probably be rather awkward.
For domain names, it usually goes subsub.sub.domain.suffix, i.e. from minor to major. That's why when converting this to a hierarchical package name, you get suffix.domain.sub.subsub.
For the first point, here is an excerpt from Java Language Specification 3rd Edition that may shed some light into this package naming convention:
7.7 Unique Package Names
Developers should take steps to avoid the possibility of two published packages having the same name by choosing unique package names for packages that are widely distributed. This allows packages to be easily and automatically installed and catalogued. This section specifies a suggested convention for generating such unique package names. Implementations of the Java platform are encouraged to provide automatic support for converting a set of packages from local and casual package names to the unique name format described here.
If unique package names are not used, then package name conflicts may arise far from the point of creation of either of the conflicting packages. This may create a situation that is difficult or impossible for the user or programmer to resolve. The class ClassLoader can be used to isolate packages with the same name from each other in those cases where the packages will have constrained interactions, but not in a way that is transparent to a naïve program.
You form a unique package name by first having (or belonging to an organization that has) an Internet domain name, such as sun.com. You then reverse this name, component by component, to obtain, in this example, com.sun, and use this as a prefix for your package names, using a convention developed within your organization to further administer package names.
The name of a package is not meant to imply where the package is stored within the Internet; for example, a package named edu.cmu.cs.bovik.cheese is not necessarily obtainable from Internet address cmu.edu or from cs.cmu.edu or from bovik.cs.cmu.edu. The suggested convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.