search

folpindo / arduino

Automatically exported from code.google.com/p/arduino
0 stars 0 forks source link

1.5.1 fails at startup here on OS X with "Cannot start Java application" #1099

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
When I download 1.5.1 and run it on OS X 10.7.5, I get this error:

"Cannot start Java application"
"Uncaught exception in main method: Java.lang.illegalStateException: Menu has 
no enabled items"

... and the only option is Quit.

-br

Original issue reported on code.google.com by bill....@palmeta.com on 5 Nov 2012 at 6:21

GoogleCodeExporter commented 9 years ago

Original comment by dmel...@gmail.com on 5 Nov 2012 at 7:02

GoogleCodeExporter commented 9 years ago 
I see something similar.  Here's a stacktrace.

     [exec] [JavaAppLauncher] Requested [1.5*], launching in [1.6] instead.
     [exec] TargetPlatform: constructor start, name: avr
     [exec] TargetPlatform: constructor start, name: bootloaders
     [exec] TargetPlatform: constructor start, name: cores
     [exec] TargetPlatform: constructor start, name: firmwares
     [exec] TargetPlatform: constructor start, name: sam
     [exec] TargetPlatform: constructor start, name: variants
     [exec] TargetPlatform: constructor start, name: sanguino
     [exec] [LaunchRunner Error] processing.app.Base.main(String[]) threw an exception:
     [exec] java.lang.IllegalStateException: Menu has no enabled items
     [exec]     at processing.app.Base.selectFirstEnabledMenuItem(Base.java:1331)
     [exec]     at processing.app.Base.rebuildBoardsMenu(Base.java:1252)
     [exec]     at processing.app.Editor.buildToolsMenu(Editor.java:690)
     [exec]     at processing.app.Editor.buildMenuBar(Editor.java:483)
     [exec]     at processing.app.Editor.<init>(Editor.java:212)
     [exec]     at processing.app.Base.handleOpen(Base.java:705)
     [exec]     at processing.app.Base.handleOpen(Base.java:670)
     [exec]     at processing.app.Base.handleNew(Base.java:568)
     [exec]     at processing.app.Base.<init>(Base.java:308)
     [exec]     at processing.app.Base.main(Base.java:201)
     [exec]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     [exec]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     [exec]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     [exec]     at java.lang.reflect.Method.invoke(Method.java:597)
     [exec]     at apple.launcher.LaunchRunner.run(LaunchRunner.java:116)
     [exec]     at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:51)
     [exec]     at apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)

Attached is a hardware folder I'm using.

Original comment by dmel...@gmail.com on 5 Nov 2012 at 7:27

Attachments:

GoogleCodeExporter commented 9 years ago 
It seems related with the new boards menu with sub-options.

Please send your complete hardware folder, if possible, and your 
preferences.txt.

C

PS (David your attachment is empty)

Original comment by c.mag...@bug.st on 5 Nov 2012 at 7:39

GoogleCodeExporter commented 9 years ago 
Here is my hardware folder.  It is "well-populated"...

-br

Original comment by bill....@palmeta.com on 5 Nov 2012 at 8:11

Attachments:

GoogleCodeExporter commented 9 years ago 
Here's mine.  (Sorry, the contents were symlinked so they didn't end up in the 
original zip.)

Original comment by dmel...@gmail.com on 6 Nov 2012 at 12:57

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hello everyone,

the thrown exception is caused by the missing platform.txt in your hardware 
folders

platform.txt is required in ide-1.5 (at least its contents)

Can you tell me if, in version 1.5.0, your custom boards were working? If you 
cannot test 1.5.0 anymore, can you then copy the "official" platform.txt from 
arduino/avr to your sanguino and tiny folders and check if the boards are 
working?

Our current choices are between completely disabling custom hardware folders 
without a platform.txt and using the official avr platform.txt in place of the 
missing one

Original comment by federico...@gmail.com on 6 Nov 2012 at 1:19

GoogleCodeExporter commented 9 years ago 
In answer to your question, my boards.txt was broken by 1.5.

I certainly hope you will find a way to make the new changes backwards 
compatible so that people have the ability to use 0023 with old boards.txt 
setups on the same machine as they are using 1.5 and whatever its fancy new 
setup turns out to be.  It sounds like what you are proposing would break that, 
or at least make it difficult.  Please tell me I am wrong.  

Backwards compatibility is important, guys.  You have zillions of projects out 
there stuck at earlier versions that depend on you to maintain a working 
toolchain.  Are you going to walk away from that responsibility?

-br

Original comment by bill....@palmeta.com on 6 Nov 2012 at 1:26

GoogleCodeExporter commented 9 years ago 
PS: It would be Really Nice, for the authors of cores who have built on the 
Arduino team's efforts and added great value thereby, and the USERS of those 
cores, who have built projects on those cores, if old cores Just Worked in 1.5. 

There is no technical reason this can't happen if you guys accept it as a 
design requirement.  Which I suspect the cores authors and users (like me) 
would vote for.

Old cores should Just Work in 1.5.

-br

