ADDITIONAL SYSTEM INFORMATION :
Generic / MacOS / Java 21

A DESCRIPTION OF THE PROBLEM :
**1. Insufficient test coverage**

Modern JUnit tests for edge cases of `MemoryUsage` (boundary values, very large values, undefined value combinations) are lacking. Existing tests use an older style (vmTestbase).

**2. Code style inconsistency**

Constant declarations in `ManagementFactory` have inconsistent spacing before `=`. Some have spaces, some don't, which is inconsistent with OpenJDK coding style.

### Steps to Reproduce

**Issue 1: Missing edge case tests**
```bash
# Check existing test coverage
find test -name "*MemoryUsage*" -type f
# Result: Only old-style vmTestbase tests exist
# Missing: Modern JUnit tests for edge cases
```

**Issue 2: Code style inconsistency**
```java
// In ManagementFactory.java
public static final String GARBAGE_COLLECTOR_MXBEAN_DOMAIN_TYPE = // Has space
    "java.lang:type=GarbageCollector";

public static final String MEMORY_MANAGER_MXBEAN_DOMAIN_TYPE= // No space ❌
    "java.lang:type=MemoryManager";

public static final String MEMORY_POOL_MXBEAN_DOMAIN_TYPE= // No space ❌
    "java.lang:type=MemoryPool";
```

### Expected Result

**Issue 1:**
- Comprehensive JUnit test suite covering all edge cases
- Tests for boundary values, large values, undefined combinations
- Modern test framework (JUnit 5) usage

**Issue 2:**
- Consistent spacing before `=` in all constant declarations
- Compliance with OpenJDK coding style guidelines
- `git jcheck` passes without warnings

### Actual Result

**Issue 1:**
- Only old-style vmTestbase tests exist
- Edge cases not covered by modern JUnit tests
- Test coverage gaps for boundary conditions

**Issue 2:**
- Inconsistent spacing in constant declarations
- `git jcheck` may flag style issues
- Code style not fully compliant with OpenJDK standards

### Proposed Solution

**1. Test coverage improvements**
- Add JUnit tests for `MemoryUsage` constructor edge cases
- Add `toString()` edge case tests (can run independently from Issue A)
- Use JUnit 5 standard

**2. Code style consistency**
- Add consistent spacing before `=` in `ManagementFactory` constant declarations
- Verify with `git jcheck`

**API Behavior Changes**: None. Only test and style improvements included.

### Included Change Items

- **#2**: Fix spacing consistency in ManagementFactory constant declarations
- **#3**: Add JUnit tests for MemoryUsage.toString() edge cases
- **#5**: Add validation tests for MemoryUsage constructor edge cases

### Test Case Code

**New test file: ConstructorValidationTest.java**
```java
/*
 * @test
 * @bug [ISSUE_NUMBER]
 * @summary Test MemoryUsage constructor with edge cases
 * @run junit ConstructorValidationTest
 */

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
import java.lang.management.MemoryUsage;

public class ConstructorValidationTest {
    @Test
    public void testConstructorWithMaxLongValues() {
        // Test with Long.MAX_VALUE to ensure no overflow
        MemoryUsage mu = new MemoryUsage(Long.MAX_VALUE, Long.MAX_VALUE,
                                         Long.MAX_VALUE, Long.MAX_VALUE);
        assertEquals(Long.MAX_VALUE, mu.getInit());
        assertEquals(Long.MAX_VALUE, mu.getUsed());
    }
    
    @Test
    public void testConstructorWithZeroValues() {
        MemoryUsage mu = new MemoryUsage(0, 0, 0, 0);
        assertEquals(0, mu.getUsed());
        assertEquals(0, mu.getCommitted());
        assertEquals(0, mu.getInit());
        assertEquals(0, mu.getMax());
    }
    
    @Test
    public void testConstructorWithUsedEqualsCommitted() {
        // Boundary case: used == committed should be valid
        MemoryUsage mu = new MemoryUsage(1024, 512, 512, 1024);
        assertEquals(512, mu.getUsed());
        assertEquals(512, mu.getCommitted());
    }
    
    @Test
    public void testConstructorWithCommittedEqualsMax() {
        // Boundary case: committed == max should be valid
        MemoryUsage mu = new MemoryUsage(1024, 256, 512, 512);
        assertEquals(512, mu.getCommitted());
        assertEquals(512, mu.getMax());
    }
    
    @Test
    public void testConstructorWithUndefinedValues() {
        MemoryUsage mu = new MemoryUsage(-1, 1024, 2048, -1);
        assertEquals(-1, mu.getInit());
        assertEquals(-1, mu.getMax());
    }
}
```

