• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

Imported package that has a error, don't know how to fix.

 
Greenhorn
Posts: 9
C++ Chrome Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So I imported a package into my project and it has this error on line 125: There is no default constructor available in 'com.google.common.collect.StandardTable.Row'

And this error on line 126: Call to 'TreeBasedTable.this.super()' must be first statement in constructor body

Can anyone help me, cause this code goes way over my head.


Code:
 
Saloon Keeper
Posts: 1646
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. Welcome to the Ranch!!

2. Congratulations on finding the CodeTags button, it generally makes code much easier to read.

Unfortunately, some Very Long Lines leave it difficult to read.  If you can try to edit those down (insert a line break at an appropriate point) it would go further towards letting us see your code clearly.

Please don't edit the post, but rather, fix the very long lines, and recompile so that we can actually see both the code and the error message referring to whatever line it lands on afterwards.
Then post again.

I am up for the challenge, but one of your problematic lines is additionally "way long" seriously complicating the effort.
 
Master Rancher
Posts: 4062
56
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, it looks like this is code from Google Guava.  Are you making your own version of their code?  Are you just trying to use a TreeBasedTable?  Is there a reason you need to compile it yourself?  Usually you would be best off downloading a particular version of Google Guava, and using that jar file to access already-compiled classes. What version number are you looking at?  Are you making changes of your own?
 
Marshal
Posts: 74376
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the Ranch (again)

Brennan Towry wrote:. . . it has this error on line 125: There is no default constructor available in 'com.google.common.collect.StandardTable.Row' . . .

Thank you for the error messages, which allow us to work out where to look
That isn't necessarily an error in the package. Go back to the class you want to extend, and find out what constructors it has; you must call one of them with super(...);
I am not used to super(...); with anything before it. Please remind us what line 126 means. Here is the JLS (=Java┬« Language Specification) section about constructors. You are obviously after a qualified constructor invocation, and the compiler isn't happy with how you wrote it. Are you allowed the cast?

I think other people may be able to provide more information.
 
Marshal
Posts: 26912
82
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The constructor of TreeRow that you declared starting at line 125 must start by calling a constructor of its superclass, which is Row, via the "super" keyword. Alternatively, if the superclass has a constructor with zero parameters then this requirement may be ignored, and the compiler will silently insert a call to that constructor. Or your third choice is to call a constructor of the same class, via the "this" keyword. That's a rule of Java.

But apparently Row doesn't have a zero-parameter constructor so you need to call one of its constructors. I don't know what those constructors are since Row isn't declared there, so you would have to check the documentation.

But note the other constructor at line 121, which calls another TreeRow constructor using the "this" keyword. That compiles correctly, but it is kind of a problem because it totally disregards the TreeBasedTable parameter which is passed to it. Ignoring that data points to some kind of a design problem.

You said (sort of) that you didn't write that code, though. Probably when you said you "imported a package" that meant you downloaded the code from somewhere. There's nothing wrong with that, people do it all the time. But you aren't guaranteed to get workable code when you do that, so when you run into problems you either have to fix them yourself or track down the people who wrote the code and get them to help.

Notice the annotation at line 21: @Beta. That (to me) implies that the code is beta-version code, meaning that there are definitely no guarantees. Although not even compiling is a bit surprising.
 
Campbell Ritchie
Marshal
Posts: 74376
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:. . . @Beta. . . . there are definitely no guarantees. Although not even compiling is a bit surprising.

Better to have code which doesn't compile than code which doesn't produce the correct result.
 
Mike Simmons
Master Rancher
Posts: 4062
56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm sure Google's actual code compiles just fine, when all necessary files are present.  I found TreeBasedTable v31.0.1 which no longer has any @Beta annotation.  Probably it would be best to use the jar for that.  Or, let us know what specific version you're using.

The Row class is declared as an inner member class of StandardTable.  In version 31.0.1, there's no single-arg constructor, but there is a constructor that accepts a single rowKey.  Which is why Google's TreeBasedTable.TreeRow constructor calls super(rowKey), which works fine.  

So, Brennan: why did you replace

with

?