Original comment by bill....@palmeta.com on 6 Nov 2012 at 1:31

GoogleCodeExporter commented 9 years ago 
If there's no platform.txt in a hardware folder, we should use the one in the 
corresponding platform of another package (e.g. the built-in package). That 
way, we don't end up with lots of redundant and outdated versions of the 
platform.txt files in all the third-party hardware folders. Often, you're just 
supplying a boards.txt file with a board with a different name (and maybe a 
different CPU speed or pinout); I imagine it will be relatively rare for people 
to need to tweak the platform.txt file. 

My suggestion would be a search path for finding an appropriate platform.txt 
file, starting with the most board-specific location and proceeding to the most 
general. That is, I would start with the package containing the boards.txt 
file, then the one containing its variant directory, then the one containing 
its core directory, and finally other packages with the same platform (e.g. the 
built-in package).

In the meantime, though, even if the code currently doesn't let us use a 
third-party hardware folder without a boards.txt, we should make sure that the 
IDE still runs. That is, we should avoid or catch this exception so you can use 
the boards defining in other folders, at least.

Original comment by dmel...@gmail.com on 6 Nov 2012 at 1:32

GoogleCodeExporter commented 9 years ago 
Also, I agree that we should stay compatible with existing boards.txt files, 
variant header files, cores, etc. I think there are a few differences (e.g. in 
the specification of the location of the bootloader hex file) that might need 
to be adjusted. 

On the other hand, the new multi-platform architecture means that the 
third-party hardware folders should have top-level folders for the various 
platforms, e.g. "avr" or "sam". I don't think it's necessarily an undue burden 
to ask people to move the files from an existing hardware folder inside an 
"avr" sub-directory, although this would mean that the folder wouldn't be 
recognized by earlier versions of the software. In the past, we haven't 
necessarily put too much effort into making it possible for people to use 
previous versions of the software side-by-side with a new one, but that doesn't 
mean we can't.

Anyway, this is up to Cristian.

Original comment by dmel...@gmail.com on 6 Nov 2012 at 2:02

GoogleCodeExporter commented 9 years ago 
Agree all above, except one thing.

Making library authors move stuff to /avr would break existing builds and 
introduce a backwards incompatibility against people stuck at 0023.  It is 
better to leave the mess out there than to force people to clean things up, 
which breaks libraries and built projects.

Existing projects should Just Work.

-br

Original comment by bill....@palmeta.com on 6 Nov 2012 at 2:37

GoogleCodeExporter commented 9 years ago 
billroy,

backward compatibility is one our priority, for sure we don't want to trash all 
the existing work done with Arduino, since its the *most important* value added 
by the Arduino community. You don't need to remember us such thing to support 
your point of view, it doesn't add anything that we already don't know.

Said that, you're mixing "libraries" and "cores".

Libraries, as I said in many other threads will continue to work as always. 
They have full backward-compatibilty, so no problems with that. Even if we 
introduce support for multiplatform-libraries (and we already did it) these are 
detected and taken apart from old-style libraries.

For "cores" the thing is more complex and can't be get rid so easily.

We introduced with IDE 1.5 the possibility to work with multiplatform cores and 
we added also a new core for ARM. Now, how can we keep separate both cores? the 
most reasonable thing to do is keep two separate folders "avr" and "sam", one 
for each core. Also the compile process was refined to make it more 
configurable: now you can tweak a simple configuration files instead of hacking 
a Java class. Note that those changes introduces an incompatibility with the 
past, but almost all are requests that developers are asking us from months.

You can't use the words "Existing projects should Just Work" as a dogma, there 
is always a balance to keep in mind: can I keep backward compatibility? if the 
answer is no, how much is worth the change? how many users/developers wants 
this change to happen?

What does this imply for "cores" developers?
Means that they should give a version of their core for IDE 1.5. This doesn't 
means they have to rewrite their core from scratch! it means moving all the 
files inside a folder called "avr" and changing a few lines on boards.txt file. 
If you are a maintainer of a "core" for Arduino you can easily do that work in 
15 minutes max.

What does this imply for "cores" users?
It means that they need to install the 1.5 version of the 3rd party core they 
are using.

There were a documentation on how to do this "migration"?
Yes, when the format of the new cores stabilizes.

To me this seems a reasonable compromise.

C

Original comment by c.mag...@bug.st on 6 Nov 2012 at 4:25

GoogleCodeExporter commented 9 years ago 

Thanks for your note.  But with all due respect, it's not a compromise.  It 
still breaks old stuff.

There's no engineering reason the old cores couldn't continue to work, and the 
new features be triggered by the presence of a file or directory, as you 
propose.  Working code is already there.  Please don't break it for consistency 
with some new scheme.  Lay the new scheme over the existing one so delicately 
that no existing code is disturbed.

How many hours of end user upgrades are okay?  How many cores times core users 
are there?  Have you done the arithmetic on one of these simple upgrades as it 
cascades through your considerable and impressive user base?  How many hours 
vanish with this decision?  We are your customers and our time deserves your 
consideration when you make engineering tradeoffs.

