Eclipse Community Forums: e(fx)clipse » Getting rid of javax.annotation imports

Help

Home

Home » Eclipse Projects » e(fx)clipse » Getting rid of javax.annotation imports

Show: Today's Messages :: Show Polls :: Message Navigator

Getting rid of javax.annotation imports [message #1688476]

Fri, 20 March 2015 19:43

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Hi,

I've initialized at EclipseCon a discussion to get rid of the mandatory
javax.annotation imports.

Bug 462686 - Remove the javax.annotation plug-in content -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=462686

I really really hate them since day 1 (reusing those has been one of the
biggest mistakes in e4 we ever made!)

Now my question is how do e(fx)clipse adopters think about this topic?
If the platform does not push this into Mars, should we e(fx)clipse make
the move before and not ship our custom javax.annotation which is bound
to the JRE classes?

I'm currently in the mood of pushing this. Thoughts?

Tom

Report message to a moderator

Re: Getting rid of javax.annotation imports [message #1688511 is a reply to message #1688476]

Fri, 20 March 2015 22:13

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Hi,

It looks like the platform can not move that easily but we can so I
replaced the javax.annotation in our target through a fake one who
delegates to the JRE so your custom bundles can now live without doing
package imports of javax.annotation.

Tom

On 20.03.15 20:43, Tom Schindl wrote:
> Hi,
>
> I've initialized at EclipseCon a discussion to get rid of the mandatory
> javax.annotation imports.
>
> Bug 462686 - Remove the javax.annotation plug-in content -
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=462686
>
> I really really hate them since day 1 (reusing those has been one of the
> biggest mistakes in e4 we ever made!)
>
> Now my question is how do e(fx)clipse adopters think about this topic?
> If the platform does not push this into Mars, should we e(fx)clipse make
> the move before and not ship our custom javax.annotation which is bound
> to the JRE classes?
>
> I'm currently in the mood of pushing this. Thoughts?
>
> Tom
>
>

Report message to a moderator

Re: Getting rid of javax.annotation imports [message #1689270 is a reply to message #1688511]

Mon, 23 March 2015 06:56

Uwe San

Messages: 119
Registered: January 2012

Senior Member

Hi Tom,

after reading the discussion on the bugtracker, I'm not sure I completely understand why the javax.annotation imports are so harmful and they have never caused any problems for us, but as far as I can tell removing them would not be a major pain for our project.

Cheers,
Uwe

Report message to a moderator

Re: Getting rid of javax.annotation imports [message #1689313 is a reply to message #1689270]

Mon, 23 March 2015 09:31

Christoph Keimel

Messages: 482
Registered: December 2010
Location: Germany

Senior Member

It has caused a lot of bug tracking in our case because this can easily be forgotten. The result is often an NPE because some field has not been initialized, but it can also be more subtle. So, if you do not know about this issue, you think to yourself: Why does @Inject work but not @PostConstruct? Isn't that part of the same mechanism? So I am +1 for this change.

Report message to a moderator

Re: Getting rid of javax.annotation imports [message #1689343 is a reply to message #1689313]

Mon, 23 March 2015 11:14

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

The real problem is that there are 2 versions of
javax.annotation.PostConstruct/PreDestroy:
a) version A in the JRE
b) version B in the repackaged bundle

Just to be extra clear, you can now go both ways! The real problem is
that if you forgot the import package for javax.annotation your
@PostConstruct would never have called, while @PostConstruct is often
caught fairly soon, @PreDestroy could leak to memory leaks you'll
discover very hard.

Tom

On 23.03.15 10:31, Christoph Keimel wrote:
> It has caused a lot of bug tracking in our case because this can easily
> be forgotten. The result is often an NPE because some field has not been
> initialized, but it can also be more subtle. So, if you do not know
> about this issue, you think to yourself: Why does @Inject work but not
> @PostConstruct? Isn't that part of the same mechanism? So I am +1 for
> this change.

Report message to a moderator

Previous Topic:	Bug 462634 - Make org.eclipse.fx.osgi optional for pure OSGi+JavaFX applications
Next Topic:	Eclipse crash on AIX

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Sep 19 23:32:43 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter