Solved Java 7 or 8

Discussion in 'Spigot Plugin Development' started by Dectom, Oct 10, 2015.

  1. Hello There,

    Recently i have been learning and making some plugins for minecraft using Java 8 and these plugins work on my localhost server however when i put them onto a hosted server then they don't work untill i change the Java version to Java 7

    Is this a common issue and should I just use Java 7 all the time for my plugins

    Many Thanks Spigot Community,
    Dectom
     
    #1 Dectom, Oct 10, 2015
    Last edited: Oct 11, 2015
  2. If you compile a plugin for Java 8, it won't work on servers that use Java 7 whereas if you compile a plugin for Java 7, it will work on servers using Java 7 and 8.

    If you want your plugin to be compatible with more servers, compile in Java 7, if you want your plugin to just work with Java 8, you will need to update the Java version on your server.
     
    • Useful Useful x 1
  3. Thank you very much i didn't know that Java 7 plugins were forward compatible

    Thanks for your help
     
  4. Don't forget to mark your solved threads with a little solved prefix ;)

    Fact: McProhosting still defaults to Java 7 machines unless you contact them to upgrade
     
    • Winner Winner x 1
  5. Some machines don't even run Java 7 so I compile in Java 6.
     
  6. If you're making plugins for yourself personally, then you can use (and fall in love with) java 8.

    Otherwise to be compatible with everyone Java 7 should suffice, but Java 6 is ideal.
     
  7. Actually I recommend using java 7 cause java 6 is too outdated and force-dropping support should be the best way. My plugins however are java 8 only.

    Additionally I've heard that java 7 pugins are not always working if you use java 8 due to some unknown reason simply nothing happens on server start.
     
  8. At the end of July the percentage of servers running Java 6 was 0.68%, it's completely unecessary to compile to Java 6.

    [​IMG]

    This number gets even lower when you consider playercount to server ratio (<0.02% java 6)
     
    • Informative Informative x 1
  9. Thanks for all the help i'll use 1.7 java coz i didn't know it was compatible with servers running Java 1.8 so hopefully i'm good
     
    • Like Like x 1
  10. @1Rogue I've sold about 100+ of my most popular plugin, Staff+, and I had one user that could not use it because it was compiled with Java 7. Of course, other users could have been affected by this, but, since I fixed it right away, there were no issues for future users.

    What I'm saying: If a user has issues, just compile in Java 6 and you're set.

    EDIT: I've found this, as well:
    [​IMG]
     
    #11 Shortninja, Oct 11, 2015
    Last edited: Oct 11, 2015
    • Like Like x 1
    • Agree Agree x 1
    • Winner Winner x 1
  11. Omnivion

    Patron

    As much as I like providing backwards compatibility, I agree. Any hosts who don't provide Java 8 are irresponsible.
     
    • Agree Agree x 3
  12. I just read somewhere about Java 9. Anyone know whats in this version?
     
  13. Here. I googled it...
    1. Java + REPL = jshell
    Yes. Previously we had doubts that project Kulla would make it in time for Java 9 but now it’s official. The next release of Java will feature a new command line tool called jshell that will add native support and popularize a Java way to REPL (Read-Eval-Print-Loop). Meaning, say, if you’ll want to run a few lines of Java on their own you won’t have to wrap it all in a separate project or method. Oh and semicolons – you can forget about those:

    ?
    1
    2
    3
    -> 2 + 2
    | Expression value is: 4
    | assigned to temporary variable $1 of type int
    There are some alternatives like REPL add-ons to popular IDEs and solutions like the Java REPL web console, but no official and right way to do this so far. jshell is already available in the early release and waiting for you to give it a test run.

    2. Microbenchmarks are coming
    The Java Microbenchmarking Harness (JMH) by Alexey Shipilev is taking the next step in its evolution and joins Java as an official benchmarking solution. We really love doing benchmarks here at Takipi, so a standardized way of performing them is something we look forward to.

    JMH is a Java harness for building, running, and analysing nano/micro/milli/macro benchmarks. When it comes to accurate benchmarking, there are forces in play like warmup times and optimizations that can have a big impact on results. Especially when you’re going down to micro and nano seconds. So today JMH is your best choice if you want to get the most accurate results to help you reach the right decision following your benchmarks – And now it’s becoming a synonym with Java 9.

    3. Will G1 be the new default garbage collector?
    A common misconception we often hear is that Java has only one garbage collector when in fact it has 4. With Java 9, there’s a running proposal that’s still in debate to replace the default garbage collector (The parallel / Throughput collector) with G1 which was introduced in Java 7. For a bite sized overview about the differences between the different collectors, you can check out this post right here.

    Generally, G1 was designed to better support heaps larger than 4GB and has been known to cause less frequent GC pauses, but when a pause do comes, it tends to be longer. Recently we’ve discussed all things GC with Haim Yadid, head of performance at Outbrain, to help you learn more about the different trade offs between the collectors. Also, if you’d like to have an inside view of this debate, the hotspot-dev and jdk9-dev mailing lists are a great place to start.

    4. HTTP 2.0 is the future
    The official HTTP 2.0 RFC was approved just a few months ago, building on top of Google’s SPDY algorithm. SPDY has already shown great speed improvements over HTTP 1.1 ranging between 11.81% to 47.7% and its implementation already exists in most modern browsers.
    Java 9 will have full support for HTTP 2.0 and feature a new HTTP client for Java that will replace HttpURLConnection, and also implement HTTP 2.0 and websockets.

    5. The process API just got a huge boost
    So far there has been a limited ability for controlling and managing operating system processes with Java. For example, in order to do something as simple as get your process PID in earlier versions of Java, you would need to either access native code or use some sort of a magical workaround. Moreover, it would require a different implementation for each platform to guarantee you’re getting the right result.

    In Java 9, expect the code for retrieving Linux PIDs, that now looks like this:

    ?
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    public static void main(String[] args) throws Exception
    {
    Process proc = Runtime.getRuntime().exec(new String[]{ "/bin/sh", "-c", "echo $PPID" });

    if (proc.waitFor() == 0)
    {
    InputStream in = proc.getInputStream();
    int available = in.available();
    byte[] outputBytes = new byte[available];

    in.read(outputBytes);
    String pid = new String(outputBytes);

    System.out.println("Your pid is " + pid);
    }
    }
    To turn into something like this (that also supports all operating systems):

    ?
    1
    System.out.println("Your pid is " + Process.getCurrentPid());
    The update will extend Java’s ability to to interact with the operating system: New direct methods to handle PIDs, process names and states, and ability to enumerate JVMs and processes and more.

    6. Debugging in Production
    While not exclusive to Java 9, we thought this post would be a good opportunity to share some of the new progress we’ve been making at Takipi. Solving errors in production has always been a messy practice, grepping for clues over huge log files, and trying to identify the state that caused each exception or logged error. But what if you could avoid logs altogether? Here’s how it’s done.

    What you’ll not be seeing in Java 9?
    Two interesting features that we assumed will make a part of the upcoming Java release – but now we know they will be skipped this time are.

    1. A standardized lightweight JSON API
    On a survey we conducted with 350 developers, the JSON API was just as hyped as Jigsaw but looks like it didn’t make the cut due to funding issues. Mark Reinhold, chief architect of the Java platform, on the JDK 9 mailing list:

    “This JEP would be a useful addition to the platform but, in the grand scheme of things, it’s not as important as the other features that Oracle is funding, or considering funding, for JDK 9. We may reconsider this JEP for JDK 10 or a later release. ”

    2. Money and Currency API
    In other news, it also looks like the expected Money and Currency API is also lacking Oracle support. This is the answer we got from Anatole Tresch, the APIs spec lead:
     
    • Like Like x 1
  14. @EODSteven Still no standardized JSON API? lol.
     
  15. No funding....
     
  16. That's relevant to overall use, not minecraft servers (which is what my statistic is for).

    That being said, if you want to cater to the 0.02% of people buying your plugins (1 in 5000), then compile Java 6. If you want to encourage people to use a better/faster/more secure java, compile in Java 8 and explain that they should update their server software.

    Private interface methods, type erasure removal, http 2.0, among other things.
     
  17. Java 7 has been EOL for over a year now and is no longer receiving security updates. Stop enabling server owners to use outdated and unsafe software. Don't be part of the problem, be part of the solution. We don't want a repeat of Java 6 where a dead software stays alive a decade after it died. Don't be that guy.
     
    • Like Like x 1
    • Agree Agree x 1