We have muti-module gradle project, where we are planning to introduce parent level one package to reduce conflict with other module. Now this single package would have 200+ packages and 1000+ classes.
For example
Moduale1-|
|
|-src-|
|-main-|
|-java-|
|-module1-|
|-subpackage1
|-subpackage2
|-subpackage1
....
Module2-|
....
Module3-|
....
we are using JDK 8.
Does this architectural change is OK? Does it would have any issue in future like when it commes to JDK upgrade? or modular persective is this bad practice?
I'm not finding any limitation with single package with these manay subpackage and classes.
Related
I develop JavaFX app with Hibernate for database access, and was faced with a problem:
I have in my module-info.java, automatic module from:
requires org.hibernate.orm.core; ( org.hibernate:hibernate-core:5.4.12.Final)
requires sqlite.dialect; (com.zsoltfabok:sqlite-dialect:1.0)
They both have the same package "org.hibernate.dialect", since it is prohibited, what I can do to resolve this issue? I certainly could change the project to not use modules, and package it with jpackage as regular fat jar. But I would like to proceed with modularized one.
Thanks.
sqlite-dialect uses the same package as hibernate-core which is either a dirty (my opinion) workaround for accessing foreign package private members or completely unnecessary if no package private members are accessed (I haven't checked it). You could make a fork of sql-dialect an change the package name (e.g., com.zsoltfabok.hibernate.dialect.sqllite), try if it works and in case it does use the fork instead (and create a pull request to the original repository).
This might be a silly question, but I need to know. I'll delete it if it's too silly to answer.
In a maven project in IntelliJ, I have the following structure:
procedure
e2e
cucumber (same level as common)
src
test
java
e2e
support
File: ScenarioState.java
package e2e.support
common (same level as cucumber)
src
main
java
common
testdata
File: Case.java
package common.testdata
Is there any way to import the package e2e.support (where ScenarioState.java resides) into the file Case.java in the common.testdata package?
I've been playing around with maven imports, dependencies etc., but I haven't found a way to do it. I might have to redesign some classes to get around it, but that would impact other parts of the project and I'd like to avoid it if possible.
If you really want to do that (and I would strongly recommend to either leave the project alone or restructure it first), define an additional source directory as in
How to add an extra source directory for maven to compile and include in the build jar?
But beware that a project like this will haunt you till the end of time.
One could have in the common's pom.xml a dependency to cucumber with <type>test-jar</type>.
However this violates the concept of src/main for the final product, and src/test for the unit-tests (not incorporated in the product, separate test classes).
(In src/test there can be other classes, so maybe easiest would be for common to have a src/test instead.)
If ScenarioState has nothing to do in src/main, one could place it in a more low-level library cucumberbase in src/main. And make a dependency in cucumber to cucumberbase with <scope>test</scope>. In <common> a normal dependency to cucumberbase.
Keep this main-test separation as otherwise other developers risk insanity.
sun.misc.Perf was in tools.jar and in Java 9 this was removed and restructured based on the modules concept, so the question is how do you access it in newer Java?
I need to know which module now contains this code.
The implementation has been moved under the jdk.internal.perf package within the java.base module.
As the name already suggests, the package has not been exported from the module and hence if you still want to explicitly make use of the classes within this package, you can make use of the VM option:
--add-exports java.base/jdk.internal.perf=<your-module-name>
Do note though, this is an unreliable way of making use of such classes and a better solution would always be to migrate for the specific use cases without depending on the (internal) sun.misc.* classes.
I'm coding in Java with Eclipse. I have two projects: ProjectOne and ProjectTwo.
I have some packages in ProjectOne that I want to include in ProjectTwo without including anything else from 'ProjectOne'. How can I do that?
You can create one more project projectThree with your needed classes from ProjectOne in it. Then ProjectOne and ProjectTwo depend on projectThree. I think this is best case scenarios now..
Project Jigsaw which is planned to released in Java 9 should solve your problem.
it adds modules to Java..
" modules provide a list of all the packages of this particular module that are considered public API and thus usable by other modules. If a class is not in an exported package, no one outside of your module can access it – even if it is public."
More can be found here...(above comment is taken from Below link)
https://blog.codecentric.de/en/2015/11/first-steps-with-java9-jigsaw-part-1/
Today I started learning Java.
I saw that package automatic gets included in .Java file.
I was wondering if it always need to be included?
Consider specify a common package for all the types within a same project.
In Java is common to start a project with a specific package setting. A package creates a namespace to disambiguate the types that it includes, to play nicelly with other projects that may or may not be in the same classpath. Normally, the package is bound to a URL of the project.
Think of Java packages like C++ namespaces.
A huge project/product written in Java can depend on lots and lots of projects, each described in a different package.
Organizations like Apache have lots of projects, organized under a common package pattern: org.apache.<<name_of_the_project>>.
Consider starting your project with a package named: com.user3552670; or something like your personal site, so persons that will consume your project can relate to the creator.
Yes and no.
It's used to specify the package of the class, read more here.
You could create a class without a package, but your code will look bad..
They exists to avoid conflicts, example between your code and default java package.
If packages doesn't exists, you can't create a class named ArrayList because already exists in Java.
Some IDEs force the fact that, if your .java file is in com/a/b/c folder his package should be com/a/b/c (If i don't remember wrong, IntellIJ IDEA do that)
Yes and no.
It must be there, but the IDE takes care of it (I don't use Netbeans, but I'd bet that it can do it, too). When moving files between packages, it has to be updated, but again, the IDE does it all.