HI @saudet
Type: Feature Request / Usability Improvement
Summary
The TensorOptions class is the most frequently encountered class by new JavaCPP PyTorch users, but its current API design creates a steep learning curve and unnecessary friction for beginners. The mandatory use of *Optional wrapper types (e.g., DeviceOptional, ScalarTypeOptional) for all chained initialization methods makes simple tensor configuration verbose, confusing, and intimidating for new developers.
We request adding non-Optional overloads for all core TensorOptions methods (device(), dtype(), layout(), requires_grad(), etc.) to support clean, direct chained initialization without wrapper objects.
Problem Description
Current Pain Points for New Users
Overly verbose syntax for basic tensor configuration:
运行
// Current (intimidating for beginners)
TensorOptions options = new TensorOptions()
.device(new DeviceOptional(new Device(torch.kCPU())))
.dtype(new ScalarTypeOptional(torch.kFloat()))
.requires_grad(new BoolOptional(true));Unnecessary complexity: New users must learn and use Optional wrapper classes for trivial operations, which is not intuitive for standard Java development patterns.
Inconsistent experience: The underlying C++ PyTorch API supports direct non-optional values, but the Java binding forces wrapper usage.
High friction: This is the first major hurdle most Java newcomers face when learning PyTorch via JavaCPP.
Key Observation
The TensorOptions class already has constructors that accept non-Optional parameters, but the chained setter methods only accept *Optional types. This inconsistency is confusing for new developers.
Proposed Solution
Add overloaded methods for all core TensorOptions configuration methods that accept raw, non-Optional types (matching the pattern you provided):
device(Device device)
dtype(ScalarType dtype) / dtype(TypeMeta dtype)
layout(Layout layout)
requires_grad(boolean requires_grad)
pinned_memory(boolean pinned_memory)
memory_format(MemoryFormat memory_format)
Ideal Simplified Syntax
运行
// Proposed (clean, intuitive for Java beginners)
TensorOptions options = new TensorOptions()
.device(new Device(torch.kCPU()))
.dtype(torch.kFloat())
.requires_grad(true);Proposed Method Signatures (Reference)
Add these non-Optional overloads alongside the existing Optional ones:
运行
// Non-Optional overloads for TensorOptions
public native @ByVal @NoException(true) TensorOptions device(@ByVal Device device);
public native @ByVal @NoException(true) TensorOptions dtype(@ByVal TypeMeta dtype);
public native @ByVal @NoException(true) TensorOptions dtype(@ByVal ScalarType dtype);
public native @ByVal @NoException(true) TensorOptions layout(@ByVal Layout layout);
public native @ByVal @NoException(true) TensorOptions requires_grad(@ByVal boolean requires_grad);
public native @ByVal @NoException(true) TensorOptions pinned_memory(@ByVal boolean pinned_memory);
public native @ByVal @NoException(true) TensorOptions memory_format(@ByVal MemoryFormat memory_format);
Benefits
Dramatically lower the learning curve for Java newcomers to PyTorch
Align with standard Java fluent API patterns (no unexpected wrapper types)
Reduce boilerplate code for the most common tensor configuration use cases
Preserve backward compatibility: Existing Optional-based code will continue to work
Match C++ PyTorch usability while maintaining Java idioms
Additional Context
This change directly addresses the biggest pain point reported by new users of the JavaCPP PyTorch binding. TensorOptions is foundational for creating tensors, so simplifying its API will make the library far more accessible to the Java developer community.
HI @saudet
Type: Feature Request / Usability Improvement
Summary
The TensorOptions class is the most frequently encountered class by new JavaCPP PyTorch users, but its current API design creates a steep learning curve and unnecessary friction for beginners. The mandatory use of *Optional wrapper types (e.g., DeviceOptional, ScalarTypeOptional) for all chained initialization methods makes simple tensor configuration verbose, confusing, and intimidating for new developers.
We request adding non-Optional overloads for all core TensorOptions methods (device(), dtype(), layout(), requires_grad(), etc.) to support clean, direct chained initialization without wrapper objects.
Problem Description
Current Pain Points for New Users
Overly verbose syntax for basic tensor configuration:
Unnecessary complexity: New users must learn and use Optional wrapper classes for trivial operations, which is not intuitive for standard Java development patterns.
Inconsistent experience: The underlying C++ PyTorch API supports direct non-optional values, but the Java binding forces wrapper usage.
High friction: This is the first major hurdle most Java newcomers face when learning PyTorch via JavaCPP.
Key Observation
The TensorOptions class already has constructors that accept non-Optional parameters, but the chained setter methods only accept *Optional types. This inconsistency is confusing for new developers.
Proposed Solution
Add overloaded methods for all core TensorOptions configuration methods that accept raw, non-Optional types (matching the pattern you provided):
device(Device device)
dtype(ScalarType dtype) / dtype(TypeMeta dtype)
layout(Layout layout)
requires_grad(boolean requires_grad)
pinned_memory(boolean pinned_memory)
memory_format(MemoryFormat memory_format)
Ideal Simplified Syntax
Proposed Method Signatures (Reference)
Add these non-Optional overloads alongside the existing Optional ones:
Benefits
Dramatically lower the learning curve for Java newcomers to PyTorch
Align with standard Java fluent API patterns (no unexpected wrapper types)
Reduce boilerplate code for the most common tensor configuration use cases
Preserve backward compatibility: Existing Optional-based code will continue to work
Match C++ PyTorch usability while maintaining Java idioms
Additional Context
This change directly addresses the biggest pain point reported by new users of the JavaCPP PyTorch binding. TensorOptions is foundational for creating tensors, so simplifying its API will make the library far more accessible to the Java developer community.