Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I use OSGI and this is the main reason that I want to disable modules, as I really don't need another module framework. Is it possible to do it, for example using command line option? If yes, then how?
There is no option to turn off the module system - it will always be active. This impacts access to JDK-internal APIs, dependencies on Java EE modules, Split packages, and a lot of other small details. Your code and your dependencies have to deal with those migration challenges if you want your application to run on Java 9.
You are by no means forced to create modules, though. You can completely ignore module-info.java and continue to place all your JARs onto the class path. The module system will silently bundle them all into the unnamed module, which was created for maximum compatibility. You won't even notice the module system is there (assuming you've overcome the challenges I described earlier).
Yes surely you can as the interviewee said here
Trisha Gee: Many people don’t realize you can use Java 9 and all its shiny new features WITHOUT using Jigsaw, i.e. you can use Java 9 very happily without migrating any of your code. There are some things which have changed in Java 9 (e.g. hiding away internal APIs) but theoretically, if your application was doing all the right things to begin with, there should be no problem compiling and running with Java 9.
have a look for the entire interview but As you saw we will have two types for Java Applications one for modular world and another for non-module system that's why Red Hat and IBM voted no for JSR 376 as mentioned here but they vote okay after that!
for more about Java 9 Module System with OSGI have a look here
Hope this is useful
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
If i put two different versions of jar files in class path, what willl happen?
for example:
log4j1.4.jar and log4j1.5.jar kept in classpath
what will happen?
While I also recommend not to do this, I still like to try to answer your original question:
Java has a classloader hierarchy, so if you have both JARs in different levels of the hierarchy, the classloader defines its precendence. Most popular example is the web application classloader hierarchy (Tomcat for example), where application classes have a higher priority than the comtainer classes (if both are applicable).
If you have both JARs in the same classloader (same level), the filesystem determines the order, which is unreliable from the developer's point-of-view, so consider it to be random. Only one loads, but you don't know which, and will maybe not even get errors from dependency problems. If you get dependency problems, they may be java.lang.Errors, such as VerifyError, NoClassDefFoundError, NoSuchMethodError.
One of two things might happen - you can get version 1.4, or you can get 1.5.
This is not recommended, might cause problems especially if you are using two versions which are far apart with slightly different API's, might cause compilation issues
Short answer is you don't want to do this.
Depending on how you use the classes provided by the JAR, you can have either a clear exception or weird behaviors.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
we have a project with a lot of dependencies. Many of them also bring various kinds of logging frameworks with them.
This leads to confusion when writing new classes, because IDE auto complete suggests like 10 different imports for the class Logger or LoggerFactory.
To minimize confusion and to consolidate the project structure I'd like to only allow the usage of slf4j Loggers and break the build if a developer uses e.g. a log4j Logger.
Question: Is there a maven plugin that allows to specify forbidden classes and that breaks the build when usage of such classes is detected?
If not, is there a SonarQube rule that at least allows to report an issue in such situations?
The Architectural constraints should be followed rule template is probably what you want. It allows you to forbid access to certain packages (e.g. **.slf4j*.**).
In terms of breaking the build, that's not available from SonarQube in the current version of the server (5.2), but is there in 5.1 and should return soon. So let's say you're on a version of the server that supports breaking the build. What you could do is create a rule from the Architectural Constraint template and give it Blocker severity in your profile. Then set a quality gate that fails on new Blockers and you're done.
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 8 years ago.
Improve this question
I'm developing an application that I plan to publicly release, or at least share with a group of people. The problem that I am facing as a developer is compatibility. On my machine, I am using the new Java 8, but I am afraid to use its new features, and in fact, I'm even afraid to use the new features in Java 7, like try-with-resources, in fear that the users will not have an up-to-date Java version, and consequently, will not be able to use my application. For example, my school's computers still use Java 6.
First off, am I correct in thinking that? Or can code compiled with a newer JDK run on a machine with an older JRE? If I am correct, is there an established "rule" or standard for compatibility? Something like, "Make sure your code is compatible with a JRE that is two versions old!" Or is it purely a matter of the developer's judgement of when new features should be utilized for a released work? And just for emphasis, I am talking about just running the program. The user will never have to compile it.
I know this is a bit open ended, but this is the best place that I could think of to ask.
Thanks.
First, you can always specify the version of Java that you want to support by compiling it with the -version flag. This means, since you're using Java 8, you could always force your code to compile down to a lower version (that is, Java 6).
To your point about older Java versions - yes, you'll likely run into that. A lot of people don't update their Java version for one reason or another. But, this is where you have to make a decision: do you choose to support their version, or do you choose to support another version? This particular part is open-ended, but depending on what you ultimately want to use in your code (diamond operator, try-with-resources (which is actually very nice), NIO), then you'd want to use the version of Java that works well with you and with what you want to support.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Might be my question is abstract or out of context, but i am asking here since i have little idea how this happens.
I am wondering how big application/ platform break down there application in to multiple module and how they able to manage modules dependencies.
For example in some E-commerce application they tend to break down it in various modules like pricing,promotions,shipping.import/export and many more.
when we develop those application we hardly think about the underlying modules and how they have been designed to provides functionalists.
Most of those module are not web-applications but are standalone module and not deployed in the web-app as jar files.
can any one help me to understand how they break up things or is there any standard way to do this.any help/resources to get insight will really be helpful
E-commerce application [...] tend to break down [the application] in various modules
like pricing,promotions,shipping.import/export and many more.
[...]
Can any one help me to understand how they break up things or is there
any standard way to do this.
There are various ways from the technology point of view to modularize applications. Large systems are split into modules that must communicate with each others, and there are various technologies to do so: EJB, web service, libraries, database, file system, message queues, etc. It's way to vague to be answered.
In practice applications ten to be modularized according to the social structure of the company. This is Conway's law. Since pricing, promotions, shipping are usually different teams within the organizations, chances are that each team will have an engineering group, and the system will be modularized according to the organizational teams.
Try looking at the various maven archetypes available out there.
for example: http://appfuse.org/display/APF/Home
You can package many EJB jar archives within an EAR archive.
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 1 year ago.
Improve this question
Is anybody out there using Project Lombok for a large scale production system? How does it influence your compile process (i.e. does it do two-pass compilation, slow it down, make it more fragile)?
Lombok doesn't do two-pass compilation. Technically it 'slows down' the compile process in that it runs in addition to the usual things that occur when you compile, but compared to the parse phase, the lower phase, and the translation phase, lombok barely even registers.
The major fragility issue is that editing lombokified code in an editor that is NOT either (A) dumb (i.e. notepad or a diff viewer), (B) eclipse, (C) netbeans, or (D) gets all its brains by running javac (e.g. vim with java plugin), it's going to suck. If that doesn't apply, the reduction of boilerplate should only make your code less fragile.
DISCLAIMER: I'm one of the two main developers of lombok :)
I used Project Lombok whilst developing a Google Web Toolkit (GWT) front end for large java & Swing UI application. As I did not use #SneakyThrows, I did not require lombok.jar at runtime.
Using the delombok behavior I provide a 2stage compilation process.
Lombok annotated java code => Java code => Javascript
In terms of suitability for large java projects, delomboking the code for the web front end takes less than 2 seconds, the rest of the gwt-compilation process takes ~50 seconds (These metrics are taken from a developer work station).
We are considering this week if we will provide Lombok support to the rest of the application. Building the main application takes around 1 hour (including unit tests, installers etc built on a box with 2xIntel E5450's).