JDE with 64 bit


Active Member

If JDE is releasing Apps with 64 bit, what would be the impact on existing custom code/development?

Thanks for your input.



Legendary Poster
Kaushik - where have you heard that JDE is releasing 64bit versions of their applications ? As far as I understand, JDE code is always going to be 32 bit - and it would be a major re-write to make it fully 64bit compliant.

The FOUNDATION is 64bit - and JDE works on 64bit systems - but the internal memory cache of JDE is still 32bit.


Legendary Poster
I did hear rumors from very good sources at Collaborate that 64 bit JDE E1 is most likely going to happen at some point and it sounded to me like they are at least exploring it if not actively working on it.


Legendary Poster
I did hear rumors from very good sources at Collaborate that 64 bit JDE E1 is most likely going to happen at some point and it sounded to me like they are at least exploring it if not actively working on it.
This has been a rumor that has been in the works for about 10 years. That and getting rid of the deployment server (or making the deployment server something other than a windows machine). It'd be great if it appears, but don't hold your breath (you'll turn VERY blue....)

To the original posters' point though - if JDE did come up with an ability for the ER code to be 'compiled' in a 64bit manner - then the ER code should all be fine (as that is part of the toolset) - but any C functions would have to be re-written to account for the difference. If there wasn't any "native" C code - it wouldn't be a big process - but with the thousands of BSFN's out there, its a pretty huge undertaking....


Legendary Poster
I would think for the most part the C BSFNs would just need to be recompiled (provided nothing moronic was done in the C code). There will be a few things that need to be fixed but I would think it would be on the same or lesser scale as the switch from single byte to unicode chars/strings was when moving from Xe (I believe they are working on a code slimer for 64 bit) - but then again I guess I can't really guess at the scope until I see some examples of what would need to be fixed.

Mati Karu

See the Oracle document "JD Edwards EnterpriseOne 64-bit Processing Frequently Asked Questions (Doc ID 2390692.1)"

Q: What is the impact to JD Edwards business processes?
A: There is no impact to JD Edwards business processes or business data. Transitioning to 64-bit processing is a technical uplift that is managed with the JD Edwards Tools Foundation.

Q: What is the impact to integration to JD Edwards?
A: There should be minimal impact to integration to JD Edwards and third-party solutions. However, depending on how these solutions were developed, there may be some work to transition the solutions to be 64-bit compliant. Oracle will deliver guidance on how to uplift integration.

Q: How are customizations impacted if I transition to 64-bit processing?
A: There is no impact to spec-based objects such as interactive applications, UBEs, NERs, and other spec-based objects. C business functions will need to be retrofitted for 64-bit. To simplify the retrofitting, Oracle will deliver a utility to assist with the conversion of C business functions to be 64-bit compliant.

Q: When will 64-bit processing be generally available?
A: Oracle is planning on delivering 64-bit with the next JD Edwards Tools Update.


Legendary Poster
I am unable to pull up this doc on JDE support site for some reason. I would like to know the details about the C BSFN retrofitting. What exactly needs to be changed? This one has me worried - much more so than the switch to Unicode when we upgraded from Xe to 9.0.


Legendary Poster
The document is there - but its not available. Which is strange. Is this the big announcement ?

Moving from 16bit to 32bit took a long time back in the late 90's. And that was pre-release. Delayed OneWorld being released by a couple of years.

Given the fact that the "first post" was more than a year ago to this point, which is the first announcement of the "next" tools release being 64bit (I'm going to assume this is TR 10.x ?given such a major change) - the QA and testing of this next TR will be pretty substantial.

I'm looking forward to this - but with trepidation.

Mati Karu

The document was available yesterday when I noticed it, but seems to have been removed again.

Before any official announcement by Oracle this is all speculation, but "next tools release" seems to refer to / 2018-Q4.

See the base bug 27439858 64-BIT LINUX-WINDOWS_REGRESSION_BASE BUG and specifically the bug 27911078 : E920 PLANNER ESU BUILD TR9.2.3 DID NOT BACKWARD COMPATIABLE WITH TR9.2.1.X.
The latter has the following problem description:
With 64-bit TR9.2.3, we need build E920 planner ESU using TR9.2.3.0.


Legendary Poster
FYI my co-worker just back from Collaborate says it WAS announced and that its the third party software companies driving the change
(Clayton Seely(?) did a presentation where this was announced)


Legendary Poster
The only note I had was that this will be for Apps 9.2 only, and will be released in a future tools release.


Reputable Poster
Here are my quick notes on the topic from the conference, take it with a grain of salt...

JDE 64-bit support to be added in a tools release in the next few months <-- not mandatory can run either 32bit or 64bit.
○ Many vendors are no longer producing drivers for 32-bit support (i.e. DB connectivity)
○ Everything except the enterprise server and developer clients are already 64 bit
○ Probably requires rewrite of Vertex O Series integration code
○ JDE workflow deprecated in 64-bit.


Legendary Poster
Thanks for the info. I wish they would give some indication of what will need to be changed in the C BSFNs. I would like to know what their "code slimer" is going to do, what things will need to be fixed... some of these things can probably be addressed before and upgrade starts.


VIP Member
This on intrigues and scares me: ○ JDE workflow deprecated in 64-bit.

There are a few areas of the system where workflow is standard and drives vanilla processes. Do you know if this was referring to the Work Flow designer or the work flow kernel (or both)? If JDE workflow is eliminated altogether I assume they are going to require some external Oracle Fusion Middleware workflow engine to be used to replace it. Don't tell me it will be some sort of crazy scheduled polling via the Orchestrator to screen scrape JDE screens to progress workflow and send alerts.