Develop Reference

Why ECLIPSE NEON is so slow on ubuntu 16.04?

I'm using the eclipse neon IDE and I put it on the path: /opt/eclipse/eclipse and i am using Ubuntu 16.04 and Java 8. The problem is that when I write in the eclipse editor, this is going too slow. For example, I just typed and in the editor it still does not end.
How can I solve it?
Thx!

Try Netbeans, or IntelliJ IDEA.
A quick browse over the Interwebs shows that quite a lot of people are complaining about Eclipse slowness. Some have every manner of trick and configuration change to help speed it up. OK, you can put yourself thru all that hassle if you want, or, you can just switch to something that already works fine out of the box.
I had Eclipse Oxygen for PHP running on a CentOS 7 VM with 2G allocated RAM. I admit, that's pretty low memory, but that's the way it has to be right now. Eclipse ran so slowly, I finally gave up and killed the process from the command line.
I installed the latest Netbeans 8.2, and it not only installed more cleanly (no Java error messages, and it put an icon on the desktop), it ran PERFECTLY without changing a thing!
I eventually changed a couple of parameters, but the point is, I didn't need to change a thing to get decent performance. Even on a low-ram system, it ran plenty fast enough.
Don't blame the hardware. Not everybody has the money to buy the latest and greatest and fastest machines available, and software developers should not expect it. With some exceptions, if your application can not run adequately on 2G of ram, you are doing something wrong.
The Eclipse developers are doing something terribly wrong.

I had faced a similar issue with eclipse oxygen.
After a some research over different forums I found the following solution.
Step 1 : Open eclipse.ini file. If you find difficulty in locating the file, see this question Where's the location of the eclipse.ini file?
Step 2 : In eclipse.ini search for below 2 variables
-Xms
-Xmx
Xms indicates minimum ram that should be allocated to eclipse.
Xmx indicates maximum ram that should be allocated to eclipse.
Step 3 :Increment both the values. You can set the value as per your choice. Below is my preference.
-Xms512m
-Xmx2048m
Here
m indicates megabytes, if you don't specify m it will consider bytes by default.

The easiest thing to do would be to re-install eclipse, and if that does not work you could try to download an older version of eclipse. It could also be slow because your computer is slow.

Eclipse execution slower than in another pc

I'm developing in Eclipse in Java and I noticed that the software execution in my eclipse is much slower (like 6 or 7 times) than the same code run in eclipse in another similar pc (both have 8gb ram 8 cores). The only difference is that I'm running on windows 7 and the other pc is running ubuntu 13.04.
I already checked and I'm using the right virtual machine (jre 1.7, the linux one is with jre 1.6) and there are at most about 20 prints on the console over a 6 minute run. Also I'm running as "run" and not debug.
What can it be? Is it possible that under linux is much faster?
UPDATE:
I installed a partition with Debian 7 on the same laptop with windows (where it was running slower). With both the default open jdk 1.6 and the new java 1.8 Debian is much faster. I would say ok if it was like 2 times slower, but a 6 minute execution instead of a 1 minute one is a bit strange.

Linux is in fact faster (usually) than Windows. It depends on alot of things though, RAM and cores are not only things that matter. CPU architecture, clock speed, OC or not and so on. If you´d post both computers specifications then it would be easier to answer but until then there's your answer.