Were you getting some other error?  I suspect you just need to copy over more classes, like StandardRowSortedTable and StandardTable.  Possibly more.  Or just download a working Guava jar file (e.g. v31.0.1 and use that.
 
Brennan Towry
Greenhorn
Posts: 9
C++ Chrome Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks everyone for your helpful responses. My coworker sent me an email telling me that this file is outdated and edited for a different, older project. He gave me the correct file. I don't know Java all to well, i'm the C++ C# integration guy.

In response to Jesse Silverman, Im not sure what you are asking me to do, if you could share a link to an example, or give a post of an example, that would be nice!
 
Jesse Silverman
Saloon Keeper
Posts: 1646
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sure.  In Python there is both a widely-accepted consensus that Very Long Lines are very difficult to read, review and debug and a fairly-widely-accepted consensus on how to break various constructs up so one's code doesn't contain any.

In C++, Java and C#, there is still pretty wide acceptance of the notion that Very Long Lines are very difficult to read, review and debug, but less of a consensus of how to break various constructs up so one's code doesn't contain any.  I was thinking that they might have something to say about it here:
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

But if there is advice towards that there, I didn't see it.

Lacking that consensus, and given that your problem is solved for now, I will just ask you to compare reading this edited version of your original code sample to the original in terms of how much one needs to ride the scroll bars to read it.  There are almost certainly better ways to achieve the same net effect (EDIT -- after a quick attempt, this code is still physically difficult to read due to lots of Very Long Lines.  It makes me appreciate how relatively easy most of the code I have been looking at is to physically read, even if it sometimes takes some thought to understand what it means) :

 
Jesse Silverman
Saloon Keeper
Posts: 1646
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To anyone/everyone else reading this thread.

I am one of the strongest proponents of annotating logically final instance members, static members and local variables as explicitly final.

It is a nice warning to anyone mucking about with my code that "Kindly don't mess with that once it has been set, or you are very liable to break the functioning of this class/object/method."

Leaving it out in those cases seems like an accident that can hardly wait to happen, and just to save six characters--I generally put it in.

I picked up from Very Wise People that annotating one's constructor and method parameters as such, on the other hand, is generally a rather silly waste of space.

In C++, the Wise Wizards seem even more against it there.  It is one of countless things that the language definition lets you do that you should just always avoid.
It buys you nothing and costs you precious horizontal space...

This code feels like it was written by someone who knows Java much better than I do, yet...
There are many painfully long lines that make you ride the scroll bar pretty heavily to read them, especially painful when trying to match code to error messages, but really, always.
There are many methods that decide to decorate their parameters with final.
Some of the Very Long Lines are method definitions that decide to decorate their parameters with final.

I believe these were the lines in my crude and only partially-successful attempt at avoiding by re-formatting Very Long Lines in the OP's code that followed that practice:
32, 38, 45, 131, 149, 154, 161, 168, 174, 236, 241

Now, I also always thought that "effectively final local variables" were an overblown feature, because I am a big fan of marking final things final anyway.
If they just happened to be final at that moment in code evolution, rather than logically so, and someone comes along and wants to capture them in a lambda/closure or anonymous class instance, now I got pasted into a corner.  I didn't even mean for those to be final, but now they are, etc. etc.

But maybe the use case was for exactly what I am seeing here?

There were lots of times that lambdas or code in anonymous local classes maybe would want to capture the values of method parameters, and until "effectively final" those all had to be marked final in the parameter list to the method, which was cluttering it up and making it hard to read?  So now, with "effectively final" we can actually read the method definitions without seeing an extra final five times?

Is this likely code that was written pre-Java 8, and therefore wanted to allow code in possible anonymous class instantiations to read the parameters?

Was it just written by people who always eat pizza with a knife and fork?

I had no trouble reading the last 50 or 60 pieces of Java code I have looked at.  This one was hard.

There may be some places where var could have helped as well, if it didn't need to target Java versions prior to 10, but the question here is about all the method parameters explicitly marked final, especially in lines that were already uncomfortably long.

 
Mike Simmons
Master Rancher
Posts: 4062
56
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Jesse:

So, again, this code is clearly copied (and subsequently modified) from the Google Guava open-source project.  Based on the @Beta annotation, it looks like it was copied from a version no later than TreeBasedTable.java v19.0.  Beyond that, I'm not sure what specific version they were working from.

Anyway, a few notes from browsing Google's versions of the code:

Google does not seem to ever have a version of this code that includes the final modifier on method parameters.  That seems to be something added by people at the original poster's company.  Like others here, and like those at Google, I see no real point to having such a modifier on method parameters.  Unfortunately it's pervasive in the codebase I see at work, but oh well.

Google's code also does not generally contain those overlong lines.  Those seem to come from changes introduced at the OP's company.

Google was indeed developing Guava for pre-Java 8 code, at least originally, and since it's a widely used open source library they tend to retain as much backward compatibility as they can.  Though at this point they don't officially maintain a pre-Java 8 version, just one for Java 8+ and one for Android.  So you won't see them using newer language features than Java 8 in that branch.

Of course, at the company the OP is working for, they might have inserted other newer features.  Or not.  I haven't looked carefully to see what all they changed.

@Brennan:

Glad to hear it's worked out now.  I know it's a pain to deal with code of unknown provenance and quality, in an unfamiliar language.  If you find you need to deal with this code more in the future, I might suggest, try removing all the files you see in the com/google/common directories, where "remove" assumes you have good version control to restore it if needed.   And instead fix any compilation errors by bringing in .jar files from Google for any libraries you need, starting with guava-19.0.jar.  You may try other versions instead.  Ideally you get everything to compile under 31.0.1 or something similarly recent, and you'll probably have (a) less code in your codebase, and (b) better code overall.  Or perhaps, by doing this, you'll discover why someone in your company felt the need to change the original Google code.
 
Jesse Silverman
Saloon Keeper
Posts: 1646
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm all good now.  I was somewhat shocked, believing that those were not local modifications, but that Google code did these things, which of course, it now turns out they didn't.

I wouldn't say I don't care why Brennan's co-workers did those things, it might be interesting to know, but it won't keep me up at night.

I too had difficulties in the past with employers deciding to download stuff from source, make questionable local modifications, and then keep using our locally-modified stuff until and unless shown that there were massive security problems in them.  Merely saying there were performance improvements or better API's wasn't enough to get the to pay for the "extra work" to re-apply possibly different local modifications to current versions.

The code as posted was seriously hard to read compared to like, 58 of the last 60 pieces of code I'd looked at.

I am starting to really appreciate the appropriate use of var now.
In C++ they are widely saying, if you have a (CastToSomethingReallyPrettyLongNowHuh) on the right side of an equals sign in an initialization, for heck's sake, just put auto as the type on the left side (that would be var for us).

I realize that var came to Java very recently.  Amazon on their coding challenges still limits you to Java 8...it can be abused, but if you avoid misuse/abuse it can REALLY be your friend in the right places.

Thanks!


 
Jesse Silverman
Saloon Keeper
Posts: 1646
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry to semi-hijack Brennan's thread after he's done with it, but on the other hand, I am fine with these kinds of things enforcing calling conventions:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Objects.html#requireNonNull(T)

That takes some space, preferably vertical, but is actually buying us something real.  NPE's suck.

Anyway, thanks all.
 
Campbell Ritchie
Marshal
Posts: 74376
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
'Ware tangent.

The requireNonNull() method is somthing many people wrote for themselves for years and years. Why did the Objects class not appear before Java7?
 
Mike Simmons
Master Rancher
Posts: 4062
56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Who knows?  I note that Java 7 was the first major release that came out after Oracle acquired Sun Microsystems.  I feel like under Sun, Java sometimes felt "stuck" for extended periods, partly from Sun's extreme aversion to any possible break in backward compatibility. That shouldn't have directly affected a new class like Objects.  But I would say that after Oracle's acquisition, it felt like Java was moving again, in a general sense.  Which really paid off in Java 8, with lambdas and streams.  But Java 7 was Oracle's first attempt to reassure developers that they were going to take good care of Java, so they put out whatever low-hanging fruit they could while saving really big stuff for the next release.  At least from my own very subjective viewpoint...
 
Campbell Ritchie
Marshal
Posts: 74376
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike Simmons wrote:. . . . after Oracle's acquisition, it felt like Java was moving again  . ..

I think you are right.
 
Jesse Silverman
Saloon Keeper
Posts: 1646
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I became distressed when I thought Google openly allowed completely unreadable code, perhaps because they just didn't care about Java, or who knows -- the code was just horrible to read.

Then Mike set me straight, the unreadability was largely added by the OP's co-workers, not anyone at Google.

For the record, since I tripped over it this evening almost at random (oof!), here is Google's coding standards for Java.

They aren't long, but definitely say several things I was horrified by in that code should never be done:
https://google.github.io/styleguide/javaguide.html

I didn't see anything in there I majorly disagreed with.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic