Applications that require Java are having strange tab namings - java

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.

Related

JTattoo to make Round buttons in java

I have a problem with my calculator Gui, I used Jtatto to Create a Calculator with Round Buttons
UIManager.setLookAndFeel("com.jtattoo.plaf.aluminium.AluminiumLookAndFeel");
But the buttons became looked like this:
Does anyone know how to fix this (i mean without any lines inside them)
This problem occurs with the newer versions of JDK since the look and feel tools are less frequently used. I currently use JDK v1.8 on NetBeans and this issue isn't there atleast for the jbuttons.
Although it's not generally recommended, you can try with the previous version of JDK to see if the issue persists or not
If you are using Apache NetBeans you can check which version of JDK NetBeans is using by selecting Tools ⇾ Java Platforms from the NetBeans menu
Further I would recommend you to either use Smart Look & Feel instead of aluminium or use the JDK v1.8 for better compatibility.
For more information you can read this article below :
https://www.geeksforgeeks.org/java-swing-jbutton-with-rounded-edges/

Understanding Deployment on Java 9+

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.

Java behaving in a different way on arm64

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.

When Does The JDK Compile Version Matter?

I have two Java artifacts being built. One needs to be built in 1.6, because PowerMock isn't compatible w/ 1.7 and we are using it in a lot of unit tests. Refactoring PowerMock out right now isn't an option as it will take too much time.
However, I want to use this artifact in a Java application built in 1.7 and run the whole thing in 1.7. I think that it should be Ok since it is just building some class files, which I doubt changed much if any probably as far back as 1.2 or earlier. Anyway, I obviously have a fuzzy understanding of this and I am interested to get a Java experts deep dive explanation as to when this would matter, when it wouldn't, and why.
Thanks!
Java is usually backwards compatible between versions so anything compiled on an old version should run fine on a newer JVM. In fact a lot of common libraries are compiled in as old a version as possible (usually Java 5 now a days) unless they need a newer feature to allow more people who are still stuck on old JVMs.
Having said that, there are a few gotchas you need to worry about. One problem I had on some Java 6 to 7 conversion was TreeMap with an initial value of null http://hariharanselvarajan-java.blogspot.com/2013/02/treemap-in-java-6-and-java-7.html
EDIT
Here is a link to Oracle discussing what isn't compatible between 6 and 7 although I would imagine this only affects things that are recompiled: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
The compiled code should be backwards compatible, so if you run it all on java7 it shouldn't matter than some was compiled using java6.
When you try the other way you get an invalid major/minor version number error.
I would assume that you can mix & match java 6 and 7 code too, just as you can (with caution) mix and match pre & post generics java.

Java errors on MacOS 10.8.4 using MatLab2013a

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+)

Categories