I am experiencing numerous problems with java in MatLab 2013a, for example while using pmode, matlabpool, creating stand alone applications etc.
Sometimes there is a work-around but this is not always the case.
Does anybody has a solution for this problem. Is there a patch or a downgraded java version that works for you?
I believe that this is a different Java disaster from the one #JamesGrammatikos pointed out. I had to figure it out myself on R2012b. See this bug report at the MathWorks. To apply the workaround, read everything and follow the directions carefully as they didn't exactly try hard to make the patch into any sort of installer. Once, applied, everything works again, but looking at the patch code, there's still room for other stuff to break.
A Java update last month ago pretty much destroyed most Java based programs on Macs (including Matlab for me). The update at this link fixed it for me.
http://support.apple.com/kb/DL1572 (OS X 10.7, 10.8+)
Related
I am having a problem with applications that require Java to run, like Eclipse, DBeaver and so on. I have Java 11 JDK installed, but the tabs on each of these applications are showing weird names. I do think that the problem is because of Java and I really wanted to know if anybody else had this kind of problem, and how they dealt with it. It is driving me crazy. I tried uninstalling and reinstalling JDK but nothing successfully resolved my problem.
I have not experienced the issue that you are seeing however I can suggest a possible reason for this.
Java 9+ represents Strings using UTF-8, rather than UTF-16 (I think), which was used previously. This means that characters will take a different number of bytes in their representation. I would suggest re-installing the packages which are showing the issue, these (if they are java based) have presumably been built with a newer java and the new install will hopefully not display this issue.
After ignoring Java updates for quite some time, I now want to move on from the somewhat shady Java 10.0.2 Runtime I found somewhere to Java 13. As it turns out, Oracle stopped the "monolithic" JRE philosophy after Java 8 and I can't seem to find any definitive answers to my questions on how I'd go about deployment.
Here's what I think stays the same:
IDE (eclipse) workflow mostly stays the same
If I want to use the program myself, I can compile it to a .jar that will run on the JVM that comes with the JDK, just like with a Java 8 runtime
Now, here comes the tricky part I can't wrap my head around: Deployment on other machines
Create a module-info.java that lists the dependencies of that program
Compile a .jar as always using the eclipse dialogue
Use jlink to create a runtime image for that program to ship alongside
...But what now?
How are these images making the program work? I read that they're some sort of small JRE for that program alone, which would remove the need for Java to be installed on the target system, but how would that be cross-platform?
Or are they some sort of "patch" to the JRE that is available to download from the official site? That would explain why that is still being updated, but it wouldn't remove the need for Java to be installed on the target machine.
TL;DR:
Is there anything wrong with my understanding so far?
How do jlink-ed runtime images work?
How are they cross-platform?
Does the target machine still need any sort of pre-installed Java-related software e.g. a runtime / the runtime provided in the link?
Thank you very much for reading through my wall of text and thank you in advance for the answer!
EDIT: Made the point of question four clearer.
All my questions have been answered by Slaw in the comments to the original question, so I'll sum them up here in this answer.
My understanding so far is correct
jlink creates a mini-JRE with the modules the program needs, as specified in module-info.java
They're not, one would need to e.g. Linux-JDK to create a linux-specific version etc.
All files needed to run/interprete the program are contained in the runtime image
Also thanks for the extr info! I'll make sure to look into JMOD, and from what I read about jpackage, it's something to be very excited for.
I am still working on the issue Java AWT Fonts scrambled which I posted here a while ago. More Debugging has been done, and it seems like the arm64 java is the problem. When running 32 bit java on arm64 it is working fine, same on amd64, arm32 and x86.
Is arm64 Java expected to behave different with that code? Shouldn't Java react the same way on every architecture? If yes, where could I open a Bug for that? I am using Oracle Java Runtime Environment if that matters. Java is so complex that I am not sure which is the right place to open that bug so it can get adressed and investigated.
Java is supposed to be platform independent but there are limits when resources of the underlying system need to be used. In that case platform dependency comes into play and you might see different behaviors with different JDKs. Fonts are provided by the operating system so you have some kind of platform specific stuff going on here as well.
Your original question and this one lack some fundamental thing: A workable source that shows the effect on your system. With that it would be possible to try to reproduce your problem on other peoples' systems and might come up with an answer why you have this effect. Your original question e.g. lacks the information what Font you're actually using and I don't see any code where you write the text that appears scrambled.
I want to change the JDK version 1.5.15 to 1.6.29. If I do this, will any problems occur in an existing application that was developed under JDK 1.5.15?
Technically that shouldn't be a problem. But I would have a bad feeling doing this without enough test coverage. There was a project in my company were they were also changing to a newer java version (don't remember which one). Everything seems to be fine but after some time a few bugs were rising. It turned out that one developer illegally relied on the order of a Collection class. The bug was caused by a changed implementation.
Take a look at the Java SE 6 Compatibility with J2SE 5.0 document. It should be ok, but please go through the incompatibilities section just in case.
Try to compile your code with new JDK(1.6.9) classpath than you are fine no need to change anything.
If code change require follow some online JDK 1.5 to 1.6 migration tutorials already available.
You will have to test this. It probably is possible to compile and run your application with JDK1.6, but some behavior might have changed in a subtle way. An example of such a change between JDK1.6 and JDK1.7 I recently encountered is posted here on StackOverflow. Although the project compiled just fine, testing (unit tests, integration tests and manual testing) revealed some issues which weren't caught by the compiler
No i don't think it will create any Problem.
I've got my hands on an old Microsoft J++ project that uses some old Microsoft-specific things from the Microsoft Java Virtual Machine (now deprecated and unsupported). It uses additional things from the old Microsoft Java Development Kit, which I can't find anywhere on the web.
It seems the best route forward is to migrate this project to the latest version of Java, and migrate the J++ .sln solution file to an Eclipse project file.
I'm a bit overwhelmed right now -- are there any tools to help ease the migration process? Any tips for doing such a conversion?
I actually developed a J++ app on Eclipse for a number of years, using Eclipse as an editor and VS as a compiler. The WFC problem was prohibitive (and will definitely keep you from porting to straight Java), but Eclipse was still able to grok and refactor most everything as a straight editor with compilation turned off. This was actually where I learned to love Eclipse.
We eventually ported the entire 700K+ line app to C# with relative ease. I would avoid J#, as it's deprecated now. Go straight to C#, use VS with Resharper and you'll almost feel like you're in Eclipse. : ) The C# converter was pretty dang accurate, and left helpful comments in the sections where it knew there was a less than 1-to-1 conversion, most of which were minor.
I would break this up in multiple steps.
First get this to compile and in Visual J++. You will most likely need to buy a used copy from e.g. Ebay.
A quick search found http://cgi.ebay.com/Visual-J-6-0-Professional-Commercial-Box-561-00176_W0QQitemZ320309632655QQihZ011QQcategoryZ80301QQcmdZViewItem
THen when you can see how this works you can work isolating and refactoring the Microsoftisms into something generically usable. This page illustrates how to make J++ work with a Sun JRE so you can do the initial work there: http://java3d.j3d.org/tutorials/quick_fix/vis_jpp.html
Then you will most likely have a bunch of java files which you can copy-paste into a fresh Java project inside Eclipse.
J++ was sufficiently unloved that you are almost certainly going to have to do a lot of your own rewrite/replacement of the WFC extensions going the Java route.
You may (and I stress the may) find the way forward to .net marginally less grubby -- if you can get hold of a copy of Visual Studio.Net (.net 1.0 vintage) and use the J# Upgrade wizard (not sure if there was ever a stand-alone commandline tool); from then you could use the Java Language Conversion Assistant (in VS 2005) to migrate to C# -- though even that path will leave you with some approximate conversions that you will need to inspect, from things that are loudly commented in the transformed code, to subtler things like Thread being sealed ( == final) in .net, and not in the Java APIs.