1.6.2 doesn't work on Linux - missing cores and Java errors

[sej7278]

There's nothing inside the hardware directory in arduino-1.6.2-linux64.tar.xz so you've forgotten the AVR cores that should be installed by default (and not rely on the new cores manager) and when trying to run it we get the following errors.

./arduino java.lang.UnsatisfiedLinkError: com.sun.jna.Native.pointerSize()I
    at com.sun.jna.Native.pointerSize(Native Method)
    at com.sun.jna.Native.<clinit>(Native.java:93)
    at cc.arduino.os.linux.LibCNative.<clinit>(LibCNative.java:38)
    at cc.arduino.os.linux.LinuxFileNativeUtils.<clinit>(LinuxFileNativeUtils.java:36)
    at cc.arduino.os.FileNativeUtils.chmod(FileNativeUtils.java:51)
    at cc.arduino.utils.ArchiveExtractor.extract(ArchiveExtractor.java:236)
    at processing.app.BaseNoGui.initPackages(BaseNoGui.java:585)
    at processing.app.Base.<init>(Base.java:256)
    at processing.app.Base.guardedMain(Base.java:198)
    at processing.app.Base.main(Base.java:113)

I think we need a more managed development process that would:

1. check builds actually work on supported platforms
2. check archives actually contain all required files
3. prevent new releases being made on weekends and Arduino Day
4. not add major new features in a point release less than a week after a major new release without consulting the community

[wayoda]

The problem seems to be with a native lib that implements Posix chmod and ln commands.

Both areas are already covered and tested in Java 7

http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#setPosixFilePermissions%28java.nio.file.Path,%20java.util.Set%29

http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#createLink(java.nio.file.Path,%20java.nio.file.Path)

http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#createSymbolicLink(java.nio.file.Path,%20java.nio.file.Path,%20java.nio.file.attribute.FileAttribute...)

Looks like a shiny new wheel was invented

[q2dg]

As I've said in #2829, using Java 1.8 just works

[wayoda]

The main point is that obviously nobody tested the Linux version before it was released to the public.

As I've said in #2829, using Java 1.8 just works

That's a workaround, not a solution

[sej7278]

The main point is that obviously nobody tested the Linux version before it was released to the public.

i don't think they tested the IDE at all did they?

java8 doesn't fix it for me either on debian sid, and it seems a pretty steep requirement, when the osx build only just supports java7

$ java -version
openjdk version "1.8.0_40-internal"
OpenJDK Runtime Environment (build 1.8.0_40-internal-b27)
OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode)

it doesn't even get as far as extracting the cores to ~/.arduino15 as its reported to do on osx, just past the splashscreen.

[PaulStoffregen]

The mac versions actually seems to be based on 1.8 now.

Yeah, it's unfortunate 123 commits when into the public repository only hours before release. Even a day or two would have allowed some beta testing on a wide range of systems and likely turned up these problems.

[sej7278]

The mac versions actually seems to be based on 1.8 now.

are they? i thought it was java 1.6 by default and 1.7 is experimental - certainly 1.6.1 was, although they've dropped support for osx < 10.7, so maybe that's changed in 1.6.2

[PaulStoffregen]

Yes, or at least Mac builds now appear to require Java 1.8. For example, look at line 271 in build.xml: https://github.com/arduino/Arduino/blob/master/build/build.xml#L271

The actual .jar files also appear to have been built with Java 1.8.

Arduino doesn't even compile on a Mac anymore (issue #2835) without some currently undocumented setup involving a symbol named MACOSX_BUNDLED_JVM. So far, I haven't manged to figure out what this is supposed to be or how to get the source to build on a Mac, but I'm going to try (guessing) again later this evening or tomorrow morning.

At least none of the builds involves 1.6 anymore.

[ffissore]

JNA bug fixed. A nightly build is on the way. IDE java code is still bound to java6, that's why we can't use java7 methods. It bundles java8 (and requires it in calling bundleapp task) only to force both windows and mac to use the bundled JVM, instead of the system one: reducing the number of java combinations eases support

[wayoda]

JNA bug fixed

Well not really , I switched back to Java 7 and reinstalled the latest version.
I ran the board manager to install the Due package and here we are again:

om.sun.jna.Native.pointerSize()I
java.lang.UnsatisfiedLinkError: com.sun.jna.Native.pointerSize()I
        at com.sun.jna.Native.pointerSize(Native Method)
        at com.sun.jna.Native.<clinit>(Native.java:93)
        at cc.arduino.os.linux.LibCNative.<clinit>(LibCNative.java:38)
        at cc.arduino.os.linux.LinuxFileNativeUtils.<clinit>(LinuxFileNativeUtils.java:36)
        at cc.arduino.os.FileNativeUtils.chmod(FileNativeUtils.java:51)
        at cc.arduino.utils.ArchiveExtractor.extract(ArchiveExtractor.java:236)
        at cc.arduino.utils.ArchiveExtractor.extract(ArchiveExtractor.java:72)
        at cc.arduino.contributions.packages.ContributionInstaller.install(ContributionInstaller.java:142)
        at cc.arduino.contributions.packages.ui.ContributionManagerUI$4.run(ContributionManagerUI.java:159)
        at java.lang.Thread.run(Thread.java:745)
ould not initialize class cc.arduino.os.linux.LinuxFileNativeUtils
java.lang.NoClassDefFoundError: Could not initialize class cc.arduino.os.linux.LinuxFileNativeUtils
        at cc.arduino.os.FileNativeUtils.chmod(FileNativeUtils.java:51)
        at cc.arduino.utils.ArchiveExtractor.extract(ArchiveExtractor.java:236)
        at cc.arduino.utils.ArchiveExtractor.extract(ArchiveExtractor.java:72)
        at cc.arduino.contributions.packages.ContributionInstaller.install(ContributionInstaller.java:142)
        at cc.arduino.contributions.packages.ui.ContributionManagerUI$4.run(ContributionManagerUI.java:159)
        at java.lang.Thread.run(Thread.java:745)

If you bundle Java 8 with Windows and Mac, why is the IDE tied to 1.6 code?
All recent Linux derivates run at least Java 1.7.

[wayoda]

Forgot to mention: Release works fine with Java 8!

[ffissore]

With "latest version" you mean the nightly right? If so, you may have downloaded it before the CI box pushed the files to the download server. May you retry?

[wayoda]

The latest version was what I found on the official Download page.
This was very likely the buggy original.

Since then I have rebuild the latest github version from scratch: it runs fine with Java 7.

The offical release is still broken.
Is there no way to replace the broken Linux version on the Homepage?

[ffissore]

Got it, thx. Btw, the nightly on the download page is similar to what you got from the source.
The only way is to make another release