I have noticed that whenever Blocks code is generated to Java it generally imports and uses JavaUtil and Lists of raw type. This is a problem in java since Lists of raw type are discouraged, and throw runtime errors when misused. Here is some good discussion on raw types: https://stackoverflow.com/questions/2770321/what-is-a-raw-type-and-why-shouldnt-we-use-it
I think this is a current limitation of Blocks, and the Javascript back end. I’m not sure how easy it is for the developers to change the way java code is generated code, but it should be changed. Lists should have defined types and normal java syntax, instead of using JavaUtil functions. And if the goal is to go backward using the Java MyBlocks function, blocks should support Lists with defined types.
When creating the custom MyBlocks using Java code, trying to return a List Double> for instance will not allow the blocks to snap together. Yet to test this but it will probably throw a runtime error if I managed to plug the java block into a variable, and then that variable into a List block.
It seems to me the only way to provide Blocks and Java List compatibility is to use the JavaUtil and the type insecure List interface. Should I create a bug/feature-request for this on the FTCRobotController Github?
I will admit that I am not the resident Blocks expert here (@lizlooney is), but what is “bad” for one language is a “boon” for another. You are correct that in many languages a typeless anything is generally a bad idea - in general most languages benefit from a strong type-safe environment. However, Blocks was designed to remove the burden of most types on programmers - this is seen as generally a “good thing” for the level of programmer that Blocks is designed for. However, as you have pointed out, this requires languages that interface with Blocks to include a lot of overhead that generic use of the language would strongly recommend against. C’est la vie.
Can Blocks export type-safe Java code? I dunno, to me that might be a LOT of work with little benefit (in my mind if you want Java code, learn to create Java code, otherwise the java export is just for show). However, I will let @lizlooney provide any additional details or thoughts.
I have just discovered that Blocks doesn’t provide any compatibility with Lists of any type (from java code), which is disappointing considering my teams needs. Or at least the blocks aren’t plugging in together. Seems like the type insecure list change did not have any effect.
I’m the java programmer on the team, the rest of the coding team uses Blocks. One of our mentors suggested that we use blocks as a “Control flow diagram,” where we can visualize everything and the advanced stuff is in the background (Java). So mainly that is why we are using this feature.
There is also the advantage of being able to change code/configuration on the fly, instead of waiting for the java code to compile (it takes around 2.5 minutes to compile). For this we need all the important variables configured in the top level Blocks environment, which unfortunately includes some lists.
I understand now that typesafe code compatibility would be too much work for little benefit, but List compatibility seems to have a bit more benefit. I don’t know how many hybrid approach teams there are out there, but it seems like it would be beneficial.
For now (since this is obviously not a quick API change) we may have to hide more of the configuration lists, and/or have 20 variable blocks. The functions that return lists will probably have to be run internally.
You are absolutely correct that the current Blocks-to-Java code generator does not handle lists very well. Arrays in Javascript (which is what Blockly is based on) are very different than Lists in Java, so I added the JavaUtil class to make a bridge so that I could generate working (barely working? semi working?) Java code. You can certainly file a bug/feature-request for this. If you can provide specific blocks (a .blk file or a picture of the blocks) where the blocks aren’t plugging together, that would be helpful in the bug. I will look at doing improvements for next season.
In your case, where you are the java programmer and the rest of the team uses blocks, I think you will have to think of Lists as something that you have in Java, but is opaque to the javascript/blocks world. So, you can have a MyBlocks method that returns List but on the blocks side, they will have to assign that to a variable. Then when they want to do something with the list, such as get an element, you will have to provide another MyBlocks method that does that. The blocks programmers should be able to pass the variable to a MyBlocks method that expects a List.
The “length of” and “is empty” blocks from the Lists category will work correctly on Java arrays and Collections, but I’m not sure about whether you can plug a MyBlocks that returns a List (or Java array) into those blocks. You might have to use a variable.
I hope this helps. In general the purpose of showing the blocks-to-java generated code is to help Blocks users become familiar with what java code looks like. But, as you’ve noticed, sometimes the code that is generated is not the way a human Java programmer would do it.
Interesting. So Blocks can pass around variables and objects of unknown type?
In the case of my code it is a bunch of numbers (a configurable grid) passed into the java methods. I’m guessing that keeping that part of the front end will involve a lot of .add() operations instead of a single list. The alternate is hiding this altogether from blocks and just putting it in java.
I will try to work on creating the feature request when I have time, but I think this will be a valuable feature.