I have installed IBM JDK 7 with release 1 and i am try to run Hello world program with -Xmt option on Ubuntu 14(OS installed in Virtual Box), but runtime i got Command-line option not recognized: -Xmt.
[In IBM documentation they said to create tenant use -Xmt with java command.]
These features are no longer available in their latest release thats why.
Check the links: here and here
They say that the had some issues but the thing is they also removed it from the developers preview page so there is no way to actually test it.
Related
I've a new computer with Debian 9 / 64bits.
After installing Netbeans 8.2 and Codename Plugin 5.0 if i try to open "CodenameOne Settings" or "CodenameOne Designer" nothing happens.
I've checked JRE_JAVA and JDK_JAVA and PATH environment variables and them points to the correct path.
I don't see any error message but the tools dont start.
I dont know what happens but i remember a similar issue in the old computer with Debian 6 / 32bits.
Can anybody help me?
Thanks a lot
Ramon Garcia
The default version of Java on Linux systems is OpenJDK which is a bit problematic due to its lack of JavaFX support. With newer JDKs we updated Codename One to download JavaFX dynamically as it was removed from the JDK but since the dynamic download only works with JDK 10 or newer (due to the way the people at Oracle compiled JavaFX) this would be the minimum version of OpenJDK.
So you can either install Oracle JDK 8 or Open JDK 11 to keep compatibility.
Notice you can track this issue by running the designer/gui builder from the command line and seeing the point of failure: https://www.codenameone.com/blog/tip-track-designer-guibuilder-issues.html
When I was installing WAS, there was a prompt alerting me to use Java 8 by default. I aggreed, because back then it wasn't matter which version to use.
Time passed and now I have necessity to use Java 6 in one of my profiles, which is coming with the WAS by default. Since I aggreed to use newer Java, WAS working on Java 8 by default now. I searched in installation repository, but in IBM Installation Manager Java versions I need are greyed out and cannot be installed separately.
Is there a way to install Java 6 alongside Java 8 in WAS, so I could just switch between them in profiles' setting? I tried official repository for Java 6, but it is empty since IBM dropped it's support in April.
P.S. I tried to change variable JAVA_HOME in Websphere profile setting (as well as in system variables) to look at JDK 1.6 I installed separately, but then my profile refuses to start.
Java 6 is no longer supported, so the WAS Installation Manager has likely removed the option to use JDK 6. For WAS 8.5 you can use either Java 7 or Java 8.
This article talks more about Java 6 End of Support:
https://developer.ibm.com/wasdev/blog/2017/10/25/java-6-end-support/
Apologies if this is more Server Fault than SO, but it is related to coding so here goes...
I have someone else's code that I am trying to compile on RHEL 7 but will run (for the moment at least) on RHEL 6. I've written my own RPM spec file to build and output an RPM file. The RPM builds fine on both RHEL 6 and RHEL 7 but when I build it on RHEL 7, does not produce an RPM which can be installed on RHEL 6 due to versions of GLIBC.
Is there a simple switch I can add to the build somewhere which will allow the resulting binary to be satisfied with an earlier version of GLIBC and be able to be installed on RHEL 6?
To be clear, I don't actually need a RHEL 7 binary at present, I'd just like to be able to compile for RHEL 6 on a RHEL 7 dev box.
You can use mock (sadly only in EPEL) to create a Red Hat Enterprise Linux 6 chroot on your Red Hat Enterprise Linux 7 system. If you use only libraries with Tier 1 ABI compatibility, your application will continue to run on Red Hat Enterprise Linux 7 without recompilation. Building on the oldest supported release (from the application point of view) is really the only way to do this. If you need a more recent C++ compiler and that's the reason why you are building on Red Hat Enterprise Linux 7, consider using Developer Toolset (DTS) instead.
Tier 1 libraries are described in the Application Compatibility Guide. There is supposed to be a PDF attachment with the previous list of packages, but I cannot access this right now.
I have Mac OS X 10.9 and Java SE Runtime Environment (build 1.7.0_17-b02)... I had another version of JEdit (I guess JEdit 4) and Java 6 before and my JEdit was working fine.
Then I upgraded Java to Java 7 because NetBeans7.4 needed to be installed with Java 7 (and I needed this new NetBeans because I had a fatal issue with NetBeans 7.3.1). So anyway, I installed Java 7 and I installed NetBeans 7.4 and my netbeans is working perfectly now, but when I tried to run the JEdit it brought up an alert saying it needs Java SE 6 to run!
I did some search in the net, and it seems that JEdit 4.5 (and I guess JEdit 5.1 too!) should not have any issue with Java 7, So I installed JEdit 5.1.0... I expected that it should work and don't bring up that complain alert BUT it didn't work and brought up "Java SE 6 is needed" complain again ...
I still can run JEdit using this command, but I can't use Cmd+C & Cmd+V shortcuts for copy and paste and it kills me!
java -jar /Applications/jEdit.app/Contents/Resources/Java/jedit.jar
Is there anybody who knows why JEdit 5.1 is complaining about Java 6 and how to fix it?! I really appreciate your help!
https://sourceforge.net/tracker/?func=detail&aid=3615181&group_id=588&atid=100588
After almost 3 months struggling with jEdit I'm ready to give up... I still can't run jEdit like a normal app. What do you suggest to replace my jEdit?! The main feature I need is realtime access to the server files... Most of editors keep a local version of files, so they don't show the changes when they are made in the server side. for example when I switch to a new git branch on server, my netbeans is still showing the branch that I was working before switching, so I need to do a complete download on the project. Any idea?!
#Monica About one year later after your question, I've experienced the same issue with Mountain Lion (according to jEdit's homepage, 5.1.0 is still the current stable version).
I've installed jEdit in /Applications/Dev/ (not /Applications as most people do, I believe; that's not important except for designating the path, see below). I'm using Java 7.
The following works for me from the command line, like for you:
java -jar /Applications/Dev/jEdit.app/Contents/Resources/Java/jedit.jar
So, I used Automator to create a normal MacOS Application named "MyJEdit.app" as in the screenshot. Now I can launch MyJEdit instead of jEdit. Other java flags might be required, for instance to set the memory usage (cf java -help and java -X).
jEdit on Mac OS X and Java 7 is a long story of annoyances, and fine points that Apple did not get quite right up to Java 6, and Oracle still learning about native platform support in the past 1-2 years.
Starting with Jdk-7u40 it works technically quite well, even Retina displays, but jEdit needs to be adapted slightly.
jEdit 5.2 will probably work with Java 7 out of the box, but a few points are still open. See also the tracker item 3615000 at Sourceforge.
Here is a practical proof that it works: Isabelle/jEdit -- it is an application based on jEdit that is bundled differently than official jEdit 5.1.0.
I would like to install ColdFusion Builder 2 Update 1 as a Plug-in for Eclipse 4.3.
The install seems to work without errors but when I attempt to register my license code, I get an error dialog box that says:
"The chosen operation is not enabled."
None of the CFB features appear in Eclipse.
In some of the documentation that I've found it references installing to Eclipse 3.6.
Can CFB 2u1 get installed on Eclipse 4.3? If not, does someone know which version of Eclipse to use for CFB? Hopefully it is something recent or I'm doing something wrong for the install.
I don't know if it matters, but I'm running:
Windows 7 Pro 64-bit
16GB RAM
According to the ColdFusion Builder System Requirements page one needs Eclipse 3.7.1. Having tried to install it on versions later than that, failing, and talking to Adobe about it, they confirmed that one needs that precise version. More recent ones won't do. This is a bit subpar on the part of Adobe, but so be it.