If the impact can be zero, why not make it so?  Move on, for sure, just don't 
break what you've already put out there.  

It wouldn't matter if it weren't being used.  This is a price of success, guys.

Thanks for listening.

-br

Original comment by bill....@palmeta.com on 6 Nov 2012 at 4:38

GoogleCodeExporter commented 9 years ago 
As the maintainer of the 2nd oldest and perhaps the most widely used 3rd party 
core, I can tell you from years of experience that dealing with changes in 
directory layout is a relatively small part of the total work needed to keep a 
3rd party core up to date.

API additions, like String, tone, Stream class are much more work.  The 
incompatible API changes for 1.0, like flush() changing from "discard input" to 
"output wait" and Print::write()'s change from void to returning size_t require 
editing code, not simply adding stuff.  Upcoming stuff, like yield() and 
concurrency features, and more distant APIs like automatic data transfer 
between Stream objects
 will probably be very compelling for Arduino users, and thus even more maintainence work for 3rd pa
rty cores.

That said, I still don't yet understand why yet another level of directory 
heirarchy was needed, when the existing target/core/board/variant system was 
already 4 levels of abstraction.  I can tell you Teensy 2.0 and 3.0 are able to 
use AVR and ARM quite easily using only a single target, 1 boards.txt (with 
minor patches to 1.0.1's Compiler.java to allow boards.txt override "avr" and 
compiler options in a few places) and 2 cores.  I'm not even using the variants 
stuff.  Maybe there was some good reason why separate architectures couldn't 
simply be different targets or different boards with options in boards.txt?

But whatever the reasoning, worrying about directories and IDE abstraction 
layer changes misses the larger picture.  The Arduino API, like most software 
in active development, is a moving target.  Even if the now 5 levels of 
abstraction (target/architecture/cores/boards/variant) never changes again, 
anyone maintaining a 3rd party core will need to do quite a substantail amount 
of ongoing maintainence to keep pace.  Good compatibility is a lot of work, 
where dealing with directory layout is only
a very minor issue, relatively speaking.

Original comment by paul.sto...@gmail.com on 6 Nov 2012 at 5:24

GoogleCodeExporter commented 9 years ago 
Also (this probably deserves its own issue), one of the pains of a 3rd party 
core with extra features is keywords.txt.

Would it be possible for 1.5.x to move keywords.txt from the global "lib" 
(applying to all targets, all architectures, all cores, all boards and all 
variants) to some other location where 3rd party cores can supply their own, or 
include the official one and add to it?

Original comment by paul.sto...@gmail.com on 6 Nov 2012 at 5:36

GoogleCodeExporter commented 9 years ago 
This should fix the issue:

https://github.com/arduino/Arduino/commit/3e7690149b26d1789f3f7e7e8861a36bfaf2e5
d1

may you check it?
C

Original comment by c.mag...@bug.st on 9 Nov 2012 at 8:54

GoogleCodeExporter commented 9 years ago 
(1) I get a stack trace at startup; see below.  The menus look happier but 
there is still a startup problem: the interior of the sketch window is not 
rendered, and there is a stack trace (see attachment) in the diagnostics panel. 
 Opening a new sketch has the same rendering problem.  Screen shot attached.

(2) In the boards menu, the Due item is disabled.  Screen shot attached.

-br

E

Original comment by bill....@palmeta.com on 9 Nov 2012 at 11:47

Attachments:

GoogleCodeExporter commented 9 years ago 
Sorry, never mind about (2), now I see the grayed out menu item is a divider, 
not a choosable item.

-br

Original comment by bill....@palmeta.com on 9 Nov 2012 at 11:48

GoogleCodeExporter commented 9 years ago 
Paul: thank you for your thoughtful comments.  It is true that many of the 
changes are small.  But not every library or core has a full-time professional 
developer making a business of it, so many of them languish in disrepair when 
the core team breaks compatibility.  This, as you know, turns into unhappy 
users who show up on the forum.

It is when you multiply compatibility-breaking changes by several hundred 
libraries and a half-dozen cores, and many thousands of User projects, that 
their impact becomes obnoxious.  Harmful to the ecosystem, in my view.

The API "SHOULD NOT" be a moving target.

-br

Original comment by bill....@palmeta.com on 9 Nov 2012 at 12:02

GoogleCodeExporter commented 9 years ago 
bill, may you try to do "ant clean" first? 

I had the same problem when I deployed 1.5.1 for Windows (seems that there is a 
specific commit that 'ant' doesn't recognize as a change and didn't update some 
java classes, I can't still explain why).

C

Original comment by c.mag...@bug.st on 10 Nov 2012 at 12:01

GoogleCodeExporter commented 9 years ago 
It is working now after:

$ ant clean;ant build;ant run

Starts up correctly, menus are there, compiles Bitlash.

Cheers,

-br

Original comment by bill....@palmeta.com on 10 Nov 2012 at 12:17

GoogleCodeExporter commented 9 years ago

Original comment by c.mag...@bug.st on 15 Dec 2012 at 10:49