[BCEL] Console warning

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[BCEL] Console warning

garydgregory
Hi All:

In BCEL, we log a warning to the console:

https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240

Which you can't really do anything about since it does not tell you what
class file it is complaining about.

1) Should remove the logging?
or,
2) Should we improve the logging?
or,
3) Do nothing?

Gary
Reply | Threaded
Open this post in threaded view
|

RE: [BCEL] Console warning

Mark Roberts
I added that warning while working on the StackMap support for Java7 (and beyond).  We were testing (daikon and randoop) on several very large test suites and found a large number of class files compiled with an obsolete version of Java that generated bogus StackMap entries.  I don't feel too strongly that it needs to remain.  Perhaps change the message to suggest recompiling with a newer version of Java?  But of course, a lot of these classfiles have been passed about and have become disconnected from their source.

Mark

-----Original Message-----
From: Gary Gregory [mailto:[hidden email]]
Sent: Wednesday, April 10, 2019 4:20 PM
To: Commons Developers List <[hidden email]>
Subject: [BCEL] Console warning

Hi All:

In BCEL, we log a warning to the console:

https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240

Which you can't really do anything about since it does not tell you what class file it is complaining about.

1) Should remove the logging?
or,
2) Should we improve the logging?
or,
3) Do nothing?

Gary


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Console warning

Rob Tompkins
In reply to this post by garydgregory


> On Apr 10, 2019, at 7:20 PM, Gary Gregory <[hidden email]> wrote:
>
> Hi All:
>
> In BCEL, we log a warning to the console:
>
> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240
>
> Which you can't really do anything about since it does not tell you what
> class file it is complaining about.
>
> 1) Should remove the logging?

Uncertain here. In the general case, I feel like we should either do nothing or throw an exception. But the logic feels like it warrants some explanation, so I don’t know

> or,
> 2) Should we improve the logging?

This should be our minimal plan, if removing it doesn’t make sense.

> or,
> 3) Do nothing?

Because you brought it up, it feels like something should be done?

>
> Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Console warning

garydgregory
In reply to this post by Mark Roberts
The problem is really that BCEL is used in many places and that when you
see 30 lines of this warning when you are running a Maven build, you go
"What the heck this? Panic?!" especially when your project does not depend
on BCEL but BCEL comes in from transitive deps.

Gary

On Wed, Apr 10, 2019 at 7:35 PM Mark Roberts <[hidden email]>
wrote:

> I added that warning while working on the StackMap support for Java7 (and
> beyond).  We were testing (daikon and randoop) on several very large test
> suites and found a large number of class files compiled with an obsolete
> version of Java that generated bogus StackMap entries.  I don't feel too
> strongly that it needs to remain.  Perhaps change the message to suggest
> recompiling with a newer version of Java?  But of course, a lot of these
> classfiles have been passed about and have become disconnected from their
> source.
>
> Mark
>
> -----Original Message-----
> From: Gary Gregory [mailto:[hidden email]]
> Sent: Wednesday, April 10, 2019 4:20 PM
> To: Commons Developers List <[hidden email]>
> Subject: [BCEL] Console warning
>
> Hi All:
>
> In BCEL, we log a warning to the console:
>
>
> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240
>
> Which you can't really do anything about since it does not tell you what
> class file it is complaining about.
>
> 1) Should remove the logging?
> or,
> 2) Should we improve the logging?
> or,
> 3) Do nothing?
>
> Gary
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Console warning

garydgregory
In reply to this post by Rob Tompkins
On Wed, Apr 10, 2019 at 7:44 PM Rob Tompkins <[hidden email]> wrote:

>
>
> > On Apr 10, 2019, at 7:20 PM, Gary Gregory <[hidden email]>
> wrote:
> >
> > Hi All:
> >
> > In BCEL, we log a warning to the console:
> >
> >
> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240
> >
> > Which you can't really do anything about since it does not tell you what
> > class file it is complaining about.
> >
> > 1) Should remove the logging?
>
> Uncertain here. In the general case, I feel like we should either do
> nothing or throw an exception. But the logic feels like it warrants some
> explanation, so I don’t know
>
> > or,
> > 2) Should we improve the logging?
>
> This should be our minimal plan, if removing it doesn’t make sense.
>
> > or,
> > 3) Do nothing?
>
> Because you brought it up, it feels like something should be done?
>