**Style fix example:**
```java
// Before (inconsistent)
public static final String MEMORY_MANAGER_MXBEAN_DOMAIN_TYPE=
    "java.lang:type=MemoryManager";

// After (consistent)
public static final String MEMORY_MANAGER_MXBEAN_DOMAIN_TYPE =
    "java.lang:type=MemoryManager";
```

### Test Strategy

**New Test Files**

1. `test/jdk/java/lang/management/MemoryUsage/ToStringTest.java`
   - Edge case tests for `toString()` method
   - Use JUnit 5

2. `test/jdk/java/lang/management/MemoryUsage/ConstructorValidationTest.java`
   - Boundary value tests for constructor
   - Test cases:
     - Long.MAX_VALUE
     - Zero values
     - `used == committed` (boundary case)
     - `committed == max` (boundary case)
     - Undefined value combinations

**Existing Tests**
- Existing tests remain unchanged
- New tests run independently from existing tests

**Style Verification**
- Run `git jcheck` to verify style compliance
- No new tests needed (formatting only)

**Test Execution**
```bash
make test TEST="jtreg:test/jdk/java/lang/management"
```

### Impact and Risk Assessment

- **Backward Compatibility**: No impact (only test and style changes)
- **Performance Impact**: None
- **Review Difficulty**: Very low. Only test additions and style fixes included

### First-Time Contributor Suitability

- Provides good learning opportunity for test writing
- Opportunity to understand code style conventions
- Very low risk
- Clear scope and expected outcomes
- From reviewer perspective: Test additions are always welcome

---

## Issue Separation Summary

| Issue | Included Items | Change Type | API Impact |
|-------|---------------|-------------|------------|
| **Issue A** | #1, #4, #6 | Behavior/Functionality Changes | Output format improvements (compatible) |
| **Issue B** | #2, #3, #5 | Quality/Maintenance | None |

Both issues can be worked on independently, and each can be resolved with a single PR. Issue A focuses on actual behavior improvements, while Issue B focuses on test and style improvements.

---

## Notes for Contributors

### Recommended Starting Point

**Issue A** is recommended as the starting point:
- Clear correctness issue
- Easy to understand and fix
- Good test coverage opportunity
- Demonstrates API understanding
- Provides immediate value

### Next Steps

1. **Create JBS issue**: Create an issue for the toString() fix
2. **Implement**: Implement fix to properly handle `-1` values
3. **Add tests**: Write JUnit tests covering all edge cases
4. **Run tests**: `make test TEST="jtreg:test/jdk/java/lang/management"`
5. **Submit PR**: Submit PR with clear description

### Why These Issues Are Suitable for First-Time Contributors

- ✅ **Clear focus**: Each issue addresses specific problems
- ✅ **Testable**: All changes can be verified with tests
- ✅ **Low risk**: Low probability of breaking existing functionality
- ✅ **Immediate value**: Improves correctness, code quality, and test coverage

---

## Additional Information for Bug Report Submission

### Reference Links

- **Oracle Java Bug Database**: https://bugreport.java.com/bugreport/
- **JDK Bug System (JBS)**: https://bugs.openjdk.org/
- **OpenJDK Contributing Guide**: https://openjdk.org/contribute/

### Notes for Submitters

1. **Before submitting**, please:
   - Check if a similar issue already exists in JBS
   - Verify the issue with the latest JDK build
   - Ensure test cases are reproducible

2. **When submitting via Oracle Java Bug Database**:
   - Use the "Enhancement" issue type for both issues
   - Select appropriate Component and Sub-component
   - Include all test case code in the "Test Case Code" section
   - Mark "Generic" for Operating System if applicable to all platforms

3. **For OpenJDK contributors**:
   - These issues can be worked on independently
   - Each issue should have its own PR
   - Follow OpenJDK coding conventions and test standards

### Related Documentation

- **MemoryUsage Javadoc**: https://docs.oracle.com/en/java/javase/21/docs/api/java.management/java/lang/management/MemoryUsage.html
- **OpenJDK Code Conventions**: https://openjdk.org/code-conventions/
- **OpenJDK Testing Guide**: `doc/testing.md` in the JDK repository