We Keep Coding

What I have to modifiy for the 64-bit requirement?

I know about that:
Inspect your APK or app bundle for native code.
You can check for .so files using APK Analyzer.
Identify whether they are built from your own code or are imported by an SDK or library that you are using.
If you do not have any .so files in your APK, you are already 64-bit compliant.
Enable 64-bit architectures and rebuild native code (.so files) imported by your own code. See the documentation for more details.
Upgrade any SDKs and libraries to 64-bit compliant versions, if needed. Reach out to the SDK or library owner if one is not available. We’re working with top library owners on their 64-bit compatibility.
Test for issues locally once you’ve rebuilt your app.
Rollout to your testers using testing tracks for thorough testing.
But I miss anything else? Any recommendations?
Thank you for your help!

If you have no native (NDK) code, that is you only write Java/Dex code, then you don't need to do anything.
If you have native code (or libraries) then you need to supply their 64-bit versions.
reference

Implications of Old version of Java.exe (7.1) using new version of runtime(8.x)

We have a situation where our application embeds a JRE. The application, by mistake, ships with a mashup (7.x version of java.exe and 8.x version of the rest of JRE).
I can confirm that the process running the v. 1.7 java.exe uses the v. 1.8 java runtime using Process Explorer. I'm surprised that the runtime or the binary didn't detect the anomaly and abandon JVM creation!
What are the implications of the same ? Security issues ? Stability issues ? I haven't gone through the source code for java.exe. From my preliminary investigations of java.exe binary, I can see that it is more than a stub. It calls out to 100 different KERNEL32.DLL APIs apart from USER32.dll, ADVAPI32.dll, COMCTL32.dll.
Sure, we can(and we will) fix the mistake. But are there implications for the several current production systems that use the above anomaly ? if yes, what are they ?

What are the implications of the same ? Security issues ? Stability
issues ?
All of those.
The JVM binary (java.exe in your case), the shared objects/DLLs that come with it, and the JAR files that implement the Java side of things all come in a combined package that is not designed nor meant to be run as anything but a combined package.
Specific lists of compatibility issues between Java 7 and Java 8 are known external issues between coherent versions of the entire JVM package.
You've added internal incompatibilities of an incoherent Java installation to those known external incompatibilities. There's no way to get a list of those. It's almost certain that no one even tries to keep track of such things.
You have no idea what should work, what will work, nor how long it will work even if it does appear to work.

java.exe is a simple launcher. It does not contain JVM or Class Library code. Its primary function is just to locate a JRE and to load jvm.dll with the arguments passed in the command line.
You can start a JVM using the Invocation API even without java.exe.
java.c log tells there are not really much changes in the launcher between JDK 7 and JDK 8. E.g. there is a launcher support for JavaFX applications and a few fixes for better argument validation. That's it. So if your application starts fine with JDK 7 launcher, there is apparently nothing to worry about.

Java Applet allowed for Javac or other jar access?

I am involved in a project that will need to run via web and have access to java's compiler tools and/or javacc api. My team is thinking of using a java applet to make it web based. I'm wondering if there are certain limitations on what an applet can and cannot do in this case. I would assume that since access to the compiler would be done on the server, not the client's machine, that this wouldn't be a problem. Does an applet allow us to separate the two as described?

