Making somes tests this week i found this situation:
When i run the tomcat using the java executable in jdk/jre/bin/java the performance is a lot betther than when i run with jdk/bin/java.
The question is: Someone knows why the jdk package delivers 2 java executables and what is the difference between them that justifies the performance difference?
I'm late to the party, but... I came here looking for the difference between the several java variants within OpenJDK. I only ended up with a few clarifications and additional questions to the "what's the difference between them" part of the question; hope it's helpful.
Looking inside the OpenJDK (I'm using OpenJDK 1.7.0) base directory I see three javas, all with different hash-sums:
bin/java, binary
jre-abrt/bin/java, binary; assuming ABRT is Automatic Bug Reporting Tool
jre/bin/java, a shell script that execs the jre-abrt/bin/java variant, in one of two different ways (more below).
The binary variants above have the same file-size and creation-time (in my version and system, anyway) but 4 bytes differ between the two files (I haven't looked much further -- this is the other part of your question -- but they are different, and it doesn't look like an ASCII string, for instance).
The script variant is the one you're saying is faster, which seems counterintuitive because it seems to be doing more. (Or perhaps you're only seeing the time to execute the script and not the exec'd java command?). The script checks to see if an ABRT shared-object file exists, and if so it passes (as -agentpath...) the .so and abrt=on. Again, this seems like it should be nothing but more work... assuming use of ABRT.
If you're still interested in this topic, perhaps it would be interesting to see the following:
what path in that script you're taking (check for existence of /usr/lib64/libabrt-java-connector.so or whatever is in your jre/bin/java script)
if directly executing the third variant (jre-abrt/bin/java) is faster
what else is being touched in both of these cases -- like inotify or strace or something, but this is probably enormous for a service like this.
the java.exe files are actually the same. The JDK is the Java Development Kit, which includes all of the java executables you need to develop applications.
The JRE is the Java Runtime Environment, which includes what you need to run Java applications
So for running the application in a deployed mode, you would need only the JRE, as end users are likely to have only a JRE and not a JDK.
Related
I am currently in high school. I was recently browsing the internet looking for what employees in the software industry usually want and what the job requirements are like.
I came accros a job description and one of the requirement is:
Strong, object-oriented design and coding skills (C/C++ and/or Java
preferably on a UNIX or Linux platform)
Note the last part: Java preferably on a UNIX or Linux platform.
I don't understand this. Isn't Java run inside a virtual environment/machine? Why would it matter what OS it is running on since Java cannot directly interact with the OS?
A developer job description may require experience with some OS for several reasons:
First, as you noticed already, there are languages that talk directly to the OS and the code needs to be aware of the underlying OS (like C/C++, which are listed in your job description).
Secondly, even if the programming language abstracts away anything that's OS-specific from you (including the file-system / path separators), you are still going to deploy / configure / run / monitor your applications on top of some OS and you need to know (at least) the basics in order to do that.
For a Java job description, If UNIX/Linux "is a plus", it usually means you're going to run your code on a UNIX/Linux system and you should know how to start a process (your own java app or some application server), how to deploy an application in a container, how to read log files and so on...
While Java the language runs on a virtual machine, the Java library must abstract access to facilities available on the host platform. Ideally, these abstractions are cross-platform, but the devil is in the details—hence the preference for experience on a particular target platform.
Develop once debug everywhere
While conceptually it shouldn't make any difference on what target platform the java code is executed on unfortunately in practice it isn't always that simple but a rather tedious task to get the code running on any platform.
Beginning from easy to circumvent mistakes e.g. using / or \ instead of java.io.File.separatorChar or : / ; instead of or java.io.File.pathSeparatorChar
there are most often problems including methods implemented in native code that often aren't that compatible across different platforms.
It might be even possible your employer is looking for someone to implement native java methods using JNI.
First, you're right in that Java runs inside of a virtual machine - it doesn't directly expose the inner workings of the system to you. However, that doesn't mean that each system doesn't differ in some way under the covers - different flavors of operating systems have different kernels, different ways they think about scheduling, different ways to handle threading, and different interrupt chains (Linux has quite a few signals, whereas Windows has a handful).
As far as Java (the language) is concerned, it runs the same everywhere. How it's actually accomplished is dependent on the native JVM that it's running on.
For this job posting, though, I wouldn't read too much into the UNIX/Linux portion. This is more or less gauging how comfortable someone would be working in a UNIX or Linux environment while programming Java. The majority of IDEs available for Java are cross-platform, but that shop may be using Mac or some flavor of *nix (RHEL, Debian, Ubuntu, etc). It'd also be important to make use of the command line/shell script, since a lot of the convenience of working with UNIX/Linux is on the command line.
Not every shop uses Windows machines to develop on. Just a heads-up.
Java does not differ on different platforms. That is the most highlighting feature of Java ( portability ). The JVM abstracts the underlying platform.
However, platform matters when it comes to a software development, which involves not just the coding part. Mostly in industries, devs work on Linux platform by logging into a terminal. You don't get a GUI as in Windows and a good IDE like NetBeans. So in that case, you should know how to compile and run a java program from terminal.
Example, In linux, In order to create a package, you create a directory ( folder ), say myJava/. You go into it (cd myJava) and write the SomeThing.java file and compile using javac SomeThing.java and you get a SomeThing.class file ( inside myJava ). Now in order to execute this, you need to use the java command. Prior using it, you need to move to the parent directory containing this package. Then execute as java myJava.SomeThing. You wouldn't be knowing this unless you play around in Linux platform. Other things like setting up the classpath etc are also matters of concern
How does one start a Java VM from C? Writing the C code seems to be straigtforward -- I've been following the code that appears on p. 84 of Liang's "The Java Native Interface". It's the linking process that has me stymied. Liang's book is 10+ years out of date in that regard and I can't find anything on the net which addresses this goal (and which works).
To be clear, what I want to do is launch a standard windows program (written in C), which then launches the JVM and calls a main() in a Java class (which I have written). This program should not rely the presence of jvm.dll or jvm.lib -- the user shouldn't have to install Java to run the program. Maybe this isn't possible without an unreasonable amount of effort.
The development environment is MinGW under windows. I'm able to link in such a way that the program works when the .dll is in a separate file, but not in a way so that there's only a single executable without any .dlls or .libs.
In hindsight, I can see now that this was a dumb question, or at least one that hadn't been thought through. The moral of the story is that the "JVM" is not a single executable, or even an executable plus some JAR files; the JVM relies on a slew of independently stored files with various mutual dependencies. Unraveling all of these relationships so that they could be brought into a single file (or even two files) would be a massive undertaking. Thanks for the knock in the head.
So, to be clear - you want to launch a JVM without the requirement of a JVM being present? How do you propose to accomplish that? Unless you're contemplating writing your own JVM implementation (which I'd say falls under the category "unreasonable amount of effort"), having a JVM installed is a reasonable requirement. Assuming that, you can just spawn a java process and include the appropriate command-line parameters (classpath, class to run etc).
Disclaimer: I don't think that having a Java runtime installed is unreasonable for users. That said, I do understand your motivations for a low-friction install for users.
Using the Sun JRE is probably not going to be fruitful here. In theory, you could grab the Sun JRE, modify it to build as a static library instead of a DLL and figure out a way to cram all the resources that get bundled with it (fonts, images, cursors, SSL certificates, localized message files, etc.) into a single resource and then modify the runtime to load from there. But this is almost certainly an "unreasonable amount of effort."
You might want to look at GCJ instead: its architecture is different than the Sun JRE which lends itself more to being embedded in another application, or it can compile your Java to native machine code.
(Also, do check the licensing to ensure that you can properly redistribute this no matter which route you take.)
Sorry for the stupid question, I'm just beginning to learn Java. Can it be compiled into a .exe to be run on another computer, or is it only for computers with a JVM?
Not exactly. You can bundle a JRE with your executable, which is kind of like the same thing. Embedding a JRE is one approach offered by launch4j.
There are third party projects that will allow you to do this. A free one is http://gcc.gnu.org/java/ . I don't believe it's officially supported by Java though, but it's also gnu, who happen to know a thing or two about compilers.
There is also http://www.excelsior-usa.com/jet.html which is a paid product, but supports up to Java 6.
Can you make candy without sugar?
Yes, you need to have a JVM (just the executing for compiling) to run and to compile.
Although, it is not necessary when trying to write just the code.
All right, I've hit a bug that has simply confused the bejeebus out of me. I'm looking for ideas about what it could be that I can investigate, because right now, I got nothing. It goes something like this:
I have a standalone Java application that occasionally needs to twiddle the Line-In volume of the computer it's running on (a WinXP machine). It does this by calling a pair of external executables (written in VB6*) that can get and set various component volumes. (They can handle Line-In, Mic, Wave, CD, and the master volume control.)
There are several hundred units in the field, running on hardware (Dell machines) that my company provided and controls. At least several dozen clients are using this feature, and it works perfectly -- except for one instance.
For this one troublemaking machine, it simply doesn't work. I watch the volume sliders when the app is running, and when the volume is supposed to drop, they stay put. When I check the app's log file, it throws no errors, and appears to be executing the code that drops the volume. When I run the executables from the command line, they work perfectly.
I can't vouch for this machine being 100% identical to all the ones that are behaving properly, but we've been buying the same line of Dells for quite some time now; at a bare minimum, it's very, very similar.
So, turning my confusion into a bullet list:
If I'm doing something stupid in the Java code (i.e., not clearing my STDOUT/STDERR buffers), why is it only an issue on this machine?
If there's something broken in the VB6 executables, why do they work on every other machine and on this machine from the command line?
If there's some sort of hardware oddity on this machine, what sort of oddity could cause the volume control executables to fail only when called from within a Java application?
I am very confused. I do not like being confused. Anybody have any suggestions that may lead to my enlightenment?**
-* -- I know, I know, VB6, 1998 called and they want their obsolescent proprietary bug generator back, etc. Wasn't my decision. But the code works. Usually.
-** -- Insert Buddhism joke here.
Update Edit: Customer service may have stumbled onto something; it may be something to do with client configuration settings in the database. New evidence suggests that either something's misconfigured for that client or my software is doing something stupid in response to a specific configuration. And the problem may be more widespread than we thought, due to this particular feature not being as commonly used as I thought.
Responding to the comments:
Debugger: Theoretically possible, but looks like a massive headache given our setup.
High Verbosity Logging, Java: Good idea this, particularly given than the problem may be more widespread than I originally believed. Time to start revisiting some assumptions. And possibly clubbing them. Like baby seals.
High Verbosity Logging, VB6: A possibility; will need to be rolled-into the high-verbosity Java logging to trap the output, since my VB6-fu is so pitiably weak I don't know how to output text to a file. But, yeah, knowing whether or not the script is even getting called would be valuable.
Window Event Viewer: Not familiar with this tool. May have to correct that.
PATH problem: Doesn't feel likely; the Java code constructs a relative path to the executable that doesn't look like it's relying on any environment variables.
My thanks for the suggestions people have provided; at the very least, you've gotten my brain moving in directions that feel promising.
Solution Edit: And the winner is ... That's Not A Bug, That's A Feature! A feature gone horribly, horribly wrong. A feature that will now be neutered so as to stop bothering us.
A batch of invalid assumptions kept me from seeing it sooner, not the least of which was "I don't need to tool the code with more debug statements -- the statements already in there are telling me all I need to know!" DaDaDom, if you'd like to turn your comment into an answer, there's a shiny checkmark in it for you.
Thanks to everybody who chimed in with a suggestion. Now if you'll excuse me, my head is late for a meeting with my desk.
Here goes an answer:
Can you create a version of the software with verbose logging or could you even debug the code? At least then you can tell if it's in the java or the VB part.
Hmmmm. I've been told that executing programs from Java is either easy or hard. The easy part is starting them up. The hard part is dealing with the I/O streams (see my earlier question on using Runtime.exec()). Maybe the VB program is doing or expecting something weird on these particular machines that the Java code isn't working with properly.
edit: I also found a link to Jakarta Commons Exec:
Rationale
Executing external processes from Java is a well-known problem area. It is inheriently platform dependent and requires the developer to know and test for platform specific behaviors, for example using cmd.exe on Windows or limited buffer sizes causing deadlocks. The JRE support for this is very limited, albeit better with the new Java SE 1.5 ProcessBuilder class.
Reliably executing external processes can also require knowledge of the environment variables before or after the command is executed. In J2SE 1.1-1.4 there is not support for this, since the method, System.getenv(), for retriving environment variables is deprecated.
There are currently several different libraries that for their own purposes have implemented frameworks around Runtime.exec() to handle the various issues outlined above. The proposed project should aim at coordinating and learning from these initatives to create and maintain a simple, reusable and well-tested package. Since some of the more problematic platforms are not readily available, it is my hope that the broad Apache community can be a great help.
Have you considered the possibility that the authenticated user may not have permission to edit volume settings on the workstation? Does the program run correctly if you run as an 'Administrator'?
We run batch files on our OpenVMS Alpha and Integrity servers. Up until now they have been written in COBOL. As you can imagine there are many reasons why will not be able to maintain that process.
At the same time we have a team of developers that use Eclipse and know Java very well. Is there away to use Eclipse with OpenVMS?
Maybe it's because I don't keep up with COBOL, but I am not sure why you're convinced you have to abandon it. I realize it's not the "in" thing, but if you already have a large code base I'd think at least twice before switching to another language. If it's a lack of developers, I don't think you're going to run out that soon.
That said, googling Eclipse & OpenVMS gave this link:
http://www.sdtimes.com/SearchResult/32973
So it looks like you can still get Eclipse for OpenVMS from eCube. If I'm reading that article correctly, HP seems to want you to go the NetBeans directions. Personally, I'm still using Emacs (and not currently doing any Java), so won't make a recommendation; I just wanted to point out that there are other ways to develop Java than Eclipse.
I didn't find Java for VMS on Sun's site (someone feel free to correct me if you find it), but it looks like you can get the JDK from HP/Compaq at:
http://www.compaq.com/java/download/ovms/1.5.0/index.html
Edit: I meant, but forgot to say: Assuming you're using a JVM on the VMS side, you should be able to development with Eclipse on another platform, and copy the byte code to the Alphas.
Speaking from experience, if you do decide to rewrite your batch processes in Java I'd suggest you use a third party batching framework like Spring Batch instead of 'growing your own'.
Using a framework also constrains you to work within a standard and should provide non-functional requirements like re-runability, transactions and error handling.
We've (re)built a number of batch processes from various technologies to Java using a home-grown framework and I find we end up spending time on fixing/optimizing the framework rather than just focusing on the business logic.
Don't leave Cobol yet - call a-cobol-programmer-thinking-about-switching-to-the-modern-world and make a trade: you teach him Java, He maintains your legacy.
Shell scripts and java usually aren't a great mix. You may want to consider installing a JVM on your VMS servers, and using one of the JVM-hosted languages that handle that case better- jython, jruby, or groovy might be candidates to consider.
Eclipse relies on native Java extensions that do not appear to have been ported to OpenVMS. Don't give up though. Java runs on OpenVMS (at least 1.5 according to a Google search).
NetBeans has a Java only edition that should work on OpenVMS. On the NetBeans Download Page select the OS Independent Zip option for the platform.
Are you running the batch files on your OpenVMS system? If so, HP makes Java available for OpenVMS, not SUN; you will have to look at their site. You can develop your java code on a windows/linux machine and test it on your VMS system; you must be aware of the native extensions that you cannot use on the VMS implementation of Java.
Speaking with some experience in this area, I suggest developing with Eclipse on your Windows/Linux/Mac desktop, and pushing the code out to OpenVMS for testing/deployment. Eclipse won't run on OpenVMS because of some platform-specific components of its GUI.
Some caveats:
Make sure that you are using the same version JVM on your desktop as on OpenVMS.
The case insensitivity in OpenVMS can be a problem when using inherently case-sensitive Java .class files. Package everything in a .jar and deploy it that way.
The attributes on .jar files have to be set correctly or the OpenVMS JVM can't open them. The following command should do the trick:
SET FILE *.jar /ATTR=(RFM:STMLF,RAT:CR)
HP provides both a "fast" JVM and a "classic" JVM. Use the fast VM unless your memory needs are highly variable.
I realize this question is rather old, but I was shocked nobody mentioned this book covering Java on OpenVMS.
https://www.theminimumyouneedtoknow.com/java_book.html
What really matters when using an x86 editor on OpenVMS source is your file transfer software. OpenVMS (and many other midrange ASCII based platforms) use even though most PC developers say LineFeed Carriage Return, the data files typically store it in the other order.
You can read much more about that here:
https://www.logikalsolutions.com/wordpress/information-technology/most-text-editors-get-tabs-wrong/
Your file transfer software will need to perform text mode file transfer changing the line ending characters OR your editor needs to both use and respect the better systems line ending characters. I thought there was something in Eclipse (via plug-in) to handle this. Notepadqq claims to have something.
Note this: They use Eclipse for development, not just editing.
That means they are running and debugging in their own PC based Eclipse universe and that ain't how it's going to work on OpenVMS. They are going to need a terminal into the VMS system and it needs to be a REAL VT-100 terminal emulator, not the worthless free stuff. You can read a little bit more about that here:
https://www.logikalsolutions.com/wordpress/information-technology/diamond-edt-keypad-support/
and here
https://www.logikalsolutions.com/wordpress/information-technology/xterm-and-vt-emulation/
Depending on how old your system is, you might have Pathworks installed and running. Then a system manager can create a directory for each user that they can map as a network drive to the PC. This lets the PC user use the directory like any other network disk and it generally could be configured to handle the line ending issues with text files.
There is no way they can develop on OpenVMS using Eclipse. They can edit files then test on OpenVMS, but they cannot develop within the IDE which I suspect is what they really want to do.
The only GUI that ever existed for OpenVMS was DECWindows. You had to run it on either a VAXStation or a DS model Alpha workstation. I never heard of Eclipse being ported to it. In the latest port of OpenVMS to x86 there is no GUI. It is a server only OS.
Yeah, I spent two decades on the platform and even wrote this book for it.
Yes, there is a version of Eclipse that supports OpenVMS called NXTware Remote. It has support for Java and COBOL languages as well as Fortran, Basic and Pascal.
You can edit OpenVMS files using pretty much any editor, including Eclipse - just use Samba to make OpenVMS directories and files visible to desktops on the network. If you install Java for OpenVMS, then you've got folks using Eclipse, and compiling and running on OpenVMS.
As for ditching Cobol - why? There's still a ton of companies running it, and it will certainly last for decades more.