I see these possible solutions:

1) Remove the logging (simple)
2) Make logging configurable (bleh)
3) Use a logging API (Log4j 2 for example)
4) Throw an exception in the next major version if this is _really_ an
incorrect state but that does not seem like it would help anyone.

I favor (1).

Gary


> >
> > Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Console warning

Rob Tompkins


> On Apr 10, 2019, at 7:46 PM, Gary Gregory <[hidden email]> wrote:
>
>> On Wed, Apr 10, 2019 at 7:44 PM Rob Tompkins <[hidden email]> wrote:
>>
>>
>>
>>> On Apr 10, 2019, at 7:20 PM, Gary Gregory <[hidden email]>
>> wrote:
>>>
>>> Hi All:
>>>
>>> In BCEL, we log a warning to the console:
>>>
>>>
>> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240
>>>
>>> Which you can't really do anything about since it does not tell you what
>>> class file it is complaining about.
>>>
>>> 1) Should remove the logging?
>>
>> Uncertain here. In the general case, I feel like we should either do
>> nothing or throw an exception. But the logic feels like it warrants some
>> explanation, so I don’t know
>>
>>> or,
>>> 2) Should we improve the logging?
>>
>> This should be our minimal plan, if removing it doesn’t make sense.
>>
>>> or,
>>> 3) Do nothing?
>>
>> Because you brought it up, it feels like something should be done?
>>
>
> I see these possible solutions:
>
> 1) Remove the logging (simple)
> 2) Make logging configurable (bleh)
> 3) Use a logging API (Log4j 2 for example)
> 4) Throw an exception in the next major version if this is _really_ an
> incorrect state but that does not seem like it would help anyone.
>
> I favor (1).

+1, particularly with Mark’s context. -Rob

>
> Gary
>
>
>>>
>>> Gary
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Console warning

Bruno P. Kinoshita-3
 +1 for dropping or improving. [imaging] will go out in 1.0 with j.u.l if I recall correctly. Maybe a similar approach would work here, if we decide to keep the logs.
CheersBruno

    On Thursday, 11 April 2019, 11:58:40 am NZST, Rob Tompkins <[hidden email]> wrote:  
 
 

> On Apr 10, 2019, at 7:46 PM, Gary Gregory <[hidden email]> wrote:
>
>> On Wed, Apr 10, 2019 at 7:44 PM Rob Tompkins <[hidden email]> wrote:
>>
>>
>>
>>> On Apr 10, 2019, at 7:20 PM, Gary Gregory <[hidden email]>
>> wrote:
>>>
>>> Hi All:
>>>
>>> In BCEL, we log a warning to the console:
>>>
>>>
>> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240
>>>
>>> Which you can't really do anything about since it does not tell you what
>>> class file it is complaining about.
>>>
>>> 1) Should remove the logging?
>>
>> Uncertain here. In the general case, I feel like we should either do
>> nothing or throw an exception. But the logic feels like it warrants some
>> explanation, so I don’t know
>>
>>> or,
>>> 2) Should we improve the logging?
>>
>> This should be our minimal plan, if removing it doesn’t make sense.
>>
>>> or,
>>> 3) Do nothing?
>>
>> Because you brought it up, it feels like something should be done?
>>
>
> I see these possible solutions:
>
> 1) Remove the logging (simple)
> 2) Make logging configurable (bleh)
> 3) Use a logging API (Log4j 2 for example)
> 4) Throw an exception in the next major version if this is _really_ an
> incorrect state but that does not seem like it would help anyone.
>
> I favor (1).

+1, particularly with Mark’s context. -Rob

>
> Gary
>
>
>>>
>>> Gary
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
 
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Console warning

garydgregory
I'm going to take the same lame-ish approach as
org.apache.bcel.classfile.JavaClass.debug. It's a hack, but we have a
precedent here; until we come to a better solution. I think JUL is ... not
great.

Gary

On Wed, Apr 10, 2019 at 8:01 PM Bruno P. Kinoshita
<[hidden email]> wrote:

