Java enums with implements

[danS]

I got this error when attempting to reverse engineer some Java 5.0 code in EA:

Code: [Select]

There was an error parsing C:\test\Test.java on line 3.
Unexpected Symbol: implements
Would you like to continue the import?

Here is the offending code:

Code: [Select]

package test;

public enum Test implements Something {
...

The implements keyword is legal for enums, so I assume this is a problem with the parser grammer.

[Eve]

Thank you for alerting us to this oversight.

It should be fixed ready for the next build.

Simon

[mikewhit]

This rather worries me that a test suite is not being applied to EA before release of a new version.

Assuage my fears !? Simon ??

(shut up, Paolo ! ;-)

[Paolo F Cantoni]

This rather worries me that a test suite is not being applied to EA before release of a new version.

Assuage my fears !?

Pause for hysterical laughter...  

Paolo

[thomaskilian]

 

[Eve]

Okay, I'll reassure you.

Every new build is tested as completely as possible before release.

The problem here is a different one entirely.  You can only test what you know.  We didn't know that this was a valid part of the language.  As a result we didn't have any tests for it.

Simon

[Paolo F Cantoni]

Pause for hysterical laughter...  

Paolo

I need to clear up some confusion regarding this post.

I was NOT implying the EA isn't tested.  Elsewhere, Thomas (backed up by me) observes that you can use the betas on production systems very quickly - as they work!  That is, they won't crash, won't corrupt the DB etc.

YOU DON'T GET TO THIS POINT WITHOUT A GOOD TESTING REGIME!

The reason for the laughter was that the issue, in my view, is precisely NOT a testing problem.  It's the problem admitted to by Simon - that of knowledge!

If you don't know that non-orthogonality is bad, then you build it in.  If you don't know that inconsistency is disastrous from a system point of view, you build it in.  If you don't think about using the product from the (naive) user's point of view, you don't make it easy to switch from no or another product.  Etc etc.

I encourage Sparxians to ponder on such abstract (airy-fairy, arty-farty) ideas and try to apply them to upcoming releases of EA.  And we users also, to provide useful feedback to Sparx...

When all's said and done, EA is still one of the [size=18]BEST[/size] [/color]modelling products around (irrespective of price!!! ).  It's just, that for me, the effort to come to grips with it and get used to its idiosyncrasies is very HIGH.   (But obviously not too high, otherwise I'd have been and gone a long time ago! )

Cheerz,

Paolo

[mikewhit]

Thanks, Simon !

I'm working in Test/Validation ATM so I have a higher than usual sensitivity to the subject !

Looks like changes in language requirements need a better feed into the specification and testing regime.
Keep an eye on that java.sun.com !!

Cheers,
Mike.

[sargasso]

As a practicing Test Manager (getting better every day!) I would like to offer a short tale of learning - ignore it if you want.

Many, many moons ago I was the test manager / tester for a wholesale banking (money market) product.  It had been in use for over two years at the developer banks site and was now being sold to recoup.  We, the software company, took the base inhouse product and detoxified it of constants referring to the developer bank, added some general architectural software packagey type of stuff,  added some original government compliance stuff etc etc and started to flog it on the market.

We reckoned it was pretty good stuff.  WE had not mucked around with the underlying business code vary very much at all and then only in consultation with one of the original architects.

A LARGE bank bought it and after 6 months of tailoring (by themselves) put it into production.  It ran like a dream for several weeks then one of the more brilliant money market dealers of the day created a secured deposit, registered securities against the deposit, actually delivered the security to the client and then cancelled the deposit.  Lo and behold, the system sweetly cancelled the deposit but left the securities locked against sale because they were lodged.  

Now like all good systems of the day there was no un-cancel function.

The IT manager of the bank took us to task, and me as the test manager in particular as to why this had never been tested!  My answer then was "Because we didin't think anyone would be insane enough to do that".  After a short period of contemplation he did agree that was a fair cop.

Over the years and systems since, I have come to the conclusions that :
a) Fundamentally all users are insane - they will each and every one of them come up with such an idea.
b) There are many, many more insane users than sane test managers.  

ergo
c) If we attempted to test for each and every insane scenario FORTRAN IV would still not be released commercially.....


So when I'm training test developers these days, I try and get them to think in the ways of the common insane user. IOW try and test for the most common types of use insanity.


Anyway, this has nothing to do with the current thread, nor is it a comment on the developers, testers and users of EA.  It just popped out of my memory when Paolo started giggling hysterically above,  for some reason or other.....

bruce  

p.s. Am I working too hard or did the colors just change??    

p.p.s.  Spolling orrers now faxed.

[Paolo F Cantoni]

[SNIP]
p.s. Am I working too hard or did the colours just change??    

Could it be that they finally brought their award home and it accidentally spilt onto the Forum?

Cheerz,

Paolo

BTW: I presume a LARGE bank bought it...

[Paolo F Cantoni]

As a practising Test Manager (getting better every day!) I would like to offer a short tale of learning - ignore it if you want.
[SNIP]

bruce,

Your points are well taken.  

However, there are some issues in your example that would, in my opinion, be instructive to discuss.  But I'm loath to do it unless people felt it would be useful.

I think (that is, I'm not sure as yet), that they touch on why we should be using model based development and why we need tools like EA to be really good at supporting declarative approaches in the support of good architecture.

If people would like to discuss this, I suggest a new thread is started, with your story as the initial post.

Cheerz,

Paolo

[mikewhit]

Mind you, checking back on my posts here, I always have a "higher than usual" sensitivity to Requirements and Test issues !

Maybe what the psyches would call [Finbar Saunders shields ON] botty-retentive ...

[sargasso]

I have invoked the demon.

Herewith, verbatim, one of the functional specifcation rules I received today.

Males don’t share unless every Female has already been paired off, so girls
travel with Males rather than Females, with men rather than boys, and with
women rather than other girls. This is because females units are allocated first,
& sharing is first come, first served.
Sharing is performed in the following order: Fm, Ff, Mf, Mm, ff, and mm.

:-/