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).
Related
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 2 years ago.
Improve this question
I don't get why would anyone want to use tools like Gradle or Maven, I mean what do they even do? I tried to understand and use them but that got me no where they just unnecessarily complicate things and create a lot of what seems to be absolutely useless files.
So, why bother at all and use these tools and what are they good for?
First of all Gradle and Maven are great tools for managing your dependencies and also giving you the option to simplify your build process. Without these tools you would have to manually download *.jar files. And copy them somewhere in your project folder.
And if you want to update, you would have to open the website again, download it and replace your existing JAR.
Quite often JARs themself have dependencies, so you would have to manually download them as well.
I can understand that the setup of Maven / Gradle at first can be time consuming, but it's usually worth the time since you just have to declare: I need package com.example.package in version 1.2.3 and you just have to run a simple install command and they will take care of downloading everything needed.
Secondly, you can declare commands describing how to run your tests and they will usually take care of your tests not getting mixed up with your final and compiled package.
Also this is good for collaboration because once this config is shared, every developer can use it without going much of a hassle of configuring your development environment. Another good point is that it is independent of any IDE, so your project is not an IntelliJ or Eclipse project and everyone can use the IDE/editor they prefer.
Basically the idea is: You configure it once and then you can enjoy the automatism.
However, if your project is really small and relying on only a few dependencies you might not need it.
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 3 years ago.
Improve this question
I want to mutate a function of a class that is loaded at runtime (it has a bug in it but the project is long gone so i cannot build the binary). What i want to do instead is write a piece of code which will run during the application initialization phase and mutate this function so that it works fine. And simply keep that code around until the replacement is ready.
Having no experience with bytecode modification what library could i use to modify and reload a class at runtime? Specifically i need to replace a throw instruction with a noop instruction (i did this once using hex editor but lost the binary).
Also if you know any tutorial on how to do something like that please share.
I can see many libraries for doing this but i cant know which ones are good/bad do the job...
I think use Java Attach API. Java Attach API is procedure of loading a Java agent into an already running JVM. you can understand the work of javaagents by reading the Java Instrument javadoc. AgentMain help to you.
Agentmain is invoked when an agent is started after the application is already running. Agents started with agentmain can be attached programatically using the Sun tools API (for Sun/Oracle JVMs only -- the method for introducing dynamic agents is implementation-dependent).
This tutorial is useful about java instrumentation.
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
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 7 years ago.
Improve this question
In our current project, we don't actually practice unit testing. Our bosses are encouraging us to go for build automation like Jenkins. Will a build automation tool really help us in productivity or quality?
It will probably help a bit, but not as much as with tests to back it up.
For example, build automation, if configured for every attempt to submit code, will ensure that if the build fails, i.e. can't compile, then either the code is prevented from entering the main branch where everyone else is working or at the very least, make sure everyone is aware the build is broken. This depends on whether your build automation runs before or after the code is merged to the branch everyone else is working on.
This would ensure that at a minimum the code at least compiles, and therefore that others on the team don't have to wrestle with code that doesn't compile and lose time trying to pinpoint errors in other code.
Depending on how much build automation is included, you might even have deliverable artifacts ready to be manually tested which saves the time of performing those builds.
But that's about the limit of it, unless you have some tests.
As a side note, the reason I said probably, is none of it is worth anything unless attention is paid to the results. If the results are there but never really followed up on, then the reality is zero value.
Sure, automating your build will improve your productivity and quality even if you haven't written any tests yet. You won't have to build manually every time someone wants a build to test or release, and you'll find out faster if you have a compilation or other build error.
But you should certainly write tests as well, and run them automatically too.
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 9 years ago.
Improve this question
How do we future proof our code against changes in third party libraries? Maintaining unit tests seems like one way of going about it.
1) Configuration management. Knowing exactly what versions of your libraries go into making up your build is essential. Some distributions are very sloppy in identifying versions, so you may want to invest in a good version extractor, such as http://www.jboss.org/tattletale -- also, comparing reports over time so that you can identify what has changed in your libraries.
2) Unit tests and integration tests. The phrase "unit test" is badly misused in the community. You need to test a spectrum of behavior in your configurations.
3) Managing interaction effects. One of the toughest issues to manage is upgrading just one item. Often, point releases of libraries depend on other point releases of other libraries. You can't just take one.
4) Planning for systematic upgrading. Build into your project schedules work to do testing of newer releases so you can estimate the impacts of doing an upgrade. With that information, you can plan your upgrades for a time when you are not under the gun because it has gotten too old, or is incompatible with the next supported JVM.