>  +1 for dropping or improving. [imaging] will go out in 1.0 with j.u.l if
> I recall correctly. Maybe a similar approach would work here, if we decide
> to keep the logs.
> CheersBruno
>
>     On Thursday, 11 April 2019, 11:58:40 am NZST, Rob Tompkins <
> [hidden email]> wrote:
>
>
>
> > On Apr 10, 2019, at 7:46 PM, Gary Gregory <[hidden email]>
> wrote:
> >
> >> On Wed, Apr 10, 2019 at 7:44 PM Rob Tompkins <[hidden email]>
> wrote:
> >>
> >>
> >>
> >>> On Apr 10, 2019, at 7:20 PM, Gary Gregory <[hidden email]>
> >> wrote:
> >>>
> >>> Hi All:
> >>>
> >>> In BCEL, we log a warning to the console:
> >>>
> >>>
> >>
> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240
> >>>
> >>> Which you can't really do anything about since it does not tell you
> what
> >>> class file it is complaining about.
> >>>
> >>> 1) Should remove the logging?
> >>
> >> Uncertain here. In the general case, I feel like we should either do
> >> nothing or throw an exception. But the logic feels like it warrants some
> >> explanation, so I don’t know
> >>
> >>> or,
> >>> 2) Should we improve the logging?
> >>
> >> This should be our minimal plan, if removing it doesn’t make sense.
> >>
> >>> or,
> >>> 3) Do nothing?
> >>
> >> Because you brought it up, it feels like something should be done?
> >>
> >
> > I see these possible solutions:
> >
> > 1) Remove the logging (simple)
> > 2) Make logging configurable (bleh)
> > 3) Use a logging API (Log4j 2 for example)
> > 4) Throw an exception in the next major version if this is _really_ an
> > incorrect state but that does not seem like it would help anyone.
> >
> > I favor (1).
>
> +1, particularly with Mark’s context. -Rob
> >
> > Gary
> >
> >
> >>>
> >>> Gary
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Console warning

garydgregory
Tracking here:  https://issues.apache.org/jira/browse/BCEL-316

Gary

On Fri, Apr 12, 2019 at 8:58 AM Gary Gregory <[hidden email]> wrote:

> I'm going to take the same lame-ish approach as
> org.apache.bcel.classfile.JavaClass.debug. It's a hack, but we have a
> precedent here; until we come to a better solution. I think JUL is ... not
> great.
>
> Gary
>
> On Wed, Apr 10, 2019 at 8:01 PM Bruno P. Kinoshita
> <[hidden email]> wrote:
>
>>  +1 for dropping or improving. [imaging] will go out in 1.0 with j.u.l if
>> I recall correctly. Maybe a similar approach would work here, if we decide
>> to keep the logs.
>> CheersBruno
>>
>>     On Thursday, 11 April 2019, 11:58:40 am NZST, Rob Tompkins <
>> [hidden email]> wrote:
>>
>>
>>
>> > On Apr 10, 2019, at 7:46 PM, Gary Gregory <[hidden email]>
>> wrote:
>> >
>> >> On Wed, Apr 10, 2019 at 7:44 PM Rob Tompkins <[hidden email]>
>> wrote:
>> >>
>> >>
>> >>
>> >>> On Apr 10, 2019, at 7:20 PM, Gary Gregory <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Hi All:
>> >>>
>> >>> In BCEL, we log a warning to the console:
>> >>>
>> >>>
>> >>
>> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240
>> >>>
>> >>> Which you can't really do anything about since it does not tell you
>> what
>> >>> class file it is complaining about.
>> >>>
>> >>> 1) Should remove the logging?
>> >>
>> >> Uncertain here. In the general case, I feel like we should either do
>> >> nothing or throw an exception. But the logic feels like it warrants
>> some
>> >> explanation, so I don’t know
>> >>
>> >>> or,
>> >>> 2) Should we improve the logging?
>> >>
>> >> This should be our minimal plan, if removing it doesn’t make sense.
>> >>
>> >>> or,
>> >>> 3) Do nothing?
>> >>
>> >> Because you brought it up, it feels like something should be done?
>> >>
>> >
>> > I see these possible solutions:
>> >
>> > 1) Remove the logging (simple)
>> > 2) Make logging configurable (bleh)
>> > 3) Use a logging API (Log4j 2 for example)
>> > 4) Throw an exception in the next major version if this is _really_ an
>> > incorrect state but that does not seem like it would help anyone.
>> >
>> > I favor (1).
>>
>> +1, particularly with Mark’s context. -Rob
>> >
>> > Gary
>> >
>> >
>> >>>
>> >>> Gary
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>