Are there any differences between these two java versions. If there are any differences how can I have the version java version "1.4.2" because that is what I have in server.
1)
java version "1.4.2_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
2)
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM AIX
They are very different from the implementation point of view as the first one is from Sun and the second from IBM. Since they are from different vendors, the patch level means nothing (the _06 on the Sun JDK).
From a behaviour point of view, they should be the same. Having said that, I remember some issues in the past with the IBM jdk, in which it would perform really poorly.
If you want to use IBM's version of java, you can get it from here.
I suggest that you carefully compare the "bugs fixed" sections of the respective release notes for the respective versions.
Note that the release date for the 1.4.2_06 version is 2004-12-10 (according to the release notes), while the IBM version name is "20090307" which implies that it was built ~5 years later. While there is no guarantee that the IBM version has tracked all of the fixes to that date, it is a fair assumption that they will have (at least) tracked the security-related patches.
Reason why I posted this because when I tried to do some deployment to server from command line, I am having few issues so wonder this could be difference in java versions.
Possibly, but (IMO) it is more likely that the problem is nothing to do with the version of Java. Either way, I think that an enumeration of the differences is unlikely to help you isolate your problem.
I suggest that you ask a new Question in which you describe your actual problems. We may or may not be able to help ... but I think your chance of success is greater than with your current approach.
Related
This maybe a dumb question but can someone explain how to install Berkeley for SICstus on Windows? This is my last resort
The entire Oracle site for Berkeley DB seems broken, with many broken links. Also, there are no longer any installers, and only the latest version of the source code. Their site has been that way for over a year. I do not know what happened.
In the mean time, I was able to download the Windows installers by first creating a free Oracle Account, logging in, and then using the links https://download.oracle.com/otn/berkeley-db/db-6.2.38_64.msi and https://download.oracle.com/otn/berkeley-db/db-6.2.38_86.msi (found via the Wayback Machine). These versions should be compatible with SICStus Prolog 4.6 on Windows.
I want to create native C extensions to PostgreSQL 9.5 64bit on Windows.
I would love to build them with MinGW-w64 if that's possible, to get my build chain as clean as possible. But I am using the EnterpriseDB build of PostgreSQL, and MinGW build crashes it.
It would also be okay if there is another free compiler that I can use in this commercial project.
I know how to get this to work with Visual Studio 2003 Express but that doesn't seem to be a solution because of License issues.
Addition to the Main Answer
In the article linked below, you can read that it is possible to write C modules using Mingw or Cygwin, and some guidelines regarding the same. However I highly discourage doing so, mostly because of the reasons listed below, and also because that page mentions that those Windows configurations have special needs and receive lighter testing than most; expect a greater incidence of build problems
Here is the full excerpt on Unix-like Platform:
Unix-like Platforms
PGXS originated on Unix-like systems, and it is easy to use there. Unpack the extension module archive and run these commands in the resulting directory:
make PG_CONFIG=path_to_postgresql_installation/bin/pg_config
make PG_CONFIG=path_to_postgresql_installation/bin/pg_config install
You may omit the PG_CONFIG overrides if running type pg_config in your shell locates the correct PostgreSQL installation. Subject to the ownership of the existing PostgreSQL installation directories, the second command will often require root privileges. These instructions also apply when building for Windows using the MinGW or Cygwin compilers. However, those Windows configurations have special needs and receive lighter testing than most; expect a greater incidence of build problems.
A common mistake is to specify the PG_CONFIG=... on the command line before the 'make', which does not work as the value is then overridden by the inner workings of makefiles.
It's important to know that different compilers are not compatible with each other. Each of them have different runtime libraries. So it is very risky to compile extensions with a different compiler other than the one used to build the software you are using.
Postgresql's Windows build uses Visual Studio, same with EnterpriseDB (as far as I know). You will need to use the same compiler to build your extensions.
(For more information please refer: Building and Installing PostgreSQL Extension Modules and Postgres Enterprise Manager Installation Guide - EnterpriseDB (PDF))
This should explain why your extensions compiled with Mingw-w64 crash.
Luckily, there are two solutions you could choose:
Use Microsoft Visual Studio Community. It is completely free for individual developers, however there are restrictions for businesses. It should compile proper modules for your Postgresql build.
Rebuild the compleat Postgresql binary with Mingw-w64 or any other compiler of your choice (LLVM/Clang maybe), and then compile extensions with the same.
Doing either of these should help you. And this applies to all platforms, languages, and other softwares too. If you want to build extensions for a software, you need the same compiler, on the same platform used to build the software being used.
So, if you want to build extensions for Postgresql on Linux, you need the same compiler (probably GCC) to build extensions.
Happy coding =)
#Swith give you link to docs how to build PostgreSQL Extension Modules with Visual Studio and as you can read:
These instructions also apply when building for Windows using the MinGW or Cygwin compilers. However, those Windows configurations have special needs and receive lighter testing than most; expect a greater incidence of build problems.
A common mistake is to specify the PG_CONFIG=... on the command line before the 'make', which does not work as the value is then overridden by the inner workings of makefiles.
Did you check this ?
Also you can read other docs Building PostgreSQL With MinGW - maybe this help you more.
It would also be okay if there is another free compiler that I can use in this commercial project.
Did you check C compliers list on wiki - in particular, you can check Cygwin compiler - it's mentioned in docs above and it's free.
I know how to get this to work with Visual Studio 2003 Express but that doesn't seem to be a solution because of License issues.
What kind of issues do you see ?
Maybe check Visual Studio 2015 Community Edition (not Express) like #Simon Mourier suggest.
There is quite different licencing between Express and Community editions - I'm not sure about details, but as far I know Community Edition is more flexible for using in commercial projects:
For organizations:
An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects.
For all other usage scenarios:
In non-enterprise organizations, up to five users can use Visual Studio Community. In enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above.
For more information, see the Visual Studio Community license terms.
Firstly my original question link regarding PB 10.5 on windows 7 64-bit has been mostly answered in the following link - PowerBuilder 10.5 Application on Windows XP 32-bit to Windows 7 64-bit
Has anyone had any experience with PB 10.5 runtime files on a 64 bit machine?
Currently have a 32-bit application on Windows XP. Client wants it working in Windows 7 64-bit. I know this is a big jump and PB 10.5 has been unsupported for a long time now.
Has any one successfully fooled around with The Runtime Packager PowerBuilder runtime DLLs and got any of the following DLL's wokring in a Windows 7 64-bit system?
libjcc.dll
libjutils.dll
pbacc105.dll
pbdwe105.dll
pbdwr105.dll
pbdwr105.pbd
pbjag105.dll
pbjvm105.dll
pbshr105.dll
pbtra105.dll
pbvm105.dll
I realize these are 32-bit DLL's but I need to start somewhere and not sure how to tackle this one. Hoping for anyones help or advise.
I suspect the most useful answer to you is a completely useless answer.
First point is that PB 10.5 pre-dates Windows 7. Very obviously, any success of 10.5 on Windows 7 is going to rely on Microsoft's ability to provide forward compatibility of applications. (MS's success with providing forward compatibility is stellar compared to other platforms I've used, but has never been perfect.)
Windows 7 was released around the PB 11.0 time frame, IIRC. It took Sybase to somewhere in the 12.0 cycle to announce that they would support Windows 7. Support for a new platform is a good feather for your marketing cap, so a reasonable interpretation of this delay is that they found some issues and had to work them out. (To the best of my knowledge, Sybase never listed those issues in one place, although some probably show up in the bug lists published with each patch.)
I'm going to go out on a limb and bet that if you created a 10.5 application with one line in the application Open event:
MessageBox ("Hello World!", "It's me!")
and deployed this to Windows 7, it would work. Conversely, from what we've inferred from Sybase's behaviour, there exists some combinations and permutations of features that will fail when deployed to Windows 7. Where your application lies in this n-dimensional spectrum of features and complexity is hard to tell.
So, I suspect that your most useful answer to your question is that it doesn't matter if I've had success with a 10.5 application on Windows 7; my experience may not have a bearing on your application's success on Windows 7. There are known risks, even if we don't know exactly what those risks are.
I do use PB11.5 IDE on Win7/64 (that is also 32b) without problem.
Concerning the runtime packager, I do not use it anymore because I develop and maintain several products that are released asynchronously and may occur to need different runtimes, sometimes from different major PB version (10.5 / 11.5) and sometimes from different releases (EBF) of the same major.
As PB seems very picky regarding the version of the runtime (in the sense that you'd better distribute the exactly same build for the runtime as the version the application is build with), I place the runtimes dll in the same directory as the application files. There is no problem for a PB 10.5 / 11.5 PB application to use its runtime files in the same directory.
Export the registry information of those dlls from a working xp 32 bit system.
if the dlls didn't reside in the powerbuilder's executable path, but something
like C:\windows\system32 or one of system32's subdirectories instead then copy
the dlls to the windows 7 64 bit system's related c:\windows\syswow64 folder
area. If it was necessary to place them in a new location then modify the
registry exports to point to the new location. If you they were from the powerbuilder's
executable path, then you don't need to modify the registry exports.
Merge them into the registry. Rebooting might be required. I've had
success with this when old dll and ocx files turned out to be necessary
to keep stuff like office database apps working after upgrading
office versions. you'll want to keep a copy of the dlls and registry merge files
in offline storage incase you have to rebuild your system from scratch
at some future date. Good luck.
PB 10.5 runs fine on Windows 7 (32 or 64 bit) from my all of my experience. PB 10.5 is still relatively common at large corporate IT shops, along with 11.5, 12.5 & PB 2017 (and above).
The package manager, included with PowerBuilder will gather all the runtime libraries needed. Windows 7 64-bit can run 32 bit or 64 fine via SYSWoW64, the 'WoW64' stands for Windows 32-bit on Windows 64-bit. SysWoW64 process running in your Windows is part of your Windows operating system.
I am working on a project where I've to implement Distributed File System, so for I/O operations, I was thinking of using NIO2 (JDK7)
JDK7 will be released in August next year.
My questions are:
Would it be good idea to use NIO2 from snapshot of JDK7 ? What problems can I face?
If I compile my code which uses both JDK6 and JDK7 classes is it possible to compile using JDK7 ?
1 - Would it be good idea to use NIO2 from snapshot of JDK7 ? What problems can I face?
For a student / research project I see no major issues, apart from the general ones like:
new APIs may still be in a state of flux, and may change without notice,
you are more likely to encounter JDK/JRE/JVM bugs, and
people who want to try out your project have to use JDK 7.
For a project that needs to go into production before the actual release of JDK 7, you probably should be more cautious.
2 - If I compile my code which uses both JDK6 and JDK7 classes is it possible to compile using JDK7?
You cannot be certain until you actually try it, but I'd be very surprised if the answer is anything other than "yes". The Java team are very aware of the need to maintain backwards compatibility.
(However, it is unlikely that you'll be able to compile using JDK 6 ... unless they decide that it is technically feasible and worthwhile to provide a backport of the feature for JDK 6. For something like NIO2, it could be "no" on both counts.)
What might be a better choice?
I have my code (mostly C - as output from the GNU Eiffel compiler and some C++ for the GUI bindings) working with Sun Studio compiler and gcc.
But i now have to setup a new developer computer and wonder if i should use Solaris with DTrace, locklint or Linux with Valgrind etc for development.
It's just about introspecting and debugging and the development is done in GNU (SmallEiffel) and therefore there is no help in any way. But the output is plain C, so C tools help a lot.
I bought some books about the Solaris and printed the developer documentation. I have to say that it seems to be a much better development environment then all the undocumented Linux tools. But Sun Studio works also on Linux...
This is an opinion so I'm marking it Community Wiki.
Solaris' days are past. That's it, really, that's all I wanted to say, thanks for listening.
Oh, and by the way, so is AIX and HP-UX. Linux is the present and the future (at least for a while) - that's where you should be putting your effort. That's where you'll get the best bang per buck for your support dollars. That's where you'll get hordes of opinionated clowns like myself willing to give you help at the drop of a hat.
This depends totally on what you are aiming for. If you are developing primarily for Linux, create a Linux box. If your primary target is Solaris, use that. But if you plan to target both OS's, make sure that you have a box for each one. That way you will be able to test on both, and notice small bugs / issues that crop up on one platform but not the other.
Apart from that, it's up to you. If your tools are available on both platforms, and you have no other reason to pick one over the other, then just go by your personal preference. Without more information, there isn't much more advice to give.
To choose a machine as your main dev platform... It's simple: What suits you best?
"Linux with Valgrind etc"
or
"Solaris with DTrace, locklint"
The environment and toolset is markedly different, even if you can use Sun Studio in both. In fact, why are you doing this question, what is bothering you about Solaris? That should give you some ideas. If you've never used Linux as a main dev platform, you should to be able to compare and switch back if necessary. Because, as I said, the toolset is markedly different, even when GNUing Solaris.
Lastly, don't forget if you aim for cross platform code you should test it in all platforms where it is supposed to run on.
I recently said good-bye to my Sun workstation and have moved to x64 Linux. I miss the stability of Solaris on Sun hardware...nVIDIA driver issues are making me crazy.
Though I like developing on Solaris WITH Sun hardware, the following two things bothered me the most about the platform:
If you want to use the latest version of libraries, you'll have to build them yourself every time. Blastwave helps out in the Solaris world, but often the packages are several versions behind. Installing Boost was quite challenging on my Sparc hardware and required a lot of study and learning just to get Boost installed.
Availability of tools is quite limited, and often free or developer versions of commercial software are not available for the Solaris OS.
If DTrace is the "killer application" for you, take a look at STrace for Linux and see if it offers the same features you're looking for. The docs are somewhat lacking in Linux, but you can usually find what you're looking for in man pages, mailing lists and what not.
Neither, Mac is best.
Mostly because you can have the Xcode IDE.