One thing you can do is use a Terminal on each platform:
First do a java -version to make sure both are really using the Oracle JVM (for example, on Ubuntu, a trivial installation of Oracle JDK may not guaranee that you're not still using the original Open JDK).
Then, run your Java program in the terminal on each machine, and see if the difference persists. If it doesn't (i.e. if you only have the big performance gap when running from Eclipse), then it might be Eclipse's fault. While Java does tend to be faster on Linux/Debian vs. Windows, Eclipse might not have the same trend. If your experiment shows that Eclipse is the reason for the performance gap:
make sure that Eclipse is configured to use the Oracle JVM on each platform
make sure Eclipse itself and all it's possible plugins are updated (and if not, update first Eclipse, then its plugins).

How to run TeamCity on 64-bit JVM

I've just found out that TeamCity runs on the 32-bit JVM on Windows, for some reason.
I'm seeing memory errors logged when checking out a large (not that large) Git repo and am already at the max heap size for the JVM. I know nothing about Java or the JVM, or TomCat.
How can I run TeamCity on a modern, 64-bit JVM? I sense its going to be a pain, else it would be the default.
We're a tiny team and if something doesn't have Apple levels of 'it just works' then we skip it.
We can live with this one project not be on the CI server, but it would be nice to know what's involved and weigh up the investment.
Any advice appreciated.
Edit
Okay so Markus pointed to this snippet (which I had read), but I can't see any information there explaining what to do.
Using 64 bit Java to Run TeamCity Server TeamCity can run under both
32 and 64 bit JVM. It is recommended to use 32 bit JVM unless you need
to dedicate more than 1.3Gb of memory to the TeamCity process.
If you choose to use x64 JVM please note that the memory usage is
almost doubled when switching from 32 to 64 bit JVM, so please make
sure you specify at least twice as much memory as for 32 bit JVM, see
Setting Up Memory settings for TeamCity Server.
If you run TeamCity as a service and switch to x64 bit, you will also
need to use x64 Tomcat executables, see more.
Did I miss something?
Edit 2
Ah, okay, buried in some paragraphs above that link is this:
"if you run as Windows service and want to upgrade JRE to 64 bit
version, you will need to replace \jre with appropriate
JRE"
So I guess I need to copy some files into the /jre folder?

The way I made it work (TeamCity 8, Windows server 2008 r2):
Install the 64-bit JRE on the target machine, now there are two ways to do this
A -> If you are using the Teamcity bundled JRE, replace the JRE folder ([TC Server folder]\JRE) with the JRE folder in the newly installed JRE x64 - You have to shut down the TC server service (along with all java.exe*32 services that might also use this JRE)
B -> Change the TeamCity Internal properties, to point to newly installed JRE x64 (see documentation for TC version 8, TC version 9 can be found here):
java.home=C\:\\<JRE x64 install folder>\\jre
java.ext.dirs=C\:\\<JRE x64 install folder>\\jre\\lib\\ext\;C\:\\Windows\\Sun\\Java\\lib\\ext
java.library.path=C\:\\<JRE x64 install folder>\\jre\\bin\;C\:\\Windows\\Sun\\Java\\bin\;C\:\\Windows\\system32\;C\:\\Windows\;C\:\\local\\Oracle\\clients\\112_64\\bin\;C\:\\local\\Oracle…
An alternative to point B would be to change Environment variable JAVA_HOME, it`s more simple, but it requires a Windows server restart after that
If you run the TC Server service now, it should run as a 64-bit Java process (chceck via PID in task manager) :
Don`t be alarmed if the server does not start up throwing an error :
Error: SQL error when doing: Connecting to MSSQL: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Download JTDS - 1.3.1 (http://sourceforge.net/projects/jtds/files/jtds/1.3.1/) and install it
Take the ntlmauth.dll file from [JTDS-1.3.1 install folder]/x64/SSO folder and replace the one in [TC Server folder]\bin
The TC server should now run fine as 64 bit Java process
You can increase the memory allocation (as that is the whole point of the upgrade) now on the server as described here : https://confluence.jetbrains.com/display/TCD8/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-SettingUpMemorysettingsforTeamCityServer

The snippet from the updated question had a link in the original, pointing to the instructions on Java update for TeamCity server in TeamCity online doc.
Basically, the instructions vary based on the TeamCity distribution used and way of launching the server.
If your intent is to increase the memory for the TeamCity server, please make sure to read through the corresponding section on the same doc page.
Yet one more note: recent TeamCity versions perform Git fetch in a separate process and Git-related memory issues during fetch might require fine-tuning of the corresponding options.

"So I guess I need to copy some files into the /jre folder?"
No. You install a 64 bit JRE, and update the relevant setting to point at the 64-bit install's JRE.
Don't copy stuff from one JRE installation into another. You will break things!

Tomcat inconsistencies + uncertainty in setting paths

Background
As this is the first question I have posted, I will try to break it down as well as possible, and I apologize for any incorrect formats. I should also point out that I am brand-new to Linux, Tomcat, and Java (all within the last few weeks), so if you do have an answer please dumb it down as much as you can. Thanks!
This question is actually several questions, but I feel the issues are somehow related so I will include them all. As for my environment, I am running an EC2 Amazon Linux instance. Details returned using
cat /proc/version are:
Linux version 2.6.35.14-97.44.amzn1.x86_64
(mockbuild#build-31006.build)
(gcc version 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC)
java -version gives me:
java version "1.6.0_29" Java(TM) SE Runtime Environment (build
1.6.0_29-b11)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)
Issue(s)
What would allow me to stop/restart Tomcat sometimes, but not
others? After I change configuration parameters and need to restart
Tomcat, I use /etc/init.d/tomcat6 restart or service tomcat6
restart with varying degrees of success: sometimes the nice green
OK, others the red FAILED. There seems to be no rhyme or reason to
why it works sometimes and not others. When it doesn't work I check
the status with service tomcat6 status, which yields something
like tomcat6 (pid ####) is running. Also worth noting is that my
Putty SSH session slows down significantly at the same time whenever
I am unable to stop Tomcat. I literally have to wait for each keystroke to be processed!
I cannot use any of the JVM-specific -XX parameters. I get an error
every time of Could not create the Java virtual machine. Of the
threads I've read about this, most surround heap memory allocation
issues, but I don't think that's my problem because when I run java
-XX, which should give me a list of available commands just like java -X does, I simply get:
Unrecognized option: -XX Could not create the Java virtual machine.
I should note that I had at least two versions of Java on this OS- it came with Open JDK, but I needed Sun Java as that was recommended for performance in Geoserver (which is the whole point of me learning all this). I read that it is not an issue to have two versions, as long as my JAVA_HOME path points to the correct directory, but is it possible that it was still somehow looking at something from the original configuration? That's what I thought, so to rule it out I did a yum remove java, which erased the original version (along with Tomcat due to the dependency, but whatevs, I can get it back later), ran java -version to make sure I still had the version I wanted. I did, then ran java -XX, hoping that it magically fixed itself after cleaning house with the unwanted OpenJDK removal, but NOPE, same error as before.
Conclusions
I am now assuming that there was no issue with old paths. I've also tried changing my JAVA_HOME variable to the appropriate path (/usr/java/jre1.6.0_29) in every conceivable location:
in bash_profile
in bashrc
java.conf
tomcat6.conf (well, before I deleted Tomcat, that is)
probably some other files. It's all a blur really.
export JAVA_HOME in the shell
... all with zero impact, with the exception of using export JAVA_HOME=/usr/java/jre1.6.0_29. Every time I ran echo $JAVA_HOME I would still get the original JAVA_HOME path, which I'm pretty sure is not what I want. Even when resetting the variable was successful (via export in the shell), I still got my -XX error. I also tried setting some JAVA_OPTS parameters, specifically for memory settings, then ran an echo $JAVA_OPTS that returned nothing.
I have spent a solid two days on this and am about ready to give up. I would really like to avoid reinstalling and reconfiguring a whole bunch of stuff if possible, not to mention I don't even know if that would fix my problem, but I would really, really like to know WHY I having these issues and whether or not they're related, so if any of you have suggestions on this or anything in general that I'm doing incorrectly, please let me know. Thanks!

I can't help you with the first issue but in regard to your second issue: "I cannot use any of the JVM-specific -XX parameters.":
the environment variable CATALINA_OPTS is used by tomcat when starting the JVM. So if you want to use 512mb of heap and 128mb of perm gen space you can issue the follwing command on a bash shell to start tomcat with some custom java options.
#> CATALINA_OPTS="$CATALINA_OPTS -Xmx512m -XX:MaxPermSize=128m" $TOMCAT_HOME/bin/catalina.sh run
you can also change the default parameters by changing CATALINA_OPTS in tomcat's startup script or you can add the paramenter to your environment (e.g. $HOME/.bashrc).
hope that helps.

Configure Launch4J to use 32-bit JVM only

I'm using Launch4J to start my Java application and if an x64 JRE is present on the system, Launch4J seems to prefer it.
Unfortunately my application cannot run on a 64 bit JVM because I'm loading a 32 bit DLL, which is not possible and leads to an UnsatisfiedLinkError.
Is there any way to force/trick Launch4J to use a 32 bit JVM only?

I have exactly the same problem : Into 64 bits environment if both 32 ans 64 bits JDK/JRE are installed this tools always detect the 64 bits version.
I have patched the source (java + C++) code to make my own version and re-compile all. I add a check box to FORCE the 32 bits JDK/JRE detection into 64 bits windows environment.
Just donwload the version and use it as the original one.
Version : launch4j-3.0.2-win32_Java32bitsDetection

I had this exact problem about a year ago, using Lauch4J to wrap a small Java program that required a 32-bit DLL (swt-win32.dll, as it happened).
I found that if there were 32-bit and 64-bit JVMs installed, Launch4J would always favour the 64-bit one. It would only work if the 64-bit JVM was uninstalled, which was obviously not a practical solution.
I found no way of getting Launch4J to prefer (and require) the 32-bit JVM, after searching quite a bit and posting questions on its forum.
Therefore, I evaluated a good number of alternative JRE converters (I used this list: http://www.excelsior-usa.com/articles/java-to-exe.html).
I ended up settling on Jar2Exe, which was the only one that had the features I needed. It's not free, though there is an evaluation version, and I think it wasn't expensive.
Hope this helps!

I don't know Launch4J, but you can get the Information about 32/64 by reading System.getProperty("os.arch");. If you encounter a 64-bit system you may quit the installer with a nice message, to tell the User to install a 32-bit JVM.
You may Wrap your startUp-Code with an Wrapper to show a Message-Box to the user.
public static void main(String[] args]){
String architecture = System.getProperty("os.arch");
// Did not test the return value of this property,,but should work
if("64".equals(architecture)){
// Show a dialog, or print a logmessage
System.exit(-1);
}
// Start my APP
com.something.startup.main(args);
}

If you don't mind including a copy of JDK with your app, try passing these arguments (in the MyApp.ini) to launch4j:
-D32 -Djava.home=d:\MyApp\JDK32 -Djava.ext.dirs=d:\MyApp\JDK32\jre\lib\ext
There are also other things going on here that you could use:
If you don't package the JRE, you can set the Launch4j option to use "jreOnly" and then, using the DOS environment variable called "%ProgramFiles%" you can locate the 32-bit or the 64-bit JRE in the expected location, depending on whether you used the SysWOW64 32-bit cmd.exe shell or the regular 64-bit shell. Then you can pass these options to the JVM:
-D32 -Djava.home=%ProgramFiles%\Java\JREDIR -Djava.ext.dirs=%ProgramFiles%\Java\JREDIR\lib\ext
or
-D32 -Djava.home=%ProgramFiles(x86)%\Java\JREDIR -Djava.ext.dirs=%ProgramFiles(x86)%\Java\JREDIR\lib\ext

I encountered the same problem some time ago and forked the project, so that the User interface exposes an option to force that a 32bit JVM ought to be found, you can grab the installer of launch4j 3.0.3 with the patch from:
http://fbergmann.github.io/launch4j/files/SetupLaunch4j_3.0.3.exe
and read more here:
http://frank-fbergmann.blogspot.de/2012/11/launch4j-for-32bit.html
http://fbergmann.github.io/launch4j/

This is an old question and Launch4J has been updated since it was asked. Now there is a dedicated user-interface control for selecting which version of the JVM to prefer.
The options currently are:
64-bit only
First 64-bit, then 32-bit
First 32-bit, then 64-bit
32-bit only
The last, one of course, is exactly what the OP requested.

For any users of Launch4j applications like Areca that get stung by this one, and need a quick work around, look in the directory where the application is launched and you will find a complete java command line to run your program inside a file named launch4j.log. Just make a bat file or script using the java vm you prefer and run it with the full command line in the log.

You will have to add a JVM parameter while configuring.
It is shown in the below post on how to add it:
http://www.technimi.com/index.php?do=/group/java/forum/building-an-exe-using-launch4j-for-32-bit-jvm/