Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All enhanced classes should implement a marker interface #187

Closed
gissuebot opened this issue Jul 7, 2014 · 14 comments
Closed

All enhanced classes should implement a marker interface #187

gissuebot opened this issue Jul 7, 2014 · 14 comments

Comments

@gissuebot
Copy link

From max.ross on March 18, 2008 00:19:58

All enhanced classes should implement a marker interface so that client
code has a reliable way to determine if an object is an instance of a
Guice-enhanced class.  Ideally the interface(s) would be configurable by
the client, but if Guice just has its own interface that its proxies always
implement that would be cool too.

Original issue: http://code.google.com/p/google-guice/issues/detail?id=187

@gissuebot
Copy link
Author

From max.ross on March 18, 2008 10:14:02

Sorry, this should have been submitted as an enhancement.  I don't see a way to
switch the issue type.

@gissuebot
Copy link
Author

From limpbizkit on May 14, 2008 08:23:44

My only anxiety about this is it adds another interface to our API. That interface doesn't do anything and it
encourages users to use instanceof.

As a hack workaround, I believe you can differentiate between enhanced and standard classes by calling:
   boolean isEnhanced = getClass().getName().contains("EnhancedByGuice");

Anybody else have an opinion on this?

Labels: -Type-Defect Type-Enhancement

@gissuebot
Copy link
Author

From limpbizkit on May 14, 2008 09:26:17

(No comment was entered for this change.)

Labels: -Priority-Medium Priority-Low

@gissuebot
Copy link
Author

From max.ross on May 14, 2008 09:45:45

Your suggestions is exactly what I'm doing, but it's relying on an internal
implementation detail which you're obviously free to change at any time.

My mistake for trying to dictate the solution rather than just explaining the problem
I need solved.

One use case is when you have a Map keyed by Class.  Maybe you're mapping the Class
to a processor that knows how to do something with instances of that Class:

Processor getProcessor(Foo foo) {
  return processorsByClass.get(foo.getClass());
}

If you're using Guice and a module is setting up interceptors on instances of Foo and
this method receives a Foo that was created by Guice, the processor lookup will fail.

I'd be happy with any mechanism that allows me to reliably determine if I'm dealing
with a dynamically created Guice subclass.  So, an interface works, but if marker
interfaces bother you (and it sounds like they do) then a helper method
(isGuiceEnhanced()) would be just as useful.

Thanks,
Max

@gissuebot
Copy link
Author

From dhanji on January 30, 2009 21:48:06

This kind of requirement is quite common in classpath scanning code (though I think, not the greatest idea in
the world =). One solution would be to do a super-crawl until you detect a class that's recognized, then cache
the proxy class as a transparent pointer so the next time it's a constant lookup.

@gissuebot
Copy link
Author

From rcouto on January 31, 2009 04:46:40

Are these objects instances of classes you control (meaning, are they instantiated by
Guice)? If so, maybe you could create an interface of your own with a method that
would return the correct TypeLiteral of each object. The technique that Jesse Wilson
posted on his blog may just do the trick: http://publicobject.com/2008/11/guice-punches-erasure-in-face.html

@gissuebot
Copy link
Author

From cgruber@google.com on July 16, 2012 11:05:08

Marking acknowledged pending prioritization.

Status: Acknowledged
Labels: Component-Core

@gissuebot
Copy link
Author

From bruno.medeiros@visagio.com on November 22, 2012 05:03:16

I also miss this feature a lot, and I don't see any problem in inserting a new interface. I'm using Guice now to replace a library internally developed and we have such a mark interface, called EnhancedClass. We do the following:

                Enhancer enhancer = new Enhancer();
                enhancer.setSuperclass(baseClass);
                enhancer.setInterfaces(new Class[]{EnhancedClass.class});

> That interface doesn't do anything and it encourages users to use instanceof.

I don't see any reason to avoid the instanceof operator, could you explain more on this?

@gissuebot
Copy link
Author

From bruno.medeiros@visagio.com on November 22, 2012 07:24:53

One more comment, the workaround should be

    boolean isEnhanced = getClass().getName().contains("EnhancerByGuice")

instead of

   boolean isEnhanced = getClass().getName().contains("EnhancedByGuice");

At least on Guice 3.0 it is.

@gissuebot
Copy link
Author

From cgruber@google.com on November 18, 2013 11:59:40

(No comment was entered for this change.)

Status: Accepted
Owner: cgruber@google.com
Labels: -Priority-Low Priority-High

@gissuebot
Copy link
Author

From cgruber@google.com on November 18, 2013 12:00:54

(No comment was entered for this change.)

Labels: Milestone-Release4.0

@tavianator
Copy link
Contributor

Any progress on this? I'm happy to send a PR but I'm not sure where to put the new API. I figure it should be something like Guice.isAopProxy(), a la Scopes.isCircularProxy().

@bcmedeiros
Copy link

I'd also like to see this fixed, my code is still as dirty as getClass().getName().contains("EnhancerByGuice").
Tavianator, I'd use Guice.isEnhanced(Class<?> class).

@domhauton
Copy link

domhauton commented Sep 7, 2017

+1 on this issue. We are using:

    private String stripGuiceMarksFromClassName(Class clazz) {
        String name = clazz.getName();
        if (name.contains("$$EnhancerByGuice$$")) {
            return clazz.getSuperclass().getName();
        } else {
            return name;
        }
    }

to get real class names

copybara-service bot pushed a commit that referenced this issue Apr 18, 2023
…eturning the unenahnced version).

(Also changes the classname suffix to be a hex string instead of an int, which had previously included a leading negative sign, which was weird.)

Fixes #1340 & fixes #187.

PiperOrigin-RevId: 525256080
copybara-service bot pushed a commit that referenced this issue Apr 18, 2023
…eturning the unenhanced version).

(Also changes the classname suffix to be a hex string instead of an int, which had previously included a leading negative sign, which was weird.)

Fixes #1340 & fixes #187.

PiperOrigin-RevId: 525256080
copybara-service bot pushed a commit that referenced this issue Apr 22, 2023
…eturning the unenhanced version).

(Also changes the classname suffix to be a hex string instead of an int, which had previously included a leading negative sign, which was weird.)

Fixes #1340 & fixes #187.

PiperOrigin-RevId: 525256080
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants