In the document provided by Log4j2.x it clearly says that it requires jdk8+ but , my question here is ,doest it require jdk8 + on both runtime and compile time ?
Because am facing some issues when it is compiled with jdk7.
However my runtime machines are running in jdk8.
Related
I am trying to run a .tcl file originally configured for 2014.4 on 2016.4 version of Vivado. However I am getting the following error:
while executing
"create_bd_cell -type ip -vlnv xilinx.com:ip:mig mig_0 "
(procedure "create_root_design" line 111)
invoked from within
"create_root_design """
(file "all.tcl" line 405)
The tcl file uses the part 'xcku040-ffva1156-2' and tries to access the IP 'mig' which I believe is renamed/changed on later versions. Is there any workaround for this?
Steps I have done till now:
Changed the version number to 2016.4
tried replacing target boards.
tried on the same board with an alternate IP for mig.
tried on both 2016.4 and 2015.4 versions
None of these have worked so far
Attaching the '.tcl' file for reference : all.tcl
Since with every version upgrade of the Vivado Design Suite, parts are renamed or removed, it is not possible to run a .tcl file meant for an earlier version in newer releases. So I ran the above query on Xilinx Community Forums and found a workaround:
Run this script on the previous version(2014 in this case), generate the design and then open the same design using the next major release(2015 version). The 2015 version will automatically suggest upgrades to the discontinued/renamed IPs. Repeat the same to get to 2016 version. That's the only way to get this done. Also have to keep checking if the core functionality of the IP is the same after automated upgrades by Vivado Design Suite.
I ran into an obscure error and am posting the solution here in the hope that it will help someone else having the same problem.
I am writing a Continuous Integration (CI) program using Delphi XE4 to ensure that a set of pascal source files will compile under older versions of Delphi. This CI program runs a series of batch files each running the command line compiler of an older Delphi version. The batch file running the XE compiler produced the following error:
F2048 Bad unit format: 'c:\program files (x86)\embarcadero\rad studio\11.0\lib\Win32\release\System.dcu' - Expected version: 22.0 ... Found version: 25.0
Note that the expected and found versions are different (in this case XE and XE4). Several people have reported similar errors where the expected and found versions were the same - this is usually a mixup between 32 and 64 bit DCUs, but that wasn't the problem here.
This problem only occurs when the CI program is run from within the Delphi XE4 IDE. If the CI program is run outside of the IDE it works fine.
The XE4 IDE adds several environment variables that are inherited by the program being debugged (in this case CI) that are in turn inherited by the batch files. One of these extra environment variables confuses the XE compiler when run in the batch file. The culprit is the added BDSLIB environment variable that points to the XE4 lib directory.
The solution was to simply add
set BDSLIB=
to the beginning of each of batch files. Once this change was made the CI program runs successfully both inside and outside the IDE.
I've created a tiny project [0] to reproduce an error in a controlled environment. The facts, I'm using jenkins to build my project, a big one, I'd like to make some parallel builds. Let me make it graphically
[MyBasicPackage] -----> [MyPackageTester] ------> [MyBasicApp]
.
.
+-----> [...]
+-----> [...]
this is the organization I've made on [0], I have a class TMyUnit (MyBasicPackage) registered on spring container to be tested. I build it and generate its .dcu, .bpl, and so on.
The second stage I build my MyPackageTester that requires MyBasicPackage. Finally I build the app that requires MyPackageTester. So far so good.
When I try to build my MyBasicPackage on, say PC-00, get the artifacts and try to build the the MyPackageTester on PC-06 (same arch, same OS, same IDE, same spring4d version), and a nice error arise:
Unit TMyUnit was compiled with a different version of Spring.Container.Registration
so, I update my spring4d on both machines (PC-00 and PC-06) and build them. Run... and same error arise.
check the library path options (C:\Program Files (x86)\Embarcadero\Studio\14.0\Componentes\spring4d\Library\DelphiXE6\Win32\Debug), delete dcu files and build them once again on both machines, same error.
copy dcu files from PC-00 to PC-06 to avoid any kind of system configuration and the same error arise.
Probably I'm trying to do something that's not possible so far. I've googled a couple of days without luck.
Any ideas?
Please feel free to fork or pull request the example ;)
Regards
[0] https://github.com/graguirre/DelphiDepencyExample
In your case you need to build with the Spring.Core runtime package. Not only will that prevent this error but your code will actually work.
If you do not then all modules will hold their own version of the GlobalContainer instance you are using and nothing will work.
Maybe one solution is put all your libraries in a centralized repository and pull them to compile your projects. It should resolve the different version error.
Apache OfBiz is not installing correctly, and fails to compile in the command prompt.
After creating the system variable JAVA_HOME to C:\Program Files\Java\jdk1.8.0_40, and editing "Path" to be C:\Program Files (x86)\Java\jre7\bin;C:\apache-ant-1.9.4\bin, I downloaded OfBiz 13.07.01 to my C:\ folder and unzipped it there. In the command prompt, I typed the following:
C:\Users\CalS>cd C:\apache-ofbiz-13.07.01
C:\apache-ofbiz-13.07.01>ant load-seed
Then, after about 50 seconds, I get this:
BUILD FAILED
C:\apache-ofbiz-13.07.01\build.xml:229: the following error occurred while executing this line:
C:\apache-ofbiz-13.07.01\build.xml:248: the following error occurred while executing this line:
C:\apache-ofbiz-13.07.01\build.xml:39: the following error occurred while executing this line:
C:\apache-ofbiz-13.07.01\build.xml:91: compile failed; see the compiler error output for details.
Please note it has been years since I dealt with DOS, so I do not know how to access the error output.
This is after I get a few dozen errors like:
[javac16] class file for org.ofbiz.widget.ContentWorkerInterfaice not found
and
[javac16] warning: [options] bootstrap class path not set in conjunctions with -source 1.6
Under 'classes'.
Misc. I have tried 'ant run-install' and 'load-demo' commands without avail. I've followed step-by-step tutorials, but very likely missed something. Please let me know what I can do to fix this and run this program successfully. Thanks!
Please have a look at the following Apache Jira Tickets for OFBiz where your problem is addressed and was fixed, so that OFBiz could be build with java 1.8.
The build errors occur due to missing fileset entries in the build.xml for some applications (party, workeffort, product, order, ebay, and pos), see: OFBIZ-5835
A fix is available in related ticket: OFBIZ-6079
There was another bug in the current release branches (checked 14.12.01, 12.04.06, 13.07.02) that I fixed last week. The fix is already committed to the branches.
See: OFBIZ-6252
You have to compile/run with the same Java version.
Seems you have some inconsistencies: JAVA_HOME ist 1.8, Path is set to jre 7 and the warning states it is using an 1.6 compiler.
With the 13.07. Release, using Java 1.7 or 1.8 is recommended and supported.
Alright, so it looks like Apache OFBiz and Java JDK 1.8.XX don't get along. I found help on another forum that confirmed the discrepancy in compatibility between OFBiz 13.07.01/Apache ant 1.9.4 and JDK 1.8.XX. This will cause the compiling of the Apache Ant to fail (which seems to run off of JDK 1.6).
I remedied the problem by downloading the archived JDK 1.7.0_67 from Oracle, re-mapping the System Variables accordingly, and re-initializing the Command Prompt.
It works now! Thank you all for your contributions.
Though solved, let me add something important. JDK version is not always an issue in such errors. Ofbiz v13.X.X works well on JDK 1.7 and above. The error shown is a peculiar issue with Ofbiz v13.07.01 dist.
As Martin pointed out, one need to add widget jars in the classpath of order, party, product & workeffort. Add the below line
<fileset dir="../../framework/widget/build/lib" includes="*.jar"/>
in build.xml of order, party, product & workeffort under applications directory.
PHP has different opcode caches like APC, Zend Optimizer to cache the code and dramatically speed things up. Does Ruby have something similar?
The default Ruby 1.9.x is based on a bytecode VM, in addition you have ruby implementations based on the Java Virtual Machine (JRuby) and LLVM (Rubinius and MacRuby). These will all do just-in-time compilation and other optimizations you'd expect from a modern VM.
Default production settings in Rails is:
config.cache_classes = true
which mean that code isn't reloaded after requests, therefore it's cached in memory.
As far as MRI is concerned, experimental bytecode caching has been released with Ruby 2.3.
All you need to do to make this feature enabled is just to require
'yomikomu' rubygem and set some environmental variables introduced at
here as you can find two export commands in the example above.
It may look a bit magical why VM-level bytecode cache is enabled only
by requiring 'yomikomu' rubygem. Koichi described about this at his
ticket.
Here is a quick benchmark result of current bytecode cache implementation. I used 'bundle version' command with benchmark-ips on Ubuntu machine. Source
The post also provides some benchmarks for this newly released functionality:
$ ruby measure.rb
Comparison:
yomikomu(fs): 5.0 i/s
yomikomanai: 3.6 i/s - 1.40x slower
Other ruby implementations might be able to take advantage of the platform native optimizations - eg. JRuby benefits from the performance benefits of JVM JIT.