Related
I have an application in the form of a jar file which is around 2MB in size. For several reasons, I have to bundle the JRE with my application. When I create an MSI with my jar and the JRE, the MSI size comes out to be around 30MB.
I am looking for a commercial or free JRE which I can bundle so that I can reduce the size of my MSI to as low as possible. I am looking at 5MB total, but even upto 10MB may be OK.
Prebuilt JRE Binaries would be great, but not an absolute must.
I looked at similar questions posted here and here.
A lot of answers in these and other threads suggest Excelsior. I downloaded an evaluation version of Excelsior JET & Tried it out - for a few reasons, I think it may not be the right product for me.
1) Excelsior looks at reducing the footprint of the Installed Product not the Installer. I don't care much about the size of the Installed Product - I am mainly looking at a smaller download (the installer of my product currently at 30MB).
2) Amongst other things, Excelsior does lot of optimizations to code to achieve this - I don't want my jar file touched at all. I want a smaller JRE with my jar as is. There isn't a way to turn off some of the optimisations also.
3) Excelsior creates an EXE - I am not particularly looking for this - I am ok with my product being invoked via the javaw.exe command line.
So are there any suggestions for my need?
Avian and ProGuard are your friends as someone has already mentioned in one of the threads you linked to (it's the second comment btw).
From the Avian homepage:
The class library is designed to be as loosely coupled as possible,
allowing tools like ProGuard to aggressively isolate the minimum code
needed for an application. This translates to smaller downloads and
faster startup.
Sounds like exactly what you need. And if that doesn't help you then look at the rest of the tools referenced in that thread.
There is a possible solution here. Those tools install a minimalistic version of Java. I don't know if it is small enough for you. Just take a look and see:
https://superuser.com/questions/745112/how-do-i-run-a-jar-file-without-installing-java
I would make the JRE a separate install from Oracle (or your preferred vendor) You could have it download as required if you wish. If the JRE is already installed, it would be a waste to download it again even a reduced JRE.
BTW: I wouldn't mess with what is in the JRE because
AFAIK its a violation of your license agreement.
Its very difficult to get right and not remove a class you might need one day.
Maybe outdated: there was a rumor about something called JavaKernel/ConsumerJRE.
http://weblogs.java.net/blog/enicholas/archive/2007/05/java_kernel_unm.html
http://www.oracle.com/technetwork/java/javase/kernel-135055.html
Is there any benchmarks or study done comparing these two IDEs in terms of
-- stability
-- developer productivity
-- features
-- performance
-- etc.
I am an Eclipse user (not by choice). Not sure about stability, but performance wise NetBeans is far supperior at least with the lates versions that I worked in; personally, I think NetBeans has enough features to make it a good development environment but I can't tell you for sure, it depends on what is the scope of your task. Overall, eclipse is a good IDE, but NetBeans is just a little better...
Mostly working with eclipse nowadays.
All I can say is M2E is a pain.
With no disrespect intended to the developers of m2e ...
This is the simply the absolute worst plugin for maven. It is slow and it is painful to use.
For big maven projects with more than 70 module components, you can forget about having a quick eclipse evironment.
If you use mvn eclipse:eclipse, the deprecated plugin for configuring eclipse, I believe you are faster with eclipse than with netbeans. Especially when it comes to refactoring.
If instead you use the official m2e plugin ...
Oh my god!
I am answering to this question due to the pure shear pain of waiting for eclipse.
" Invoking CDI Builder" because an #Inject collaborator moved around in the class, triggering a massive build wait time delay... god!
Eclipse! Well... Eclipse is a great IDE for getting started, on small projects, but as projects get enterprise level, and if you use m2e ... oh! you will cry!
And wonder ... how can it be this bad.
Netbeans! Perhaps nota any better in the end.
Last time I used Netbeans, i had two major complaints, that were total deal brekers:
(a) Netbeans was simply awful when dealing with massiven class refactoring.
You change a class name on sub module A, that affects modules B, C and D.
And until you class renaming, move over packages is done, you can go take a coffee, and order a cab.
(b) netbeans had a bug in parsing interfaces, namely there was some sort of regular expression that would take the longest time to run.
So if you can use the old deprecated mvn eclipse:eclipse, you would end up being far better of.
With that said.
The Netbeans debugger compared to the eclipse debugger is light years better.
I prefer the graphics of netbeans and I prefer the simplicity of netbeans.
Just try using the "expressions" where the autocomplete does not work, and you ave to go to "display" to get autcomplete to work and copy it bakc over to expressions!
Eclipse is a patch work, with hundreds of thousands of developers making hundreds of different components of the IDE, leading to an overall result of a total inconsistent product.
Eclipse is a never ending set of settings, just open the preferences and ...
Netbeans, UI is always desing for maximum simplicty.
As I wait for my m2e to finish rebuilding prjects based on whatever whim lead eclipse to start a new build, I start considering again if I should not revisit Netbeans and install the eclipse formatter ...
Eclipse is really in bad shape, In my humble oppinion.
Ther performance of eclipse has to improve 100 fold, especiall eclipse + m2e has to get way way better.
Intelli J - i have never tried.
The best IDE have used so far, is wihout any doubt, Microsfot Visual Code for Javascript and TypeScript.
You use Microsoft Visual Code, and just wonder why eclipse is not like that.
If you are doing Angular Js/Typecipt, simply forget about any other IDE out there. Microsoft Visual Code is the best thing there is, it is fantastic and joy to use.
Blazing fast and light and good looking on every platform of your desire.
But for java + maven, the echo system is a bit lacking on good options.
The man is not supposed to wait for the machine.
A human is always supposed to be slower then a machine ... this is not the case with eclipse m2e, this I can tell you.
The furstration!!!!
Unless you have lots of hardware to throw at it, go with Netbeans.
I have a VM running CentOS 7. At this time, I am only able to allocate 2G ram to the VM, and running Eclipse Oxygen for PHP on it is painfully slow. Netbeans runs just fine in this configuration.
I'm sure some Eclipse devotee would suggest giving the VM more ram which might probably resolve the issue, but unfortunately that is not currently possible.
Another thing that ought to be mentioned is that Eclipse is rather unique in its UI. For example, virtually every editor on the planet uses Ctrl-F to "Find", then function key F3 to "Find Next". Ctrl-G is "Goto line number". Netbeans follows this convention. Eclipse, however, uses Ctrl-K to "Find Next" and Ctrl-L for "Line number".
This won't be an issue if you use Eclipse and nothing else, but if you're like the more typical developer, you use Eclipse when appropriate along with some other tool when appropriate. You will get confused sometimes and use the wrong shortcut. This creates unpredictable problems, particularly if you're unsure what the wrong shortcut just did to your file.
It's not a "performance" issue as per the application, but it slows down the developer. To me, that's just as bad.
Again, some Eclipse devotee might suggest that Eclipse shortcuts can be configured any way you like, which is true, but really, does anybody have that kind of time? Eclipse comes with literally thousands of configuration options, and it's an Internet Search to figure out how to change almost anything.
Netbeans doesn't have thousands of configuration options, although there are things you can tweak. It just sorta mostly works the way you expect out of the box.
To conclude, the actual slowness on less-than-most-super-powerful hardware is probably the biggest thing against Eclipse. I don't know what the code is trying to do, but Netbeans is somehow able to do it with less hardware.
Eclipse and Netbeans are both good IDE (Integrated Development Environment) programs. If you are just a Java, C++, C or Fortran programmer you can use any of them.
If you are WEB base developer (For Example: JSF, Serverlet, Applet) in this case NetBeans is much more powerful then Eclipse.
On the other hand, If you are mobile developer for Android OS, in this case Eclipse is much more powerful then Netbeans.
So it depends on your programming league :)))
We have rather large code base (150+ projects, 400000+ lines of Java code, some Groovy and Gradle code, some Perl code, some XML, a lot of JSPs etc.). I managed to open all those projects in Spring Tools Studio 2.6 to which I also added some plugins for Groovy, Perl, Checkstyle, PMD.
And the problem is that Eclipse is holding my CPU busy all the time. And it's really slow when I update something, it's building slowly, any kind of UI operations happen with a delay.
Also I have rather good machine 64-bit, 8GBs of RAM and I run 64-bit version of STS and I give 2GBs to Eclipse (but it does not get higher that 1GB of heap anyway).
So, my first question is there a way to determine what is making it slow? And do some of you guys have succeded in working with such large code bases in a single workspace?
I have tried looking at the threads (using jconsole) of the JVM that runs Eclipse, but I can't find anything intersting there.
I'll make a few suggestions - these are in order of easiness. If you are hell bent on figuring out what plugin it was and either joining that project to fix it or send hate mail to a support list, then you probably want to skip to "Profile It" below.
Check the console
If you start eclipse from the command line ( ie type eclipse ) then if there are any exceptions being thrown you'll see them in here. Sometimes slowness can be caused by a plugin repeatedly failing and throwing lots of exception. Sometimes it is something you can fix - sometimes you have to remove that plugin.
Boost your RAM
We love GC but it causes a slow death. The beauty of GC is that your program never runs out of memory - because the user thinks it has locked up and kills it before it actually runs out of ram. So, try increasing the PermGen and other Eclipse memory settings: http://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F
Create a new Workspace
I often give up and just delete/recreate the whole workspace. There are so many plugins there is can be a real challenge to debug and often it garbage in the workspace directory that keeps things breaking.
Keep Eclipse Lean
If I want to keep Eclipse really snappy, I'll create an install for a single project and add only the plugins needed. If you can start from the non-EE version you're already far less bloated.
Profile It
The VisualVM that is included in with the Sun JDK (you probably already have it installed.) can be used to see what classes are consuming the most processor time and which objects are taking up memory (and what created them).
Start VisualVM up, and you should see Eclipse listed in the Applications. Right click on the Eclipse entry and "Open" Eclipse inside VisualVM. You can now attach a profiler and see what classes are being used.
Profiling will slow everything down (a lot!) so you might want to start with the smallest possible example you can - or be extremely patient. Especially at the start of profiling it will take a long time as it 'instruments' the classes (injecting bytecode to allow profiling).
One way to know what Eclipse is doing by enabling debugging. There is some information here about debugging eclipse builders, however the process is generic i.e. you need to start eclipse from command line $eclipsec –debug > log.txt and enable debugging for certain plugins using the .options file. I guess you would want to look a bit closely at 'update' and 'build' operations.
Another option would be to use a tool, e.g. MAT (Memory Analyzer), YourKit. I find YourKit to be quite useful, you could for example enable CPU profiling in YourKit and then perform an action in Eclipse which you feel is taking a lot of time. Once the action completes, you can take a snapshot and do some analysis in YourKit. A caveat is that a attaching the YourKit profiler to Eclipse will further slow down Eclipse.
Having said that 150+ projects in one workspace is a bit much. If it is possible you should probably setup one workspace per component with the rest of the plugins in a target platform. All your workspaces can share a single target platform. With 150+ projects a full workspace build alone can take quite a bit of time since a large number of class files have to be generated which means a large amount of disk IO, and eclipse cannot help you there only a SSD can :)
Eclipse 2019-09 proposes a new way:
Automatic detection of UI freezes in the Eclipse SDK
The Eclipse SDK has been configured to show stack traces for UI freezes in the Error Log view by default for new workspaces.
You can use this information to identify and report slow parts of the Eclipse IDE.
You can disable the monitoring or tweak its settings via the options in the General > UI Responsiveness Monitoring preference page as shown below.
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.