Basically the subject says it all: We have a couple of components running on Java 5, they're talking to each other via RMI. Should we expect any problems, if we move some of them to Java6? By moving I mean compiling them with -source/target 1.6 and running on a java6 vm.
Nope, you shouldn't expect any problems with that. But anyway take a look to the Release notes for RMI in java 6
Good luck!
We have successfully pulled in Java 5 serialized objects into Java 6 objects so there should be no limitation on the serialization front.
You should also be able to switch between 32bit and 64bit Java as well without issues.
Related
If I am not mistaken older versions of Java e.g. Oracle Forms running on 1.4, will still work, when ran in JVM 8.
But my question is related to Java Accessibility. I am struggling to make the Oracle Forms expose its elements. Therefore I am wondering whether it could be that the JRE which is running Oracle Forms 1.4 would require me to have Java Access Bridge for 1.4?
I am not sure how this part works any assistance is greatly appreciated!
Found an answer from https://docs.oracle.com/javase/7/docs/technotes/guides/access/enable_and_test.html
In case there are many versions of Java used in the technology stack, it is advisable to just go through them all and disabling different versions.
In my case, unfortunately, the application is built in a way that Accessibility is not supported.
I have a doubt about java upgrading
I have applications running in java 6, for example.
And I wanto to upgrade my java to a 7 or 8
My doubt is: What is the best way to upgrade mi current java version?
Or how can I do it?
This applications currently are productive, so this means I has to upgrade the java version witouth affectate it.
I'm very confused about this, hope you can help me
There's only one way to do it:
Upgrade the JVM
Recompile the code and fix any errors that the JVM complains about.
Regression test the code running under the new JVM and make sure the functionality is unchanged.
Take the opportunity to see if there are any advantages to adding new features (e.g. java.time package, lambdas, java.util.function package, etc.)
No one should be running on any JVM other than 8 or 9. JDKs older than 8 have passed the end of their support lives. They are not getting any more security patches.
You are making the excuse that everyone tries when faced with currency issues: "The code is working fine. Why change it?"
Unfortunately there's a price to falling behind.
I'd advise you to upgrade as soon as possible. Stop the excuses.
JDK 9 is the current version. Current or current-1 is usually acceptable; current-3 is not.
Since the release of Java 8, I found myself slowly becoming dependent on Java 8-specific features (ex. lambda statements) on a library project that I have just started.
I have seen many other projects which, to this day, still build against Java 7, or even Java 6, causing me to second-guess myself.
Is it a good idea to immediately start building against the newest version of Java, or should I still use older versions?
Note that unlike those other projects that have started back when Java 6/7 was the newest version, mine was started recently when Java 8 is the newest.
There are two reasons I can think of that would require staying with a pre-Java 8 JVM:
You are writing a library that is being used by a large group of people outside your organization who are still stuck on a pre-Java 8 JVM. If you use the latest and greatest JVM, they won't be able to use your product anymore.
You are dependent on a 3rd party library that has not upgraded to Java 8 and breaks on Java 8.
Since you mentioned this is a new project, #1 is unlikely. Even if you plan on having external users, if it's a new project, requiring the latest version of the JVM isn't really an issue.
Number 2 is also getting more and more unlikely as the more popular 3rd party libraries have released updates to work on Java 8. Even the few stragglers are usually OK working on Java 8. For example I use an ancient version of hibernate with Java 8. I just don't use any Java 8 features in any mapped fields/entities.
Java 8 denotes a major change to the language since Java 5 (or perhaps its inception). If you are targeting specifically the changed language parts (which I guess you claim) then making it usable only by Java 8+ runtime makes sense.
When Java 5 occurred 10 years ago and you wanted to use all the new features introduced at the time (e.g. foreach statement, Enums etc.) into your own library development, what would you have done? I believe you would have made your library require Java 5 at the minimum. If you agree with that, then that (sound) logic applies consistently to your present situation as well.
For server side application, possibly a version or two prior to the current version as suggested by EJP.
On the client side however, I don't see any point in trying to support older Java versions. The JRE has been auto-updating since at least Java 6. It has gotten to the point where Java Web Start launched applications cannot specify an earlier than current JRE. Or rather, it can specify any JRE it chooses in the launch file, but that will be ignored in favor of the latest version installed on the user's computer.
Recently, I had a question like whether we can use java to programme the hardware...
I answered them like, to run java application we need JVM. So we can't use java to program the hardware...
But, I came to know, it is wrong...
But I don't understand clearly, how to install a jvm inside the hardware... how to run java application in hardware ...
Please clarify my doubt and if possible give me some example applications working in hardware...
Thanks
Why not?
The most reasonable parsing of "install jvm inside hardware" is to install software - the most common way to create a JVM.
However, there is nothing stopping you from building hardware that conforms to the JVM specs.
Here are some links:
The Java Virtual Machine in Hardware
A Hardware Implementation of the Java Virtual Machine
A few links:
Oracle embedded java (not sure if thats what you mean)
JOP : JVM on FPGA
IBM Liquid Metal project
There are JVM implementations for many different platforms. I like the one for lego mindstorms, you only need to flash the controller with the appropriate firmware and there you go.
We've been developing a windows based application using Java for a while now, but NOW we want to make a mac port and have to reverse of code from Java 6 and Java 5. Is there any easy way to do this rather than re-coding Java 6 specific code? We'd like to keep our code up to date.
There are a couple of libraries out there which can help you. Unfortunately I haven't tried them myself, because I've never run into such a situation.
Retroweaver
Retrotransaltor
backport-jsr166
See here:
http://en.wikipedia.org/wiki/Comparison_of_backporting_tools
I tried retrotranslator from 1.6 to 1.4.2 and it works pretty well!
Apple released Java 6 on the latest version of OS X. What features are you using specifically from Java6 that aren't in java5?
In my experience this is so easy that the whining takes more time than the doing. There are very few things in 1.6 that can't be backported with a minute or so (literally) worth of work. How many compile errors are you seeing when you try it with 1.5, and what for?
Keep in mind that there are readily available, API compatible, low-footprint backports for the few things that are useful in 1.6 (SwingWorker).
Do you know how much you would have to rewrite if you just went back to Java 5? If you changes the JDK setting in your IDE and try to recompile it should give you a pretty good idea on how big the changes would actually be. For most developers, Java 6 didn't really offer too much in the way of new features/APIs but I guess it's possible your project depends heavily on something that was added.
There is also Java 8 for Mac OS X. New versions of Java would be compatible, like Java 8 is compatible with Java 5 Code, so Java 6 code is compatible too.
You might be able to backport the additional libraries from Java 6 to Java 5, but I imagine it would be rather more trouble that it's worth. Intel Macs with 64-bit processors (so not the original Intel Mac Mini) running Leopard have Java 6, so perhaps you could just target them?