An applet (and even a JavaFX applet) can work in this situation if the applet is signed. There are numerous subtle pitfalls with applets, so I would advise prototyping before committing to that technology. Follow the JavaFX deployment guide to see how to deploy a JavaFX based applet.
I had thought that to compile Java, you needed to have the full Java Development Kit installed (which would be tricky to ensure in an applet deployment situation). But it seems that the compile API is included in the javax.tools API included with the standard Java Runtime Environment. So this likely means that you could develop your solution, including client based deployment and compilation of Java code, without requiring the user install the full Java Development Kit.
You may alternately wish to consider a client/server solution where the compilation can be performed on the server. An example of such an approach (with a Java WebStart based solution) is the TopCoder Algorithm Competition Application. Here is a jnlp file (http://apps.topcoder.com/wiki/display/tc/The+Algorithm+Competition+Arena) to run this application. I suggest you register an ID at TopCoder using the application and try out writing and compiling some code using it. The TopCoder implementation uses plain Swing as it was written before JavaFX existed, but you could equally use JavaFX for your implementation if you preferred.
If you additionally need an editor (with syntax aware text styling) for the code you will be compiling, you could use something like this CodeMirror based editor embedded in JavaFX. The CodeMirror based solution wraps the editor in html based WebView control. For JavaFX 8 you will probably be able to make use of the new TextFlow control for a syntax highlighting text editor, but that API is not part of a supported public release yet.
Update
I got this work using the strategy outlined in this answer.
The image is an html page allowing access as an applet or a webstart application to the client code editor. The top area of the image is the code editing area which is based on a WebEngine with an embedded syntax highlighting CodeMirror JavaScript editor that supports Java editing. The bottom area of the image is the output of compiling the code in the editor locally on the client machine and subsequently running it. The output constists of any compilation errors, any program output to sysout, as well as any runtime exceptions printed to syserr. The tricky parts of the solution were:
Working out how to capture sysout and syserr and redirect them to a JavaFX control.
Finding the Java compiler.
The default Oracle Java Runtime Environment Provider merely provides a generic interface to a Java Compiler implementation, but it provides no java compiler implementation itself - that implementation is only included in the tools.jar included with the jdk. So when I packaged my applet, I included the tools.jar in the packaging for the applet. I had some difficulty getting the service provider interface to get me an instance of the javac compiler, so in the end, I just instantiated it using the following line:
JavaCompiler compiler = new com.sun.tools.javac.api.JavacTool();
The above is somewhat brittle as sun may change their private com.sun classes at any time - but at least it worked in this instance.
Another thing to be aware of is that if you ship a tools.jar with a javac compiler which is earlier than the runtime environment that you have available for your system, then you might get some warnings such as below:
warning: C:\Program Files\Java\jre8\lib\rt.jar(java/lang/Object.class): major version 52 is newer than 51, the highest major version supported by this compiler.
It is recommended that the compiler be upgraded.
The above warning occurred because I shipped the applet with a java 7 tools.jar and ran the applet with a java 8 runtime (note that the applet worked fine regardless of those warnings).
Update
I put the code for this solution in a github repository (project name conception). The updated solution uses the Eclipse Compiler for Java rather than the Oracle Java Compiler. Mostly because, for the Eclipse Compiler, it is a separate jar (only 1.8meg rather than the 14meg tool jar of the oracle distribution) and the licensing is a bit clearer. Because the Java compiler interface is pluggable, the Oracle compiler can still be used if tools.jar is placed on the classpath.

Yeah applets can access them and can be a good choice. But it has very limited/ dull look and feell. Go for JavaFx in this you can define your own StyleSheet so it will give you a very good look and feel and yeah definitely it will separate the two layers too.
JavaFx Oracle Documentation

Tizen Mobile & IPad Linux - Does it allow GCC and Java?

https://www.tizen.org/ Tizen Mobile & IPad Linux very exciting.
Its allowing GCC. But does it run Dalvik JVM or OpenJDK?
Will then it will be compatible with 32-bit or 64-bit compilers?
Or we need to convert our source to be re-compiled using ARM compilers? of GCC?
Will it be easier to port C, Java code's now to Tizen? Where its complex and not natively available under Android phones/platforms?

As far as I know, it will be possible to package applications as DEB or RPM packages, you will be able to include an embedded VM (for example Avian VM) if you want, probably no JVM will be installed by default. JavaSE Embedded and OpenJDK should work (maybe with small modifications) under Tizen even though the documention only mentions C/C++ for native apps and HTML5/JavaScript for web apps. Moreover, there is no Java binding to its native APIs yet except those already available for Linux ARM and for APIs supported in any Linux distribution (for example JOGL 2.0). If you really need some help to use Java under Tizen, please contact the JogAmp Foundation here. Xerxes already succeeded in running JOGL 2.0 under Meego as you can see here, why not doing the same thing under Tizen?
N.B: Don't expect official Java support under Tizen.

If you check this two presentation from May:
Tips and Tricks: Designing Low-Power Native and Web Apps on page 3.
and this
Implementation of Standard Accessibility APIs for Tizen on page 9.
You see that basically Tizen will have two APIs and hence two types of applications:
Native;
Web(HTML5) pretty well documented already.
So no JVM or OpenJDK, don't know the Native API apps binaries will be compiled to but probably will know soon.
Since Tizen is pretty much in development you can check from time to time the official site.

Does it matter which vendor's JDK you build with?

If I'm deploying to servers with WebSphere 6.1 (Java 1.5), should I use IBM's JDK on my build box? Or will Sun's JDK compile to the same binary?
If I should use IBM's, where can I get the Windows x64 version?

I would as much as possible try to keep development as close to production as possible. Ibm and Sun's JDK's certainly both satisfy the SDK certification, but they are by no means identical. Their instrumentation and memory management are at least slightly different. If nothing else, the bugs in the JDK will be different, which your code may only trip over in one scenario vs. another. It'll also probably only happen at 4 am, and when the moon is full especially when you have company over.
I can't tell you where to get IBM's jdk, but if you've got a license to websphere at your company, you should have a contact at IBM to get you a link to that JDK.
Good luck, and always try to minimize differences where possible.

It should not make any difference. It will probably not be exactly the same binary but 100% compatible. I assume you're using external libraries anyways like log4j or maybe hibernate or whatever and those are not built using the IBM JDK.
There are differences in the JREs, however. For example, I remember that when I listed methods or fields of a class using reflection, the IBM JRE used to give them to me in a different order than the Sun one.

I would use the same JDK to build that is going to be used when the application is deployed (if you have control over that).
The binaries may be different if the compiler is different, but they should be semantically identical. I don't know if IBM wrote its own compiler. The JRockit JDK actually uses the Sun compiler but the JVMs are different. So with JRockit the binaries are identical.
If the application is used with different JDKs at run time, I would still build with the one that you think will be used at deployment time most of the time and do some runtime testing with different JDKs.

The IBM JDK ships with J9 VM and SUN JDK runs on Hotspot VM which have different algorithms to function. You application may not perform the same if you deploy and tune in SUN JDK and your production uses IBM JDK for WAS. Check with the vendors and open a ticket,let us know how it goes.

Compiling with any JDK should not cause a problem unless you are referencing classes outside of the java.* and javax.* pacakges (which you should not be.) Of course there's always a chance that there's a discrepancy between a given vendor's JDK and the spec which could cause some really weird runtime errors that are hard to track down, but I've never seen this before in my experience.
I would recommend running any test suites you have using the target JRE as runtime behaviors differ between vendors much more often than compilation semantics do.

JDKs are compiling your code to a bytecode and not directly to machine code. Is expected that compilers of different vendors generating cross-vendor compatible code. For example IBMs compiler for JDK1.5 will produce code that runs on SUN's JDK 1.5 and later without any problem.
Another issue is how compilers optimizing the bytecode, I have not information that some compilers performing better optimization than others. The largest part of optimization is performed during runtime by JVM (for example JIT (just-in-time) or AOT (ahead-of-time) strategies).

Having worked with WebSphere a long time the version of the JDK is very important. WebSphere 6.1 ships with an IBM JDK 1.5 (or is it 5). When you patch the WebSphere there are equivalent patches for the JDK as well. While it may work with a different version of the JDK (even a different vendor) I doubt you will get much support from IBM if something goes wrong.
If you need a 64 bit JVM I would suggest that there is probably a 64 bit build, while I cannot comment on windows specifically I can tell you there is a 64 bit WebSphere 6.1 build for both AIX and Linux.
The best answer is to check with the vendor and see if they will support your configuration. What you don't want to do is get it working, then have an issue in live, call up support and find out that you have an unsupported environment.

They should compile to the same bytecode specification, although they may compile different bytecode (much as in the same way different C compilers generate different machine code). I don't think there would be any problems in running the resulting code - I've compiled Java 1.4 on a Mac and then deployed to IBM's J9 running on a PocketPC before with no problems (this was before J9 could handle Java 5 bytecode).
Regardless, I'd definitely make your compilation platform a bullet point on your readme file so that your client can see if it is a problem.
Alternatively, you could build and deploy with ANT, and use Sun's JDK with ANT.