# Compatibility across Julia 1+ versions

**URL:** <https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196>\
**Category:** General Usage\
**Created:** [August 6, 2019, 1:29am UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196 "2019-08-06T01:29:47Z")\
**Posts on this page:** 15\
**Page:** 3

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [September 24, 2019, 4:25pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/41 "2019-09-24T16:25:17Z")

</div>

Hm, I tried it on a few different machines and I did not get segfaults.

What do the `Xmx128M` options do? Just for the hell of it, can you see if it crashes without those? (only thing I did differently)

---

<div class="post-metadata">

**Author:** ![Gcr](https://avatars.discourse-cdn.com/v4/letter/g/c2a13f/32.png) [@Gcr](https://discourse.julialang.org/u/Gcr)\
**Post date:** [September 24, 2019, 6:55pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/42 "2019-09-24T18:55:53Z")

</div>

On Ubuntu, without the “-Xmx128M”, still crashes.

On OSX 10.14.5, I get the segmentation fault but Julia doesn’t not crash. JavaCall still doesn’t work.

---

<div class="post-metadata">

**Author:** ![Gcr](https://avatars.discourse-cdn.com/v4/letter/g/c2a13f/32.png) [@Gcr](https://discourse.julialang.org/u/Gcr)\
**Post date:** [September 24, 2019, 6:57pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/43 "2019-09-24T18:57:49Z")

</div>

Factoid: On OSX, it’s Oracle’s JDK not OpenJDK

---

<div class="post-metadata">

**Author:** ![Gcr](https://avatars.discourse-cdn.com/v4/letter/g/c2a13f/32.png) [@Gcr](https://discourse.julialang.org/u/Gcr)\
**Post date:** [September 25, 2019, 12:59pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/44 "2019-09-25T12:59:15Z")

</div>

I tried switching to OpenJDK 13 on OSX. I got the same result. As I stated earlier, the error is thrown at jvm.jl line 177, which is a ccall.

Let me say this: I am setting the environment variable in start.jl like so  
`ENV["JULIA_COPY_STACKS"] = 1`  
I can’t imagine that it would be a problem, but just in case.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [September 25, 2019, 7:42pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/45 "2019-09-25T19:42:43Z")

</div>

Actually, I think that _is_ a problem. The environment variable gets parsed in C before Julia initializes. Can you try it by actually setting the variable in the shell?

---

<div class="post-metadata">

**Author:** ![cchderrick](https://avatars.discourse-cdn.com/v4/letter/c/ecd19e/32.png) [@cchderrick](https://discourse.julialang.org/u/cchderrick)\
**Post date:** [September 26, 2019, 5:30pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/46 "2019-09-26T17:30:44Z")

</div>

Can confirm here!

Here is how I test it using OpenJDK docker image; `$PWD` has the Julia binary.

```julia
 docker run -it --rm -v"$PWD":/home openjdk:11.0.2 /bin/bash

```

1. I did the `ENV["JULIA_COPY_STACKS"]=1`, it seg fault.

2. Set environment variable this way, it seg fault.

3. Set environment variable this way, JVM initialized!

---

<div class="post-metadata">

**Author:** ![Gcr](https://avatars.discourse-cdn.com/v4/letter/g/c2a13f/32.png) [@Gcr](https://discourse.julialang.org/u/Gcr)\
**Post date:** [September 26, 2019, 5:31pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/47 "2019-09-26T17:31:00Z")

</div>

Thanks for the insight ExpandingMan. I did not realize the bit about “parsed in C…”. I can now call Java successfully. I still get the segmentation fault however, but it is no longer fatal.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [September 26, 2019, 5:33pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/48 "2019-09-26T17:33:11Z")

</div>

> [@Gcr](#):
>
> I still get the segmentation fault however, but it is no longer fatal.

Where are you still getting a segfault? That’s still potentailly concerning. I know some of the JavaCall.jl tests fail, but I didn’t think any were segfaults. Can you confirm that most tests pass for you when you do `]test JavaCall`? Should only see a few faillures.

---

<div class="post-metadata">

**Author:** ![Gcr](https://avatars.discourse-cdn.com/v4/letter/g/c2a13f/32.png) [@Gcr](https://discourse.julialang.org/u/Gcr)\
**Post date:** [September 27, 2019, 1:48pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/49 "2019-09-27T13:48:05Z")

</div>

I ran the test as suggested.  
Let me tell you the tale of two operating systems.

Ubuntu 19.04  
OpenJDK = 11.0.4  
Julia = 1.3.0-rc2.0

and

JULIA\_COPY\_STACKS=1

We get a clean go.

OSX = 10.14.5  
OpenJDK = 13  
Julia = 1.3.0-rc2.0

and

JULIA\_COPY\_STACKS=1

We get the seg fault. We should also recall that this same seg fault would occur with…

OSX = 10.14.5  
Oracle JDK = 8  
Julia = 1.0

…and was routinely ignored.

Thanks for the help. I can now at least make progress.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [October 7, 2019, 6:38pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/50 "2019-10-07T18:38:54Z")

</div>

For anyone interested, I just made a PR for JDBC.jl that gets it working in 1.3 with Tables.jl (thanks to @quinnj for that part).

We should be ready to tag this quite soon, and happily it seems that JDBC functionality will be fully restored in 1.3 (with `JULIA_COPY_STACKS=1`).

---

<div class="post-metadata">

**Author:** ![Marc.Cox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/marc.cox/32/7514_2.png) [@Marc.Cox](https://discourse.julialang.org/u/Marc.Cox)\
**Post date:** [October 24, 2019, 9:20pm UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/51 "2019-10-24T21:20:24Z")

</div>

@ExpandingMan Thx for championing the cause and doing the PR for JDBC.

@StefanKarpinski **NOTE**  **exactly How Important**  **Java support ergo JDBC support is –**  **It’s** **VERY important in major businesses - in fact its #1 per this \>\> [TIOBE Index - TIOBE](https://www.tiobe.com/tiobe-index/)**

… also consider the following …  
— Python talks to **Spark** _ **AND** _ **Hadoop. !!**  
— Python ALSO has APIs for _ **NEWER** _ **NoSQL databases**

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [October 25, 2019, 5:31am UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/52 "2019-10-25T05:31:36Z")

</div>

> [@Marc.Cox](#):
>
> VERY important in major businesses

When making arguments like this, please note that in most open source communities, it is implicitly assumed that if A is _very_ important to B, especially if they use it to make money, B will fix A, or pay someone to do it.

The corollary is that if they don’t, it is not _that_ important.

---

<div class="post-metadata">

**Author:** ![anon92994695](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@anon92994695](https://discourse.julialang.org/u/anon92994695)\
**Post date:** [October 25, 2019, 11:10am UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/53 "2019-10-25T11:10:43Z")

</div>

The farther we (as human beings) can get away from the JVM with regards to data science the happier I will be. Spark is a hot mess. Anyone saying anything about python supporting spark via PySpark or whatever makes me inquire to their mental wellbeing. I’d love to see a graph of the frequency of curse words stated per day after switching to PySpark at a previous job. I couldn’t even begin to describe how finicky and awful writing pyspark statements is compared to something like distributed JuliaDB or similar technologies in python or R or almost anything else. The main advantage I’ve seen is it has been widely adopted, and is pretty stable (when it works and the functionality is properly documented).

That being said I do appreciate this effort because having JVM interop is crucial for lots of projects. Sorry to make this post - I just have post traumatic spark disorder, and needed to vent.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [October 26, 2019, 6:31am UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/54 "2019-10-26T06:31:55Z")

</div>

> [@anon92994695](#):
>
> Spark is a hot mess.

I think it has a use case, but the fixed cost of getting it to work reliably is quite large. People tend to underestimate the scale of projects where investing in the whole stack required for Spark starts to make sense.

---

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [October 26, 2019, 7:20am UTC](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196/55 "2019-10-26T07:20:07Z")

</div>

It’s basically difficult economics problems. B maybe important for many business but no single business want to pay for it on their own. The solutions a company like Julia computing which can charge each business that want somethibg a small price. But business have alternatives and are risk averse so they don’t pay and instead use something else.

[Previous page](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196.md?page=2)