My environment is JDK6. And I test my code in Win7 and Win2003 both using the same JRE.
I installed JAVA WindowsLookAndFeel using code "UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");".
I supposed UI should behave consistently in Win7 and Win2003 after I installed WindowsLookAndFeel. I think it should be different from using code "UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());"which is OS-related. But the truth is UI looks like Win7 in Win7, looks like Win2003 in Win2003. I read source code of WindowsLookAndFeel and found if windows NT version is less than 4.0, WindowsLookAndFeel will use WindowsClassicLookAndFeel instead. But Win2003's windows NT version is 5.2.
And even CrossPlatformLookAndFeelClassName also has a different java look in Win7 and Win2003.
Can you explain it? I am really confused.
Can I have same UI on different windows OS by installing WindowsLookAndFeel?
Thank you.
I supposed UI should behave consistently in Win7 and Win2003 after I installed WindowsLookAndFeel.
That supposition is not correct. The Oracle tutorial says this:
"For Windows, the System L&F is "Windows," which mimics the L&F of the particular Windows OS that is running—classic Windows, XP, or Vista."
... and that is what WindowsLookAndFeel implements.
And even CrossPlatformLookAndFeelClassName also has a different java look in Win7 and Win2003.
The tutorial says this:
"CrossPlatformLookAndFeel—this is the "Java L&F" (also called "Metal") that looks the same on all platforms. It is part of the Java API (javax.swing.plaf.metal) and is the default that will be used if you do nothing in your code to set a different L&F."
I think that might better be stated as "... aims to look the same on all platforms". In reality, it is really difficult to get UIs to look identical across platforms.
Another possibility is that you are (somehow) picking up a different default look and feel in different versions of Java and/or platforms; e.g. Metal versus Ocean versus Nimbus.
Finally, you may simply be expecting too much. Win2003 is not listed as a supported platform for Java 7. It was supported for Java 6, but clearly it wouldn't have been a high priority for Sun / Oracle to get the UI consistency perfect for a legacy Windows platform that was due to be de-supported.
Related
I am using the javax.comm API to help my program communicate with hardware over serial port. I am using the Windows 7 and NetBeans IDE 9.
I used the common Java program to check the available ports on my PC. The program compiled and ran without error. However it returned nothing.
What can I do to use the javax.comm API on Windows? It seems win32com.dll does not work with a 64-bit operating system.
This is how I got it to work.
I've tested it using JDK 1.6 (32bit) on my Windows 7 64bit machine.
Install 32bit JDK.
Copy 'win32com.dll' to JDK_HOME\jre\bin.
Copy 'javax.comm.properties'to to JDK_HOME\jre\lib.
Copy 'comm.jar'to to JDK_HOME\jre\lib\ext.
Now run your program and it should work.
Recent 2.2pre versions of RXTX include binaries for 64-bit windows. I think the latest RXTX information source has changed to this: http://rxtx.qbang.org instead of http://www.rxtx.org though.
At one point the RXTX library included drop-in support for using the javax.comm api. I'm not sure if it still does, but the main change then to use the "native" RXTX packaging was primarily just a package name change.
it seem the win32com.dll does not work with 64-bit Operating system
I think that is correct. In fact, according to the relevant download page, Oracle no longer supports the javax.comm API for any Windows platform.
However, I found this page which has a 64bit build of the DLL, among other things.
EDIT
By an astounding piece of research (i.e. following the links and reading stuff) I found the download page for the latest RXTX, which claims to have binaries for various platforms. If your platform is not there, try building from source. If that doesn't work, consider investing the effort in making it work.
I've integrated RXTX libraries into some of my earlier projects and i found out this bug it has while working with comm ports under windows, so you might want to check this first before going into some serious app design.
Communication works fine, never had any problem with that, but once you open the port you cannot close it and reopen, if you use method provided for closing port, your app just hangs, no exception no nothing. I found later the same behavior described by users on web, but never really found the solution to this problem.
Again, this might help you save some time, check it first.
Latest release, which is this http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip, doesn't have this issue no more. Unfortunately i think its solved only for windows, its still there on Linux binaries, and i haven't tried it on mac.
Have you got a look on RXTX ? I think it is still active.
I had this issue...on a 64 bit machine..running windows 7
a legacy application developed in jdk 1.4, for 32 bit windows... and using the win32 comm api binary
i tried the RXTX binary for 64 bit and i was able to communicate with my device on some level... but... there were other problems as my application referenced a version of the jpos library that internally was using the comm-api (had import javax.comm.*... in some Serial...Listener class)....
I installed a 32 bit jdk and setup the comm-api binaries for 32 bit windows as directed here...setup comm api on windows
all was fine afterwards
You might be interested at an alternative library I've authored: http://code.google.com/p/jperipheral/
I have a Swing application that gets deployed on clients machine using a JNLP. Earlier we were using Java 5/6 to run the application on client machine and did support only pre Windows Vista operating systems. We also force the application to have "Windows Classic" look and feel by introducing -swing.noxp=true parameter in the JNLP file. This made sure that the application always had a classic look and feel.
But, now with the new requirement we have to support Java 7 and Windows 7/8 as well. In the Java 7u45 document I read that -swing.noxp is no longer supported. This eventually means that I can not use this parameter for the application to default to classic look and feel.
I tried launching the application with Windows 7 and Java 7u51 without the "-swing.noxp" parameter. This made the application look like Windows 7 default theme which gave a weird look and feel to the application (I can post the comparative snap shots if need be).
My question here is, does Java 7 have some parameter (in place of -swing.noxp) which will do the trick for me(because client want the application to have the same look and feel as pre Java 7 upgrade.)?
I know I can change the PLAFs and all but that is a huge code change. I am looking for something simple and similar to -swing.noxp
Thanks for the help in advance.
We have applet that uses smartcards to sign something. Everything was OK until new java update on Mac OS.
I'll explain. When macos had java 6 and special plugin for it, everything worked. But now they removed their plugin, and users must download browser-plugin for java 7 from Oracle web site.
Applet still sees Card Reader but doesn't see smartcard in it.
We use reader.isCardPresent() method, and it returns "false", no exceptions etc. like everything ok and there is no card in cardreader. We restore backup of the os, when there was 6 java and MacOS's own plugin, everything works. But we have many clients that have just bought new iMac or MacBook, they cannot use 6 java and apple's plugin.
Everything works on Windows.
We don't use any deprecated methods. Seems like problem with Oracle's plugin for Mac OS.
Anyone had similar problem or may be you have any ideas.
I just make some tests: take code from sample and slightly modify it. Run the sample on jdk1.7.0_09 in macosx 10.8.2. Pcsc framework 1.4.0.
terminal.isCardPresent() return false, but card can be accessed. Bug exist when java running both 32 and 64 bit mode. Pcscd running in 32 bit mode only, because generic pcsc driver is still 32-bit only.
In pcscd debug log i see some parsing errors in SHMMessageReceive, so bug may be in java or in the pcsc framework (winscard_msg.cpp).
with some fuzz around Windows 7, does somebody have experiences with Java compatibility with Windows 7? Should this be a concern or do the programs probably work ok?
I'd be especially interested if somebody has experiences with Swing applications?
The versions available seem to be beta versions so they won't provide perfect basis for evaluation but some.
br, Touko
Updating info related to the question:
According to Supported System Configurations for Java SE 6 and Java For Business 6
,
Windows 7 support was introduced in 1.6.0_14
From Java SE 6 Update 14 Release Notes changes:
6821003 hotspot runtime_system Update hotspot windows os_win32 for windows 7
From Java SE 6 Update 18 Release Notes:
For 6u18, support has been added for the following system configurations:
* Windows 7 support is now available
I have been using various Java apps on my Win 7 x64 box just fine and never had any problems. Even some of my oldt poorly coded swing apps have worked without issues.
For the most part, Win 7 is Vista in new clothing. Shouldn't have much issues because of that.
Your biggest concern is having the right Java runtime installed. WHen that is out of the way you can expect properly written Swing programs to work identically.
(With proper I refer to not having hardcoded button sizes or similar)
There are several problem of swing application in windows7 there are stated below:
JCheckBoxMenuItem will not show image
JCheckBoxMenuItem(Icon,Text,boolean);//Icon will not displayed
you can refer the http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122141.
Focus issues. Sometimes escape won't work
The problem I have with my Swing application on Windows 7 (and presumably Vista - haven't tried it), is that the Java Runtime indicates to Windows that it is UAC-aware, while my application that runs in the JVM actually isn't. As a result, if someone installs it into the traditional location (e.g. C:\Program Files\MyApp), the application fails because it cannot write configuration data or error log files to its installation directory. Because I use some third-party libraries that write their own files to the current (i.e. install) directory, and I've got many more important things to do than dig into those libraries just to make their error reporting and configuration storage UAC-aware, I took the path of least resistance and changed my default install directory to C:\MyApp. I realize that this is a regression back to the old DOS days where people ended up with myriad application directories in C:\, but it's not my fault that Windows' method of implementing UAC Virtualization for legacy applications doesn't work for Java apps.
The swing-UI of Java-programs doesn't work perfectly together with the awesome-wm. awesome is a window-manager for UNIX, that automatically resizes program-windows, and the Swing-UI doesn't recognize these resizes correctly. I don't care if awesome or Java is guilty, what I wanna know if I can change my Java-programs in a way, that they will work with awesome. So that users of my programs get the correct experience, even when they use exotic window-managers.
Easiest workaround - get wmname from suckless and use it to set the name of the window manager to LG3D:
wmname LG3D
98% of the time this will fix the issue.
From the man page of awesome:
BUGS
Of course there´s no bug in awesome. But there may be unexpected behaviours.
Java applications which use the XToolkit/XAWT backend may draw grey windows only. The XToolkit/XAWT backend breaks ICCCM-compliance
in recent JDK 1.5 and early JDK 1.6 versions, because it assumes a reparenting window manager. As a workaround you can use JDK 1.4
(which doesn´t contain the XToolkit/XAWT backend) or you can set the following environment variable (to use the older Motif backend
instead): AWT_TOOLKIT=MToolkit
You might find that this is a similar problem to that experienced with using Compiz and Java (on Ubuntu at least), but I am guessing.
The fix for this (taken from here) is to add the following environment variable to your program:
AWT_TOOLKIT="MToolkit"