We have recently described and evaluated a research prototype system (called XJ, for transactional Java) that allows execution of Java programs extended with transactional memory (TM) abstractions (Chapman et al. 2014, 2016). The system allows mixed execution of these abstractions using both software (STM) and hardware (HTM) transactional memory. The prototype system, based on OpenJDK, suffers a number of roadblocks impeding production use, including: (i) Per-object metadata in support of manipulation of objects by transactions is inserted via bytecode rewriting at load time, in the form of a new word-sized instance field placed at the beginning of each object; (ii) The HotSpot optimizing compilers (C1 and C2) require gentle coaxing to compile both the STM and HTM versions of methods via alternating execution in a warm-up phase. Here we explore possible changes to OpenJDK that would allow for more integrated support for TM in HotSpot, as needed to support hybrid STM/HTM. These changes include encoding per-object transactional metadata in the synchronization word carried by all OpenJDK objects, and integrating more effectively with the profiling and compilation mechanisms of the HotSpot interpreter and compilers. We believe that the proposed changes are incremental, though we also expect that a deeper re-engineering would yield somewhat better ability to tune synchronization hot-paths for performance.